idnits 2.17.1 draft-ietf-nemo-ro-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 988. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2005) is 6773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-04 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-03 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '10') (Obsoleted by RFC 6724) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Expires: April 14, 2006 P. Thubert 5 Cisco Systems 6 M. Watari 7 KDDI R&D Labs 8 F. Zhao 9 UC Davis 10 October 11, 2005 12 Network Mobility Route Optimization Problem Statement 13 draft-ietf-nemo-ro-problem-statement-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 14, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 With current Network Mobility (NEMO) Basic Support, all 47 communications to and from Mobile Network Nodes must go through the 48 bi-directional tunnel established between the Mobile Router and Home 49 Agent when the mobile network is away. This results in various 50 inefficiencies associated with packet delivery. This document 51 investigates such inefficiencies, and provides for the motivation 52 behind Route Optimization (RO) for NEMO. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 4 58 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 59 2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 6 60 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6 61 2.4. Sub-Optimality with Combined Mobile IPv6 Route 62 Optimization . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 9 64 2.6. Instability of Communications within a Nested Mobile 65 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10 67 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 75 Appendix B. Various configurations involving Nested Mobile 76 Networks . . . . . . . . . . . . . . . . . . . . . . 15 77 B.1. CN located in the fixed infrastructure . . . . . . . . . . 15 78 B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 16 79 B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16 80 B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 16 81 B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 17 82 B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 18 83 B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18 84 B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 18 85 B.3. CN and MNN located in the same nested NEMO . . . . . . . . 19 86 B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 20 87 B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20 88 B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21 89 B.4. CN located behind the same nested MR . . . . . . . . . . . 21 90 B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22 91 B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 22 92 B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 94 Intellectual Property and Copyright Statements . . . . . . . . . . 25 96 1. Introduction 98 With current Network Mobility (NEMO) Basic Support [1], all 99 communications to and from nodes in a mobile network must go through 100 the bi-directional tunnel established between the Mobile Router and 101 its Home Agent when the mobile network is away. Although such an 102 arrangement allows Mobile Network Nodes to reach and be reached by 103 any node on the Internet , limitations associated to the base 104 protocol degrade overall performance of the network, and, ultimately, 105 can prevent all communications to and from the Mobile Network Nodes. 107 Some of these concerns already exist with Mobile IPv6 [4] and were 108 addressed by the mechanism known as Route Optimization, which is part 109 of the base protocol. With Mobile IPv6, Route Optimization mostly 110 improves the end to end path between Mobile Node and Correspondent 111 Node, with an additional benefit of reducing the load of the Home 112 Network, thus its name. 114 NEMO Basic Support presents a number of additional issues, making the 115 problem more complex, so it was decided to address Route Optimization 116 separately. In that case, the expected benefits are more dramatic, 117 and a Route Optimization mechanism could enable connectivity that 118 would be broken otherwise. In that sense, Route Optimization is even 119 more important to NEMO Basic Support than it is to Mobile IPv6. 121 This document explores limitations inherent in NEMO Basic Support, 122 and their effects on communications between a Mobile Network Node and 123 its corresponding peer. This is detailed in Section 2. It is 124 expected for readers to be familiar with general terminologies 125 related to mobility in [4][2], NEMO related terms defined in [3], and 126 NEMO goals and requirements [5]. 128 2. NEMO Route Optimization Problem Statement 130 In essence, the goal of Route Optimization in NEMO is to reduce 131 limitations and sub-optimalities introduced by the bi-directional 132 tunnel between a Mobile Router and its Home Agent (also known as the 133 MRHA tunnel). In the following sub-sections, we will describe the 134 effects of sub-optimal routing with NEMO Basic Support, how it may 135 cause a bottleneck to be formed in the home network, and how these 136 get amplified with nesting of mobile networks. Closely related to 137 nesting, we will also look into the sub-optimality even when Mobile 138 IPv6 Route Optimization is used over NEMO Basic Support. This is 139 followed by a description of security policy in home network that may 140 forbid transit traffic from Visiting Mobile Nodes in mobile networks. 141 In addition, we will explore the impact of MRHA tunnel on 142 communications between two Mobile Network Nodes on different links of 143 the same mobile network. We will also provide additional motivations 144 for Route Optimization by considering the potential deadlock 145 situation when a Home Agent is part of a mobile network. 147 2.1. Sub-Optimality with NEMO Basic Support 149 With NEMO Basic Support, all packets sent between a Mobile Network 150 Node and its Correspondent Node are forwarded through the MRHA 151 tunnel, resulting in a sub-optimal path between the two nodes. This 152 sub-optimality has the following undesirable effects: 154 o Longer route leading to increased delay and additional 155 infrastructure load 157 Because a packet must transit from a mobile network to the Home 158 Agent then to the Correspondent Node, the transit time of the 159 packet is usually longer than if the packet were to go straight 160 from the mobile network to the Correspondent Node. When the 161 Correspondent Node (or the mobile network) resides near the Home 162 Agent, the increase in packet delay can be very small. However 163 when the mobile network and the Correspondent Node are relatively 164 near to one another but far away from the Home Agent on the 165 Internet, the increase in delay is very large. Applications such 166 as real-time multimedia streaming may not be able to tolerate such 167 increase in packet delay. In general, the increase in delay may 168 also impact the performance of transport protocols such as TCP, 169 since the sending rate of TCP is partly determined by the round- 170 trip-time (RTT) perceived by the communication peers. 172 Moreover, by using a longer route, the total resource utilization 173 for the traffic would be much higher than if the packets were to 174 follow a direct path between the Mobile Network Node and 175 Correspondent Node. This would result in additional load in the 176 infrastructure. 178 o Increased packet overhead 180 The encapsulation of packets in the MRHA tunnel results in 181 increased packet size due to addition of an outer header. This 182 reduces the bandwidth efficiency, as IPv6 header can be quite 183 substantial relative to the payload for applications such as voice 184 samples. For instance, given a voice application using a 8kbps 185 algorithm (e.g. G.729) and taking a voice sample every 20ms (as 186 in RFC 1889), the packet transmission rate will be 50 packets per 187 second. Each additional IPv6 header is an extra 320 bits per 188 packet (i.e. 16kbps), which is twice the actual payload! 190 o Increased processing delay 192 The encapsulation of packets in the MRHA tunnel also results in 193 increased processing delay at the points of encapsulation and 194 decapsulation. Such increased processing may include encryption/ 195 decryption, topological correctness verifications, MTU 196 computation, fragmentation and reassembly. 198 o Increased chances of packet fragmentation 200 The augmentation in packet size due to packet encapsulation may 201 increase the chances of the packet being fragmented along the MRHA 202 tunnel. This can occur if there is no prior path MTU discovery 203 conducted, or if the MTU discovery mechanism did not take into 204 account the encapsulation of packets. Packets fragmentation will 205 result in a further increase in packet delays, and further 206 reduction of bandwidth efficiency. 208 o Increased susceptibility to link failure 210 Under the assumption that each link has the same probability of 211 link failure, a longer routing path would be more susceptibility 212 to link failure. Thus, packets routed through the MRHA tunnel may 213 be subjected to a higher probability of being lost or delayed due 214 to link failure, compared to packets that traverse directly 215 between the Mobile Network Node and its Correspondent Node. 217 2.2. Bottleneck in Home Network 219 Apart from the increase in packet delay and infrastructure load, 220 forwarding packets through the Home Agent may also lead to either the 221 Home Agent or the Home Link becoming a bottleneck for the aggregated 222 traffic from/to all the Mobile Network Nodes. A congestion at home 223 would lead to additional packet delay, or even packet loss. In 224 addition, Home Agent operations such as security check, packet 225 interception and tunneling might not be as optimized in the Home 226 Agent software as plain packet forwarding. This could further limit 227 the Home Agent capacity for data traffic. Furthermore, with all 228 traffic having to pass through the Home Link, the Home Link becomes a 229 single point of failure for the mobile network. 231 Data packets that are delayed or discarded due to congestion at the 232 home network would cause additional performance degradation to 233 applications. Signaling packets, such as Binding Update messages, 234 that are delayed or discarded due to congestion at the home network, 235 may affect the establishment or update of bi-directional tunnels, 236 causing disruption of all traffic flow through these tunnels. 238 A NEMO Route Optimization mechanism that allows the Mobile Network 239 Nodes to communicate with their Correspondent Nodes via a path that 240 is different from the MRHA tunneling and thereby avoiding the Home 241 Agent, may alleviate or even prevent the congestion at the Home Agent 242 or Home Link. 244 2.3. Amplified Sub-Optimality in Nested Mobile Networks 246 By allowing other mobile nodes to join a mobile network, and in 247 particular mobile routers, it is possible to form arbitrary levels of 248 nesting of mobile networks. With such nesting, the use of NEMO Basic 249 Support further amplifies the sub-optimality of routing. We call 250 this the amplification effect of nesting, where the undesirable 251 effects of sub-optimal routing with NEMO Basic Support are amplified 252 with each level of nesting of mobile networks. This is best 253 illustrated by an example shown in Figure 1. 255 +--------+ +--------+ +--------+ +--------+ 256 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 257 +------+-+ +---+----+ +---+----+ +-+------+ 258 \ | | / 259 +--------+ +------------------------------+ 260 | MR1_HA |----| Internet |-----CN1 261 +--------+ +------------------------------+ 262 | 263 +---+---+ 264 root-MR | MR1 | 265 +-------+ 266 | | 267 +-------+ +-------+ 268 sub-MR | MR2 | | MR4 | 269 +---+---+ +---+---+ 270 | | 271 +---+---+ +---+---+ 272 sub-MR | MR3 | | MR5 | 273 +---+---+ +---+---+ 274 | | 275 ----+---- ----+---- 276 MNN CN2 278 Figure 1: An example of nested Mobile Network 280 Using NEMO Basic Support, the flow of packets between a Mobile 281 Network Node, MNN, and a Correspondent Node, CN1, would need to go 282 through three separate tunnels, illustrated in Figure 2 below. 284 ----------. 285 ---------/ /----------. 286 -------/ | | /------- 287 MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 288 MR3-------\ | | \-------MR3_HA 289 MR2--------\ \----------MR2_HA 290 MR1---------MR1_HA 292 Figure 2: Nesting of Bi-Directional Tunnels 293 This leads to the following problems: 295 o Sub-optimal routing 297 Both inbound and outbound packets will flow via the Home Agents of 298 all the Mobile Routers on their paths within the mobile network, 299 with increased latency, less resilience and more bandwidth usage. 300 Appendix B illustrates in detail the packets routes under 301 different nesting configurations of the Mobile Network Nodes. 303 o Increased Packet Size 305 An extra IPv6 header is added per level of nesting to all the 306 packets. The header compression suggested in [6] cannot be 307 applied because both the source and destination (the intermediate 308 Mobile Router and its Home Agent), are different hop to hop. 310 Nesting also amplifies the probability of congestion at the home 311 networks of the upstream Mobile Routers. In addition, the Home Link 312 of each upstream Mobile Router will also be a single point of failure 313 for the nested Mobile Router. 315 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization 317 When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 318 Mobile Node of the mobile network. Packets sent to and from the 319 Visiting Mobile Node will have to be routed not only via the Home 320 Agent of the Visiting Mobile Node, but also via the Home Agent of the 321 Mobile Router in the mobile network. This suffers the same 322 amplification effect of nested mobile network mentioned in 323 Section 2.3. 325 In addition, although Mobile IPv6 [4] allows a mobile host to perform 326 Route Optimization with its Correspondent Node in order to avoid 327 tunneling with its Home Agent, the "optimized" route is no longer 328 optimized when the mobile host is attached to a mobile network. This 329 is because the route between the mobile host and its Correspondent 330 Node is subjected to the sub-optimality introduced by the MRHA 331 tunnel. Interested readers may refer to Appendix B for examples of 332 how the routes will appear with nesting of Mobile IPv6 hosts in 333 mobile networks. 335 The readers should also note that the same sub-optimality would apply 336 when the mobile host is outside the mobile network and its 337 Correspondent Node is in the mobile network. 339 2.5. Security Policy Prohibiting Traffic From Visiting Nodes 341 NEMO Basic Support requires all traffic from visitors to be tunneled 342 to the Mobile Router's Home Agent. This might represent a breach in 343 the security of the home network (some specific attacks against the 344 Mobile Router's binding by rogue visitors have been documented in 345 [7][8]). Administrators might thus fear that malicious packets will 346 be routed into the Home Network via the bi-directional tunnel. As a 347 consequence, it can be expected that in many deployment scenarios, 348 policies will be put in place to prevent unauthorized Visiting Mobile 349 Nodes from attaching to the Mobile Router. 351 However, there are deployment scenarios where allowing unauthorized 352 Visiting Mobile Nodes is actually desirable. For instance, when 353 Mobile Routers attach to other Mobile Routers and form a nested NEMO, 354 they depend on each other to reach the Internet. When Mobile Routers 355 have no prior knowledge of one another (no security association, AAA, 356 PKI etc...), it could still be acceptable to forward packets, 357 provided that the packets are not tunneled back to the Home Networks. 359 A Route Optimization mechanism that allows traffic from Mobile 360 Network Nodes to by-pass the bi-directional tunnel between a Mobile 361 Router and its Home Agent would be a necessary first step towards a 362 Tit for Tat model, where MRs would benefit from a reciprocal 363 altruism, based on anonymity and innocuousness, to extend the 364 Internet infrastructure dynamically. 366 2.6. Instability of Communications within a Nested Mobile Network 368 Within a nested mobile network, two Mobile Network Nodes may 369 communicate with each other. Let us consider the previous example 370 illustrated in Figure 1 where MNN and CN2 are sharing a communication 371 session. With NEMO Basic Support, a packet sent from MNN to CN2 will 372 need to be forwarded to the Home Agent of each Mobile Router before 373 reaching CN2. Whereas, a packet following the direct path between 374 them need not even leave the mobile network. Readers are referred to 375 Appendix B.3 for detailed illustration of the resulting routing 376 paths. 378 Apart from the consequences of increased packet delay and packet size 379 which are discussed in previous sub-sections, there are two 380 additional effects that are undesirable: 382 o when the nested mobile network is disconnected from the Internet 383 (e.g. MR1 loses its egress connectivity), MNN and CN2 can no 384 longer communicate with each other, even though the direct path 385 from MNN to CN2 is unaffected; 387 o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a 388 bottleneck for all the traffic that is coming in and out of the 389 nested mobile network. 391 A Route Optimization mechanism could allow traffic between two Mobile 392 Network Nodes nested within the same mobile network to follow a 393 direct path between them, without being routed out of the mobile 394 network. This may also off-load the processing burden of the 395 upstream Mobile Routers when the direct path between the two Mobile 396 Network Nodes does not traverse these Mobile Routers. 398 2.7. Stalemate with a Home Agent Nested in a Mobile Network 400 Several configurations for the Home Network are described in [9]. In 401 particular, there is a mobile home scenario where a (parent) Mobile 402 Router is also a Home Agent for its mobile network. In other words, 403 the mobile network is itself an aggregation of Mobile Network 404 Prefixes assigned to (children) Mobile Routers. 406 A stalemate situation exists in the case where the parent Mobile 407 Router visits one of its children. The child Mobile Router cannot 408 find its Home Agent in the Internet and thus cannot establish its 409 MRHA tunnel and forward the visitors traffic. The traffic from the 410 parent is thus blocked from reaching the Internet and it will never 411 bind to its own (grand parent) Home Agent. 413 Then again, a Route Optimization mechanism that bypasses the nested 414 tunnel might enable the parent traffic to reach the Internet and let 415 it bind. At that point, the child Mobile Router would be able to 416 reach its parent and bind in turn. Additional nested Route 417 Optimization solutions might also enable the child to locate its Home 418 Agent in the nested structure and bind regardless of whether the 419 Internet is reachable or not. 421 3. Conclusion 423 With current NEMO Basic Support, all communications to and from 424 Mobile Network Nodes must go through the MRHA tunnel when the mobile 425 network is away. This results in various inefficiencies associated 426 with packet delivery. This document investigates such 427 inefficiencies, and provides for the motivation behind Route 428 Optimization for NEMO. 430 We have described the effects of sub-optimal routing with NEMO Basic 431 Support, how it may cause a bottleneck to be formed in the home 432 network, and how they get amplified with nesting of mobile networks. 433 These effects will also be seen even when Mobile IPv6 Route 434 Optimization is used over NEMO Basic Support. In addition, other 435 issues concerning the nesting of mobile networks that might provide 436 additional motivation for a NEMO Route Optimization mechanism were 437 also explored, such as the prohibition of forwarding traffic from a 438 Visiting Mobile Node through a MRHA tunnel due to security concerns, 439 the impact of MRHA tunnel on communications between two Mobile 440 Network Nodes on different links of the same mobile network, and the 441 possibility of deadlock when Home Agents are nested within a mobile 442 network. 444 4. IANA Considerations 446 This is an informational document and does not require any IANA 447 action. 449 5. Security Considerations 451 This document highlights some limitations of the NEMO Basic Support. 452 In particular, some security concerns could prevent interesting 453 applications of the protocol, as detailed in Section 2.5. 455 Route Optimization for RFC 3963 [1] might introduce new threats, just 456 as it might alleviate existing ones. This aspect will certainly be a 457 key criterion in the evaluation of the proposed solutions. 459 6. Acknowledgments 461 The authors wish to thank the co-authors of previous drafts from 462 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 463 Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. In addition, 464 sincere appreciation is also extended to Jari Arkko, Carlos 465 Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik 466 Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and 467 Patrick Wetterwald for their various contributions. 469 7. References 471 7.1. Normative Reference 473 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 474 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 475 January 2005. 477 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 478 RFC 3753, June 2004. 480 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 481 draft-ietf-nemo-terminology-03 (work in progress), 482 February 2005. 484 7.2. Informative Reference 486 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 487 IPv6", RFC 3775, June 2004. 489 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 490 draft-ietf-nemo-requirements-04 (work in progress), 491 February 2005. 493 [6] Deering, S. and B. Zill, "Redundant Address Deletion when 494 Encapsulating IPv6 in IPv6", 495 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 496 November 2001. 498 [7] Petrescu, A., "Threats for Basic Network Mobility Support (NEMO 499 threats)", draft-petrescu-nemo-threats-01 (work in progress), 500 January 2004. 502 [8] Jung, S., "Threat Analysis on NEMO Basic Operations", 503 draft-jung-nemo-threat-analysis-02 (work in progress), 504 July 2004. 506 [9] Thubert, P., "NEMO Home Network models", 507 draft-ietf-nemo-home-network-models-03 (work in progress), 508 March 2005. 510 [10] Draves, R., "Default Address Selection for Internet Protocol 511 version 6 (IPv6)", RFC 3484, February 2003. 513 Appendix A. Change Log 515 o draft-ietf-nemo-ro-problem-statement-01: 517 * Added text on effect on TCP contributed by Carlos in Sect 2.1 - 518 "Sub-Optimality with NEMO Basic Support" 520 * Added text on VMN using CoA as source address in Appendix B.4.3 522 * Re-written Section 2.5 - "Security Policy Prohibiting Traffic 523 From Visiting Nodes" 525 * Replaced "deadlock" with "stalemate" in Section 2.7. 527 * Minor typographical corrections 529 o draft-ietf-nemo-ro-problem-statement-00: 531 * Initial version adapted from Section 1 & 2 of 532 'draft-thubert-nemo-ro-taxonomy-04.txt' 534 * Added Section 2.2: Bottleneck in the Home Network 536 * Added Section 2.5: Security Policy Prohibiting Traffic From 537 Visiting Nodes 539 * Added Section 2.7: Deadlock with a Home Agent Nested in a 540 Mobile Network 542 * Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt' 544 Appendix B. Various configurations involving Nested Mobile Networks 546 In the following sections, we try to describe different communication 547 models which involve a nested mobile network, and to clarify the 548 issues for each cases. We illustrate the path followed by packets if 549 we assume nodes only use Mobile IPv6 and NEMO Basic Support 550 mechanisms. Different cases are considered where a Correspondent 551 Node is located in the fixed infrastructure, in a distinct nested 552 mobile network as the Mobile Network Node, or in the same nested 553 mobile network as the Mobile Network Node. Additionally, cases where 554 Correspondent Nodes and Mobile Network Nodes are either standard IPv6 555 nodes or Mobile IPv6 nodes are considered. As defined in [3], 556 standard IPv6 nodes are nodes with no mobility functions whatsoever, 557 i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not 558 only can they not move around keeping open connections, but also they 559 cannot process Binding Updates sent by peers. 561 B.1. CN located in the fixed infrastructure 563 The most typical configuration is the case where a Mobile Network 564 Node communicates with a Correspondent Node attached in the fixed 565 infrastructure. Figure 3 below shows an example of such topology. 567 +--------+ +--------+ +--------+ 568 | MR1_HA | | MR2_HA | | MR3_HA | 569 +---+----+ +---+----+ +---+----+ 570 | | | 571 +-------------------------+ 572 | Internet |----+ CN 573 +-------------------------+ 574 | | 575 +---+---+ +--+-----+ 576 root-MR | MR1 | | VMN_HA | 577 +---+---+ +--------+ 578 | 579 +---+---+ 580 sub-MR | MR2 | 581 +---+---+ 582 | 583 +---+---+ 584 sub-MR | MR3 | 585 +---+---+ 586 | 587 ----+---- 588 MNN 590 Figure 3: CN located at the infrastructure 592 B.1.1. Case A: LFN and standard IPv6 CN 594 The simplest case is where both MNN and CN are fixed nodes with no 595 mobility functions. That is, MNN is a Local Fixed Node, and CN is a 596 standard IPv6 node. Packets are encapsulated between each Mobile 597 Router and its respective Home Agent. As shown in Figure 4, in such 598 case, the path between the two nodes would go through: 600 1 2 3 4 3 2 1 601 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 602 LFN IPv6 Node 604 The digits represent the number of IPv6 headers. 606 Figure 4: MNN and CN are standard IPv6 nodes 608 B.1.2. Case B: VMN and MIPv6 CN 610 In this second case, both end nodes are Mobile IPv6 enabled mobile 611 nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route 612 optimization may thus be initiated between the two and packets 613 wouldn't go through the Home Agent of the Visiting Mobile Node nor 614 the Home Agent of the Correspondent Node (not shown in the figure). 615 However, packets will still be tunneled between each Mobile Router 616 and its respective Home Agent, in both directions. As shown in 617 Figure 5, the path between MNN and CN would go through: 619 1 2 3 4 3 2 1 620 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 621 VMN MIPv6 623 Figure 5: MNN and CN are MIPv6 mobile nodes 625 B.1.3. Case C: VMN and standard IPv6 CN 627 When the communication involves a Mobile IPv6 node either as a 628 Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route 629 optimization cannot be performed because the standard IPv6 630 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, 631 MNN would establish a bi-directional tunnel with its HA, which causes 632 the flow to go out the nested NEMO. Packets between MNN and CN would 633 thus go through MNN's own Home Agent (VMN_HA). The path would 634 therefore be as shown on Figure 6: 636 2 3 4 5 4 637 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA 638 VMN | 639 | 3 640 1 2 | 641 CN --- VMN_HA --- MR3_HA 642 IPv6 Node 644 Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 646 Providing Route Optimization involving a Mobile IPv6 node may require 647 optimization among the Mobile Routers and the Mobile IPv6 node. 649 B.2. CN located in distinct nested NEMOs 651 The Correspondent Node may be located in another nested mobile 652 network, different from the one MNN is attached to, as shown in 653 Figure 7. We define such configuration as "distinct nested mobile 654 networks". 656 +--------+ +--------+ +--------+ +--------+ 657 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 658 +------+-+ +---+----+ +---+----+ +-+------+ 659 \ | | / 660 +--------+ +-------------------------+ +--------+ 661 | MR1_HA |----| Internet |----| VMN_HA | 662 +--------+ +-------------------------+ +--------+ 663 | | 664 +---+---+ +---+---+ 665 root-MR | MR1 | | MR4 | 666 +---+---+ +---+---+ 667 | | 668 +---+---+ +---+---+ 669 sub-MR | MR2 | | MR5 | 670 +---+---+ +---+---+ 671 | | 672 +---+---+ ----+---- 673 sub-MR | MR3 | CN 674 +---+---+ 675 | 676 ----+---- 677 MNN 679 Figure 7: MNN and CN located in distinct nested NEMOs 681 B.2.1. Case D: LFN and standard IPv6 CN 683 Similar with Case A, we start off with the case where both end nodes 684 do not have any mobility functions. Packets are encapsulated at 685 every mobile router on the way out the nested mobile network, 686 decapsulated by the Home Agents and then encapsulated again on its 687 way down the nested mobile network. 689 1 2 3 4 3 2 690 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 691 LFN | 692 | 1 693 1 2 3 2 | 694 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 695 IPv6 Node 697 Figure 8: MNN and CN are standard IPv6 nodes 699 B.2.2. Case E: VMN and MIPv6 CN 701 Similar with Case B, when both end nodes are Mobile IPv6 nodes, the 702 two nodes may initiate Mobile IPv6 route optimization. Again, 703 packets will not go through the Home Agent of the MNN nor the Home 704 Agent of the Mobile IPv6 Correspondent Node (not shown in the 705 figure). However, packets will still be tunneled for each Mobile 706 Router to its Home Agent and vise versa. Therefore, the path between 707 MNN and CN would go through: 709 1 2 3 4 3 2 710 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 711 VMN | 712 | 1 713 1 2 3 2 | 714 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 715 MIPv6 Node 717 Figure 9: MNN and CN are MIPv6 mobile nodes 719 B.2.3. Case F: VMN and standard IPv6 CN 721 Similar to Case C, when the communication involves a Mobile IPv6 node 722 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 723 route optimization can not be performed because the standard IPv6 724 Correspondent Node cannot process Mobile IPv6 signaling. MNN would 725 therefore establish a bi-directional tunnel with its Home Agent. 726 Packets between MNN and CN would thus go through MNN's own Home Agent 727 as shown on figure Figure 10: 729 2 3 4 5 4 3 730 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 731 VMN | 732 | 2 733 1 2 3 2 1 | 734 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA 735 IPv6 Node 737 Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 739 B.3. CN and MNN located in the same nested NEMO 741 Figure 11 below shows the case where the two communicating nodes are 742 connected behind different Mobile Routers that are connected in the 743 same nested mobile network, and thus behind the same root Mobile 744 Router. Route optimization can avoid packets being tunneled outside 745 the nested mobile network. 747 +--------+ +--------+ +--------+ +--------+ 748 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 749 +------+-+ +---+----+ +---+----+ +-+------+ 750 \ | | / 751 +--------+ +-------------------------+ +--------+ 752 | MR1_HA |----| Internet |----| VMN_HA | 753 +--------+ +-------------------------+ +--------+ 754 | 755 +---+---+ 756 root-MR | MR1 | 757 +-------+ 758 | | 759 +-------+ +-------+ 760 sub-MR | MR2 | | MR4 | 761 +---+---+ +---+---+ 762 | | 763 +---+---+ +---+---+ 764 sub-MR | MR3 | | MR5 | 765 +---+---+ +---+---+ 766 | | 767 ----+---- ----+---- 768 MNN CN 770 Figure 11: CN and MNN located in the same nested NEMO 772 B.3.1. Case G: LFN and standard IPv6 CN 774 Again, we start off with the case where both end nodes do not have 775 any mobility functions. Packets are encapsulated at every Mobile 776 Router on the way out the nested mobile network via the root Mobile 777 Router, decapsulated and encapsulated by the Home Agents and then 778 make their way back to the nested mobile network through the same 779 root Mobile Router. Therefore, the path between MNN and CN would go 780 through: 782 1 2 3 4 3 2 783 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 784 LFN | 785 | 1 786 1 2 3 4 3 2 | 787 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 788 IPv6 Node 790 Figure 12: MNN and CN are standard IPv6 nodes 792 B.3.2. Case H: VMN and MIPv6 CN 794 Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, 795 the two nodes may initiate Mobile IPv6 route optimization which will 796 avoid the packets to go through the Home Agent of MNN nor the Home 797 Agent of the Mobile IPv6 CN (not shown in the figure). However, 798 packets will still be tunneled between each Mobile Router and its 799 respective Home Agent in both directions. Therefore, the path would 800 be the same with Case G and go through: 802 1 2 3 4 3 2 803 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 804 LFN | 805 | 1 806 1 2 3 4 3 2 | 807 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 808 MIPv6 Node 810 Figure 13: MNN and CN are MIPv6 mobile nodes 812 B.3.3. Case I: VMN and standard IPv6 CN 814 As for Case C and Case F, when the communication involves a Mobile 815 IPv6 node either as a Visiting Mobile Node or as a Correspondent 816 Node, Mobile IPv6 Route Optimization can not be performed. 817 Therefore, MNN will establish a bi-directional tunnel with its Home 818 Agent. Packets between MNN and CN would thus go through MNN's own 819 Home Agent. The path would therefore be as shown on Figure 14: 821 2 3 4 5 4 3 822 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 823 VMN | 824 | 2 825 | 826 VMN_HA 827 | 828 | 1 829 1 2 3 4 3 2 | 830 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 831 IPv6 Node 833 Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 835 B.4. CN located behind the same nested MR 837 Figure 15 below shows the case where the two communicating nodes are 838 connected behind the same nested Mobile Router. The optimization is 839 required when the communication involves MIPv6-enabled nodes. 841 +--------+ +--------+ +--------+ +--------+ 842 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 843 +------+-+ +---+----+ +---+----+ +-+------+ 844 \ | | / 845 +--------+ +-------------------------+ +--------+ 846 | MR1_HA |----| Internet |----| VMN_HA | 847 +--------+ +-------------------------+ +--------+ 848 | 849 +---+---+ 850 root-MR | MR1 | 851 +---+---+ 852 | 853 +-------+ 854 sub-MR | MR2 | 855 +---+---+ 856 | 857 +---+---+ 858 sub-MR | MR3 | 859 +---+---+ 860 | 861 -+--+--+- 862 MNN CN 864 Figure 15: MNN and CN located behind the same nested MR 866 B.4.1. Case J: LFN and standard IPv6 CN 868 If both end nodes are Local Fixed Nodes, no special function is 869 necessary for optimization of their communication. The path between 870 the two nodes would go through: 872 1 873 MNN --- CN 874 LFN IPv6 Node 876 Figure 16: MNN and CN are standard IPv6 nodes 878 B.4.2. Case K: VMN and MIPv6 CN 880 Similar with Case H, when both end nodes are Mobile IPv6 nodes, the 881 two nodes may initiate Mobile IPv6 route optimization. Although few 882 packets would go out the nested mobile network for the Return 883 Routability initialization, however, unlike Case B and Case E, 884 packets will not get tunneled outside the nested mobile network. 885 Therefore, packets between MNN and CN would eventually go through: 887 1 888 MNN --- CN 889 VMN MIPv6 Node 891 Figure 17: MNN and CN are MIPv6 mobile nodes 893 If the root Mobile Router is disconnected while the nodes exchange 894 keys for the Return Routability procedure, they may not communicate 895 even though they are connected on the same link. 897 B.4.3. Case L: VMN and standard IPv6 CN 899 When the communication involves a Mobile IPv6 node either as a 900 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 901 Route Optimization cannot be performed. Therefore, even though the 902 two nodes are on the same link, MNN will establish a bi-directional 903 tunnel with it's Home Agent, which causes the flow to go out the 904 nested mobile network. Path between MNN and CN would require another 905 Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 907 2 3 4 5 4 3 908 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 909 VMN | 910 | 2 911 | 912 VMN_HA 913 | 914 | 1 915 1 2 3 4 3 2 | 916 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 917 IPv6 Node 919 Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 921 However, MNN may also decide to use its care-of address as the source 922 address of the packets, thus avoiding the tunneling with the MNN's 923 Home Agent. This is particularly useful for a short-term 924 communication that may easily be retried if it fails. Default 925 Address Selection [10] provides some mechanisms for controlling the 926 choice of the source address. 928 Authors' Addresses 930 Chan-Wah Ng 931 Panasonic Singapore Laboratories Pte Ltd 932 Blk 1022 Tai Seng Ave #06-3530 933 Tai Seng Industrial Estate 934 Singapore 534415 935 SG 937 Phone: +65 65505420 938 Email: chanwah.ng@sg.panasonic.com 940 Pascal Thubert 941 Cisco Systems Technology Center 942 Village d'Entreprises Green Side 943 400, Avenue Roumanille 944 Biot - Sophia Antipolis 06410 945 FRANCE 947 Email: pthubert@cisco.com 949 Masafumi Watari 950 KDDI R&D Laboratories Inc. 951 2-1-15 Ohara 952 Fujimino, Saitama 356-8502 953 JAPAN 955 Email: watari@kddilabs.jp 957 Fan Zhao 958 University of California Davis 959 One Shields Avenue 960 Davis, CA 95616 961 US 963 Phone: +1 530 752 3128 964 Email: fanzhao@ucdavis.edu 966 Intellectual Property Statement 968 The IETF takes no position regarding the validity or scope of any 969 Intellectual Property Rights or other rights that might be claimed to 970 pertain to the implementation or use of the technology described in 971 this document or the extent to which any license under such rights 972 might or might not be available; nor does it represent that it has 973 made any independent effort to identify any such rights. Information 974 on the procedures with respect to rights in RFC documents can be 975 found in BCP 78 and BCP 79. 977 Copies of IPR disclosures made to the IETF Secretariat and any 978 assurances of licenses to be made available, or the result of an 979 attempt made to obtain a general license or permission for the use of 980 such proprietary rights by implementers or users of this 981 specification can be obtained from the IETF on-line IPR repository at 982 http://www.ietf.org/ipr. 984 The IETF invites any interested party to bring to its attention any 985 copyrights, patents or patent applications, or other proprietary 986 rights that may cover technology that may be required to implement 987 this standard. Please address the information to the IETF at 988 ietf-ipr@ietf.org. 990 Disclaimer of Validity 992 This document and the information contained herein are provided on an 993 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 994 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 995 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 996 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 997 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 998 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1000 Copyright Statement 1002 Copyright (C) The Internet Society (2005). This document is subject 1003 to the rights, licenses and restrictions contained in BCP 78, and 1004 except as set forth therein, the authors retain all their rights. 1006 Acknowledgment 1008 Funding for the RFC Editor function is currently provided by the 1009 Internet Society.