NEMONetwork Working Group C. NgInternet-DraftRequest for Comments: 4888 Panasonic Singapore LabsIntended status:Category: Informational P. ThubertExpires: March 19, 2007Cisco Systems M. Watari KDDI R&D Labs F. Zhao UC DavisSeptember 15, 2006July 2007 Network Mobility Route Optimization Problem Statementdraft-ietf-nemo-ro-problem-statement-03Status ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 19, 2007.this memo is unlimited. Copyright Notice Copyright (C) TheInternet Society (2006).IETF Trust (2007). Abstract With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates suchproblems,problems and providesforthe motivation behind Route Optimization (RO) for NEMO. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .43 2. NEMO Route Optimization Problem Statement . . . . . . . . . .53 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . .54 2.2. Bottleneck in the Home Network . . . . . . . . . . . . . .. . 76 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . .76 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization . . . . . . . . . . . . . . . . . . . . . . .98 2.5. Security Policy Prohibiting TrafficFromfrom Visiting Nodes .109 2.6. Instability of Communications within a Nested Mobile Network . . . . . . . . . . . . . . . . . . . . . . . . .109 2.7. Stalemate with a Home Agent Nested in a Mobile Network . .1110 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .1210 4.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.Security Considerations . . . . . . . . . . . . . . . . . . .12 6.11 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .13 7.11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.1.12 6.1. Normative Reference . . . . . . . . . . . . . . . . . . .14 7.2.12 6.2. Informative Reference . . . . . . . . . . . . . . . . . .1412 Appendix A.Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix B.Variousconfigurations involvingConfigurations Involving Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . . .16 B.1.13 A.1. CNlocatedLocated in thefixed infrastructureFixed Infrastructure . . . . . . . . . .16 B.1.1.13 A.1.1. Case A: LFN andstandardStandard IPv6 CN . . . . . . . . . . .17 B.1.2.14 A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . .17 B.1.3.14 A.1.3. Case C: VMN andstandardStandard IPv6 CN . . . . . . . . . . .17 B.2.14 A.2. CNlocatedLocated indistinct nestedDistinct Nested NEMOs . . . . . . . . . . .18 B.2.1.15 A.2.1. Case D: LFN andstandardStandard IPv6 CN . . . . . . . . . . .19 B.2.2.16 A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . .19 B.2.3.16 A.2.3. Case F: VMN andstandardStandard IPv6 CN . . . . . . . . . . .19 B.3. CN and16 A.3. MNNlocatedand CN Located in thesame nestedSame Nested NEMO . . . . . . . .20 B.3.1.17 A.3.1. Case G: LFN andstandardStandard IPv6 CN . . . . . . . . . . .21 B.3.2.18 A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . .21 B.3.3.18 A.3.3. Case I: VMN andstandardStandard IPv6 CN . . . . . . . . . . .22 B.4.19 A.4. CNlocated behindLocated Behind thesame nestedSame Nested MR . . . . . . . . . . .22 B.4.1.19 A.4.1. Case J: LFN andstandardStandard IPv6 CN . . . . . . . . . . .23 B.4.2.20 A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . .23 B.4.3.20 A.4.3. Case L: VMN andstandardStandard IPv6 CN . . . . . . . . . . .2421 AppendixC.B. Example of How a Stalemate Situationcan Occur . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . .Can Occur . . .2922 1. Introduction With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the Mobile Router and its Home Agent (also known as the MRHA tunnel) when the mobile network is away. Although such an arrangement allows Mobile Network Nodes to reach and be reached by any node on the Internet, limitations associated to the base protocol degrade overall performance of thenetwork,network and, ultimately, can prevent all communications to and from the Mobile Network Nodes. Some of these concerns already exist with Mobile IPv6 [4] and were addressed by the mechanism known as Route Optimization, which is part of the base protocol. With Mobile IPv6, Route Optimization mostly improves theend to endend-to-end path between the Mobile Node and Correspondent Node, with an additional benefit of reducing the load of the Home Network, thus its name. NEMO Basic Support presents a number of additional issues, making the problem more complex, so it was decided to address Route Optimization separately. In that case, the expected benefits are more dramatic, and a Route Optimization mechanism could enable connectivity that would be broken otherwise. In that sense, Route Optimization is even more important to NEMO Basic Support than it is to Mobile IPv6. This document explores limitations inherent in NEMO Basic Support, and their effects on communications between a Mobile Network Node and its corresponding peer. This is detailed in Section 2. It is expectedforthat readersto beare familiar with general terminologies related to mobility in [4][2],NEMO relatedNEMO-related terms defined in [3], and NEMO goals and requirements [5]. 2. NEMO Route Optimization Problem Statement Given the NEMO Basic Support protocol, all data packets to and from Mobile Network Nodes must go through the Home Agent, even though a shorter path may exist between the Mobile Network Node and its Correspondent Node. In addition, with the nesting of Mobile Routers, these data packets must go through multiple Home Agents and several levels of encapsulation, which may be avoided. This results in various inefficiencies and problems with packetdeliverydelivery, which can ultimately disrupt all communications to and from the Mobile Network Nodes. In the following sub-sections, we will describe the effects of a pinball route with NEMO Basic Support, how it may cause a bottleneck to be formed in thehome network,Home Network, and how these get amplified with nesting of mobile networks. Closely related to nesting, we will also look into the sub-optimality even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. This is followed by a description of security policy inhome networkthe Home Network that may forbid transit traffic from Visiting Mobile Nodes in mobile networks. In addition, we will explore the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network. We will also provide additional motivations for Route Optimization by considering the potential stalemate situation when a Home Agent is part of a mobile network. 2.1. Sub-Optimality with NEMO Basic Support With NEMO Basic Support, all packets sent between a Mobile Network Node and its Correspondent Node are forwarded through the MRHA tunnel, resulting in a pinball route between the two nodes. This has the following sub-optimal effects: o Longerroute leadingRoute Leading toincreased delayIncreased Delay andadditional infrastructure loadAdditional Infrastructure Load Because a packet must transit from a mobile network to the Home Agent then to the Correspondent Node, the transit time of the packet is usually longer than if the packet were to go straight from the mobile network to the Correspondent Node. When the Correspondent Node (or the mobile network) resides near the Home Agent, the increase in packet delay can be very small.HoweverHowever, when the mobile network and the Correspondent Node are relatively near to one another but far away from the Home Agent on the Internet, the increase in delay is very large. Applications such as real-time multimedia streaming may not be able to tolerate such increase in packet delay. In general, the increase in delay may also impact the performance of transport protocols such as TCP, since the sending rate of TCP is partly determined by the round-trip-timetrip time (RTT) perceived by the communication peers. Moreover, by using a longer route, the total resource utilization for the traffic would be much higher than if the packets were to follow a direct path between the Mobile Network Node and Correspondent Node. This would result in additional load in the infrastructure. o Increasedpacket overheadPacket Overhead The encapsulation of packets in the MRHA tunnel results in increased packet size due to the addition of an outer header. This reduces the bandwidth efficiency, as an IPv6 header can be quite substantial relative to the payload for applications such as voice samples. For instance, given a voice application usinga 8kbpsan 8 kbps algorithm(e.g.(e.g., G.729) and taking a voice sample every20ms20 ms (as in RFC1889),1889 [6]), the packet transmission rate will be 50 packets per second. Each additional IPv6 header is an extra 320 bits per packet(i.e. 16kbps),(i.e., 16 kbps), which is twice the actual payload! o Increasedprocessing delayProcessing Delay The encapsulation of packets in the MRHA tunnel also results in increased processing delay at the points of encapsulation and decapsulation. Such increased processing may include encryption/ decryption, topological correctness verifications, MTU computation,fragmentationfragmentation, and reassembly. o IncreasedchancesChances ofpacket fragmentationPacket Fragmentation The augmentation in packet size due to packet encapsulation may increase the chances of the packet being fragmented along the MRHA tunnel. This can occur if there is no prior path MTU discovery conducted, or if the MTU discovery mechanism did not take into account the encapsulation of packets.PacketsPacket fragmentation will result in a further increase in packetdelays,delays and further reduction of bandwidth efficiency. o IncreasedsusceptibilitySusceptibility tolink failureLink Failure Under the assumption that each link has the same probability of link failure, a longer routing path would be moresusceptibilitysusceptible to link failure. Thus, packets routed through the MRHA tunnel may be subjected to a higher probability of being lost or delayed due to link failure, compared to packets that traverse directly between the Mobile Network Node and its Correspondent Node. 2.2. Bottleneck in the Home Network Apart from the increase in packet delay and infrastructure load, forwarding packets through the Home Agent may also lead to either the Home Agent or the Home Link becoming a bottleneck for the aggregated traffic from/to all the Mobile Network Nodes. A congestion at home would lead to additional packet delay, or even packet loss. In addition, Home Agent operations such as security check, packetinterceptioninterception, and tunneling might not be as optimized in the Home Agent software as plain packet forwarding. This could further limit the Home Agent capacity for data traffic. Furthermore, with all traffic having to pass through the Home Link, the Home Link becomes a single point of failure for the mobile network. Data packets that are delayed or discarded due to congestion at thehome networkHome Network would cause additional performance degradation to applications. Signaling packets, such as Binding Update messages, that are delayed or discarded due to congestion at thehome network,Home Network may affect the establishment or update of bi-directional tunnels, causing disruption of all traffic flow through these tunnels. A NEMO Route Optimization mechanism that allows the Mobile Network Nodes to communicate with their Correspondent Nodes via a path that is different from the MRHA tunneling and thereby avoiding the HomeAgent,Agent may alleviate or even prevent the congestion at the Home Agent or Home Link. 2.3. Amplified Sub-Optimality in Nested Mobile Networks By allowing other mobile nodes to join a mobile network, and in particular mobile routers, it is possible to form arbitrary levels of nesting of mobile networks. With such nesting, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the undesirable effects of a pinball route with NEMO Basic Support are amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +------------------------------+ | MR1_HA |----| Internet |-----CN1 +--------+ +------------------------------+ | +---+---+ root-MR | MR1 | +-------+ | | +-------+ +-------+ sub-MR | MR2 | | MR4 | +---+---+ +---+---+ | | +---+---+ +---+---+ sub-MR | MR3 | | MR5 | +---+---+ +---+---+ | | ----+---- ----+---- MNN CN2 Figure 1: AnexampleExample ofnesteda Nested Mobile Network Using NEMO Basic Support, the flow of packets between a Mobile Network Node, MNN, and a Correspondent Node, CN1, would need to go through three separate tunnels, illustrated in Figure 2 below. ----------. ---------/ /----------. -------/ | | /------- MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 MR3-------\ | | \-------MR3_HA MR2--------\ \----------MR2_HA MR1---------MR1_HA Figure 2: Nesting of Bi-Directional Tunnels This leads to the following problems: o Pinball Route Both inbound and outbound packets will flow via the Home Agents of all the Mobile Routers on their paths within the mobile network, with increased latency, lessresilienceresilience, and more bandwidth usage. AppendixBA illustrates in detail thepacketspackets' routes under different nesting configurations of the Mobile Network Nodes. o Increased Packet Size An extra IPv6 header is added per level of nesting to all the packets. The header compression suggested in[6][7] cannot be applied because both the source and destination (the intermediate Mobile Router and its HomeAgent),Agent) are different hop to hop. Nesting also amplifies the probability of congestion at thehome networksHome Networks of the upstream Mobile Routers. In addition, the Home Link of each upstream Mobile Router will also be a single point of failure for the nested Mobile Router. 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization When a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of the mobile network. Packets sent to and from the Visiting Mobile Node will have to be routed not only via the Home Agent of the Visiting Mobile Node, but also via the Home Agent of the Mobile Router in the mobile network. This suffers the same amplification effect of nested mobile network mentioned in Section 2.3. In addition, although Mobile IPv6 [4] allows a mobile host to perform Route Optimization with its Correspondent Node in order to avoid tunneling with its Home Agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its Correspondent Node is subjected to the sub-optimality introduced by the MRHA tunnel. Interested readers may refer to AppendixBA for examples of how the routes will appear with nesting of Mobile IPv6 hosts in mobile networks. The readers should also note that the same sub-optimality would apply when the mobile host is outside the mobile network and its Correspondent Node is in the mobile network. 2.5. Security Policy Prohibiting TrafficFromfrom Visiting Nodes NEMO Basic Support requires all traffic from visitors to be tunneled to the Mobile Router's Home Agent. This might represent a breach in the security of thehome networkHome Network (some specific attacks against the Mobile Router's binding by rogue visitors have been documented in[7][8]).[8][9]). Administrators might thus fear that malicious packets will be routed into the Home Network via the bi-directional tunnel. As a consequence, it can be expected that in many deployment scenarios, policies will be put in place to prevent unauthorized Visiting Mobile Nodes from attaching to the Mobile Router. However, there are deployment scenarios where allowing unauthorized Visiting Mobile Nodes is actually desirable. For instance, when Mobile Routers attach to other Mobile Routers and form a nested NEMO, they depend on each other to reach the Internet. When Mobile Routers have no prior knowledge of one another (no security association,AAA, PKI etc...),Authentication, Authorization, and Accounting (AAA), Public-Key Infrastructure (PKI), etc.), it could still be acceptable to forward packets, provided that the packets are not tunneled back to the Home Networks. A Route Optimization mechanism that allows traffic from Mobile Network Nodes toby-passbypass the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step towards a Tit for Tat model, where MRs would benefit from a reciprocal altruism, based on anonymity and innocuousness, to extend the Internet infrastructure dynamically. 2.6. Instability of Communications within a Nested Mobile Network Within a nested mobile network, two Mobile Network Nodes may communicate with each other. Let us consider the previous example illustrated in Figure 1 where MNN and CN2 are sharing a communication session. With NEMO Basic Support, a packet sent from MNN to CN2 will need to be forwarded to the Home Agent of each Mobile Router before reachingCN2. Whereas,CN2, whereas, a packet following the direct path between them need not even leave the mobile network. Readers are referred to AppendixB.3A.3 for detailed illustration of the resulting routing paths. Apart from the consequences of increased packet delay and packetsizesize, which are discussed in previous sub-sections, there are two additional effects that are undesirable: o when the nested mobile network is disconnected from the Internet(e.g.(e.g., MR1 loses its egress connectivity), MNN and CN2 can no longer communicate with each other, even though the direct path from MNN to CN2 is unaffected; o the egress link(s) of the root Mobile Router(i.e.(i.e., MR1) becomes a bottleneck for all the traffic that is coming in and out of the nested mobile network. A Route Optimization mechanism could allow traffic between two Mobile Network Nodes nested within the same mobile network to follow a direct path between them, without being routed out of the mobile network. This may also off-load the processing burden of the upstream Mobile Routers when the direct path between the two Mobile Network Nodes does not traverse these Mobile Routers. 2.7. Stalemate with a Home Agent Nested in a Mobile Network Several configurations for the Home Network are described in[9].[10]. In particular, there is a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its mobile network. In other words, the mobile network is itself an aggregation of Mobile Network Prefixes assigned to (children) Mobile Routers. A stalemate situation exists in the case where the parent Mobile Router visits one of its children. The child Mobile Router cannot find its Home Agent in the Internet and thus cannot establish its MRHA tunnel and forward thevisitorsvisitor's traffic. The traffic from the parent is thus blocked from reaching theInternetInternet, and it will never bind to its own(grand parent)(grandparent) Home Agent. AppendixCB gives a detailed illustration of how such a situation can occur. Then again, a Route Optimization mechanism that bypasses the nested tunnel might enable the parent traffic to reach the Internet and let it bind. At that point, the child Mobile Router would be able to reach its parent and bind in turn. Additional nested Route Optimization solutions might also enable the child to locate its Home Agent in the nested structure and bind regardless of whether or not the Internet isreachable or not.reachable. 3. Conclusion With current NEMO Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates suchinefficiencies,inefficiencies and providesforthe motivation behind Route Optimization for NEMO. We have described the sub-optimal effects of pinball routes with NEMO Basic Support, how they may cause a bottleneck to be formed in thehome network,Home Network, and how they get amplified with nesting of mobile networks. These effects will also be seen even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. In addition, other issues concerning the nesting of mobile networks that might provide additional motivation for a NEMO Route Optimization mechanism were also explored, such as the prohibition of forwarding traffic from a Visiting Mobile Node throughaan MRHA tunnel due to security concerns, the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network, and the possibility of a stalemate situation when Home Agents are nested within a mobile network. 4.IANA Considerations This is an informational document and does not require any IANA action. 5.Security Considerations This document highlights some limitations oftheNEMO Basic Support. In particular, some security concerns could prevent interesting applications of the protocol, as detailed in Section 2.5. Route Optimization for RFC 3963 [1] might introduce new threats, just as it might alleviate existing ones. This aspect will certainly be a key criterion in the evaluation of the proposed solutions.6.5. Acknowledgments The authors wish to thank the co-authors of previousdraftsversions from which thisdraftdocument is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by Masafumi Watari on the extracted appendix was written while still at Keio University. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, RyujiWakikawaWakikawa, and Patrick Wetterwald for their various contributions.7.6. References7.1.6.1. Normative Reference [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",draft-ietf-nemo-terminology-05 (work in progress), March 2006. 7.2.RFC 4885, July 2007. 6.2. Informative Reference [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Ernst, T., "Network Mobility Support Goals and Requirements",draft-ietf-nemo-requirements-05 (work in progress), October 2005.RFC 4886, July 2007. [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [7] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6",draft-deering-ipv6-encap-addr-deletion-00 (workWork inprogress),Progress, November 2001.[7][8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, "Threats for Basic Network Mobility Support (NEMO threats)",draft-petrescu-nemo-threats-01 (workWork inprogress),Progress, January 2004.[8][9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat Analysis on NEMO Basic Operations",draft-jung-nemo-threat-analysis-02 (workWork inprogress),Progress, July 2004.[9][10] Thubert, P., Wakikawa, R., and V. Devarapalli,"NEMO Home Network models", draft-ietf-nemo-home-network-models-06 (work in progress), February 2006. [10] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. Appendix A. Change Log o draft-ietf-nemo-ro-problem-statement-03: * Keepalive release o draft-ietf-nemo-ro-problem-statement-02: * Added Appendix C to illustrate the formation of stalemate situation in Section 2.7 * Editorial changes to the Abstract to better reflect the document contents * Minor editorial changes throughout Section 2 o draft-ietf-nemo-ro-problem-statement-01: * Added text on effect on TCP contributed by Carlos in Sect 2.1 - "Sub-Optimality with NEMO Basic Support" * Added text on VMN using CoA as source address in Appendix B.4.3 * Re-written Section 2.5 - "Security Policy Prohibiting Traffic From Visiting Nodes" * Replaced "deadlock" with "stalemate" in Section 2.7. * Minor typographical corrections o draft-ietf-nemo-ro-problem-statement-00: * Initial version adapted from Section 1 & 2 of 'draft-thubert-nemo-ro-taxonomy-04.txt' * Added Section 2.2: Bottleneck in the Home Network * Added Section 2.5: Security Policy Prohibiting Traffic From Visiting Nodes * Added Section 2.7: Deadlock with a"Network Mobility HomeAgent Nested in a MobileNetwork* Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt'Models", RFC RFC4887, July 2007. [11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. AppendixB.A. Variousconfigurations involvingConfigurations Involving Nested Mobile Networks In the following sections, we try to describe different communication modelswhichthat involve a nested mobilenetwork,network and to clarify the issues for each case. We illustrate the path followed by packets if we assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. Different cases are considered where a Correspondent Node is located in the fixed infrastructure, in a distinct nested mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node. Additionally, cases where Correspondent Nodes and Mobile Network Nodes are either standard IPv6 nodes or Mobile IPv6 nodes are considered. As defined in [3], standard IPv6 nodes are nodes with no mobility functions whatsoever,i.e.i.e., they are not Mobile IPv6noror NEMO enabled. Thismeanmeans thatnot only cantheynotcannot move around keeping openconnections, but alsoconnections and that they cannot process Binding Updates sent by peers.B.1.A.1. CNlocatedLocated in thefixed infrastructureFixed Infrastructure The most typical configuration is the case where a Mobile Network Node communicates with a Correspondent Node attached in the fixed infrastructure. Figure 3 below shows an example of such topology. +--------+ +--------+ +--------+ | MR1_HA | | MR2_HA | | MR3_HA | +---+----+ +---+----+ +---+----+ | | | +-------------------------+ | Internet |----+ CN +-------------------------+ | | +---+---+ +--+-----+ root-MR | MR1 | | VMN_HA | +---+---+ +--------+ | +---+---+ sub-MR | MR2 | +---+---+ | +---+---+ sub-MR | MR3 | +---+---+ | ----+---- MNN Figure 3: CNlocatedLocated at theinfrastructure B.1.1.Infrastructure A.1.1. Case A: LFN andstandardStandard IPv6 CN The simplest case is where both MNN and CN are fixed nodes with no mobility functions. That is, MNN is a Local Fixed Node, and CN is a standard IPv6 node. Packets are encapsulated between each Mobile Router and its respective HomeAgent.Agent (HA). As shown in Figure 4, in such a case, the path between the two nodes would go through: 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN LFN IPv6 Node The digits represent the number of IPv6 headers. Figure 4: MNN and CNare standardAre Standard IPv6nodes B.1.2.Nodes A.1.2. Case B: VMN and MIPv6 CN In this second case, both end nodes are MobileIPv6 enabledIPv6-enabled mobile nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6route optimizationRoute Optimization may thus be initiated between the two and packets would not go through the Home Agent of the Visiting Mobile Nodenoror the Home Agent of the Correspondent Node (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent, in both directions. As shown in Figure 5, the path between MNN and CN would go through: 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN VMN MIPv6 Figure 5: MNN and CNareAre MIPv6mobile nodes B.1.3.Mobile Nodes A.1.3. Case C: VMN andstandardStandard IPv6 CN When the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6route optimizationRoute Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, MNN would establish a bi-directional tunnel with its HA, which causes the flow to go out the nested NEMO. Packets between MNN and CN would thus go through MNN's own Home Agent (VMN_HA). The path would therefore be as shownonin Figure 6: 2 3 4 5 4 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA VMN | | 3 1 2 | CN --- VMN_HA --- MR3_HA IPv6 Node Figure 6: MNN isaan MIPv6mobile nodeMobile Node and CN is astandardStandard IPv6nodeNode Providing Route Optimization involving a Mobile IPv6 node may require optimization among the Mobile Routers and the Mobile IPv6 node.B.2.A.2. CNlocatedLocated indistinct nestedDistinct Nested NEMOs The Correspondent Node may be located in another nested mobile network, different from the one MNN is attached to, as shown in Figure 7. We define such configuration as "distinct nested mobile networks". +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | | +---+---+ +---+---+ root-MR | MR1 | | MR4 | +---+---+ +---+---+ | | +---+---+ +---+---+ sub-MR | MR2 | | MR5 | +---+---+ +---+---+ | | +---+---+ ----+---- sub-MR | MR3 | CN +---+---+ | ----+---- MNN Figure 7: MNN and CNlocatedLocated indistinct nestedDistinct Nested NEMOsB.2.1.A.2.1. Case D: LFN andstandardStandard IPv6 CN Similarwithto Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at everymobile routerMobile Router on the way out of the nested mobile network, decapsulated by the HomeAgentsAgents, and then encapsulated again onitstheir way down the nested mobile network. 1 2 3 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA LFN | | 1 1 2 3 2 | CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA IPv6 Node Figure 8: MNN and CNare standardAre Standard IPv6nodes B.2.2.Nodes A.2.2. Case E: VMN and MIPv6 CN Similarwithto Case B, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6route optimization.Route Optimization. Again, packets will not go through the Home Agent of the MNNnoror the Home Agent of the Mobile IPv6 Correspondent Node (not shown in the figure). However, packets will still be tunneled for each Mobile Router to its Home Agent andvisevice versa. Therefore, the path between MNN and CN would go through: 1 2 3 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA VMN | | 1 1 2 3 2 | CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA MIPv6 Node Figure 9: MNN and CNareAre MIPv6mobile nodes B.2.3.Mobile Nodes A.2.3. Case F: VMN andstandardStandard IPv6 CN Similar to Case C, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, MIPv6route optimization can notRoute Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. MNN would therefore establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent as shownon figurein Figure 10: 2 3 4 5 4 3 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA VMN | | 2 1 2 3 2 1 | CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA IPv6 Node Figure 10: MNN isaan MIPv6mobile nodeMobile Node and CN is astandardStandard IPv6node B.3. CN andNode A.3. MNNlocatedand CN Located in thesame nestedSame Nested NEMO Figure 11 below shows the case where the two communicating nodes are connected behind different Mobile Routers that are connected in the same nested mobile network, and thus behind the same root Mobile Router. RouteoptimizationOptimization can avoid packets being tunneled outside the nested mobile network. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | +---+---+ root-MR | MR1 | +-------+ | | +-------+ +-------+ sub-MR | MR2 | | MR4 | +---+---+ +---+---+ | | +---+---+ +---+---+ sub-MR | MR3 | | MR5 | +---+---+ +---+---+ | | ----+---- ----+---- MNN CN Figure 11:CN andMNNlocatedand CN Located in thesame nestedSame Nested NEMOB.3.1.A.3.1. Case G: LFN andstandardStandard IPv6 CN Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, decapsulated and encapsulated by the HomeAgentsAgents, and then make their way back to the nested mobile network through the same root Mobile Router. Therefore, the path between MNN and CN would go through: 1 2 3 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA LFN | | 1 1 2 3 4 3 2 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA IPv6 Node Figure 12: MNN and CNare standardAre Standard IPv6 nodesB.3.2.A.3.2. Case H: VMN and MIPv6 CN Similarwithto Case B and Case E, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6route optimizationRoute Optimization, which will avoid the packetsto gogoing through the Home Agent of MNNnoror the Home Agent of the Mobile IPv6 CN (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent in both directions. Therefore, the path would be the same as with Case G and go through: 1 2 3 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA LFN | | 1 1 2 3 4 3 2 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA MIPv6 Node Figure 13: MNN and CNareAre MIPv6mobile nodes B.3.3.Mobile Nodes A.3.3. Case I: VMN andstandardStandard IPv6 CN As for Case C and Case F, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimizationcan notcannot be performed. Therefore, MNN will establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent. The path would therefore be as shownonin Figure 14: 2 3 4 5 4 3 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA VMN | | 2 | VMN_HA | | 1 1 2 3 4 3 2 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA IPv6 Node Figure 14: MNN isaan MIPv6mobile nodeMobile Node and CN is astandardStandard IPv6node B.4.Node A.4. CNlocated behindLocated Behind thesame nestedSame Nested MR Figure 15 below shows the case where the two communicating nodes are connected behind the same nested Mobile Router. The optimization is required when the communication involves MIPv6-enabled nodes. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | +---+---+ root-MR | MR1 | +---+---+ | +-------+ sub-MR | MR2 | +---+---+ | +---+---+ sub-MR | MR3 | +---+---+ | -+--+--+- MNN CN Figure 15: MNN and CNlocated behindLocated Behind thesame nestedSame Nested MRB.4.1.A.4.1. Case J: LFN andstandardStandard IPv6 CN If both end nodes are Local Fixed Nodes, no special function is necessary for optimization of their communications. The path between the two nodes would go through: 1 MNN --- CN LFN IPv6 Node Figure 16: MNN and CNare standardAre Standard IPv6nodes B.4.2.Nodes A.4.2. Case K: VMN and MIPv6 CN Similarwithto Case H, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6route optimization.Route Optimization. Although few packets would go out the nested mobile network for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested mobile network. Therefore, packets between MNN and CN would eventually go through: 1 MNN --- CN VMN MIPv6 Node Figure 17: MNN and CN are MIPv6mobile nodesMobile Nodes If the root Mobile Router is disconnected while the nodes exchange keys for the Return Routability procedure, they may not communicate even though they are connected on the same link.B.4.3.A.4.3. Case L: VMN andstandardStandard IPv6 CN When the communication involves a Mobile IPv6 node either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, even though the two nodes are on the same link, MNN will establish a bi-directional tunnel withit'sits Home Agent, which causes the flow to go out the nested mobile network.PathThe path between MNN and CN would require another Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 2 3 4 5 4 3 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA VMN | | 2 | VMN_HA | | 1 1 2 3 4 3 2 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA IPv6 Node Figure 18: MNN isaan MIPv6mobile nodeMobile Node and CN is astandardStandard IPv6nodeNode However, MNN may also decide to use itscare-of addressCare-of Address (CoA) as the source address of the packets, thus avoiding the tunneling with the MNN's Home Agent. This is particularly useful for a short-term communications that may easily be retried if it fails. Default Address Selection[10][11] provides some mechanisms for controlling the choice of the source address. AppendixC.B. Example of How a Stalemate SituationcanCan Occur Section 2.7 describes theoccurenceoccurrence of a stalemate situation where a Home Agent of a Mobile Router is nested behind the Mobile Router. Here, we illustrate a simple example where such a situation can occur. Consider a mobility configuration depicted in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation indicates that HA1 is a border router. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent. /-----CN +----------+ home link 1 +--------+ | | ----+-----------------| HA1/BR |---| Internet | | +--------+ | | | +----------+ +--+--+ +-----+ | MR1 | | HA2 | +--+--+ +--+--+ | | -+--------+-- mobile net 1 / home link 2 | +--+--+ +--+--+ | MR2 | | LFN | +--+--+ +--+--+ | | -+--------+- mobile net 2 Figure 19: Initial Deployment In Figure 19 above, communications between CN and LFNfollowsfollow a direct path as long as both MR1 and MR2 are positioned at home. No encapsulation intervenes. In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in Figure 20 below. /-----CN +----------+ home link 1 +--------+ | | --+-----------| HA1/BR |---| Internet | | +--------+ | | +--+--+ +-----+ +----------+ | MR1 | | HA2 | \ +--+--+ +--+--+ +-----+ | | | AR | -+--------+- mobile net 1 +--+--+ home link 2 | +--+--+ +-----+ | MR2 | | LFN | +--+--+ +--+--+ | | mobile net 2 -+--------+- Figure 20: Mobile Network 2 Leaves Home Once MR2 acquires a Care-of Address under AR, the tunnel setup procedure occurs between MR2 and HA2. MR2 sends a Binding Update to HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi- directional tunnel has MR2 and HA2 as tunnel endpoints. After the tunnel MR2HA2 has been set up, the path taken by a packet from CN towards LFN can be summarized as: CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. Non-encapsulated packets are marked "->" while encapsulated packets are marked "=>". Consider next the attachment of the first mobile network under the second mobile network, like in Figure 21 below. After this movement, MR1 acquires a Care-of Address valid in the second mobile network. Subsequently, it sends a Binding Update (BU) message addressed to HA1. This Binding Update is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible,due to the fact thatbecause the tunnel between MR2 and HA2hashad been previously torn down (when the mobile net 1hasmoved from home). The communications between CN and LFN stops, even though both mobile networks are connected to the Internet. /-----CN +----------+ +--------+ | | | HA1/BR |---| Internet | +--------+ | | +----------+ \ +-----+ | AR | +--+--+ | +--+--+ +-----+ | MR2 | | LFN | +--+--+ +--+--+ | | mobile net 2 -+--------+- | +--+--+ +-----+ | MR1 | | HA2 | +--+--+ +--+--+ | | mobile net 1 -+--------+- Figure 21: Stalemate Situation Occurs If both tunnels between MR1 and HA1, and between MR2 andHA2HA2, were up simultaneously, they would have "crossed over" each other. If the tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be noticed that the path of the tunnel MR1-HA1 includes only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels are crossing over each other if the IP path between two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming that both tunnels are up). When both endpoints of one tunnel are included in the path of the other tunnel, then tunnels are simply encapsulating each other. Authors' Addresses Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng IndustrialEstateEstate, Singapore 534415 SG Phone: +65 65505420Email:EMail: chanwah.ng@sg.panasonic.com Pascal Thubert Cisco SystemsTechnology CenterVillage d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCEEmail:EMail: pthubert@cisco.com Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPANEmail:EMail: watari@kddilabs.jp Fan ZhaoUniversity of CaliforniaUC Davis One Shields Avenue Davis, CA 95616 US Phone: +1 530 752 3128Email:EMail: fanzhao@ucdavis.edu Full Copyright Statement Copyright (C) TheInternet Society (2006).IETF Trust (2007). 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. 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 INTERNETSOCIETYSOCIETY, THE IETF TRUST 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. Intellectual Property 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 ietf-ipr@ietf.org.AcknowledgmentAcknowledgement Funding for the RFC Editor function is currently provided by theIETF Administrative Support Activity (IASA).Internet Society.