From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4888.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc4888.txt (limited to 'doc/rfc/rfc4888.txt') diff --git a/doc/rfc/rfc4888.txt b/doc/rfc/rfc4888.txt new file mode 100644 index 0000000..8a0ca9b --- /dev/null +++ b/doc/rfc/rfc4888.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. Ng +Request for Comments: 4888 Panasonic Singapore Labs +Category: Informational P. Thubert + Cisco Systems + M. Watari + KDDI R&D Labs + F. Zhao + UC Davis + July 2007 + + + Network Mobility Route Optimization Problem Statement + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The 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 such problems and provides the motivation behind Route + Optimization (RO) for NEMO. + + + + + + + + + + + + + + +Ng, et al. Informational [Page 1] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3 + 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 + 2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6 + 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6 + 2.4. Sub-Optimality with Combined Mobile IPv6 Route + Optimization . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9 + 2.6. Instability of Communications within a Nested Mobile + Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10 + 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12 + 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 + Appendix A. Various Configurations Involving Nested Mobile + Networks . . . . . . . . . . . . . . . . . . . . . . 13 + A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13 + A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14 + A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14 + A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14 + A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15 + A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16 + A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16 + A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16 + A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17 + A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18 + A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18 + A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19 + A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19 + A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20 + A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20 + A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21 + Appendix B. Example of How a Stalemate Situation Can Occur . . . 22 + + + + + + + + + + + + + +Ng, et al. Informational [Page 2] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +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 the 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 the end-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 + expected that readers are familiar with general terminologies related + to mobility in [4][2], NEMO-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 packet delivery, 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 the Home Network, and how these get amplified with + + + +Ng, et al. Informational [Page 3] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 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 in the 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 Longer Route Leading to Increased Delay and Additional + 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. However, + 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 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 Increased Packet 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 + + + + +Ng, et al. Informational [Page 4] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + quite substantial relative to the payload for applications such as + voice samples. For instance, given a voice application using an 8 + kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms + (as in RFC 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., 16 kbps), which is twice the actual + payload! + + o Increased Processing 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, fragmentation, and reassembly. + + o Increased Chances of Packet 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. Packet fragmentation will + result in a further increase in packet delays and further + reduction of bandwidth efficiency. + + o Increased Susceptibility to Link Failure + + Under the assumption that each link has the same probability of + link failure, a longer routing path would be more susceptible 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. + + + + + + + + + + + + + + + + + +Ng, et al. Informational [Page 5] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +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, packet + interception, 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 the + Home Network would cause additional performance degradation to + applications. Signaling packets, such as Binding Update messages, + that are delayed or discarded due to congestion at the 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 Home + 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. + + + + + + + + + + + + + + +Ng, et al. Informational [Page 6] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + +--------+ +--------+ +--------+ +--------+ + | 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: An Example of a 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 + + + + + + + + + + + + + +Ng, et al. Informational [Page 7] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 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, less resilience, and more bandwidth usage. + Appendix A illustrates in detail the packets' 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 [7] cannot be + applied because both the source and destination (the intermediate + Mobile Router and its Home Agent) are different hop to hop. + + Nesting also amplifies the probability of congestion at the Home + 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 Appendix A 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. + + + + + + +Ng, et al. Informational [Page 8] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +2.5. Security Policy Prohibiting Traffic from 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 the Home Network (some specific attacks against the + Mobile Router's binding by rogue visitors have been documented in + [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, + 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 to bypass 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 + reaching CN2, whereas, a packet following the direct path between + them need not even leave the mobile network. Readers are referred to + Appendix A.3 for detailed illustration of the resulting routing + paths. + + Apart from the consequences of increased packet delay and packet + size, 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., MR1 loses its egress connectivity), MNN and CN2 can no + + + + +Ng, et al. Informational [Page 9] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 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., 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 [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 the visitor's traffic. The traffic from the + parent is thus blocked from reaching the Internet, and it will never + bind to its own (grandparent) Home Agent. Appendix B 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 is 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 such inefficiencies + and provides the motivation behind Route Optimization for NEMO. + + + + + + +Ng, et al. Informational [Page 10] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + We have described the sub-optimal effects of pinball routes with NEMO + Basic Support, how they may cause a bottleneck to be formed in the + 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 through an 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. Security Considerations + + This document highlights some limitations of NEMO 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. + +5. Acknowledgments + + The authors wish to thank the co-authors of previous versions from + which this document 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, + Ryuji Wakikawa, and Patrick Wetterwald for their various + contributions. + + + + + + + + + + + + + + + + +Ng, et al. Informational [Page 11] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +6. References + +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", + 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", + 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", Work in Progress, November 2001. + + [8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, + "Threats for Basic Network Mobility Support (NEMO threats)", + Work in Progress, January 2004. + + [9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat + Analysis on NEMO Basic Operations", Work in Progress, + July 2004. + + [10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network + Mobility Home Network Models", RFC RFC4887, July 2007. + + [11] Draves, R., "Default Address Selection for Internet Protocol + version 6 (IPv6)", RFC 3484, February 2003. + + + + + + + + + +Ng, et al. Informational [Page 12] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +Appendix A. Various Configurations Involving Nested Mobile Networks + + In the following sections, we try to describe different communication + models that involve a nested mobile 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., they are not + Mobile IPv6 or NEMO enabled. This means that they cannot move around + keeping open connections and that they cannot process Binding Updates + sent by peers. + +A.1. CN Located in the Fixed 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: CN Located at the Infrastructure + + + + +Ng, et al. Informational [Page 13] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +A.1.1. Case A: LFN and Standard 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 Home 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 CN Are Standard IPv6 Nodes + +A.1.2. Case B: VMN and MIPv6 CN + + In this second case, both end nodes are Mobile IPv6-enabled mobile + nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route + Optimization may thus be initiated between the two and packets would + not go through the Home Agent of the Visiting Mobile Node or 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 CN Are MIPv6 Mobile Nodes + +A.1.3. Case C: VMN and Standard IPv6 CN + + When the communication involves a Mobile IPv6 node either as a + Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route + 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 shown in Figure 6: + + + + +Ng, et al. Informational [Page 14] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 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 is an MIPv6 Mobile Node and CN is a Standard IPv6 Node + + Providing Route Optimization involving a Mobile IPv6 node may require + optimization among the Mobile Routers and the Mobile IPv6 node. + +A.2. CN Located in Distinct 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 CN Located in Distinct Nested NEMOs + + + + + + +Ng, et al. Informational [Page 15] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +A.2.1. Case D: LFN and Standard IPv6 CN + + Similar to Case A, 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, + decapsulated by the Home Agents, and then encapsulated again on their + 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 CN Are Standard IPv6 Nodes + +A.2.2. Case E: VMN and MIPv6 CN + + Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two + nodes may initiate Mobile IPv6 Route Optimization. Again, packets + will not go through the Home Agent of the MNN or 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 and vice 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 CN Are MIPv6 Mobile Nodes + +A.2.3. Case F: VMN and Standard 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, MIPv6 + Route Optimization cannot be performed because the standard IPv6 + Correspondent Node cannot process Mobile IPv6 signaling. MNN would + + + +Ng, et al. Informational [Page 16] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 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 shown in 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 is an MIPv6 Mobile Node and CN is a Standard IPv6 Node + +A.3. MNN and CN Located in the Same 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. Route Optimization 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 + + + + +Ng, et al. Informational [Page 17] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + Figure 11: MNN and CN Located in the Same Nested NEMO + +A.3.1. Case G: LFN and Standard 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 Home Agents, 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 CN Are Standard IPv6 nodes + +A.3.2. Case H: VMN and MIPv6 CN + + Similar to Case B and Case E, when both end nodes are Mobile IPv6 + nodes, the two nodes may initiate Mobile IPv6 Route Optimization, + which will avoid the packets going through the Home Agent of MNN or + 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 CN Are MIPv6 Mobile Nodes + + + + + + +Ng, et al. Informational [Page 18] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +A.3.3. Case I: VMN and Standard 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 Optimization cannot 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 shown in 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 is an MIPv6 Mobile Node and CN is a Standard IPv6 Node + +A.4. CN Located Behind the Same 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. + + + + + + + + + + + + + + + + + + + + + +Ng, et al. Informational [Page 19] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + +--------+ +--------+ +--------+ +--------+ + | 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 CN Located Behind the Same Nested MR + +A.4.1. Case J: LFN and Standard 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 CN Are Standard IPv6 Nodes + +A.4.2. Case K: VMN and MIPv6 CN + + Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two + nodes may initiate Mobile IPv6 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: + + + + +Ng, et al. Informational [Page 20] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + 1 + MNN --- CN + VMN MIPv6 Node + + + Figure 17: MNN and CN are MIPv6 Mobile 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. + +A.4.3. Case L: VMN and Standard 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 with its Home Agent, which causes the flow to go out the + nested mobile network. The 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 is an MIPv6 Mobile Node and CN is a Standard IPv6 Node + + However, MNN may also decide to use its Care-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 [11] provides some mechanisms for controlling the + choice of the source address. + + + + + + + + +Ng, et al. Informational [Page 21] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +Appendix B. Example of How a Stalemate Situation Can Occur + + Section 2.7 describes the occurrence 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 LFN follow 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. + + + + + + + + + + + +Ng, et al. Informational [Page 22] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + /-----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, because the tunnel + between MR2 and HA2 had been previously torn down (when the mobile + net 1 moved from home). The communications between CN and LFN stops, + even though both mobile networks are connected to the Internet. + + + + + +Ng, et al. Informational [Page 23] + +RFC 4888 NEMO RO Problem Statement July 2007 + + + /-----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 and HA2, 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. + + + + + + + + + + + + + + + + +Ng, et al. Informational [Page 24] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +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: chanwah.ng@sg.panasonic.com + + + Pascal Thubert + Cisco Systems + Village d'Entreprises Green Side + 400, Avenue de Roumanille + Batiment T3, Biot - Sophia Antipolis 06410 + FRANCE + + EMail: pthubert@cisco.com + + + Masafumi Watari + KDDI R&D Laboratories Inc. + 2-1-15 Ohara + Fujimino, Saitama 356-8502 + JAPAN + + EMail: watari@kddilabs.jp + + + Fan Zhao + UC Davis + One Shields Avenue + Davis, CA 95616 + US + + Phone: +1 530 752 3128 + EMail: fanzhao@ucdavis.edu + + + + + + + + + + + + +Ng, et al. Informational [Page 25] + +RFC 4888 NEMO RO Problem Statement July 2007 + + +Full Copyright Statement + + Copyright (C) The 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 INTERNET SOCIETY, 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Ng, et al. Informational [Page 26] + -- cgit v1.2.3