The IESG has approved the following document: - 'Analysis of Multihoming in Network Mobility Support ' <draft-ietf-nemo-multihoming-issues-07.txt> as an Informational RFC This document is the product of the Network Mobility Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt Technical Summary This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. Working Group Summary This document has been relatively non-controversial in the WG. The document has been reviewed by many members of the working group; The document has gone through working group last call, with one comment raised and addressed. The WG seems to have a pretty good understanding of multihoming and how this document defines the issues related to it. Protocol Quality This specification has been reviewed by Jari Arkko for the IESG. A call for additional review from multihoming-related WGs in the IETF was made on the AD's request. This call did not result in any reviews. However, some members from the MONAMI6 WG and the SHIM6 have been involved involved in the NEMO work around this document. Note to RFC Editor Please change in Section 1: OLD: Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks such as vehicles typically require the use of several interfaces and technologies since the mobile network may be moving in distant geographical locations where different access technologies are provided and governed by distinct access control policies. NEW: Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks typically require the use of several interfaces and technologies. For example, this is particularly useful for ITS (Intelligent Transport Systems) applications since vehicles are moving across distant geographical locations. Access would be provided through different access technologies (e.g. Wimax, Wifi, 3G) and through different access operators. OLD: o multiple global prefixes are available in the mobile network.--> NEW: o multiple global prefixes are available in the mobile network. Please expand first occurrence of MNP to Mobile Network Prefix. Please add the following between the first and second sentences in the first paragraph of Section 2.1: "The MR and the AR are connected to the Internet via a single Access Router (AR)." Please change in Section 3.1: OLD: W-PAN NEW: wireless personal area network Please change in Section 4: OLD: [8] and [8] NEW: [8] Please add an informative reference to DHCPv6 (RFC 3315) in the last sentence of Section 2. Add this text to the end of Section 8 (Security Considerations): For instance, an attacker could try to use the multihomed device as a means to access another network that wouldn't be normally reachable through the Internet. Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to enable it. Please replace Section 4.10 contents with this: When a mobile network is multihomed, the MNNs would be able to benefit from this configuration, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly: o In the (*,*,n) configuration, the MNNs can influence the path by source address selection (see Section 4.1.3, Section 4.7). o In the (n,*,*) configuration, the MNNs can influence the path by default router selection (see Section 4.1.3). o In the (1,n,1) configuration, the MNNs cannot influence the path selection. One aspect of preference setting is that the preference of the MNN (eg. application or transport layer configuration) may not be the same as the preference used by a MR. Thus, forwarding choice made by the MR may not be the best one for a particular flow, and may even be detrimental to some transport control loops (such as the flow control algorithm for TCP may be messed up when MR unexpectedly performs load balancing on a TCP flow). A mechanism that allows the MNN to indicate its preference for a given traffic would be helpful here. Another aspect of preference setting is that the MNN may not even be aware of the existence of multiple forwarding paths, e.g. the (1,n,1) configuration. A mechanism for the MR to advertise the availability of multiple tunneling paths would allow the MNN to take advantage of this, coupled with the previously mentioned mechanism that allows the MNN to indicate its preference for a given traffic. This problem is general in the sense that any IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the MNNs may possess such capability. It is recommended that vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks. In addition, the Monami6 WG is currently developing a flow filtering solution for mobile nodes to indicate how flows should be forwarded by a filtering agent (such as home agent, mobility anchor points). It is recommended that the Monami6 WG considers the issues described here so that flow filtering can be performed by MNN to indicate how flows should be forwarded by the MR. Please change in Section 3.1: OLD: This is a (1,1,*) if both accesses are performed with the same ISP. If the two accesses are offered by independent ISPs, this is a (1,n,n) configuration. NEW: This is a (1,1,*) if both a single home agent is used for both. If two independent home agents are used, this is a (1,n,n) configuration. OLD: Alternatively, the train company might be forced to use different ISPs when the train crosses different countries, thus a (n,n,n) configuration. NEW: Alternatively, the train company might use different home agents, in different countries, thus a (n,n,n) configuration. OLD: This is a (n,n,n) configuration if the two access technologies are subscribed separately. NEW: This is a (n,n,n) configuration if different home agents are also used. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
