idnits 2.17.00 (12 Aug 2021) /tmp/idnits56221/draft-thubert-nemo-ro-taxonomy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 191 has weird spacing: '... C-Side ooooo...' == Line 295 has weird spacing: '...pondent nnnnn...' == Line 302 has weird spacing: '... Anchor ooooo...' == Line 506 has weird spacing: '...ization withi...' -- 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 (February 15, 2004) is 6670 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 739, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 742, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') == Outdated reference: A later version (-03) exists of draft-kniveton-mobrtr-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-04 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-01) exists of draft-ng-nemo-access-router-option-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-02) exists of draft-droms-nemo-dhcpv6-pd-01 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 -- Possible downref: Normative reference to a draft: ref. '8' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: draft-ietf-manet-dsr has been published as RFC 4728 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '10') == Outdated reference: draft-ietf-manet-aodv has been published as RFC 3561 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodv (ref. '11') ** Obsolete normative reference: RFC 2460 (ref. '13') (Obsoleted by RFC 8200) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thubert 3 Internet-Draft M. Molteni 4 Expires: August 15, 2004 Cisco Systems 5 C. Ng 6 Panasonic Singapore Labs 7 H. Ohnishi 8 NTT 9 E. Paik 10 Seoul National Univ. 11 February 15, 2004 13 Taxonomy of Route Optimization models in the Nemo Context 14 draft-thubert-nemo-ro-taxonomy-02 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 15, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 NEMO enables Mobile Networks by extending Mobile IP to support Mobile 45 Routers. This memo documents how the MIPv6 concept of Route 46 Optimization can to be adapted for NEMO to optimize traffic routing 47 between nodes in a mobile network and their correspodnet nodes. 48 Different route optimizations schemes are discussed, including: 50 1. route optimization with corresponding nodes initiated bu mobile 51 routers on behalf of the mobile network nodes; 53 2. a visiting mobile node performing MIPv6 RO over the NEMO base 54 protocol; 56 3. performing RO over the routing infrastructure involving 57 optimizing the route between two routers situated near to each 58 end point, instead of end-to-end; and 60 4. minimizing the number of tunnels required when there is multiple 61 levels of nesting. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. MIPv6 Route Optimization over NEMO . . . . . . . . . . . . . . 4 68 4. Optimization within the infrastructure . . . . . . . . . . . . 4 69 4.1 Route Optimization within a ISP network . . . . . . . . . . . 5 70 4.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 6 71 4.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . . . 7 72 5. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 8 73 5.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 8 74 5.2 Route Optimization inside the Nested Mobile Network . . . . . 12 75 6. General Considerations . . . . . . . . . . . . . . . . . . . . 12 76 6.1 Securing the protocol in nested tunnels optimization . . . . . 12 77 6.2 Recursive complexity in route optimization . . . . . . . . . . 12 78 6.3 Mobile Access router selection . . . . . . . . . . . . . . . . 13 79 6.4 Mobility transparency and RO . . . . . . . . . . . . . . . . . 14 80 6.5 Multihoming Considerations . . . . . . . . . . . . . . . . . . 15 81 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . 19 87 1. Introduction 89 This document assumes the reader is familiar with Mobile IPv6 defined 90 in [1], with the concept of Mobile Router (MR) and with the Nemo 91 terminology defined in [2]. 93 From the discussions on the mailing list, it appears that the common 94 current understanding of the problem space of Route Optimization 95 (RO), in the Nemo context, is still limited. 97 This draft attempts to clarify the state of the discussion and 98 propose a taxonomy of the various aspects of the problem. We will 99 look at different possible types of route optimizations related to 100 mobile network. 102 Firstly, the Mobile Router can initiate route optimization with 103 corresponding nodes (CN) on behalf of the mobile network nodes (MNN). 105 Secondly, we consider the feasibility of having a visiting mobile 106 node (VMN) performing MIPv6 RO over the NEMO base protocol. 108 Thirdly, we explore the prospect of performing RO over the routing 109 infrastructure. This involves optimizing the route between two 110 routers situated near to each end point. 112 Lastly, route optimizations involving nested mobile networks are 113 explored. This involves minimizing the number of tunnels required 114 when there is multiple levels of nesting. 116 2. MR-to-CN 118 This section covers the case where the Route Optimization is 119 performed between the MR and the correspondent nodes which mobile 120 network nodes (MNNs) are communicating with. This scenario is useful 121 when a lot of MNNs in a mobile network is communicating with a few 122 corresponding nodes. In such cases the MR only needs to send one 123 binding update (BU) to optimized the route between CN and a few MNNs. 125 A major issue with this form of optimization is that the end-to-end 126 principle of the MIPv6 Reverse Routability (RR) test is broken. The 127 RR test is meant to ensure the care-of address (CoA) and the home 128 address (HoA) are collocated. With a mobile network, when the MR 129 performs RO on behalf of the MNNs, the CoA in BU will be the MR's 130 CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. 132 Some tricks may be performed on the fly by the MRs but it seems that 133 a clean MR-to-CN optimization for Nemo will impact the CN function. 135 Once we modify the CN behavior, we need to introduce a negotiation 136 from the start of the RR test to determine the protocol. In 137 particular, the Mobile Node and the CN must decide whether checking 138 the collocation is possible, and if not, whether a CN is willing to 139 accept the risk. If not, the optimization may be limited to 140 triangular routing MR->CN->HA->MR. 142 This is a major evolution from [1], since MIPv6 has no such 143 negotiation capability at this time. 145 3. MIPv6 Route Optimization over NEMO 147 MIPv6 mobile nodes can move everywhere. If the user brings mobile 148 nodes (e.g. MIP VoIP terminal) into the vehicle that supports NEMO 149 function, packets destined to the mobile node will have to be routed 150 not only to its home agent but also the home agent of the mobile 151 router. This pattern resembles Nested NEMO case which is described in 152 later section. This solution is needed to use both MIPv6 and NEMO 153 technologies efficiently. 155 When a Mobile Node visits a Mobile Network, the best Route 156 Optimization is obtained if the path in the Infrastructure is the 157 same as if the Mobile Network was attached at the attachment point of 158 the Mobile Router (i.e., there is not additional Tunneling that is 159 linked to NEMO). 161 A possible approach to this is to extend the solution for nested 162 mobile network optimization to include VMN as well. In this case, 163 the VMN is treated as though it is an MR. This type of solution will 164 most likely require some extensions for a MIPv6 VMN and CN. 166 4. Optimization within the infrastructure 168 This section elaborates on cases where the Route Optimization is 169 performed within the Routing Infrastructure. This model is useful 170 when an ISP wants to control the route optimization procedures and 171 does not desire to add any functions to the CN or the MR in order to 172 achieve route optimizations between CN and LFN. 174 In this model, both the LFN behind the MR and the Correspondent can 175 be MIP agnostic. The drawback is the introduction of Mobile Routes in 176 specific Routers, causing additional signaling and load to the 177 Routing Fabric. 179 The general idea is that there is a correspondent-side router (C-side 180 Router) in the infrastructure that is located "closer" to the CN than 181 the HA of the MR. This C-side Router can terminate MIP on behalf of 182 the CN. 184 Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent 185 # n # 186 o # n # # :== Tunnel 187 o # n # o :== Optimized 188 o # n # n :== Non-Optimized 189 o # n # 190 ################################## n # 191 C-Side oooooooooooooooooooooooooooooooo Mobile 192 Router ################################ Router 193 | 194 ====Mobile Network======= 196 Optimization in the Infrastructure 198 This optimization is only valid when the path via the C-side Router 199 is shorter than the path via the Home Agent. 201 The Optimization can take place independently for the 2 directions of 202 the traffic: 204 Egress 206 The MR locates the C-side Router, establishes a tunnel with that 207 Router and sets a route to the Correspondent Node via the C-side 208 Router over the Tunnel. After this, traffic to the Correspondent 209 Node does not flow through the Home Agent anymore. 211 Ingress 213 The C-side Router is on the way of the traffic from the 214 Correspondent Node to the Home Agent. Also, it is aware of the MR 215 and the mobile network behind the MR and establishes the 216 appropriate tunnel and route. After this, it is able to reroute 217 traffic to the mobile network over the tunnel to the MR. 219 4.1 Route Optimization within a ISP network 221 This form of Route Optimization provides local savings for an ISP. 222 This idea was described in Ohnishi's Mobile Border Gateway draft. The 223 goal is to locate the closest (BGP) gateway for a Correspondent that 224 is located outside of the domain, and tunnel between the MR and that 225 gateway as opposed to the Home Agent for that specific Correspondent. 227 4.2 Correspondent Router 229 A globally better optimization is obtained if the tunnel from the MR 230 is terminated closer to the destination on the Correspondent side. 231 This is the role of a Correspondent Router (CR). 233 +-------------------+ # :== Tunnel 234 | Autonomous System | o :== Optimized 235 | ----------------- | n :== Non-Optimized 236 | | 237 | | 238 | Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent 239 | | # n # 240 | o | # n # 241 | o | # n # 242 | o | # n # 243 | o | # n # 244 | o | # n # 245 | #################################### ? 246 | CR oooooooooooooooooooooooooooooooooooooo Mobile 247 | #################################### Router 248 | | | 249 +-------------------+ ===========Mobile Network======== 251 Correspondent Router 253 The MR locates the CR for a given Correspondent and establishes a 254 Tunnel to the CR for that destination and its prefix(es). Then, the 255 CR establishes the Tunnel back to the MR and the Mobile Routes to the 256 MR's Mobile Networks via that Tunnel. 258 A key point is that the CR must be on the interception path of the 259 traffic from the Correspondent to the Mobile Networks in order to 260 reroute the traffic over the appropriate Tunnel. This can be achieved 261 in several fashions: 263 Redistribution 265 There's a limited Number of CRs that cover an Autonomous System. 266 They redistribute the Mobile Routes on the fly, or within rate and 267 amount limits. Garbage Collection is done at appropriate time to 268 limit the perturbation on the Routing. 270 Default Router 272 The CR is a Default Router for the Correspondent, or for the whole 273 AS of the Correspondent (it's a border gateway). In this case, 274 redistribution is not needed. 276 Core Routers 278 The Core Routers for the network of the Correspondent are all CRs. 279 If the path from the correspondent to the Home Agent does not pass 280 via a CR, then it's not worth optimizing. If it is, then the CRs 281 are on the way. Again, redistribution is not needed. 283 4.3 Distributed Anchor Routers 285 Taking the idea of a correspondent router a step further, it is 286 possible to have a distributed set of anchor routers across the 287 Internet. Outgoing packets sent from a mobile network will be 288 tunneled to one of the nearest anchor router (instead of to the home 289 agent of the mobile router). This M-Side (Mobile Network Side) 290 anchor router will decapsulate the packet, inspect the destination, 291 and tunnel the packet to another anchor router situated near the CN 292 (C-Side Anchor Router). From there, the packet will be decapsulated 293 and forwarded to the CN. 295 Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent 296 o # n # 297 o # n # # :== Tunnel 298 o # n # o :== Optimized 299 o # n # n :== Non-Optimized 300 o # n # 301 C-Side ################## M-Side ###### n # 302 Anchor oooooooooooooooooo Anchor oooo Mobile 303 Router ################## Router #### Router 304 | 305 ====Mobile Network======= 307 Optimization in the Infrastructure 309 The C-Side Anchor Router will be subjected to the same condition as 310 listed in the previous sub-section if packets sent from the CN to the 311 mobile network are to be route-optimized too. Otherwise, the 312 solution will only partially optimize routing to a triangular routing 313 (i.e. packet sent by CN will still go through the home agent of the 314 mobile network). 316 The anchor router share many similarities with the concept of 317 Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6) 318 [9]. In fact, it can be combined with HMIPv6 whereby each M-Side 319 anchor router is also an MAP, and the MR obtains a regional 320 care-of-address from the MAP. 322 5. Nested Mobile Network 324 5.1 Nested Tunnels Optimization 326 This section covers the case where one mobile network is within 327 another mobile network. For example, a user brings a Personal Area 328 Network (PAN) consisting of some IP devices to a train which is also 329 using NEMO technology. In another example, a car which conatins a 330 mobile network moves into the ferry which has another mobile network. 331 This configuration of mobile networks within another mobile network 332 is called nested Mobile Networks. 334 Let us illustrate the problem by an example. In this example, the 335 nested Mobile Network has a tree topology. In the tree each node is a 336 basic Mobile Network, represented by its MR. 338 +---------------------+ 339 | Internet |---CN 340 +---------------|-----+ 341 / Access Router 342 MR3_HA | 343 ======?====== 344 MR1 345 | 346 ====?=============?==============?=== 347 MR5 MR2 MR6 348 | | | 349 =========== ===?========= ============= 350 MR3 351 | 352 ==|=========?== Net3 353 LFN1 MR4 354 | 355 ========= 357 An example nested Mobile Network 359 This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3) 360 inside the tree, represented by its mobile router MR3. The path to 361 the Top Level Mobile Router (TLMR) MR1 and then the Internet is: 363 MR3 -> MR2 -> MR1 -> Internet 365 Consider the case where a LFN belonging to Net3 sends a packet to a 366 Correspondent Node (CN) in the Internet, and the CN replies back. 368 With no Nested Tunnels Optimization, we would have three 369 bi-directional nested tunnels, as described in [3] and illustrated in 370 the following drawings: 372 -----------. 373 --------/ /-----------. 374 -------/ | | /----------- 375 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 376 MR3_HA -------\ | | \----------- MR3 377 MR2_HA --------\ \----------- MR2 378 MR1_HA ----------- MR1 380 No Nested Tunnels Optimization 382 Such a solution introduces the following problems: 384 "Pinball" routing 386 Both inbound and outbound packets will flow via the HAs of all the 387 MRs on their path within the NEMO, with increased latency, less 388 resilience and more bandwidth usage. To illustrate this effect, 389 the figure below shows the route taken by a packet sent from LFN 390 to CN: 392 +--> HAofMR1 ---------------------+ 393 | | 394 +----------------- HAofMR2 <--+ | 395 | | 396 +---------------+ | 397 | V 398 HAofMR3 <------+ CN 399 | 400 | 401 LFN --> MR1 --> MR2 --> MR3 403 'Pinball' Routing 405 Packet size 407 An extra IPv6 header is added per level of nesting to all the 408 packets. The header compression suggested in [4] cannot be applied 409 because both the source and destination (the intermediate MR and 410 its HA), are different hop to hop. 412 On the other hand, with a Nested Tunnel Optimization, we would have 413 at most one bi-directional tunnel outside the Mobile Network, that 414 may depend on the traffic flow: 416 __- --_ 417 Tunnel---------------------------- MR1 ( Mobile ) MR3 418 CN ----------( - - - - - - - - - - ( - - - - )--------- LFN 419 Endpoint---------------------------- MR1 ( Network ) MR3 420 --___--- 422 Nested Tunnels Optimization 424 The end-point of such a Tunnel on the Mobile side may either be MR1 425 or MR3, depending on the solution. In the case of a Mobile Node 426 visiting Net3, that Mobile Node may also be the end-point. 428 The potential approaches for avoiding the nesting of tunnels include: 430 Mobile Aggregation 432 This model applies to a category of problems were the Mobile 433 Networks share a same administration and consistently move 434 together (e.g. a fleet at sea). In this model, there is a cascade 435 of Home Agents. 437 The main Home Agent is fixed in the infrastructure, and advertises 438 an aggregated view of all the Mobile Networks. This aggregation is 439 actually divided over a number of Mobile Routers, the TLMRs. The 440 TLMRs subdivide some of their address space to the other Mobile 441 Routers forming their fleet, for which they are Home Agent. 443 As Home Agents, the TLMRs terminate MIP Tunnels from the inside of 444 the Mobile Network. As Mobile Router, they also terminate their 445 home Tunnels. As routers, they forward packets between the 2 446 tunnels. 448 Surrogate 450 The TLMR acts as a proxy in the MIP registration, in a fashion of 451 MIPv4 Foreign Agent or HMIP MAP (see [9]). For instance, the TLMR 452 maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and 453 switches packets between the two. 455 Internal Routing and gateway 457 This item can be approached from a MANET standpoint. This was 458 already done for DSR (see [10]) and AODV (see [11] and [8]) From a 459 Nemo standpoint, a full MANET is not necessary since the goal is 460 to find a way to the infrastructure, as opposed to any-to-any 461 connectivity. 463 RRH 465 The Reverse Routing Header (RRH) approach avoids the multiple 466 encapsulation of the traffic but maintains the home tunnel of the 467 first MR on the egress path. It is described in details in [5]. 468 The first MR on the way out (egress direction) encapsulates the 469 packet over its reverse tunnel, using a form of Record Route 470 header, the RRH. 472 The next MRs simply swap their CoA and the source of the packet, 473 saving the original source in the RRH. The HA transforms the RRH 474 in a Routing Header to perform a Source Routing across the nested 475 Mobile Network, along the ingress path to the target MR. 477 Access Router Option 479 The Access Router Option (ARO) approach [6] is somewhat similar to 480 the RRH in that only the home tunnel of the first MR in the egress 481 path is maintained. This is done by having MR to send an ARO in 482 Binding Update to inform its HA the address of its access router. 483 Using this information, HA can build a Routing Header to 484 source-route a packet to the target MR within in a nested mobile 485 network. Details can be found in [6]. 487 Prefix delegation approach 489 The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo 490 is to MIPv6. The Access Router of the nested structure is both a 491 Nemo Home Agent and a DHCP-PD server, for an aggregation that it 492 owns and advertises to the Infrastructure. When visiting the 493 nested structure, each MR is delegated a mobile network prefix 494 from the AR using DHCP-Prefix Delegation. The MR registers this 495 delegated MNP to the AR that is acting as a Nemo Home Agent. The 496 MR also autoconfigures an address from the delegated MNP and uses 497 it as a CareOf to register its own MNPs to its own Home Agent 498 using Nemo basic support. It is possible for a MR to protect its 499 own MNPs while advertising in the clear the local MNP for other 500 MRs to roam in. This allows a strict privacy of visited and 501 visitors, and enables some specific policies in each Mobile 502 Router. Details can be found in [7]. 504 5.2 Route Optimization inside the Nested Mobile Network 506 Although optimization within a mobile network is not within the 507 charter of the NEMO working group, it might be insightful to discuss 508 such optimizations. 510 The expectation is that the mobile routes installed by NEMO can 511 cohabit with a MANET support that would perform the RO inside the 512 Nested Mobile Network. In other words, MIP redistributes its prefixes 513 locally to a MANET and the MR-HA tunnel is bypassed. 515 6. General Considerations 517 6.1 Securing the protocol in nested tunnels optimization 519 These approaches are generally difficult to secure unless all the 520 Mobile Routers and Visiting Mobile Node belong to a same 521 administrative domain and share predefined Security Associations. 523 Even if an intermediate MR is 'trusted', this does not prove it is 524 able to provide the necessary bandwidth, and may not provide a good 525 service. Eventually, a MR that is capable of securing (IPSec) its 526 traffic may select a Mobile Access Router based on quality of service 527 heuristics as opposed as trust. 529 The problem is global to the whole Mobile Network in the case of a 530 MANET-based solution. For an RRH-based solution, the threat comes 531 from on-axis MRs in the nested Mobile Network but is mostly limited 532 to denial of service. This is detailed in [5]. The approach taken is 533 to limit the threat to Black Hole and Grey Hole by using IPSec. 535 6.2 Recursive complexity in route optimization 537 A number of drafts and publications suggest -or can be extended to- a 538 model where the Home Agent and any arbitrary Correspondent would 539 actually get individual binding from the chain of nested Mobile 540 Routers, and form a routing header appropriately. 542 An intermediate MR would keep track of all the pending communications 543 between hosts in its subtree of Mobile Networks and their CNs, and a 544 binding message to each CN each time it changes its point of 545 attachment. 547 If this was done, then each CN, by receiving all the binding messages 548 and processing them recursively, could infer a partial topology of 549 the nested Mobile Network, sufficient to build a multi-hop routing 550 header for packets sent to nodes inside the nested Mobile Network. 552 However, this extension has a cost: 554 1. Binding Update storm 556 when one MR changes its point of attachment, it needs to send a 557 BU to all the CNs of each node behind him. When the Mobile 558 Network is nested, the number of nodes and relative CNs can be 559 huge, leading to congestions and drops. 561 2. Protocol Hacks 563 Also, in order to send the BUs, the MR has to keep track of all 564 the traffic it forwards to maintain his list of CNs. In case of 565 IPSec tunneled traffic, that CN information may not be available. 567 3. CN operation 569 The computation burden of the CN becomes heavy, because it has to 570 analyze each BU in a recursive fashion in order to infer nested 571 Mobile Network topology required to build a multi hop routing 572 header. 574 4. Missing BU 576 If a CN doesn't receive the full set of PSBU sent by the MR, it 577 will not be able to infer the full path to a node inside the 578 nested Mobile Network. The RH will be incomplete and the packet 579 may or may not be delivered. 581 5. Obsolete BU 583 If the Binding messages are sent asynchronously by each MR, then, 584 when the relative position of MRs and/or the TLMR point of 585 attachment change rapidly, the image of Mobile Network that the 586 CN maintains is highly unstable. If only one BU in the chain is 587 obsolete due to the movement of an intermediate MR, the 588 connectivity may be lost. 590 6.3 Mobile Access router selection 592 In some case, nested Mobile Networks attaches to visiting network 593 with multiples mobile access router that are gateways to the global 594 internet. These RO methods may cover the function in which how the MR 595 in the nested Mobile Network choose the one of the mobile access 596 routers. This function is not explicitly described in current 597 methods and needs to be discussed. 599 6.4 Mobility transparency and RO 601 [cwng's interpretation of Mobility Transparency in RO] 603 It is desirable in mobility-related protocols that the mobility of a 604 mobile node is transparent to other entities and other layers in the 605 mobile node. The Basic NEMO support achieve this mobility 606 transparency of the mobile network to the MNNs by a MR-HA tunnel so 607 that MNNs need not be aware of the MR's change in point of 608 attachment. 610 Such a feature is, as mentioned, desirable. However, when route 611 optimizations, end-to-end principle, and other factors come into 612 consideration, achieving mobility transparency may not be practical. 614 For instance, to achieve nested tunnel optimizations, the mobility of 615 the top-level MR is often exposed to other entities, such as the HA 616 of a nested MR. In the case of MR performing BU for MNNs, it might 617 be necessary to pass mobility information of the MR to CN (and even 618 MNN) in order not to break the end-to-end principle. For the 619 scenario of optimization using infrastructure, the mobility 620 information might be necessarily exposed to correspondent routers or 621 MAP. 623 Thus, one should bear in mind when designing RO solution that a 624 sacrifice might be necessary when weighing conflicting factors such 625 as mobility transparency, optimization level, and end-to-end 626 integrity. 628 [Hosik's interpretation of Mobility Transparency in RO] 630 In the case of extended support of NEMO such as nested NEMO, mobility 631 transparency is desirable but that is not mandatory for the 632 efficiency of the route optimization. For example, the notebook and 633 PDA inside a vehicle can access to the Internet through the mobile 634 router of the vehicle. In that case, if the movement of the vehicle 635 affects to the notebook or the PDA, they can perform individual 636 binding update operation to the correspondent node or its home agent 637 but that can cause location privacy problem. 639 [Onishi's interpretation of Mobility Transparency in RO] 641 In RO solutions, MR can optimize the route between its own HA and MR. 642 It is desirable that communication can not be interrupted by this 643 route optimization. ???? 645 6.5 Multihoming Considerations 647 In multihomed mobile networks, route optimization is dependant on how 648 the connections to the Internet are available and selected. 650 In case of macro mobility, we may have multiple HAs from place to 651 place. New route optimization could be possible by routing between CN 652 and one of the multiple Home Agents (possibly using differenc Home 653 Addresses). 655 When multiple connections are available for the purpose of fault 656 tolerance, a selection mechanism is needed for CN to eveluate the 657 connection availability in order to perform route optimization. 659 7. Conclusion 661 The Problem space of Route Optimization in the NEMO context is 662 multifold and can be split is several work areas. It will be 663 critical, though, that the solution to a given piece of the puzzle be 664 compatible and integrate smoothly with the others. 666 Hopefully, the solutions will build on MIPv6 ([1]), as recommended by 667 the NEMO Charter. On the other hand, MIPv6 seems to be evolving in a 668 direction that makes it more and more difficult to provide a NEMO 669 solution with backward compatibility, since: 671 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, 673 2) The RR test has no negotiable option and is not open for 674 extension, and 676 3) The HaO and RH type 2 are designed for a collocated CareOf 677 Address. More specifically, they are not designed to be multi-hop as 678 RRH is, and not extensible, though RRH can be considered as an 679 extension of HAO. 681 The authors intent is to trigger fruitful discussions that in turn 682 will enhance our common understanding of the problem space so that at 683 some point, this paper turns into a problem statement for the Nemo 684 Route Optimization. 686 8. Acknowledgements 688 The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki 689 Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji 690 Wakikawa and Patrick Wetterwald for their various contributions. 692 References 694 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 695 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 696 2003. 698 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 699 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 701 [3] kniveton, t., "Mobile Router Support with Mobile IP", 702 draft-kniveton-mobrtr-02 (work in progress), July 2002. 704 [4] Deering, S. and B. Zill, "Redundant Address Deletion when 705 Encapsulating IPv6 in IPv6", 706 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 707 November 2001. 709 [5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 710 its application to Mobile Networks", 711 draft-thubert-nemo-reverse-routing-header-04 (work in 712 progress), February 2004. 714 [6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization 715 with Access Router Option", 716 draft-ng-nemo-access-router-option-00 (work in progress), 717 November 2002. 719 [7] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 720 draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 721 2004. 723 [8] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc 724 Networks", draft-wakikawa-manet-globalv6-03 (work in progress), 725 October 2003. 727 [9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 728 "Hierarchical MIPv6 mobility management (HMIPv6)", 729 draft-ietf-mobileip-hmipv6-06 (work in progress), July 2002. 731 [10] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad 732 Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in 733 progress), April 2003. 735 [11] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance 736 Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in 737 progress), July 2002. 739 [12] Postel, J., "Internet Protocol", STD 5, RFC 791, September 740 1981. 742 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 743 Specification", RFC 2460, December 1998. 745 Authors' Addresses 747 Pascal Thubert 748 Cisco Systems Technology Center 749 Village d'Entreprises Green Side 750 400, Avenue Roumanille 751 Biot - Sophia Antipolis 06410 752 FRANCE 754 EMail: pthubert@cisco.com 756 Marco Molteni 757 Cisco Systems Technology Center 758 Village d'Entreprises Green Side 759 400, Avenue Roumanille 760 Biot - Sophia Antipolis 06410 761 FRANCE 763 EMail: mmolteni@cisco.com 765 Chan-Wah Ng 766 Panasonic Singapore Laboratories Pte Ltd 767 Blk 1022 Tai Seng Ave #06-3530 768 Tai Seng Industrial Estate 769 Singapore 534415 770 SG 772 EMail: cwng@psl.com.sg 774 Hiroyuki Ohnishi 775 NTT network service systems laboratories, NTT cooperation 776 9-11, Midori-Cho 3-Chome 777 Musashino-shi 778 Tokyo 180-8585 779 JAPAN 781 EMail: ohnishi.hiroyuki@lab.ntt.co.jp 782 Eun Kyoung Paik 783 Seoul National University 784 Shillim-dong, Kwanak-gu 785 Seoul 151-744 786 KOREA 788 EMail: eun@mmlab.snu.ac.kr 790 Intellectual Property Statement 792 The IETF takes no position regarding the validity or scope of any 793 intellectual property or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; neither does it represent that it 797 has made any effort to identify any such rights. Information on the 798 IETF's procedures with respect to rights in standards-track and 799 standards-related documentation can be found in BCP-11. Copies of 800 claims of rights made available for publication and any assurances of 801 licenses to be made available, or the result of an attempt made to 802 obtain a general license or permission for the use of such 803 proprietary rights by implementors or users of this specification can 804 be obtained from the IETF Secretariat. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights which may cover technology that may be required to practice 809 this standard. Please address the information to the IETF Executive 810 Director. 812 Full Copyright Statement 814 Copyright (C) The Internet Society (2004). All Rights Reserved. 816 This document and translations of it may be copied and furnished to 817 others, and derivative works that comment on or otherwise explain it 818 or assist in its implementation may be prepared, copied, published 819 and distributed, in whole or in part, without restriction of any 820 kind, provided that the above copyright notice and this paragraph are 821 included on all such copies and derivative works. However, this 822 document itself may not be modified in any way, such as by removing 823 the copyright notice or references to the Internet Society or other 824 Internet organizations, except as needed for the purpose of 825 developing Internet standards in which case the procedures for 826 copyrights defined in the Internet Standards process must be 827 followed, or as required to translate it into languages other than 828 English. 830 The limited permissions granted above are perpetual and will not be 831 revoked by the Internet Society or its successors or assignees. 833 This document and the information contained herein is provided on an 834 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 835 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 836 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 837 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 838 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 840 Acknowledgment 842 Funding for the RFC Editor function is currently provided by the 843 Internet Society.