idnits 2.17.00 (12 Aug 2021) /tmp/idnits49522/draft-thubert-nemo-ro-taxonomy-01.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 396 has weird spacing: '... C-Side ooooo...' == Line 503 has weird spacing: '...pondent nnnnn...' == Line 510 has weird spacing: '... Anchor ooooo...' -- 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 (June 3, 2003) is 6927 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: '11' is defined on line 603, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 606, 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') -- 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-01 -- 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 (-05) exists of draft-wakikawa-manet-globalv6-02 -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: draft-ietf-manet-dsr has been published as RFC 4728 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '9') == Outdated reference: draft-ietf-manet-aodv has been published as RFC 3561 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodv (ref. '10') ** Obsolete normative reference: RFC 2460 (ref. '12') (Obsoleted by RFC 8200) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 10 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: December 2, 2003 Cisco Systems 5 C. Ng 6 Panasonic Singapore Labs 7 June 3, 2003 9 Taxonomy of Route Optimization models in the Nemo Context 10 draft-thubert-nemo-ro-taxonomy-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 2, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 Nemo enables Mobile Networks by extending Mobile IP to support Mobile 42 Routers. This paper documents how the MIPv6 concept of Route 43 Optimization can to be adapted for Nemo to optimize: 45 1. the nested tunnels of the nested Nemo configuration 47 2. router-to-router in the infrastructure as opposed to end-to-end. 49 and much more ... :) 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Nested Mobile Network . . . . . . . . . . . . . . . . . . 3 55 2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . 3 56 2.1.1 Pitfalls and threats . . . . . . . . . . . . . . . . . . . 7 57 2.1.1.1 Securing the protocol . . . . . . . . . . . . . . . . . . 7 58 2.1.1.2 Recursive complexity . . . . . . . . . . . . . . . . . . . 7 59 2.2 Route Optimization inside the Nested Mobile Network . . . 8 60 3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . 9 62 5. Optimization within the infrastructure . . . . . . . . . . 9 63 5.1 Route Optimization within a ISP network . . . . . . . . . 10 64 5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . 11 65 5.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . 12 66 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13 68 References . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 70 Full Copyright Statement . . . . . . . . . . . . . . . . . 16 72 1. Introduction 74 This document assumes the reader is familiar with Mobile IPv6 defined 75 in [1], with the concept of Mobile Router (MR) and with the Nemo 76 terminology defined in [2]. 78 From the discussions on the mailing list, it appears that the common 79 current understanding of the problem space of Route Optimization 80 (RO), in the Nemo context, is still limited. 82 This paper attempts to clarify the state of the discussion and 83 propose a taxonomy of the various aspects of the problem. We will 84 look at different possible types of route optimizations related to 85 mobile network. 87 Firstly, route optimizations involving nested mobile networks are 88 explored. This involves minimizing the number of tunnels required 89 when there is multiple levels of nesting. 91 Secondly, the Mobile Router can initiate route optimization with 92 corresponding nodes (CN) on behalf of the mobile network nodes (MNN). 94 Thirdly, we consider the feasibility of having a visiting mobile node 95 (VMN) performing MIPv6 RO over the NEMO base protocol. 97 Lastly, we explore the prospect of performing RO over the routing 98 infrastructure. This involve optimizing the route between two 99 routers situated near to each end point. 101 2. Nested Mobile Network 103 2.1 Nested Tunnels Optimization 105 Let us illustrate the problem by an example. In this example, the 106 nested Mobile Network has a tree topology. In the tree each node is 107 a basic Mobile Network, represented by its MR. 109 +---------------------+ 110 | Internet |---CN 111 +---------------|-----+ 112 / Access Router 113 MR3_HA | 114 ======?====== 115 MR1 116 | 117 ====?=============?==============?=== 118 MR5 MR2 MR6 119 | | | 120 =========== ===?========= ============= 121 MR3 122 | 123 ==|=========?== Net3 124 LFN1 MR4 125 | 126 ========= 128 An example nested Mobile Network 130 This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3) 131 inside the tree, represented by its mobile router MR3. The path to 132 the Top Level Mobile Router (TLMR) MR1 and then the Internet is: 134 MR3 -> MR2 -> MR1 -> Internet 136 Consider the case where a LFN belonging to Net3 sends a packet to a 137 Correspondent Node (CN) in the Internet, and the CN replies back. 139 With no Nested Tunnels Optimization, we would have three bi- 140 directional nested tunnels, as described in [3] and illustrated in 141 the following drawings: 143 -----------. 144 --------/ /-----------. 145 -------/ | | /----------- 146 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 147 MR3_HA -------\ | | \----------- MR3 148 MR2_HA --------\ \----------- MR2 149 MR1_HA ----------- MR1 151 No Nested Tunnels Optimization 153 Such a solution introduces the following problems: 155 "Pinball" routing 157 Both inbound and outbound packets will flow via the HAs of all the 158 MRs on their path within the NEMO, with increased latency, less 159 resilience and more bandwidth usage. To illustrate this effect, 160 the figure below shows the route taken by a packet sent from LFN 161 to CN: 163 +--> HAofMR1 ---------------------+ 164 | | 165 +----------------- HAofMR2 <--+ | 166 | | 167 +---------------+ | 168 | V 169 HAofMR3 <------+ CN 170 | 171 | 172 LFN --> MR1 --> MR2 --> MR3 174 'Pinball' Routing 176 Packet size 178 An extra IPv6 header is added per level of nesting to all the 179 packets. The header compression suggested in [4] cannot be 180 applied because both the source and destination (the intermediate 181 MR and its HA), are different hop to hop. 183 On the other hand, with a Nested Tunnel Optimization, we would have 184 at most one bi-directional tunnel outside the Mobile Network, that 185 may depend on the traffic flow: 187 __- --_ 188 Tunnel---------------------------- MR1 ( Mobile ) MR3 189 CN ----------( - - - - - - - - - - ( - - - - )--------- LFN 190 Endpoint---------------------------- MR1 ( Network ) MR3 191 --___--- 193 Nested Tunnels Optimization 195 The end-point of such a Tunnel on the Mobile side may either be MR1 196 or MR3, depending on the solution. In the case of a Mobile Node 197 visiting Net3, that Mobile Node may also be the end-point. 199 The potential approaches for avoiding the nesting of tunnels include: 201 Mobile Aggregation 203 This model applies to a category of problems were the Mobile 204 Networks share a same administration and consistently move 205 together (e.g. a fleet at sea). In this model, there is a 206 cascade of Home Agents. 208 The main Home Agent is fixed in the infrastructure, and advertises 209 an aggregated view of all the Mobile Networks. This aggregation 210 is actually divided over a number of Mobile Routers, the TLMRs. 211 The TLMRs subdivide some of their address space to the other 212 Mobile Routers forming their fleet, for which they are Home Agent. 214 As Home Agents, the TLMRs terminate MIP Tunnels from the inside of 215 the Mobile Network. As Mobile Router, they also terminate their 216 home Tunnels. As routers, they forward packets between the 2 217 tunnels. 219 Surrogate 221 The TLMR acts as a proxy in the MIP registration, in a fashion of 222 MIPv4 Foreign Agent or HMIP MAP (see [8]). For instance, the TLMR 223 maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and 224 switches packets between the two. 226 Internal Routing and gateway 228 This item can be approached from a MANET standpoint. This was 229 already done for DSR (see [9]) and AODV (see [10] and [7]) From a 230 Nemo standpoint, a full MANET is not necessary since the goal is 231 to find a way to the infrastructure, as opposed to any-to-any 232 connectivity. 234 RRH 236 The Reverse Routing Header (RRH) approach avoids the multiple 237 encapsulation of the traffic but maintains the home tunnel of the 238 first MR on the egress path. It is described in details in [5]. 239 The first MR on the way out (egress direction) encapsulates the 240 packet over its reverse tunnel, using a form of Record Route 241 header, the RRH. 243 The next MRs simply swap their CoA and the source of the packet, 244 saving the original source in the RRH. The HA transforms the RRH 245 in a Routing Header to perform a Source Routing across the nested 246 Mobile Network, along the ingress path to the target MR. 248 Access Router Option 250 The Access Router Option (ARO) approach [6] is somewhat similar to 251 the RRH in that only the home tunnel of the first MR in the egress 252 path is maintained. This is done by having MR to send an ARO in 253 Binding Update to inform its HA the address of its access router. 254 Using this information, HA can build a Routing Header to source- 255 route a packet to the target MR within in a nested mobile network. 256 Details can be found in [6]. 258 2.1.1 Pitfalls and threats 260 2.1.1.1 Securing the protocol 262 These approaches are generally difficult to secure unless all the 263 Mobile Routers and Visiting Mobile Node belong to a same 264 administrative domain and share predefined Security Associations. 266 Even if an intermediate MR is 'trusted', this does not prove it is 267 able to provide the necessary bandwidth, and may not provide a good 268 service. Eventually, a MR that is capable of securing (IPSec) its 269 traffic may select a Mobile Access Router based on quality of service 270 heuristics as opposed as trust. 272 The problem is global to the whole Mobile Network in the case of a 273 MANET-based solution. For an RRH-based solution, the threat comes 274 from on-axis MRs in the nested Mobile Network but is mostly limited 275 to denial of service. This is detailed in [5]. The approach taken 276 is to limit the threat to Black Hole and Grey Hole by using IPSec. 278 2.1.1.2 Recursive complexity 280 A number of drafts and publications suggest -or can be extended to- a 281 model where the Home Agent and any arbitrary Correspondent would 282 actually get individual binding from the chain of nested Mobile 283 Routers, and form a routing header appropriately. 285 An intermediate MR would keep track of all the pending communications 286 between hosts in its subtree of Mobile Networks and their CNs, and a 287 binding message to each CN each time it changes its point of 288 attachment. 290 If this was done, then each CN, by receiving all the binding messages 291 and processing them recursively, could infer a partial topology of 292 the nested Mobile Network, sufficient to build a multi-hop routing 293 header for packets sent to nodes inside the nested Mobile Network. 295 However, this extension has a cost: 297 1. Binding Update storm 299 when one MR changes its point of attachment, it needs to send a 300 BU to all the CNs of each node behind him. When the Mobile 301 Network is nested, the number of nodes and relative CNs can be 302 huge, leading to congestions and drops. 304 2. Protocol Hacks 306 Also, in order to send the BUs, the MR has to keep track of all 307 the traffic it forwards to maintain his list of CNs. In case of 308 IPSec tunneled traffic, that CN information may not be available. 310 3. CN operation 312 The computation burden of the CN becomes heavy, because it has to 313 analyze each BU in a recursive fashion in order to infer nested 314 Mobile Network topology required to build a multi hop routing 315 header. 317 4. Missing BU 319 If a CN doesn't receive the full set of PSBU sent by the MR, it 320 will not be able to infer the full path to a node inside the 321 nested Mobile Network. The RH will be incomplete and the packet 322 may or may not be delivered. 324 5. Obsolete BU 326 If the Binding messages are sent asynchronously by each MR, then, 327 when the relative position of MRs and/or the TLMR point of 328 attachment change rapidly, the image of Mobile Network that the 329 CN maintains is highly unstable. If only one BU in the chain is 330 obsolete due to the movement of an intermediate MR, the 331 connectivity may be lost. 333 2.2 Route Optimization inside the Nested Mobile Network 335 This is not part of the Nemo Charter. 337 The expectation is that the mobile routes installed by Nemo can 338 cohabit with a MANET support that would perform the RO inside the 339 Nested Mobile Network. In other words, MIP redistributes its 340 prefixes locally to a MANET and the MR-HA tunnel is bypassed. 342 3. MR-to-CN 344 This section covers the case where the Route Optimization is 345 performed between the MR and the Correspondent Node. 347 A major issue is that the MIPv6 Reverse Routability test is broken, 348 since it is meant to ensure that the CoA (the MR) an the Home Address 349 (the Mobile Node) are collocated. With a Mobile Network, a LFN is 350 reachable via the Care-Of Address, but not at the Care-Of Address. 351 Some tricks may be performed on the fly by the MRs but it seems that 352 a clean MR-to-CN optimization for Nemo will impact the CN function. 354 Once we modify the CN behavior, we need to introduce a negotiation 355 from the start of the RR test to determine the protocol. In 356 particular, the Mobile Node and the CN must decide whether checking 357 the collocation is possible, and if not, whether a CN is willing to 358 accept the risk. If not, the optimization may be limited to 359 triangular routing MR->CN->HA->MR. 361 This is a major evolution from [1], since MIPv6 has no such 362 negotiation capability at this time. 364 4. MIPv6 Route Optimization over Nemo 366 When a Mobile Node visits a Mobile Network, the best Route 367 Optimization is obtained if the path in the Infrastructure is the 368 same as if the Mobile Network was attached at the attachment point of 369 the Mobile Router (i.e., there is not additional Tunneling that is 370 linked to Nemo). 372 A possible approach to this is to extend the solution for nested 373 mobile network optimization to include VMN as well. In this case, 374 the VMN is treated as though it is an MR. This type of solution will 375 most likely require some extensions for a MIPv6 VMN and CN. 377 5. Optimization within the infrastructure 379 This section elaborates on cases where the Route Optimization is 380 performed within the Routing Infrastructure. In this model, both the 381 LFN behind the MR and the Correspondent can be MIP agnostic. The 382 drawback is the introduction of Mobile Routes in specific Routers, 383 causing additional signaling and load to the Routing Fabric. 385 The general idea is that there is a correspondent-side Router in the 386 infrastructure that is located "closer" to the Correspondent than the 387 HA. That Router can terminate MIP on behalf of the CN. 389 Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent 390 # n # 391 o # n # # :== Tunnel 392 o # n # o :== Optimized 393 o # n # n :== Non-Optimized 394 o # n # 395 ################################## n # 396 C-Side oooooooooooooooooooooooooooooooo Mobile 397 Router ################################ Router 398 | 399 ====Mobile Network======= 401 Optimization in the Infrastructure 403 This optimization is only valid when the path via the correspondent- 404 side Router is shorter than the path via the Home Agent. 406 The Optimization can take place independently for the 2 directions of 407 the traffic: 409 Egress 411 The MR locates the correspondent-side Router, establishes a Tunnel 412 with that Router and sets a route to the Correspondent via the 413 correspondent-side Router over the Tunnel. At this point, the 414 traffic to the Correspondent does not flow via the Home Agent 415 anymore. 417 Ingress 419 The correspondent-side Router is on the way of the traffic from 420 the Correspondent to the Home Agent. Also, it is aware of the MR 421 and the Mobile Networks behind the MR and establishes the 422 appropriate Tunnel and Route. At that point, it is able to 423 reroute the traffic to the Mobile Network over the Tunnel to the 424 MR. 426 5.1 Route Optimization within a ISP network 428 This form of Route Optimization provides local savings for a ISP. 429 This idea was described in Ohnishi's Mobile Border Gateway draft. 430 The goal is to locate the closest (BGP) gateway for a Correspondent 431 that is located outside of the domain, and tunnel between the MR and 432 that gateway as opposed to the Home Agent for that specific 433 Correspondent. 435 5.2 Correspondent Router 437 A globally better optimization is obtained if the tunnel from the MR 438 is terminated closer to the destination on the Correspondent side. 439 This is the role of a Correspondent Router (CR). 441 +-------------------+ # :== Tunnel 442 | Autonomous System | o :== Optimized 443 | ----------------- | n :== Non-Optimized 444 | | 445 | | 446 | Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent 447 | | # n # 448 | o | # n # 449 | o | # n # 450 | o | # n # 451 | o | # n # 452 | o | # n # 453 | #################################### ? 454 | CR oooooooooooooooooooooooooooooooooooooo Mobile 455 | #################################### Router 456 | | | 457 +-------------------+ ===========Mobile Network======== 459 Correspondent Router 461 The MR locates the CR for a given Correspondent and establishes a 462 Tunnel to the CR for that destination and its prefix(es). Then, the 463 CR establishes the Tunnel back to the MR and the Mobile Routes to the 464 MR's Mobile Networks via that Tunnel. 466 A key point is that the CR must be on the interception path of the 467 traffic from the Correspondent to the Mobile Networks in order to 468 reroute the traffic over the appropriate Tunnel. This can be 469 achieved in several fashions: 471 Redistribution 473 There's a limited Number of CRs that cover an Autonomous System. 474 They redistribute the Mobile Routes on the fly, or within rate and 475 amount limits. Garbage Collection is done at appropriate time to 476 limit the perturbation on the Routing. 478 Default Router 480 The CR is a Default Router for the Correspondent, or for the whole 481 AS of the Correspondent (it's a border gateway). In this case, 482 redistribution is not needed. 484 Core Routers 486 The Core Routers for the network of the Correspondent are all CRs. 487 If the path from the correspondent to the Home Agent does not pass 488 via a CR, then it's not worth optimizing. If it is, then the CRs 489 are on the way. Again, redistribution is not needed. 491 5.3 Distributed Anchor Routers 493 Taking the idea of a correspondent router a step further, it is 494 possible to have a distributed set of anchor routers across the 495 Internet. Outgoing packets sent from a mobile network will be 496 tunneled to one of the nearest anchor router (instead of to the home 497 agent of the mobile router). This M-Side (Mobile Network Side) 498 anchor router will decapsulate the packet, inspect the destination, 499 and tunnel the packet to another anchor router situated near the CN 500 (C-Side Anchor Router). From there, the packet will be decapsulated 501 and forwarded to the CN. 503 Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent 504 o # n # 505 o # n # # :== Tunnel 506 o # n # o :== Optimized 507 o # n # n :== Non-Optimized 508 o # n # 509 C-Side ################## M-Side ###### n # 510 Anchor oooooooooooooooooo Anchor oooo Mobile 511 Router ################## Router #### Router 512 | 513 ====Mobile Network======= 515 Optimization in the Infrastructure 517 The C-Side Anchor Router will be subjected to the same condition as 518 listed in the previous sub-section if packets sent from the CN to the 519 mobile network are to be route-optimized too. Otherwise, the 520 solution will only partially optimize routing to a triangular routing 521 (i.e. packet sent by CN will still go through the home agent of the 522 mobile network). 524 The anchor router share many similarities with the concept of 525 Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6) 526 [8]. In fact, it can be combined with HMIPv6 whereby each M-Side 527 anchor router is also an MAP, and the MR obtains a regional care-of- 528 address from the MAP. 530 6. Conclusion 532 The Problem space of Route Optimization in the Nemo context is 533 multifold and can be split is several work areas. It will be 534 critical, though, that the solution to a given piece of the puzzle be 535 compatible and integrate smoothly with the others. 537 Hopefully, the solutions will build on MIPv6 ([1]), as recommended by 538 the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a 539 direction that makes it more and more difficult to provide a Nemo 540 solution with backward compatibility, since: 542 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, 544 2) The RR test has no negotiable option and is not open for 545 extension, and 547 3) The HaO and RH type 2 are designed for a collocated CareOf 548 Address. More specifically, they are not designed to be multi-hop as 549 RRH is, and not extensible, though RRH can be considered as an 550 extension of HaO. 552 The authors intent is to trigger fruitful discussions that in turn 553 will enhance our common understanding of the problem space so that at 554 some point, this paper turns into a problem statement for the Nemo 555 Route Optimization. 557 7. Acknowledgements 559 The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki 560 Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji 561 Wakikawa and Patrick Wetterwald for their various contributions. 563 References 565 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 566 IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), March 567 2003. 569 [2] Lach, H. and T. Ernst, "Network Mobility Support Terminology", 570 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 572 [3] Kniveton, T., "Mobile Router Tunneling Protocol", draft- 573 kniveton-mobrtr-03 (work in progress), November 2002. 575 [4] Deering, S. and B. Zill, "Redundant Address Deletion when 576 Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr- 577 deletion-00 (work in progress), November 2001. 579 [5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 580 its application to Mobile Networks", draft-thubert-nemo- 581 reverse-routing-header-01 (work in progress), October 2002. 583 [6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization 584 with Access Router Option", draft-ng-nemo-access-router-option- 585 00 (work in progress), November 2002. 587 [7] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc 588 Networks", draft-wakikawa-manet-globalv6-02 (work in progress), 589 November 2002. 591 [8] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier, 592 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- 593 ietf-mobileip-hmipv6-07 (work in progress), October 2002. 595 [9] Johnson, D., Maltz, D., Broch, J. and J. Jetcheva, "The Dynamic 596 Source Routing Protocol for Mobile Ad Hoc Networks", draft- 597 ietf-manet-dsr-07 (work in progress), February 2002. 599 [10] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance 600 Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in 601 progress), February 2003. 603 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 604 1981. 606 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 607 Specification", RFC 2460, December 1998. 609 Authors' Addresses 611 Pascal Thubert 612 Cisco Systems Technology Center 613 Village d'Entreprises Green Side 614 400, Avenue Roumanille 615 Biot - Sophia Antipolis 06410 616 FRANCE 618 EMail: pthubert@cisco.com 620 Marco Molteni 621 Cisco Systems Technology Center 622 Village d'Entreprises Green Side 623 400, Avenue Roumanille 624 Biot - Sophia Antipolis 06410 625 FRANCE 627 EMail: mmolteni@cisco.com 629 Chan-Wah Ng 630 Panasonic Singapore Laboratories Pte Ltd 631 Blk 1022 Tai Seng Ave #06-3530 632 Tai Seng Industrial Estate 633 Singapore 534415 634 SG 636 EMail: cwng@psl.com.sg 638 Full Copyright Statement 640 Copyright (C) The Internet Society (2003). All Rights Reserved. 642 This document and translations of it may be copied and furnished to 643 others, and derivative works that comment on or otherwise explain it 644 or assist in its implementation may be prepared, copied, published 645 and distributed, in whole or in part, without restriction of any 646 kind, provided that the above copyright notice and this paragraph are 647 included on all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by removing 649 the copyright notice or references to the Internet Society or other 650 Internet organizations, except as needed for the purpose of 651 developing Internet standards in which case the procedures for 652 copyrights defined in the Internet Standards process must be 653 followed, or as required to translate it into languages other than 654 English. 656 The limited permissions granted above are perpetual and will not be 657 revoked by the Internet Society or its successors or assigns. 659 This document and the information contained herein is provided on an 660 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 661 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 662 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 664 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Acknowledgement 668 Funding for the RFC Editor function is currently provided by the 669 Internet Society.