idnits 2.17.1 draft-ietf-nemo-ro-problem-statement-00.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 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 961. ** 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 == Line 646 has weird spacing: '...le Node or as...' -- 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 (July 4, 2005) is 6870 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) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == 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. '4') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '6') Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: January 5, 2006 P. Thubert 5 Cisco Systems 6 M. Watari 7 KDDI R&D Labs 8 F. Zhao 9 UC Davis 10 July 4, 2005 12 Network Mobility Route Optimization Problem Statement 13 draft-ietf-nemo-ro-problem-statement-00 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 January 5, 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 . 8 64 2.6 Instability of Communications within a Nested Mobile 65 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.7 Deadlock 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 . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.1 Normative Reference . . . . . . . . . . . . . . . . . . . 12 73 7.2 Informative Reference . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 75 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 B. Various configurations involving Nested Mobile 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 . . . . . . . . . . . . . . . 21 88 B.3.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21 89 B.4 CN located behind the same nested MR . . . . . . . . . . . 22 90 B.4.1 Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22 91 B.4.2 Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23 92 B.4.3 Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23 93 Intellectual Property and Copyright Statements . . . . . . . . 24 95 1. Introduction 97 With current Network Mobility (NEMO) Basic Support [1], all 98 communications to and from nodes in a mobile network must go through 99 the bi-directional tunnel established between the Mobile Router and 100 its Home Agent when the mobile network is away. Although such an 101 arrangement allows Mobile Network Nodes to reach and be reached by 102 any node on the Internet at all time, limitations associated to the 103 base protocol degrade overall performance of the network, and, 104 ultimately, can prevent all communications to and from the Mobile 105 Network Nodes. 107 Some of these concerns already exist with Mobile IPv6 [2] 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 [2][3], NEMO related terms defined in [4], 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 higher than if the packet were to go straight 160 from the mobile network to the Correspondent Node. In the best 161 case, where the Correspondent Node (or the mobile network) resides 162 near the Home Agent, the increase in packet delay is minimal. In 163 the worst case, where the mobile network and the Correspondent 164 Node are relatively near to one another but far away from the Home 165 Agent on the Internet, the increase in delay is tremendous. 166 Applications such as real-time multimedia streaming may not be 167 able to tolerate such increase in packet delay. 169 Moreover, by using a longer route, the total resource utilization 170 for the traffic would be much higher than if the packets were to 171 follow a direct path between the Mobile Network Node and 172 Correspondent Node. This would result in additional load in the 173 infrastructure. 175 o Increased packets overhead 177 The encapsulation of packets in the MRHA tunnel results in 178 increased packet size due to addition of an outer header. This 179 reduces the bandwidth efficiency, as IPv6 header can be quite 180 substantial relative to the payload for applications such as voice 181 samples. For instance, consider a voice application using a 8kbps 182 algorithm (e.g. G.729) and taking a voice sample every 20ms (as 183 in RFC 1889). The packet transmission rate will be 50 packets per 184 second. IPv6/UDP/RTP header cause an overhead of 384 bits (i.e. 185 19200bps of overhead). Each additional IPv6 header is an extra 186 16kpbs, which is twice the actual payload. 188 o Increased processing delay 190 The encapsulation of packets in the MRHA tunnel also results in 191 increased processing delay at the points of encapsulation and 192 decapsulation. Such increased processing may include encryption/ 193 decryption, topological correctness verifications, MTU 194 computation, fragmentation and reassembly. 196 o Increased chances of packet fragmentation 198 The augmentation in packet size due to packet encapsulation may 199 increase the chances of the packet being fragmented along the MRHA 200 tunnel. This can occur if there is no prior path MTU discovery 201 conducted, or if the MTU discovery mechanism did not take into 202 account the encapsulation of packets. Packets fragmentation will 203 result in a further increase in packet delays, and further 204 reduction of bandwidth efficiency. 206 o Increased susceptibility to link failure 208 Under the assumption that each link has the same probability of 209 link failure, a longer routing path would be more susceptibility 210 to link failure. Thus, packets routed through the MRHA tunnel may 211 be subjected to a higher probability of being lost or delayed due 212 to link failure, compared to packets that traverse directly 213 between the Mobile Network Node and its Correspondent Node. 215 2.2 Bottleneck in Home Network 217 Apart from the increase in packet delay and infrastructure load, 218 forwarding packets through the Home Agent may also lead to either the 219 Home Agent or the Home Link becoming a bottleneck for the aggregated 220 traffic from/to all the Mobile Network Nodes. A congestion at home 221 would lead to additional packet delay, or even packet loss. In 222 addition, Home Agent operations such as security check, packet 223 interception and tunneling might not be as optimized in the Home 224 Agent software as plain packet forwarding. This could further limit 225 the Home Agent capacity for data traffic. Furthermore, with all 226 traffic having to pass through the Home Link, the Home Link becomes a 227 single point of failure for the mobile network. 229 Data packets that are delayed or discarded due to congestion at the 230 home network would cause additional performance degradation to 231 applications. Signaling packets, such as Binding Update messages, 232 that are delayed or discarded due to congestion at the home network, 233 may affect the establishment or update of bi-directional tunnels, 234 causing disruption of all traffic flow through these tunnels. 236 A NEMO Route Optimization mechanism that allows the Mobile Network 237 Nodes to communicate with their Correspondent Nodes via a path that 238 is different from the MRHA tunneling and thereby avoiding the Home 239 Agent, may alleviate or even prevent the congestion at the Home Agent 240 or Home Link. 242 2.3 Amplified Sub-Optimality in Nested Mobile Networks 244 By allowing other mobile nodes to join a mobile network, and in 245 particular mobile routers, it is possible to form arbitrary levels of 246 nesting of mobile networks. With such nesting, the use of NEMO Basic 247 Support further amplifies the sub-optimality of routing. We call 248 this the amplification effect of nesting, where the undesirable 249 effects of sub-optimal routing with NEMO Basic Support are amplified 250 with each level of nesting of mobile networks. This is best 251 illustrated by an example shown in Figure 1. 253 +--------+ +--------+ +--------+ +--------+ 254 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 255 +------+-+ +---+----+ +---+----+ +-+------+ 256 \ | | / 257 +--------+ +------------------------------+ 258 | MR1_HA |----| Internet |-----CN1 259 +--------+ +------------------------------+ 260 | 261 +---+---+ 262 root-MR | MR1 | 263 +-------+ 264 | | 265 +-------+ +-------+ 266 sub-MR | MR2 | | MR4 | 267 +---+---+ +---+---+ 268 | | 269 +---+---+ +---+---+ 270 sub-MR | MR3 | | MR5 | 271 +---+---+ +---+---+ 272 | | 273 ----+---- ----+---- 274 MNN CN2 276 Figure 1: An example of nested Mobile Network 278 Using NEMO Basic Support, the flow of packets between a Mobile 279 Network Node, MNN, and a Correspondent Node, CN1, would need to go 280 through three separate tunnels, illustrated in Figure 2 below. 282 ----------. 283 ---------/ /----------. 284 -------/ | | /------- 285 MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 286 MR3-------\ | | \-------MR3_HA 287 MR2--------\ \----------MR2_HA 288 MR1---------MR1_HA 290 Figure 2: Nesting of Bi-Directional Tunnels 292 This leads to the following problems: 294 o Sub-optimal routing 296 Both inbound and outbound packets will flow via the Home Agents of 297 all the Mobile Routers on their paths within the mobile network, 298 with increased latency, less resilience and more bandwidth usage. 299 Appendix B illustrates in detail the packets routes under 300 different nesting configurations of the Mobile Network Nodes. 302 o Increased Packet Size 304 An extra IPv6 header is added per level of nesting to all the 305 packets. The header compression suggested in [7] cannot be 306 applied because both the source and destination (the intermediate 307 Mobile Router and its Home Agent), are different hop to hop. 309 Nesting also amplifies the probability of congestion at the home 310 networks of the upstream Mobile Routers. In addition, the Home Link 311 of each upstream Mobile Router will also be a single point of failure 312 for the nested Mobile Router. 314 2.4 Sub-Optimality with Combined Mobile IPv6 Route Optimization 316 When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 317 Mobile Node of the mobile network. Packets sent to and from the 318 Visiting Mobile Node will have to be routed not only via the Home 319 Agent of the Visiting Mobile Node, but also via the Home Agent of the 320 Mobile Router in the mobile network. This suffers the same 321 amplification effect of nested mobile network mentioned in 322 Section 2.3. 324 In addition, although Mobile IPv6 [2] allows a mobile host to perform 325 Route Optimization with its Correspondent Node in order to avoid 326 tunneling with its Home Agent, the "optimized" route is no longer 327 optimized when the mobile host is attached to a mobile network. This 328 is because the route between the mobile host and its Correspondent 329 Node is subjected to the sub-optimality introduced by the MRHA 330 tunnel. Interested readers may refer to Appendix B for examples of 331 how the routes will appear with nesting of Mobile IPv6 hosts in 332 mobile networks. 334 The readers should also note that the same sub-optimality would apply 335 when the mobile host is outside the mobile network and its 336 Correspondent Node is in the mobile network. 338 2.5 Security Policy Prohibiting Traffic From Visiting Nodes 340 The ability of Mobile Routers to attach to other Mobile Routers 341 allows the possibility for them to form a mesh that extends the 342 infrastructure dynamically, relaying each others packets to the 343 Internet. By providing reachability to one another, they cooperate 344 to improve the network availability for all parties. When Mobile 345 Routers have no prior knowledge of their peers (no Security 346 association, AAA, PKI etc...) it can still be mutually beneficial to 347 apply a form of reciprocal altruism based on anonymity and 348 innocuousness. In particular, it is possible to adopt a tit for tat 349 (T4T) strategy and forward traffic unless the other party proves to 350 be uncooperative when it is solicited. 352 On the other hand, NEMO Basic Support requires all the traffic from a 353 visitor to be tunneled to the Mobile Router's Home Agent. This might 354 represent a breach in the security of the home network (some specific 355 attacks against the Mobile Router binding by rogue visitors have been 356 documented in [8][9]). As a consequence, it can be expected that in 357 many deployments, policies will be put in place to prevent untrusted 358 visitors from attaching to the Mobile Router. This will block T4T 359 nested NEMO for developing widely. 361 A Route Optimization mechanism that would prevent the multiple re- 362 encapsulation of the packets by nested Mobile Routers might as a side 363 effect alleviate this limitation and leave the way to a more open and 364 efficient model for the fringe of the Internet. 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 processing burden of the upstream 395 Mobile Routers when the direct path between the two Mobile Network 396 Nodes does not traverse these Mobile Routers. 398 2.7 Deadlock with a Home Agent Nested in a Mobile Network 400 Several configurations for the Home Network are described in [6]. 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, that is further 404 subnetted in Mobile Network Prefixes, that are assigned to (children) 405 Mobile Routers. 407 A deadlock has been documented in the case where the parent Mobile 408 Router visits one of its children. The child Mobile Router can not 409 find its Home Agent in the Internet and thus cannot establish its 410 MRHA tunnel and forward the visitors traffic. The traffic from the 411 parent is thus blocked from reaching the Internet and it will never 412 bind to its own (grand parent) Home Agent. 414 Then again, a Route Optimization mechanism that bypasses the nested 415 tunnel might enable the parent traffic to reach the Internet and let 416 it bind. At that point, the child Mobile Router would be able to 417 reach its parent and bind in turn. Additional nested Route 418 Optimization solutions might also enable the child to locate its Home 419 Agent in the nested structure and bind regardless of whether the 420 reach to the Internet is available at all. 422 3. Conclusion 424 With current NEMO Basic Support, all communications to and from 425 Mobile Network Nodes must go through the MRHA tunnel when the mobile 426 network is away. This results in various inefficiencies associated 427 with packet delivery. This document investigates such 428 inefficiencies, and provides for the motivation behind Route 429 Optimization for NEMO. 431 We have described the effects of sub-optimal routing with NEMO Basic 432 Support, how it may cause a bottleneck to be formed in the home 433 network, and how they get amplified with nesting of mobile networks. 434 These effects will also be seen even when Mobile IPv6 Route 435 Optimization is used over NEMO Basic Support. In addition, other 436 issues concerning the nesting of mobile networks that might provide 437 additional motivation for a NEMO Route Optimization mechanism were 438 also explored, such as the prohibition of forwarding traffic from a 439 Visiting Mobile Node through a MRHA tunnel due to security concerns, 440 the impact of MRHA tunnel on communications between two Mobile 441 Network Nodes on different links of the same mobile network, and the 442 possibility of deadlock when Home Agents are nested within a mobile 443 network. 445 4. IANA Considerations 447 This is an informational document and does not require any IANA 448 action. 450 5. Security Considerations 452 This is an informational document that describes some limitations 453 with NEMO Basic Support and does not introduce any additional 454 security concerns. Please see RFC3963 [1] for security 455 considerations pertaining to the NEMO Basic Support protocol. 457 6. Acknowledgments 459 The authors wish to thank the co-authors of previous drafts from 460 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 461 Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. In addition, 462 sincere appreciation is also extended to Greg Daley, Erik Nordmark, 463 T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and 464 Patrick Wetterwald for their various contributions. 466 7. References 468 7.1 Normative Reference 470 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 471 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 472 January 2005. 474 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 475 IPv6", RFC 3775, June 2004. 477 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 478 RFC 3753, June 2004. 480 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 481 draft-ietf-nemo-terminology-03 (work in progress), 482 February 2005. 484 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 485 draft-ietf-nemo-requirements-04 (work in progress), 486 February 2005. 488 [6] Thubert, P., "NEMO Home Network models", 489 draft-ietf-nemo-home-network-models-03 (work in progress), 490 March 2005. 492 7.2 Informative Reference 494 [7] Deering, S. and B. Zill, "Redundant Address Deletion when 495 Encapsulating IPv6 in IPv6", 496 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 497 November 2001. 499 [8] Petrescu, A., "Threats for Basic Network Mobility Support (NEMO 500 threats)", draft-petrescu-nemo-threats-01 (work in progress), 501 January 2004. 503 [9] Jung, S., "Threat Analysis on NEMO Basic Operations", 504 draft-jung-nemo-threat-analysis-02 (work in progress), 505 July 2004. 507 Authors' Addresses 509 Chan-Wah Ng 510 Panasonic Singapore Laboratories Pte Ltd 511 Blk 1022 Tai Seng Ave #06-3530 512 Tai Seng Industrial Estate 513 Singapore 534415 514 SG 516 Phone: +65 65505420 517 Email: chanwah.ng@sg.panasonic.com 519 Pascal Thubert 520 Cisco Systems Technology Center 521 Village d'Entreprises Green Side 522 400, Avenue Roumanille 523 Biot - Sophia Antipolis 06410 524 FRANCE 526 Email: pthubert@cisco.com 528 Masafumi Watari 529 KDDI R&D Laboratories Inc. 530 2-1-15 Ohara 531 Kamifukuoka, Saitama 356-8502 532 JAPAN 534 Email: watari@kddilabs.jp 536 Fan Zhao 537 University of California Davis 538 One Shields Avenue 539 Davis, CA 95616 540 US 542 Phone: +1 530 752 3128 543 Email: fanzhao@ucdavis.edu 545 Appendix A. Change Log 547 o draft-ietf-nemo-ro-problem-statement-00: 549 * Initial version adapted from Section 1 & 2 of 550 'draft-thubert-nemo-ro-taxonomy-04.txt' 552 * Added Section 2.2: Bottleneck in the Home Network 554 * Added Section 2.5: Security Policy Prohibiting Traffic From 555 Visiting Nodes 557 * Added Section 2.7: Deadlock with a Home Agent Nested in a 558 Mobile Network 560 * Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt' 562 Appendix B. Various configurations involving Nested Mobile Networks 564 In the following sections, we try to describe different communication 565 models which involves a nested mobile network, and to clarify the 566 issues for each cases. We illustrate the path followed by packets if 567 we assume nodes only use Mobile IPv6 and NEMO Basic Support 568 mechanisms. Different cases are considered where a Correspondent 569 Node is located in the fixed infrastructure, in a distinct nested 570 mobile network as the Mobile Network Node, or in the same nested 571 mobile network as the Mobile Network Node. Additionally, cases where 572 Correspondent Nodes and Mobile Network Nodes are either standard IPv6 573 nodes or Mobile IPv6 nodes are considered. As defined in [4], 574 standard IPv6 nodes are nodes with no mobility functions whatsoever, 575 i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not 576 only can they not move around keeping open connections, but also they 577 cannot process Binding Updates sent by peers). 579 B.1 CN located in the fixed infrastructure 581 The most typical configuration is the case where a Mobile Network 582 Node communicates with a Correspondent Node attached in the fixed 583 infrastructure. Figure 3 below shows an example of such topology. 585 +--------+ +--------+ +--------+ 586 | MR1_HA | | MR2_HA | | MR3_HA | 587 +---+----+ +---+----+ +---+----+ 588 | | | 589 +-------------------------+ 590 | Internet |----+ CN 591 +-------------------------+ 592 | | 593 +---+---+ +--+-----+ 594 root-MR | MR1 | | VMN_HA | 595 +---+---+ +--------+ 596 | 597 +---+---+ 598 sub-MR | MR2 | 599 +---+---+ 600 | 601 +---+---+ 602 sub-MR | MR3 | 603 +---+---+ 604 | 605 ----+---- 606 MNN 608 Figure 3: CN located at the infrastructure 610 B.1.1 Case A: LFN and standard IPv6 CN 612 The simplest case is where both MNN and CN are fixed nodes with no 613 mobility functions. That is, MNN is a Local Fixed Node, and CN is a 614 standard IPv6 node. Packets are encapsulated between each Mobile 615 Router and its respective Home Agent. As shown in Figure 4, in such 616 case, the path between the two nodes would go through: 618 1 2 3 4 3 2 1 619 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 620 LFN IPv6 Node 622 The digits represent the number of IPv6 headers. 624 Figure 4: MNN and CN are standard IPv6 nodes 626 B.1.2 Case B: VMN and MIPv6 CN 628 In this second case, both end nodes are Mobile IPv6 enabled mobile 629 nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route 630 optimization may thus be initiated between the two and packets 631 wouldn't go through the Home Agent of the Visiting Mobile Node nor 632 the Home Agent of the Correspondent Node (not shown in the figure). 633 However, packets will still be tunneled between each Mobile Router 634 and its respective Home Agent, in both directions. As shown in 635 Figure 5, the path between MNN and CN would go through: 637 1 2 3 4 3 2 1 638 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 639 VMN MIPv6 641 Figure 5: MNN and CN are MIPv6 mobile nodes 643 B.1.3 Case C: VMN and standard IPv6 CN 645 When the communication involves a Mobile IPv6 node either as a 646 Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route 647 optimization cannot be performed because the standard IPv6 648 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, 649 MNN would establish a bi-directional tunnel with its HA, which causes 650 the flow to go out the nested NEMO. Packets between MNN and CN would 651 thus go through MNN's own Home Agent (VMN_HA). The path would 652 therefore be as shown on Figure 6: 654 2 3 4 5 4 655 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA 656 VMN | 657 | 3 658 1 2 | 659 CN --- VMN_HA --- MR3_HA 660 IPv6 Node 662 Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 664 Providing Route Optimization involving a Mobile IPv6 node may require 665 optimization among the Mobile Routers and the Mobile IPv6 node. 667 B.2 CN located in distinct nested NEMOs 669 The Correspondent Node may be located in another nested mobile 670 network, different from the one MNN is attached to, as shown on 671 Figure 7. We define such configuration as ``distinct nested mobile 672 networks.'' 674 +--------+ +--------+ +--------+ +--------+ 675 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 676 +------+-+ +---+----+ +---+----+ +-+------+ 677 \ | | / 678 +--------+ +-------------------------+ +--------+ 679 | MR1_HA |----| Internet |----| VMN_HA | 680 +--------+ +-------------------------+ +--------+ 681 | | 682 +---+---+ +---+---+ 683 root-MR | MR1 | | MR4 | 684 +---+---+ +---+---+ 685 | | 686 +---+---+ +---+---+ 687 sub-MR | MR2 | | MR5 | 688 +---+---+ +---+---+ 689 | | 690 +---+---+ ----+---- 691 sub-MR | MR3 | CN 692 +---+---+ 693 | 694 ----+---- 695 MNN 697 Figure 7: MNN and CN located in distinct nested NEMOs 699 B.2.1 Case D: LFN and standard IPv6 CN 701 Similar with Case A, we start off with the case where both end nodes 702 do not have any mobility functions. Packets are encapsulated at 703 every mobile router on the way out the nested mobile network, 704 decapsulated by the Home Agents and then encapsulated again on its 705 way down the nested mobile network. 707 1 2 3 4 3 2 708 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 709 LFN | 710 | 1 711 1 2 3 2 | 712 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 713 IPv6 Node 715 Figure 8: MNN and CN are standard IPv6 nodes 717 B.2.2 Case E: VMN and MIPv6 CN 719 Similar with Case B, when both end nodes are Mobile IPv6 nodes, the 720 two nodes may initiate Mobile IPv6 route optimization. Again, 721 packets will not go through the Home Agent of the MNN nor the Home 722 Agent of the Mobile IPv6 Correspondent Node (not shown in the 723 figure). However, packets will still be tunneled for each Mobile 724 Router to its Home Agent and vise versa. Therefore, the path between 725 MNN and CN would go through: 727 1 2 3 4 3 2 728 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 729 VMN | 730 | 1 731 1 2 3 2 | 732 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 733 MIPv6 Node 735 Figure 9: MNN and CN are MIPv6 mobile nodes 737 B.2.3 Case F: VMN and standard IPv6 CN 739 Similar to Case C, when the communication involves a Mobile IPv6 node 740 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 741 route optimization can not be performed because the standard IPv6 742 Correspondent Node cannot process Mobile IPv6 signaling. MNN would 743 therefore establish a bi-directional tunnel with its Home Agent. 744 Packets between MNN and CN would thus go through MNN's own Home Agent 745 as shown on figure Figure 10: 747 2 3 4 5 4 3 748 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 749 VMN | 750 | 2 751 1 2 3 2 1 | 752 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA 753 IPv6 Node 755 Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 757 B.3 CN and MNN located in the same nested NEMO 759 Figure 11 below shows the case where the two communicating nodes are 760 connected behind different Mobile Routers that are connected in the 761 same nested mobile network, and thus behind the same root Mobile 762 Router. Route optimization can avoid packets being tunneled outside 763 the nested mobile network. 765 +--------+ +--------+ +--------+ +--------+ 766 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 767 +------+-+ +---+----+ +---+----+ +-+------+ 768 \ | | / 769 +--------+ +-------------------------+ +--------+ 770 | MR1_HA |----| Internet |----| VMN_HA | 771 +--------+ +-------------------------+ +--------+ 772 | 773 +---+---+ 774 root-MR | MR1 | 775 +-------+ 776 | | 777 +-------+ +-------+ 778 sub-MR | MR2 | | MR4 | 779 +---+---+ +---+---+ 780 | | 781 +---+---+ +---+---+ 782 sub-MR | MR3 | | MR5 | 783 +---+---+ +---+---+ 784 | | 785 ----+---- ----+---- 786 MNN CN 788 Figure 11: CN and MNN located in the same nested NEMO 790 B.3.1 Case G: LFN and standard IPv6 CN 792 Again, we start off with the case where both end nodes do not have 793 any mobility functions. Packets are encapsulated at every Mobile 794 Router on the way out the nested mobile network via the root Mobile 795 Router, decapsulated and encapsulated by the Home Agents and then 796 make their way back to the nested mobile network through the same 797 root Mobile Router. Therefore, the path between MNN and CN would go 798 through: 800 1 2 3 4 3 2 801 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 802 LFN | 803 | 1 804 1 2 3 4 3 2 | 805 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 806 IPv6 Node 808 Figure 12: MNN and CN are standard IPv6 nodes 810 B.3.2 Case H: VMN and MIPv6 CN 812 Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, 813 the two nodes may initiate Mobile IPv6 route optimization which will 814 avoid the packets to go through the Home Agent of MNN nor the Home 815 Agent of the Mobile IPv6 CN (not shown in the figure). However, 816 packets will still be tunneled between each Mobile Router and its 817 respective Home Agent in both directions. Therefore, the path would 818 be the same with Case G and go through: 820 1 2 3 4 3 2 821 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 822 LFN | 823 | 1 824 1 2 3 4 3 2 | 825 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 826 MIPv6 Node 828 Figure 13: MNN and CN are MIPv6 mobile nodes 830 B.3.3 Case I: VMN and standard IPv6 CN 832 As for Case C and Case F, when the communication involves a Mobile 833 IPv6 node either as a Visiting Mobile Node or as a Correspondent 834 Node, Mobile IPv6 Route Optimization can not be performed. 835 Therefore, MNN will establish a bi-directional tunnel with its Home 836 Agent. Packets between MNN and CN would thus go through MNN's own 837 Home Agent. The path would therefore be as shown on Figure 14: 839 2 3 4 5 4 3 840 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 841 VMN | 842 | 2 843 | 844 VMN_HA 845 | 846 | 1 847 1 2 3 4 3 2 | 848 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 849 IPv6 Node 851 Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 853 B.4 CN located behind the same nested MR 855 Figure 15 below shows the case where the two communicating nodes are 856 connected behind the same nested Mobile Router. The optimization is 857 required when the communication involves MIPv6-enabled nodes. 859 +--------+ +--------+ +--------+ +--------+ 860 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 861 +------+-+ +---+----+ +---+----+ +-+------+ 862 \ | | / 863 +--------+ +-------------------------+ +--------+ 864 | MR1_HA |----| Internet |----| VMN_HA | 865 +--------+ +-------------------------+ +--------+ 866 | 867 +---+---+ 868 root-MR | MR1 | 869 +---+---+ 870 | 871 +-------+ 872 sub-MR | MR2 | 873 +---+---+ 874 | 875 +---+---+ 876 sub-MR | MR3 | 877 +---+---+ 878 | 879 -+--+--+- 880 MNN CN 882 Figure 15: MNN and CN located behind the same nested MR 884 B.4.1 Case J: LFN and standard IPv6 CN 886 If both end nodes are Local Fixed Nodes, no special function is 887 necessary for optimization of their communication. The path between 888 the two nodes would go through: 890 1 891 MNN --- CN 892 LFN IPv6 Node 894 Figure 16: MNN and CN are standard IPv6 nodes 896 B.4.2 Case K: VMN and MIPv6 CN 898 Similar with Case H, when both end nodes are Mobile IPv6 nodes, the 899 two nodes may initiate Mobile IPv6 route optimization. Although few 900 packets would go out the nested mobile network for the Return 901 Routability initialization, however, unlike Case B and Case E, 902 packets will not get tunneled outside the nested mobile network. 903 Therefore, packets between MNN and CN would eventually go through: 905 1 906 MNN --- CN 907 VMN MIPv6 Node 909 Figure 17: MNN and CN are MIPv6 mobile nodes 911 If the root Mobile Router is disconnected while the nodes exchange 912 keys for the Return Routability procedure, they may not communicate 913 even though they are connected on the same link. 915 B.4.3 Case L: VMN and standard IPv6 CN 917 When the communication involves a Mobile IPv6 node either as a 918 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 919 Route Optimization cannot be performed. Therefore, even though the 920 two nodes are on the same link, MNN will establish a bi-directional 921 tunnel with it's Home Agent, which causes the flow to go out the 922 nested mobile network. Path between MNN and CN would require another 923 Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 925 2 3 4 5 4 3 926 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 927 VMN | 928 | 2 929 | 930 VMN_HA 931 | 932 | 1 933 1 2 3 4 3 2 | 934 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 935 IPv6 Node 937 Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 939 Intellectual Property Statement 941 The IETF takes no position regarding the validity or scope of any 942 Intellectual Property Rights or other rights that might be claimed to 943 pertain to the implementation or use of the technology described in 944 this document or the extent to which any license under such rights 945 might or might not be available; nor does it represent that it has 946 made any independent effort to identify any such rights. Information 947 on the procedures with respect to rights in RFC documents can be 948 found in BCP 78 and BCP 79. 950 Copies of IPR disclosures made to the IETF Secretariat and any 951 assurances of licenses to be made available, or the result of an 952 attempt made to obtain a general license or permission for the use of 953 such proprietary rights by implementers or users of this 954 specification can be obtained from the IETF on-line IPR repository at 955 http://www.ietf.org/ipr. 957 The IETF invites any interested party to bring to its attention any 958 copyrights, patents or patent applications, or other proprietary 959 rights that may cover technology that may be required to implement 960 this standard. Please address the information to the IETF at 961 ietf-ipr@ietf.org. 963 Disclaimer of Validity 965 This document and the information contained herein are provided on an 966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 968 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 969 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 970 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 973 Copyright Statement 975 Copyright (C) The Internet Society (2005). This document is subject 976 to the rights, licenses and restrictions contained in BCP 78, and 977 except as set forth therein, the authors retain all their rights. 979 Acknowledgment 981 Funding for the RFC Editor function is currently provided by the 982 Internet Society.