NEMO Working Group C. Ng Internet-Draft Panasonic Singapore Labs Expires:
January 10,April 25, 2005 E. Paik Seoul National UniversityKT T. Ernst WIDE at Keio University July 12,October 25, 2004 Analysis of Multihoming in Network Mobility Support draft-ietf-nemo-multihoming-issues-00draft-ietf-nemo-multihoming-issues-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, I certifyeach author represents that any applicable patent or other IPR claims of which I amhe or she is aware have been or will be disclosed, and any of which Ihe or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10,April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.Abstract This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 (1,1,1): Single MR, Single HA, Single NEMO-PrefixMNP . . . . . . . . 7 2.2 (1,1,n): Single MR, Single HA, Multiple NEMO-PrefixesMNPs . . . . . . . 7 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-PrefixMNP . . . . . . . 8 2.4 (1,n,n): Single MR, Multiple HAs, Multiple NEMO-Prefixes . . . . . . . . . . . . . . . . .MNPs . . . . . 8 2.5 (n,1,1): Multiple MRs, Single HA, Single NEMO-PrefixMNP . . . . . . . 9 2.6 (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes . . . . . . . . . . . . . . . . .MNPs . . . . . 9 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-PrefixMNP . . . . . 10 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes . . . . . .MNPs . . . . . . . . . . . . . . . . 1110 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 1718 4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19 4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 18 4.619 4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 18 4.719 4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 19 4.820 4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 19 4.920 4.10 Source Address Selection . . . . . . . . . . . . . . . . . 19 4.1020 4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 20 4.1121 4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 20 4.1221 4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 2021 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 2122 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2123 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 2223 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 2425 A. Alternative Classifications Approach . . . . . . . . . . . . . 2526 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 2526 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 2526 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 2627 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 2829 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 2930 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 2930 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 2930 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 3031 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 3031 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 3132 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 3233 Intellectual Property and Copyright Statements . . . . . . . . 3335 1. Introduction The goals and objectives of Network Mobility Support (NEMO) are identified in  while the terminology is being described in  and . NEMO Basic Support  is the solution proposed by the NEMO Working Group to provide continuous Internet connectivity to nodes located in a mobile network. This solutions basically solves the problem by setting up bi-directional tunnels between the mobile routers (MRs) connecting the mobile network to the Internet and their respective Home Agents (HAs), much how this is done in Mobile IPv6 , the solution for host mobility. NEMO Basic Support is transparent to nodes located behind the mobile router (i.e. the mobile network nodes, or MNNs) and as such doesn't require MNNs to take any action in the mobility management. We note that mobile networks are typically connected by means of wireless and thus less reliable links. In addition, there could be many nodes behind the MR, so a loss of connectivity or a failure to connect to the Internet has a more significant impact than for a single node. Real-life scenarios as illustrated in  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. The purpose of this memo is to investigate issues related to such a bi-directional tunneling mechanism when mobile networks are multihomed, i.e. when there is more than one point of attachment between the mobile network and the Internet. This arises either when a MR has multiple egress interfaces, or the mobile network has multiple MRs or is eitherassociated with multiple HAs, when it has multiple MRs,or when an MR hasmultiple egress interfacesprefixes are advertised down to the mobile network (see definitions in ). As specified by R.12 in section 5 of , the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed. Using NEMO Basic Support, this translates into having multiple bi-directional tunnels between the mobile network and its HA(s), and may result into multiple NEMO-PrefixesMNPs being advertised to the MNNs. However, NEMO Basic Support does not specify any particular mechanism to manage multiple bi-directional tunnels. The objective of this memo is thus three-folds: o to capture issues for deploying a multihomed mobile network, o to identify which multihoming configurations are useful, o to identify issues that may prevent useful multihomed configurations to be supported under the operation of NEMO Basic Support. It doesn't mean that those not supported will not work with NEMO Basic Support, just that it is up to the implementors to make it work (hopefully issues discussed in this memo will be helpful to these implementors). For doing so, a taxonomy to classify the possible multihomed configurations is described in Section 2. Deployment scenarios, their benefits, and requirements to meet these benefits are illustrated in Section 3. Following this, we study the general issues in Section 4, and we conclude with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e. with the NEMO terminology as defined in  (section 3) and , Goals and Benefits of Multihoming , Goals and Requirements of Network Mobility Support , and the NEMO Basic Support specification . The readers are reminded when describing the issues, we implicitly have an IPv6 environment in mind (as NEMO Basic Support  is for IPv6), though some of the issues are independent of IP version. Note that goals and benefits for multihoming as discussed in  is applicable to fixed nodes, mobile nodes, fixed networks and mobile networks, so we won't re-state the motivations in the present memo. 2. Classification Various discussions on the topic of multihoming issues in NEMO have been carried out on the mailing list and at IETF meetings. As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. Three approaches have been proposed on the NEMO mailing list. These are, namely, (i) the Configuration-Oriented Approach, (ii) the Ownership-Oriented Approach, and (iii) the Problem-Oriented Approach. As the WG consensus seems to have converged to the Configuration-Oriented Approach, we only describe this approach here. The other two approaches are outlined in Appendix A.1 and Appendix A.2. The Configuration-Oriented ApproachMultihomed configurations can be classified depending on how many mobile routers are present, how many egress interfaces, Care-of Address (CoA) and Home Addresses (HoA) the mobile routers have, how many prefixes (NEMO-prefixes)(MNPs) are advertised to the mobile network nodes, etc. For doing so, we use three key parameters differentiating different multihomed configurations. With these parameters, we can refer to each configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows: o 'x' indicates the number of MRs where: x=1 implies a mobile network has only a single MR, presumably multihomed. x=N implies a mobile network has more than one MR. o 'y' indicates the number of HAs associated with the entire mobile network, where: y=1 implies that a single HA is assigned to the mobile network. y=N implies that multiple HAs (possibly in different administrative domains) are assigned to the mobile network. o 'z' indicates the number of NEMO-prefixesMNPs announced to MNNs, where: z=1 implies that a single NEMO-prefixMNP is advertised to the MNNs. z=N implies that multiple NEMO-prefixesMNPs are advertised to the MNNs. It can be seen that the above three parameters are fairly orthogonal to one another. Thus different values of 'x', 'y' and 'z' give rise to different combinations of the 3-tuple (x,y,z). As described in the sub-sections below, a total of 8 possible configurations can be identified. One thing the reader has to keep in mind is that in each of the following 8 cases, the MR may be multihomed if either (i) multiple prefixes are advertised on the home link, (ii) multiple prefixes are advertised on the visited link, or (iii) the MR is equipped with multiple interfaces. In such a case, the MR would have a combination of Home Address / Care-of Address pairs. Issues pertaining to a multihomed MR are also addressed in the companion document . A simplified analysis of multihoming configuration in NEMO Basic Support using the same classification can be found in . 2.1 (1,1,1): Single MR, Single HA, Single NEMO-PrefixMNP The (1,1,1) mobile network has only one MR advertising a single NEMO-prefix.MNP. In addition, the MR is associated with only one HA at any one time. A bi-directional tunnel may be established between each pair of Home Address / Care-of address if the MR is itself multihomed. The MR may be multihomed and MNNs are (usually) not multihomed since they would configure a single address on the single NEMO-prefixMNP announced on the link they are attached to. _____ _ p _ | | |_|-|<-_ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA Figure 1: (1,1,1): 1 MR, 1 HA, 1 NEMO-prefixMNP 2.2 (1,1,n): Single MR, Single HA, Multiple NEMO-PrefixesMNPs The (1,1,n) mobile network has only one MR, which is associated to only one HA at any one time. However, two or more NEMO-prefixesMNPs are advertised to the mobile network nodes. The MR may be itself multihomed, and MNNs are multihomed if several NEMO-PrefixesMNPs are advertised on the link they are attached to. If that conditions holds, MNNs would configure an address with each NEMO-prefixMNP announced on the link. _____ _ p1,p2 _ | | |_|-|<-_ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA Figure 2: (1,1,n): 1 MR, 1 HA, multiple NEMO-prefixesMNPs 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-PrefixMNP The (1,n,1) mobile network has only one MR advertising a single NEMO-prefix.MNP. The MR, however, is associated to multiple HAs, possibly one HA per Home Address, or one HA per egress interface. No assumption is made on whether or not the HAs belongs to the same administrative domain (it may be justified to locate HAs in distinct ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical Prefix from a Different Origin] )The MR may be multihomed whereas MNNs are (usually) not multihomed since they would configure a single address on the single NEMO-prefixMNP announced on the link they are attached to. AR HA2 _ | |-|_|-| _ _____ | |-|_| _ p _ | |-| |_|-|<-_ |-|_|-| | _ |-|_|=| |_____|-| _ |_|-| | | _ |-|_| |-|_|-| | MNNs MR AR Internet AR HA1 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 NEMO-prefixMNP 2.4 (1,n,n): Single MR, Multiple HAs, Multiple NEMO-PrefixesMNPs The (1,n,n) mobile network has only one MR. However, the MR is associated with multiple HAs, possibly one per Home Address (or one HA per egress interface), and the MR advertises more than one NEMO-prefixMNP on its ingress interfaces. No assumption is made on whether or not the HAs belongs to the same administrative domain. The MR may be multihomed, and the MNNs are generally multihomed since they would configure an address on each NEMO-prefixMNP announced on the link they are attached to. AR HA2 _ | _ _____ |-|_|-|-|_| _ p1,p2 _ | |-| | |_|-|<-_ |-|_|-| | _ _ |-|_|=| |_____|-| _ |-|_| |_|-| | |-|_|-| | | MNNs MR AR Internet AR HA1 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple NEMO-prefixesMNPs 2.5 (n,1,1): Multiple MRs, Single HA, Single NEMO-PrefixMNP The (n,1,1) mobile network has more than one MR advertising global routes. These MRs, however, advertise the same NEMO-prefixMNP and are associated with the same HA. Each MR may be itself multihomed, whereas MNNs are (usually) not multihomed since they would configure a single address on the single NEMO-prefixMNP announced on the link they are attached to. MR2 p<-_ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| p<- | | MNNs MR1 Internet AR HA Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 NEMO-prefixMNP 2.6 (n,1,n): Multiple MRs, Single HA, Multiple NEMO-PrefixesMNPs The (n,1,n) mobile network has more than one MR advertising different global routes and different NEMO-prefixes.MNPs. However, these MRs are associated to the same HA. Each MR may be itself multihomed, and MNNs are generally multihomed since they would configure an address on each NEMO-prefixMNP announced on the link they are attached to. MR2 p2<-_ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| p1<- | | MNNs MR1 Internet AR HA Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple NEMO-prefixesMNPs 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-PrefixMNP The (n,n,1) mobile network has more than one MR advertising different global routes. The mobile network is associated with multiple HAs at any one time. No assumptions are made on whether or not the HAs belongs to the same administrative domain. However, the MRs advertises the same NEMO-prefix.MNP. Each MR may be itself multihomed whereas MNNs are (usually) not multihomed since they would configure a single address on the single NEMO-prefixMNP announced on the link they are attached to. MR2 AR HA2 p _ | <-_ | |-|_|-| _ _ |-|_|-| _____ | |-|_| |_|-| |-| |-| _ | | | |_|-| _ |-|_____|-| _ |-|_|-| | _ |-|_| <- | |-|_|-| p | MNNs MR1 Internet AR HA1 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 NEMO-prefixMNP 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple NEMO-PrefixesMNPs The (n,n,n) mobile network has multiple MRs advertising different global routes and different NEMO-prefixes.MNPs. The mobile network is associated with more than one HA at any one time. No assumptions is made on whether or not the HA belongs to the same administrative domain. Each MR may be itself multihomed and MNNs are generally multihomed since they would configure an address on each NEMO-prefixMNP announced on the link they are attached to MR2 AR HA2 p2 _ | <-_ | |-|_|-| _ _ |-|_|-| _____ | |-|_| |_|-| |-| |-| _ | | | |_|-| _ |-|_____|-| _ |-|_|-| | _ |-|_| <- | |-|_|-| p1 | MNNs MR1 Internet AR HA1 Figure 8: (n,n,n): Multiple MRs, HAs, and NEMO-prefixesMNPs 3. Deployment Scenarios and Prerequisites The following generic goals and benefits of multihoming are discussed in a companion document : 1. Permanent and Ubiquitous Access 2. Redundancy/Fault-Recovery 3. Load Sharing 4. Load Balancing 5. Preference Settings These benefits are now illustrated from a NEMO perspective with a typical instance scenario for each case in the taxonomy. We then discuss the prerequisites to fulfill these. 3.1 Deployment Scenarios x=1: Multihomed mobile network with a single MR o Example: an MR with dual/multiple access interfaces (e.g. 802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both accesses are subscribed to the same ISP. If the two accesses are offered by independent ISPs, this is a S/mP-(1,n,n) [for the meaning of this abbreviation, see Appendix A.1]. Benefits: Ubiquity, Redundancy/Fault-RecoveryRedundancy/Fault-Recovery, Load Sharing, Preference Settings x=N: Multihomed mobile networks with multiple MRs o Example 1: a train with one MR in each car, all served by the same HA, thus a (n,1,*). Alternatively, the train company might be forced to use different ISP when the train go to different locations, thus it is a (n,n,n). Benefits: Load SharingSharing, Redundancy/Fault-Recovery, Ubiquity o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled PDA. This is a S/mP-(n,n,n) if the two access technologies are subscribed separately. Benefits: Ubiquity, Redundancy/Fault-RecoveryRedundancy/Fault-Recovery, Preference Settings y=1: Multihomed mobile networks with a single HA o Most single ISP cases in above examples. y=N: Multihomed mobile networks with multiple HAs o Most multiple ISP cases in above examples. o Example: a transatlantic flight with a HA in each continent. This is a (1,n,1) network if there is only one MR. Benefits: Ubiquity (reduced delay, shortest path) z=1: Multihomed mobile networks with a single NEMO-prefixMNP o Most single ISP cases in above examples. z=N: Multihomed mobile networks with multiple NEMO-prefixesMNPs o Most multiple ISP cases in above examples. o Example: a car with a prefix taken from home (personal traffic transit on this prefix and is paid by the owner) and one that belongs to the car manufacturer (maintenance traffic is paid by the car-manufacturer). This will typically be a (1,1,n). Benefits: preference settings 3.2 Prerequisites In this section, we try to define the requirements in order to fulfill the expected multihoming benefits as detailed in . At least one bi-directional tunnel must be available at any point in time between the mobile network and the fixed network to meet all expectations. But for most goals to be effective, multiple tunnels must be maintained simultaneously: o Permanent and Ubiquitous Access: At least one bi-directional tunnel must be available at any point in time. o Redundancy and Fault-Recovery: Both the inbound and outbound traffic must be transmitted or diverted over another bi-directional tunnel once a bi-directional tunnel is broken or disrupted. o Load Sharing and Load Balancing: Multiple tunnels must be maintained simultaneously. o Preference Settings: A mechanismImplicitly, multiple tunnels must be provided to the user or the application to decidemaintained simultaneously if preferences are set for deciding which of the available bi-directional tunneltunnels should be used. A mechanism must be provided to the user/application about the availability of multiple bi-direction tunnels, and perhaps also to set the preference. The preference may reside in the mobile router or mobile network nodes (using  for instance). 4. Problem Statement In order to reach the multihoming benefits, multiple tunnels may be maintained simultaneously (e.g. load balancing, load sharing) or not (e.g. redundancy) between the mobile network and the fixed network. In some cases, it may be necessary to divert packets from a (perhaps failed) bi-directional tunnel to an alternative (perhaps newly established) bi-directional tunnel (i.e. for matters of fault recovery, preferences), or to split traffic between multiple tunnel (load sharing, load balancing). For doing so, the issues discussed below must be addressed, preferably dynamically. For each issue, we also investigate potential ways to solve the problem. 4.1 Path Survival Internet connectivity is guaranteed for all MNNs as long as at least one bi-directional tunnel is maintained between the mobile network and the fixed Internet. When an alternative tunnel must be found to substitute for the failed one, the loss of one tunnel to the Internet may result in broken sessions. In this case, new transport sessions will have to be established over the alternate tunnel if no mechanism is provided to make this change transparent at layers above layer 3. In the (1,1,1) case specifically, packets are always transmitted to/ fromto/from the same MR's ingress interface, i.e. independently of MR's links connectivity status. The tunnel can be changed transparently to the MNNs if mechanisms such as those studied in  are brought to the MR. 4.2 Path Selection When multiple bi-directional tunnels are available and possibly used simultaneously, the mode of operation may be either primary-secondary (one tunnel is precedent over the others and used as the default tunnel, while the other serves as a back-up) or peer-to-peer (no tunnel has precedence over one another, they are used with the same priority). This questions which bi-directional tunnel would be selected, and based on which parameter (e.g. type of flow that goes into/out of the mobile network). A dynamic path selection mechanism is thus needed so that this path could be selected by: o The HA: it should be able to select the path based on some information recorded in the binding cache. o The MR: it should be able to select the path based on router advertisements received on both its egress interfaces or on its ingress interfaces for the (n,*,*) case. o The MNN: it should be able to select the path based on "Default Router Selection" (see [Section 6.3.6. Default Router Selection] ) in the (n,*,*) case or based on "Source Address Selection" in the (*,*,n) cases (see Section 4.94.10 of the present memo). o The user or the application: e.g. in case where a user wants to select a particular access technology among the available technologies for reasons of cost or data rate. o A combination of any of the above: a hybrid mechanism should be also available, e.g. one in which the HA, the MR, and/or the MNNs are coordinated to select the path. 4.3 Ingress Filtering Ingress filtering mechanisms may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs. This could occur whenif different NEMO-prefixesMNPs are handled by different HAs such ashome agents. If packet with a source address configured from a specific MNP is tunnelled to a home agent that does not handle that specific MNP, the onepacket may be discarded due to ingress filtering (either by the home agent or by a border gateway in the home network). As an example of how this could happen, consider the deployment scenario illustrated in Figure 9. In Figure 9, the mobile network has two mobile routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two bi-directional tunnels are established are established between the two pairs. Each mobile router advertises a different NEMO-prefixMNP (P1 and P2). NEMO-prefixMNP P1 is registered to HA1, and NEMO-prefixMNP P2 is registered to HA2. Thus, MNNs should be free to auto-configure their addresses on any of P1 or P2. Ingress filtering could thus happen in two cases: o If the two tunnels are available, MNN cannot forward packet with source address equals P1.MNN to MR2. This would cause ingress filtering at HA2 to occur (or even at MR2). This is contrary to normal Neighbor Discovery  practice that an IPv6 node is free to choose any router as its default router regardless of the prefix it chooses to use. A simple solution is to require all MNNs to set their default router to the MR that advertises the NEMO-prefixMNP the MNNs configured their addresses from. If such requirement is not placed on mobile network nodes, then a multihoming solution for mobile networks must address this problem. For a possible approach, see . However, this is not enough to maintain connectivity if a tunnel fails (see Section 4.1 for a discussion of this issue). o If the tunnel to HA1 is broken, packets would be sent through the tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or some border gateway in the domain of HA2) performs ingress filtering, packets with source address configured from NEMO-PrefixMNP P1 may be discarded. It should be noted that this problem may be faced by any (*,n,n) mobile network, even if MR1 and MR2 are in fact the same entity in Figure 9. To avoid ingress filtering mechanisms dropping packets in such situations, MR(s) can stop advertising P1. This would prevent MNNs from using the address auto-configured on this prefix. However, such a method suffers from the following two limitations: o Switching addresses is time consuming since nodes have to wait for addresses to get deprecated .. o Switching addresses force transport sessions without multihoming capabilities (such as TCP) to terminate, and be re-established using the alternative source address. Transport sessions with multihoming capabilities (such as SCTP) may be able to continue without disruption (see also Section 4.1) Although one way to avoid the long wait for address deprecation by sending a router advertisement with zero Lifetime, the termination/disruption of transport sessions may render this solution unattractive. It is possible to overcome these limitations by using nested tunnels. Appendix B describes one such approach. Prefix: P1 +-----+ +----+ +----------+ +-----+ +--| MR1 |--| AR |--| |---| HA1 | | +-----+ +----+ | | +-----+ IP: +-----+ | | | Prefix: P1 P1.MNN or | MNN |--+ | Internet | P2.MNN +-----+ | | | Prefix: P2 | +-----+ +----+ | | +-----+ +--| MR2 |--| AR |--| |---| HA2 | Prefix: P2 +-----+ +----+ +----------+ +-----+ Figure 9: An (n,n,n) mobile network 4.4 Failure Detection It is expected for faults to occur more readily at the edge of the network (i.e. the mobile nodes), due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in timely fashion. In order for fault recovery to work, the MRs and HAs must first possess a means to detect failures: o On the MR's side, the MR can also rely on router advertisements from access routers, or other layer-2 trigger mechanisms to detect faults (e.g. faults, e.g.  or ) .. (For a related issue, see Section 4.5.) o On the HA's side, it is more difficult for HAs to detect tunnel failures. For an ISP deployment model, the HAs and MRs can use proprietary methods (such as constant transmission of heartbeat signals) to detect failures and check tunnel liveness. In the S/P model (see Appendix A.2), a lack of standardized "tunnel liveness" protocol means that it is harder to detect failures. A possible method is for the MRs to send binding updates more regularly with shorter Lifetime values. Similarly, HAs can return binding acknowledgment messages with smaller Lifetime values, thus forcing the MRs to send binding updates more frequently. These binding updates can be used to emulate "tunnel heartbeats". This however may lead to more traffic and processing overhead, since binding updates sentbinding updates sent to HAs must be protected (and possibly encrypted) with security associations. There are other failure modes to consider as well, such as failure at home agent, failure at access routers, or in general failure of a link or node along the path from the mobile router to the home agent. By the nature of the routing infrastructure, failure of intermediate nodes or links are recovered by the the routing infrastructure by choosing a different route. For those failures that can't be receovered (such a failure of the access router), a heartbeadt protocol or the use of small-lifetime binding updates described above can also be used to detect tunnel failures. 4.5 Media Detection In order to achieve benefits such as ubiquity or fault recovery, it is necessary for mobile router to detect the availability of network media. This may be achieved using layer 2 triggers , or other mechanism developed/recommended by the Detecting Network Attachment (DNA) Working Group. This is related to Section 4.4, since the ability to HAs must be protected (and possibly encrypted) with security associations. 4.5detect media availability would often implies the ability to detect media in-availability. 4.6 HA Synchronization In the (*,n,1) mobile networks, a single NEMO-prefixMNP would be registered at different HAs. This gives rise to the following issues: o Only one HA may actively advertise a route to the NEMO-prefix.MNP. o Multiple HAs at different domains may advertise a route to the same NEMO-prefixMNP This may pose a problem in the routing infrastructure as a whole. The implications of this aspect needs further exploration. Certain level of HA co-ordination may be required. A possible approach is to adopt a HA synchronization mechanism such as that described in  and .. Such synchronization might also be necessary in a (*,n,*) mobile network, when a MR sends binding update messages to only one HA (instead of all HAs). In such cases, the binding update information might have to be synchronized betweeen HAs. The mode of synchoronization may be either primary-secondary or peer-to-peer. See also Section 4.6. 4.64.7. 4.7 MR Synchronization In the (n,*,*) mobile network, different MRs may need to be synchronized in order to take common decisions. The mode of synchoronization may be either primary-secondary or peer-to-peer. This may include: o In the (n,*,1) case, advertising the same NEMO-PrefixMNP (see also "prefix delegation" in Section 4.7).4.8). o In the (n,*,n) case, a MR relaying the advertisement of the NEMO-PrefixMNP from another failed MR. o In the (n,*,*) cases, relaying between MRs everything that needs to be relayed, such as data packets, creating a tunnel from the ingress interface, etc. 4.74.8 Prefix Delegation In the (*,*,1) mobile network, the same NEMO-prefixMNP must be advertised to the MNNs through different paths. This questions how to perform prefix delegation: o For the (*,n,1) mobile network, how multiple HAs would delegate the same NEMO-prefixMNP to the mobile network. For doing so, the HAs may be somehow configured to advertise the same NEMO-prefix.MNP. (see also "HA Synchronization" in Section 4.5).4.6). o For the (n,*,n) mobile network, how multiple mobile routers would be synchronized to advertise the same NEMO-PrefixMNP down the NEMO-link. For doing so, the MRs may be somehow configured to advertise the same NEMO-prefixMNP (see also "MR Synchronization" in Section 4.6).4.7). This could be configured manually, or dynamically. Alternatively, prefix delegation mechanisms  could be used to ensure all routers advertise the same NEMO-prefix. 4.8MNP. 4.9 Multiple Bindings/Registrations When a MR is configured with multiple Care-of Addresses, it is often necessary for it to bind these Care-of Addresses to the same NEMO-Prefix.MNP. This is a generic issue, since Mobile IPv6 nodes face a similar problem if they wish to bind multiple Care-of Addresses to the same Home Address". This is better discussed in . It is sufficient to note that solutions like  can solve this. 4.94.10 Source Address Selection In the (*,*,n) mobile networks, MNNs would be configured with multiple addresses. Source address selection mechanisms are needed to decide which address to choose from. It may be desirable for MNN to be able to acquire "preference" information on each NEMO-prefixMNP from the MRs. This allows default address selection mechanism such as that specified in  to be used. Further exploration on setting such "preference" information in Router Advertisement based on performance of the bi-directional tunnel might prove to be useful. 4.104.11 Impact on the Routing Infrastructure In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple routes directed to the mobile network may be advertised in the Internet. ThisAlthough this may provide shorter paths, but this would add ait also adds burden into routing tables as multiple routes to the route would be published insame prefix are injected into the Internet Router Registry for multiple ASs.routing infrastructure. Such issues are investigated in the MULTI6 working group at the IETF. 4.114.12 Nested Mobile Networks When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached two different root-MRs, thus the aggregated network no longer forms a simple tree structure. As such, a solution to prevent an infinite loop must be provided. 4.124.13 Split Mobile Networks When a (n,*,1) network splits, (i.e. the two MRs split themselves up), the only available NEMO-prefixMNP will then be registered by two different MRs on different links. This cannot be allowed, as the HA has no way to know which node with an address configured from that NEMO-prefixMNP is attached to which MR. Some mechanism must be present for the NEMO-prefixMNP to either be forcibly removed from one (or all) MRs, or the implementors must not allow a (n,*,1) network to split. A possible approach to solving this problem is described in .. 5. Conclusion This document is an analysis of multihoming in the context of network mobility. The purpose of this memo is to investigate issues related to such a bi-directional tunneling mechanism when mobile networks are multihomed. Several issues that might impact the deployment of NEMO with multihoming capabilities were identified in Section 4. They include: 1. Path Survival 2. Path Availability 3. Ingress Filtering 4. Failure Detection 5. Media Detection 6. HA Synchronization 6.7. MR Synchronization 7.8. Prefix Delegation 8.9. Multiple Binding/Registrations 9.10. Source Address Selection 10.11. Imapct on the Routing Infrastructure 11.12. Nested Mobile Networks 12.13. Split Mobile Networks. This study is a work in progress and need to be improved by a thorough study of each individual issues. Particularly, this memo should be completed by a thorough threat analysis of multihoming configurations of mobile network. We will add security threat issues here as and when they are encountered, such as those described in .. We also encourage interested people to contribute to this part. 6. Acknowledgments The authors would like to thank people who have given valuable comments on various multihoming issues on the mailing list, and also those who have suggested directions in the 56th - 59th60th IETF Meetings. Sincere gratitude is also extended to Marcelo Bagnulo Braun for his extensive review and comments on the -00 version of this draft. The initial evaluation of NEMO Basic Support is a contribution from Julien Charbon. 7 References  Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02draft-ietf-nemo-requirements-03 (work in progress), FebruaryOctober 2004.  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01draft-ietf-nemo-terminology-02 (work in progress), FebruaryOctober 2004.  Devarapalli, V., "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004.  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Ernst, T., Montavont, N., Wakikawa, R. and E-K. Paik, "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00draft-ernst-generic-goals-and-benefits-00 (work in progress), FebruaryJuly 2004.  Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of Multihoming in Mobile IPv6", draft-montavont-mobileip-multihoming-pb-statement-01 (work in progress), Feb 2004.  Ernst, T. and J. Charbon, "Multihoming with NEMO Basic Support", Proceedings First International Conference on Mobile Computing and Ubiquitous Networking (ICMU), January 2004.  Savola, P., "Examining Site Multi-homing in Finnish Networks", Master's Thesis. , AprilDraves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.  Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for Multiple Interfaces", draft-montavont-mobileip-mmi-00draft-montavont-mobileip-mmi-02 (work in progress), July 2002.October 2003.  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", draft-ietf-ipv6-router-selection-04draft-ietf-ipv6-router-selection-06 (work in progress), JuneOctober 2004.  Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. Yegin, A., "Link-layer Hints for Detecting Network Attachments", draft-yegin-dna-l2-hints-01 (work in progress), February 2004.  Yegin, A., "Supporting Optimized Handover for IP Mobility -Requirements for Underlying Systems", draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.  Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004.  Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July 2004.  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.  Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 2004.  Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-02draft-wakikawa-mobileip-multiplecoa-03 (work in progress), September 2003. July 2004.  Kumazawa, M., Watanabe, Y., Matsumoto, T. and S. Narayana,"Token based Duplicate Network Detection for split mobile network (Token based DND)", draft-kumazawa-nemo-tbdnd-00draft-kumazawa-nemo-tbdnd-01 (work in progress), JulyOctober 2004.  Choi, S., "Threat for Multi-homed Mobile Networks", draft-cho-nemo-threat-multihoming-00 (work in progress), February 2004. Authors' Addresses Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 EMail: email@example.com Paik,Eun Kyoung Seoul National University Multimedia and Mobile communicationsPaik KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744137-792 Korea Phone: +82-2-880-1832+82-2-526-5233 Fax: +82-2-872-2045+82-2-526-5200 EMail: firstname.lastname@example.org@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ ErnstThierry Ernst WIDE at Keio University Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 EMail: email@example.com URI: http://www.sfc.wide.ad.jp/~ernst/ Appendix A. Alternative Classifications Approach A.1 Ownership-Oriented Approach An alternative approach to classifying multihomed mobile network is proposed by EricErik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'. A.1.1 ISP Model The case of the HA(s) and MR(s) are controlled by the same entity can be best illustrated as an Internet Service Provider (ISP) installing mobile routers on trains, ships or planes. It is up to the ISP to deploy a certain configuration of mobile network; all 8 configurations as described in the Configuration-Oriented Approach are possible. In the remaining portion of this document, when specifically referring to a mobile network configuration that is controlled by a single entity, we will add an 'ISP' prefix: for example: ISP-(1,1,1) or ISP-(1,N,N). When the HA(s) and MR(s) are controlled by a single entity (such as an ISP), the ISP can decide whether it wants to assign one or multiple NEMO-prefixesMNPs to the mobile network just like it can make the same decision for any other link in its network (wired or otherwise). In any case, the ISP will make the routing between the mobile networks and its core routers (such as the HAs) work. This include not introducing any aggregation between the HAs which will filter out routing announcements for the NEMO-prefix(es).MNP(es). To such ends, the ISP has various means and mechanisms. For one, the ISP can run its Interior Gateway Protocol (IGP) over bi-directional tunnels between the MR(s) and HA(s). Alternatively, static routes may be used with the tunnels. When static routes are used, a mechanism to test "tunnel liveness" might be necessary to avoid maintaining stale routes. Such "tunnel liveness" may be tested by sending heartbeats signals from MR(s) to the HA(s). A possibility is to simulate heartbeats using Binding Updates messages by controlling the "Lifetime" field of the Binding Acknowledgment message to force the MR to send Binding Update messages at regular interval. However, a more appropriate tool might be the Binding Refresh Request message, though conformance to the Binding Refresh Request message may be less strictly enforced in implementations since it serves a somewhat secondary role when compared to Binding Update messages. A.1.2 Subscriber/Provider Model The case of the HA(s) and MR(s) are controlled by the separate entities can be best illustrated with a subscriber/provider model, where the MRs belongs to a single subscriber and subscribes to one or more ISPs for HA services. There is two sub-categories in this case: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the remaining portion of this document, when specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to only one ISP, we will add an 'S/P' prefix: for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to multiple ISPs, we will add an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). Not all 8 configurations are likely to be deployed for the S/P and S/ mPS/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) mobile network where there is only a single HA. For the S/P model, the following configurations are likely to be deployed: o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single NEMO-PrefixMNP o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple NEMO-PrefixesMNPs o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single NEMO-PrefixMNP o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple NEMO-PrefixesMNPs o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single NEMO-PrefixMNP o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple NEMO-PrefixesMNPs o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single NEMO-PrefixMNP o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple NEMO-PrefixesMNPs For the S/mP model, the following configurations are likely to be deployed: o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single NEMO-PrefixMNP o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, Multiple NEMO-PrefixesMNPs o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, Multiple NEMO-PrefixesMNPs When the HA(s) and MR(s) are controlled by different entities, it is more likely the scenario where the MR is controlled by one entity (i.e. the subscriber), and the MR is establishing multiple bi-directional tunnels to one or more HA(s) provided by one or more ISP(s). In such case, it is unlikely for the ISP to run IGP over the bi-directional tunnel, since ISP would most certainly wish to retain full control of its routing domain. A.2 Problem-Oriented Approach A third approach is proposed by Pascal Thubert (Cisco System). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of NEMO-prefixesMNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are: o Tarzan: Single HA for Different Care-of Addresses of Same NEMO-PrefixMNP This is the case where one mobile router registers different Care-of Addresses to the same home agent for the same subnet prefix. This is equivalent to the case of y=1, i.e. the (1,1,n) mobile network. o JetSet: Multiple HAs for Different Care-of Addresses of Same NEMO-PrefixMNP This is the case where the mobile router registers different Care-of Addresses to different home agents for the same subnet prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) mobile network. o Shinkansen: Single NEMO-PrefixMNP Advertised by MR(s) This is the case where one NEMO-prefixMNP is announced by different MRs. This is equivalent to the case of z=n, i.e. the (1,*,n) mobile network. o DoubleBed: Multiple NEMO-PrefixesMNPs Advertised by MR(s) This is the case where more than one NEMO-prefixesMNPs are announced by the different MRs. This is equivalent to the case of z=n, i.e. the (n,*,n) mobile network. Appendix B. Nested Tunneling for Fault Tolerance In order to utilize the additional robustness provided by multihoming, MRs that employ bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if a MR detects that one of its egress interface is down, it should detect if any other alternate route to the global Internet exists. This alternate route may be provided by any other MRs connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the MR itself possess. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route. In the remaining part of this section, we will attempt to investigate methods of performing such re-establishment of bi-directional tunnels. It is not the objective of this memo to specify a new protocol specifically tailored to provide this form of re- establishments. Instead, we will limit ourselves to currently available mechanisms specified in Mobile IPv6  and Neighbor Discovery in IPv6 . B.1 Detecting Presence of Alternate Routes To actively utilize the robustness provided by multihoming, a MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility. The case where a MR possesses multiple egress interface (bound to the same HA or otherwise) should be trivial, since the MR should be able to "realize" it has multiple routes to the global Internet. In the case where multiple MRs are on the mobile network, each MR has to detect the presence of other MR. A MR can do so by listening for Router Advertisement message on its *ingress* interfaces. When a MR receives a Router Advertisement message with a non-zero Router Lifetime field from one of its ingress interfaces, it knows that another MR which can provide an alternate route to the global Internet is present in the mobile network. B.2 Re-Establishment of Bi-Directional Tunnels When a MR detects that the link beby which its current bi-directional tunnel with its HA is using is down, it needs to re-establish the bi-directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the MR; secondly, the alternate route is provided by another MR connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate MR. B.2.1 Using Alternate Egress Interface When an egress interface of a MR loses the connection to the global Internet, the MR can make use of its alternate egress interface should it possess multiple egress interfaces. The most direct way to do so is for the mobile router to send a binding update to the home agent of the failed interface using the Care-of Address assigned to the alternate interface in order to re-establish the bi-directional tunneling using the Care-of Address on the alternate egress interface. After a successful binding update, the MR encapsulates outgoing packets through the bi-directional tunnel using the alternate egress interface. The idea is to use the global address (most likely a Care-of Address) assigned to an alternate egress interface as the new (back-up) Care-of Address of the mobile router to re-establish the bi-directional tunneling with its home agent. B.2.2 Using Alternate Mobile Router When the MR loses a connection to the global Internet, the MR can utilize a route provided by an alternate MR (if one exists) to re-establish the bi-directional tunnel with its HA. First, the MR has to obtain a Care-of Address from the alternate MR (i.e. attaches itself to the alternate MR). Next, it sends binding update to its HA using the Care-of Address obtained from the alternate MR. From then on, the MR can encapsulates outgoing packets through the bi-directional tunnel using via the alternate MR. The idea is to obtain a Care-of Address from the alternate MR and use this as the new (back-up) Care-of Address of the MR to re-establish the bi-directional tunneling with its HA. Note that every packet sent between MNNs and their correspondent nodes will experience two levels of encapsulation. First level of tunneling occurs between a MR which the MNN uses as its default router and the MR's HA. The second level of tunneling occurs between the alternate MR and its HA. B.3 To Avoid Tunneling Loop The method of re-establishing the bi-directional tunnel as described in Appendix B.2 may lead to infinite loops of tunneling. This happens when two MRs on a mobile network lose connection to the global Internet at the same time and each MR tries to re-establish bi-directional tunnel using the other MR. We refer to this phenomenon as tunneling loop. One approach to avoid tunneling loop is for a MR that has lost connection to the global Internet to insert an option into the Router Advertisement message it broadcasts periodically. This option serves to notify other MRs on the link that the sender no longer provides global connection. Note that setting a zero Router Lifetime field will not work well since it will cause MNNs that are attached to the MR to stop using the MR as their default router too (in which case, things are back to square one). Appendix C. Change Log o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt which is itself a merge of 3 previous drafts draft-ng-nemo-multihoming-issues-02.txt, draft-eun-nemo-multihoming-problem-statement-00.txt, and draft-charbon-nemo-multihoming-evaluation-00.txt o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF * Addressed Issue #1 in Section 1: Added a note to remind readers that IPv6 is implicitly assumed * Addressed Issue #3 in Section 2.3: Removed text on assumption * Addressed Issue #6 in Section 3.1: Added benefits * Addressed Issue #7 in Section 3.2: Modified text * Addressed Issue #9 in Section 4.3: Modified text * Addressed Issue #10 in Section 4.4: Added paragraph on other failure modes * Addressed Issue #10: New Section 4.5 on media detection * Addressed Issue #11 in Section 4.11: modified text o Changes from draft-ng-multihoming-issues-03 to draft-ietf-nemo-multihoming-issues-00: * Expanded "Problem Statement" (Section 4) * Merged "Evaluation" Section into "Problem Statement" (Section 4) * Cleaned up description in "Classification" (Section 2), and clearly indicate in each classification, what are the multihomed entities * Re-organized "Deployment Scenarios and Prerequisites" (Section 3), and created the "Prerequisites" sub-section. o Changes from draft-ng-multihoming-issues-02 to draft-ng-multihoming-issues-03: * Merged with draft-eun-nemo-multihoming-problem-statement (see "Problem Statement" (Section 4)) * Included conclusions from draft-charbon-nemo-multihoming-evaluation-00 * Re-organized some part of "Benefits/Issues of Multhoming in NEMO" to "Problem Statement" (Section 4) * Removed lots of text to be in sync with . * Title changed from "Multihoming Issues in NEMO Basic Support" to "Analysis of Multihoming in NEMO" * Changed (w,x,y) to (x,y,z) in taxonomy. * Moved alternative approaches of classification to Appendix * Creation of this Change-Log itself ;-) Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.