idnits 2.17.00 (12 Aug 2021) /tmp/idnits59764/draft-thubert-nemo-ipv4-traversal-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 275: '... the UDP tunnel MUST be terminated by...' RFC 2119 keyword, line 310: '... The Mobile Node MUST be tuned to send...' RFC 2119 keyword, line 324: '...h a InDoors Handle, a Mobile Node MUST...' RFC 2119 keyword, line 465: '...he DoG function in the Home Agent MUST...' RFC 2119 keyword, line 644: '...e, the Stray DoG MUST encapsulate the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7035 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) == Unused Reference: '5' is defined on line 729, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 733, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 737, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 739, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-01 -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-03) exists of draft-petrescu-nemo-mrha-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 8 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 2, 2003 P. Wetterwald 5 Cisco Systems 6 February 2003 8 IPv4 traversal for MIPv6 based Mobile Routers 9 draft-thubert-nemo-ipv4-traversal-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 2, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 Since IPv6 connectivity is not yet broadly available, there is a need 41 in NEMO for a simple technology that allows a MIPv6 based Mobile 42 Router to roam over IPv4 networks. 44 The Doors Protocol proposed in this memo allows an arbitrary Mobile 45 Node to roam even within private IPv4 address spaces, across both 46 Network and Port Address Translations, in order to cope with existing 47 of deployments of technologies such as GPRS. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and concepts . . . . . . . . . . . . . . . . . . 3 53 2.1 Doors Handle . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2 Other definitions . . . . . . . . . . . . . . . . . . . . . 5 55 3. Basic MIPv6 Doors support . . . . . . . . . . . . . . . . . 5 56 3.1 Known Restrictions . . . . . . . . . . . . . . . . . . . . . 7 57 3.2 Operation for a MIPv6 Mobile Node roaming over IPv4 . . . . 7 58 3.2.1 Sending packets over the Doors tunnel . . . . . . . . . . . 8 59 3.2.2 Receiving packets over the Doors tunnel . . . . . . . . . . 9 60 3.3 Operation for the Home Agent of a MIPv6 MN roaming over IPv4 9 61 3.3.1 Receiving packets over the Doors tunnel . . . . . . . . . . 9 62 3.3.2 Sending packets over the Doors tunnel . . . . . . . . . . . 11 63 4. Distributed configurations . . . . . . . . . . . . . . . . . 12 64 4.1 Hierarchical MIP . . . . . . . . . . . . . . . . . . . . . . 12 65 4.2 Reverse Routing Header . . . . . . . . . . . . . . . . . . . 12 66 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 68 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 72 1. Introduction 74 This document assumes that the reader is familiar with Mobile IPv6 75 defined in [1], with the concept of Mobile Router (MR) and with the 76 Nemo terminology defined in [2], as well as IPv4 Network Address 77 Translation (NAT) and Port Address Translation (PAT). 79 During the transition phase from IPv4 to IPv6, hot spots that 80 actually provide IPv6 connectivity will be scarce and Mobile Routers 81 should support an alternate roaming technology over IPv4. 83 There is an existing panel of solutions from the NGTRANS WG (ISATAP, 84 6to4, TEREDO), but these solutions fail to traverse simply every type 85 of NAT and PAT, such as present today in GPRS deployments. 87 There is a real value in combining MIPv6 and IPv4 traversal 88 technologies. MIP brings a MN-HA tunnel and a binding cache into the 89 picture, as well as a keep alive procedure. The MIP cache can be 90 used to store the PAT/NAT states, while the Binding flow can be tuned 91 to keep the PAT/NAT active. As a result, it is possible for a IPv6 92 Mobile Router to traverse PAT/NAT with no protocol overhead or 93 additional states in the network. 95 The Doors Protocol developed in this draft is aimed at the Nemo 96 problem space. In particular, only the MN-HA tunnel is considered 97 (as opposed to any MN-CN tunnel). Also, some restrictions apply that 98 may be circumvented by additional work. 100 2. Terminology and concepts 102 2.1 Doors Handle 104 Existing technologies such as 6to4 use synthetized IPv6 addresses to 105 build automatic tunnels. In such technologies, the result is still a 106 valid Global IPv6 address, that can be used as Source or Destination 107 address in IPv6 packets, and points on one of the machine's 108 interfaces. 110 Here, we synthetize a 128-bits tag, named Doors Handle. The Doors 111 Handle is not a valid Global IPv6 Address, and can not generally be 112 used as a Source or Destination IPv6 address. 114 The Doors Handle should not be used for upper layer checksums, 115 either: the tag only is meant to be used as an IPv6 address in the 116 header of a packet that is encapsulated inside a IPv4 (UDP) tunnel. 117 In fact, the Doors Handle points on that IPv4 (UDP) tunnel, as 118 opposed to an interface on a machine, and is meant to be used only as 119 a CareOf by MIPv6 Nodes roaming over a IPv4 network. 121 The Doors Handle has the following format: 123 0 1 2 3 124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Direction := (InDoors | OutDoors) | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | MN UDP Port | well-known Doors Port | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | MN IPv4 address | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Door IPv4 address | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Doors Handle 137 Direction 139 The 32-bits protocol ID indicates that the Doors protocol is being 140 used to synthetize this address. At this time, There are 2 IDs 141 defined: 143 0x12345678: InDoors 145 0x12343210: OutDoors 147 MN UDP Port 149 16-bits UDP Source port, chosen dynamically by the Mobile Node. 151 Doors Port 153 16-bits UDP Destination port. A well known value DOORSPORT to be 154 assigned by IANA. For interoperability testing, DOORSPORT of 434 155 (MIPv4 Port) is used in the meantime. 157 MN IPv4 Address 159 32-bits private IPv4 address that the MN acquires dynamically 160 while roaming, using DHCP or IPCP, or that is statically 161 configured. 163 Door IPv4 Address 165 32-bits public IPv4 address of the door, that the MN learns 166 dynamically while roaming, using DHCP or IPCP extension (TBD), or 167 that is statically configured. 169 2.2 Other definitions 171 DoG 173 The Doors Gateway (DoG) is the function that terminates the Doors 174 Tunnel on both Home and Mobile ends. The DoG performs IPv4/UDP 175 automatic tunneling and a IPv6 level Network Address Translation. 177 DooR 179 A Doors Router (DooR) is a router that implements the Doors 180 Gateway. The Home Door is connected to the Home Network via IPv6. 181 Mobile Routers implementing the Doors Protocol are Mobile DooRs. 183 Doors Tunnel 185 The Doors Tunnel is an IPv4/UDP automatic tunnel that encapsulates 186 a Mobile IPv6 tunnel. The Tunnel has two Directions, InDoors and 187 OutDoors. 189 InDoors 191 A packet going InDoors flows between the Mobile Node and the DoG. 192 An InDoors packet is characterized by a Source IPv6 address that 193 is an InDoors Handle. An InDoors Handle is generated by the 194 Mobile Node, with the Direction field set to InDoors. 196 OutDoors 198 A packet going OutDoors flows between DoG and the Mobile Node. An 199 OutDoors packet is characterized by a Destination IPv6 address 200 that is an OutDoors Handle. An OutDoors Handle is generated by 201 the DoG, based on an InDoors Handle, after the IPv4 Address 202 Translation, with the Direction field set to OutDoors. 204 3. Basic MIPv6 Doors support 206 The Basic MIPv6 Doors support collocates a DoG function with the Home 207 Agent. A roaming Mobile Node generates an InDoors Handle and uses it 208 as CareOf to Bind over a Doors Tunnel to its Home Agent. All packets 209 are sent over the MN-HA tunnel, with no Route Optimization. 211 When sending a packet with a Source IPv6 address that is an InDoors 212 Handle, the Mobile Node automatically tunnels the packet over the 213 associated Doors tunnel. In turn, when sending a packet with a 214 Destination IPv6 address that is an OutDoors Handle, a HA 215 automatically tunnels the packet over the associated Doors tunnel. 217 +-----------------+ 218 | Correspondent | ^ 219 +-----------------+ | 220 | | 221 +++++++++++ | 222 + + | 223 + IPv6 + | IPv6 Connectivity 224 + + | 225 ++++++++++++ | 226 | | 227 +-----------------+ | 228 | Home Agent | | 229 | DoG | ^ 230 +-----------------+ . | 231 | | 232 +++++++++++ . | 233 + IPv4 + | 234 + Public + . | 235 + Network + | Doors 236 ++++++++++++ . | Tunnel 237 | | 238 +-----------------+ . | 239 | PAT / NAT | | 240 +-----------------+ . | 241 | | 242 +++++++++++ . | 243 + IPv4 + | 244 + Private + . | 245 + Network + | 246 ++++++++++++ . | 247 | | 248 +-----------------+ . | 249 | DoG | v 250 | Mobile Router | | 251 +-----------------+ | 252 | | 253 +++++++++++ | 254 + IPv6 + | 255 + Mobile + | 256 + Network + | 257 ++++++++++++ | 258 | | 259 +-----------------+ | 260 | MNN | v 261 +-----------------+ 263 Basic Doors Model 265 3.1 Known Restrictions 267 Since the CareOf is NATed on the way, it will cause problems to 268 Authentication Header and upper layer checksum computations, so 269 terminating a connection with the CareOf will not generally work. 270 The HA may have to save the original source IPv6 address in the 271 packets on order to perform signature and checksum validations. 273 Also, since the Doors Handle is not a valid IPv6 address, the packet 274 can not be forwarded after UDP decapsulation, so in basic MIPv6 mode, 275 the UDP tunnel MUST be terminated by the Home Agent. 277 Most of these limitations can be circumvented, but this is not 278 covered in this version of this draft, in order to keep it simple. 279 Yet, binding flows and MN-HA tunneling purposes, the Nemo 280 requirements can be fulfilled by the procedures described hereafter. 282 3.2 Operation for a MIPv6 Mobile Node roaming over IPv4 284 A MN roaming generates its InDoors Handle as follows: 286 +-------------+-------+-------+--------------+--------------+ 287 | | | | | | 288 | InDoors | xxxx | DOORS | MN private @ |Door public @ | 289 | | | | | | 290 +-------------+-------+-------+--------------+--------------+ 292 InDoors Handle 294 Direction: InDoors 296 MN UDP port: A value chosen dynamically by the Mobile Node. It 297 may be a signature used for verification purposes. 299 Doors Port: DOORSPORT 301 MN IPv4 address: the private IPv4 CoA acquired by the mobile 302 router on his roaming interface by any mechanism (configuration, 303 DHCP, IPCP, ...) 305 Door IPv4 address: An IPv4 address of the Home Agent. 307 The Mobile Node may recompute a new port periodically, build a new 308 CareOf and rebind. 310 The Mobile Node MUST be tuned to send Binding Updates often enough to 311 make sure that the NAT/PAT states are kept alive. As a result, there 312 is no additional control traffic for that purpose. 314 3.2.1 Sending packets over the Doors tunnel 316 According to non-optimized MIPv6 and basic Nemo principles, the 317 Mobile Node, and in particular if it is a Nemo Mobile Router, uses 318 the MN-HA tunnel for all communications with the Infrastructure, 319 sourcing packets with the CareOf and using the Home Address Option to 320 pass the address that is actually used as Source for upper layer 321 purposes. 323 When sending or forwarding a IPv6 packet with a Source address that 324 is a Door Number with a InDoors Handle, a Mobile Node MUST 325 encapsulate the packet into a IPv4/UDP tunnel using the following 326 settings: 328 <-- outer IPv4 header -> <-UDP ports-> 329 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 330 | | | | | | | | | | | | 331 |oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload 332 | | | | | | | | | | | | 333 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 335 InDoors Packet 337 NAF represents the Non-Address Fields of a IP header 339 Sport is the UDP Source port, set to the MN UDP port from the 340 Handle 342 DPort is the UDP Destination Port, set to the Doors Port from the 343 Handle 345 SRCV4 is the Source IPv4 address, set to the MN IPv4 address from 346 the Handle 348 DESTV4 is the Destination IPv4 address, set to the Door IPv4 349 address from the Handle. 351 SRC is the IPv6 Source Address, set to CoA == InDoors Handle 353 DEST is the Home Agent Address 355 The Payload may be Home Address Dest Option and a Mobility Header 356 or a IPv6 packet from a Node in the Mobile Network 358 This causes packets in the MN-HA tunnel to be automatically 359 reencapsulated into an IPv4/UDP tunnel to the HA IPv4 address, as 360 long as the CareOf Address is a Doors Handle. 362 3.2.2 Receiving packets over the Doors tunnel 364 The process of terminating the Doors tunnel on the MN side is: 366 Decapsulating the IPv6 packet from the IPv4/UDP encapsulation 368 Recomposing the original IPv6 address as known on the MR side. 370 When receiving a packet over UDP with Source Port equal to DOORSPORT, 371 a Mobile Node checks whether there's an inner IPv6 packet with a 372 Destination IPv6 address that is actually a Doors Handle. 374 If so, and if the Direction of the Handle is OutDoors, the MN 375 restores its InDoors Handle by: 377 Overwriting the Direction to InDoors 379 Overwriting the MN IPv4 address field with the IPv4 Destination 380 address from the received packet 382 Overwriting the MN UDP port field with the UDP Destination port 383 from the received packet 385 If the generated Doors Handle does not match its CareOf, the node 386 drops the packet. 388 Then, the node decapsulates the UDP tunnel and receives the resulting 389 IPv6 packet. The result is either yet an other level of 390 decapsulation, or, in the case of a RH type 2, a forwarding to the 391 next hop in the RH, that should be the node's home address. 393 This causes the MN-HA tunnel to be automatically decapsulated from an 394 IPv4/UDP tunnel as long as the Doors Handle is the CareOf. 396 3.3 Operation for the Home Agent of a MIPv6 MN roaming over IPv4 398 For basic MIPv6 Doors support, Home Agent runs the DoG, and the 399 OutDoors Handle is stored as CareOf in the Binding Cache. 401 3.3.1 Receiving packets over the Doors tunnel 403 The process of terminating the Doors Tunnel on the HA side is: 405 Decapsulating the IPv6 packet from the IPv4/UDP encapsulation 407 Translating the original source IPv6 address into an OutDoors 408 Handle. 410 When receiving a packet over UDP with Source Port equal to DOORSPORT, 411 the DoG function in a HA checks whether there's an inner IPv6 packet 412 with a Source IPv6 address that is actually a Doors Handle. 414 If so, and if the Direction is InDoors, DoG translates the Handle by: 416 Overwriting the Direction to OutDoors 418 Overwriting the MN IPv4 address field with the IPv4 Source Address 419 from the received packet 421 Overwriting the MN UDP port field with the UDP Source port from 422 the received packet 424 As a result, the layout of the OutDoors Handle is as follows: 426 +-------------+-------+-------+--------------+--------------+ 427 | | | | | | 428 | OutDoors | yyyy | DOORS | MN public @ |Door public @ | 429 | | | | | | 430 +-------------+-------+-------+--------------+--------------+ 432 OutDoors Handle 434 Direction: OutDoors 436 MN UDP port: May have been PATed 438 Doors Port: DOORSPORT 440 MN IPv4 address: the public IPv4 address of the MN if NATed 442 Door IPv4 address: An IPv4 address of the Home Agent. 444 At that time of translating the Handle, the DoG knows both the 445 InDoors and OutDoors tags. It may save the InDoors Handle for AH 446 computation and upper layer checksums, should there be a need for it. 448 Then, the DoG decapsulates the UDP tunnel and receives the resulting 449 IPv6 packet. As the HA is collocated with the DoG, the packet is 450 received and the OutDoors Handle is used as CareOf and stored in the 451 binding cache. 453 So the transition between IPv4 and IPv6 roaming is smooth, handled by 454 the DoG function, transparently to the HA support. 456 3.3.2 Sending packets over the Doors tunnel 458 When the HA forwards packets to a Mobile Node that is not at home, it 459 encapsulates them over the MN-HA tunnel. The Destination IPv6 460 address is the translated CareOf Address of the MN, that is the 461 OutDoors Handle of that MN if it is roaming over IPv4 using the Doors 462 Protocol. 464 When sending or forwarding a IPv6 packet with a Destination address 465 that is an OutDoors Handle, the DoG function in the Home Agent MUST 466 encapsulate the packet into a IPv4/UDP tunnel using the following 467 settings: 469 <-- outer IPv4 header -> <-UDP ports-> 470 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 471 | | | | | | | | | | | | 472 |oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload 473 | | | | | | | | | | | | 474 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 476 InDoors Packet 478 NAF represents the Non-Address Fields of a IP header 480 Sport is the UDP Source port, set to the Doors Port from the 481 Handle 483 DPort is the UDP Destination Port, set to the MN UDP port from the 484 Handle 486 SRCV4 is the Source IPv4 address, set to the Door IPv4 address 487 from the Handle. 489 DESTV4 is the Destination IPv4 address, set to the MN IPv4 address 490 from the Handle 492 SRC is the Home Agent Address 494 DEST is the IPv6 Source Address, set to the mapped CoA == OutDoors 495 Handle 497 The Payload may start with a Routing Header of type 2, or be a 498 IPv6 packet from a Node in the Mobile Network 500 When applied to Nemo, between a Mobile Router and its Home Agent, the 501 Doors protocol maintains a single state in the PAT/NAT for all the 502 communications of all the Mobile Network Nodes. 504 4. Distributed configurations 506 With the basic MIPv6 Doors support, the Home DooR is necessarily 507 collocated with the Home Agent. This is fine for a small, collapsed 508 configuration (A single HA/Door), but more of a problem for a larger, 509 distributed configuration. Further improvements, described 510 hereafter, allow for a distribution of that functionality. 512 4.1 Hierarchical MIP 514 A Mobility Anchor Point (MAP), as defined in [4] can be used to 515 terminate the Doors tunnel on behalf of the Home Agent. This permits 516 a distributed configuration with no dependencies of between the 517 number of MAPs and the number of HAs. 519 A new IPv4 region is defined, and several MAP/Doors can be deployed 520 to handle that region. They keep a state for the Mobile Nodes that 521 use their service for Regional mobility, but advertise their own 522 Global IPv6 address to the Home Agent, which uses it as the MN 523 CareOf. 525 As a result, the HA is transparent when a IPv4 traversal occurs. 527 4.2 Reverse Routing Header 529 The RRH, as defined in [3] provides an alternate technique to 530 distribute the Doors Gateways for roaming Mobile Routers. In this 531 case, a number of Mobile Routers, called Stray DoGs are deployed on 532 the Home Network side of the IPv4 Network, and configured to be "not 533 at home" - even though they do not move-, and to be Home DooRs. 535 Since they are not at home, the Stray DoGs perform the procedure 536 defined in [3] for a roaming Mobile Router, when forwarding a packet 537 decapsulated by the DoG: 539 They swap the Source address with their own (Global IPv6) CareOf 540 Address, adding the original Source (the OutDoors Handle) to the RRH. 542 As a result, the Home Agent is again transparent to the fact that 543 IPv4 traversal occurred. 545 The whole IPv4 network is now considered as the Mobile Network of the 546 Doors gateways. As a result, the Mobile Router roaming over IPv4 is 547 considered at a depth of one, attached to its selected Doors Gateway. 549 Other MRs may be attached to that roaming MR in a nested Nemo 550 Fashion. Each one maintains a tunnel to its home Agent, while all of 551 these tunnels share the same IPv4/UDP end points. 553 +-----------------+ 554 | Correspondent | ^ 555 +-----------------+ | 556 | | IPv6 Connectivity 557 +++++++++++ | 558 +-----+ + + | 559 | HA1 |--+ IPv6 + | ^ 560 +-----+ + + | | 561 ++++++++++++ | | 562 | | | 563 +-----------------+ | | 564 | Door | | ^ | 565 +-----------------+ | | 566 | . | | MR1's 567 +++++++++++ | | tunnel 568 + IPv4 + . | | Home 569 + Public + | | 570 + Network + . | Doors | 571 ++++++++++++ | Tunnel | 572 | . | (a single | 573 +-----------------+ | one for | 574 | PAT / NAT | . | all the | 575 +-----------------+ | nested | 576 | . | Nemo) | 577 +++++++++++ | | 578 + IPv4 + . | | 579 + Private + | | 580 + Network + . | | 581 ++++++?+++++ | | 582 | . | | 583 +-----------------+ | | 584 | Mobile Router 1 | v v 585 +-----------------+ | ^ 586 | | | 587 ====?=============?========== | | Nested 588 MR5 MR2 | | Mobile 589 | | | | Network 590 =========== ===?===== | | 591 MR3 | | 592 | | | 593 ==|=========?== | | 594 LFN1 MR4 | | 595 | | | 596 =============== v V 598 Doors with RRH 600 With RRH, the InDoors packets are formatted as follows: 602 <-- outer IPv4 header -> <-UDP ports-> <-RRH-> 603 +----+--------+--------+ +-----+-----+ +----+----+-----+ +------+------- 604 | | | | | | | | | | | | ... | 605 |oNAF| oSRCV4 |oDESTV4 | | SP | DP | |iNAF|iSRC|iDEST| | CoAx | Payload 606 | | | | | | | | | | | | HoAx | 607 +----+--------+--------+ +-----+-----+ +----+----+-----+ +------+------- 609 InDoors Packet with RRH support 611 NAF represents the Non-Address Fields of a IP header 613 Sport is the UDP Source port, set to the MN UDP port from the 614 Handle 616 DPort is the UDP Destination Port, set to the Doors Port from the 617 Handle 619 SRCV4 is the Source IPv4 address, set to the MN IPv4 address from 620 the Handle 622 DESTV4 is the Destination IPv4 address, set to the Door IPv4 623 address from the Handle. 625 SRC is the IPv6 Source Address, set to CoA == InDoors Handle 627 DEST is the Home Agent Address 629 RRH contains the Source Routed path to the First MR down the 630 nested Nemo, that is the real tunnel endpoint 632 The Payload may start with a Home Address Destination Option and a 633 Mobility Header or a IPv6 packet from a Node in the Mobile Network 635 The packets on the return path are sent by the Home Agent to the 636 Stray DoG that originated the inbound packets. 638 The encapsulating headers contains a Routing Header of type 2 derived 639 from the RRH. Conforming the RH type 2 processing, the Stray DoG 640 needs to forward the packet to the first entry in the Routing Header, 641 which happens to be a OutDoors Handle. 643 When sending or forwarding a IPv6 packet with a Destination address 644 that is an OutDoors Handle, the Stray DoG MUST encapsulate the packet 645 into a IPv4/UDP tunnel using the following settings: 647 <-- outer IPv4 header -> <-UDP ports-> <-RH2-> 648 +----+--------+--------+ +-----+-----+ +----+----+-----+ +------+------- 649 | | | | | | | | | | | | ... | 650 |oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | CoAx | Payload 651 | | | | | | | | | | | | HoAx | 652 +----+--------+--------+ +-----+-----+ +----+----+-----+ +------+------- 654 OutDoors Packet with RRH support 656 NAF represents the Non-Address Fields of a IP header 658 Sport is the UDP Source port, set to the Doors Port from the 659 Handle 661 DPort is the UDP Destination Port, set to the MN UDP port from the 662 Handle 664 SRCV4 is the Source IPv4 address, set to the Door IPv4 address 665 from the Handle. 667 DESTV4 is the Destination IPv4 address, set to the MN IPv4 address 668 from the Handle 670 SRC is the Home Agent Address 672 DEST is the IPv6 Source Address, set to the mapped CoA == OutDoors 673 Handle 675 The Routing Header type 2 contains the Source Routed path to the 676 First MR down the nested Nemo, that is the real tunnel endpoint 678 The Payload is a IPv6 packet to a Node in a Mobile Network behind 679 the Mobile Router HoAx 681 This solution presents a number of advantages: 683 This solution does not keep states in the gateways. The NATed 684 addresses are stored and maintained in the Home Agent binding 685 cache, as long as they are needed, by the Mobile IPv6 protocol. 687 The MR may swap its Doors Gateway whenever it needs, since this 688 will seen as yet an other roaming. In particular, the -optionally 689 local, private- address of a local Doors Gateway may be available 690 in a DHCP or an IPCP extension. 692 There is only one entry in the NAT/PAT gateway for a full Nested 693 Nemo configuration. This limits the size of the tables that the 694 NAT gateway has to maintain. 696 5. IANA considerations 698 A port number value is required for DOORSPORT. Note that this 699 requirement could be alleviated by a common configuration on both 700 sides, but this makes the deployment a bit more complex. 702 The values for InDoors and OutDoors also have to be standardized. 703 0x12345678 and 0x12343210 are given for interoperability testing in 704 the meantime. 706 6. Acknowledgements 708 The authors wish to thank: Ole Troan, Vincent Ribiere, Massimo 709 Lucchina, Daniel Shell, Ravi Samprathi, and the coffee machine for 710 their various contributions. 712 References 714 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 715 IPv6", draft-ietf-mobileip-ipv6-20 (work in progress), January 716 2003. 718 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 719 draft-ernst-monet-terminology-01 (work in progress), July 2002. 721 [3] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its 722 application to Mobile Networks", draft-thubert-nemo-reverse- 723 routing-header-01 (work in progress), October 2002. 725 [4] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier, 726 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- 727 ietf-mobileip-hmipv6-07 (work in progress), October 2002. 729 [5] Petrescu, A., "Issues in Designing Mobile IPv6 Network Mobility 730 with the MR-HA Bidirectional Tunnel (MRHA)", draft-petrescu- 731 nemo-mrha-01 (work in progress), November 2002. 733 [6] Sarikaya, B., "Architectural Requirements for Base Network 734 Mobility Using Bidirectional Tunneling", draft-sarikaya-nemo- 735 archreqs-00 (work in progress), November 2002. 737 [7] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 739 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 740 Specification", RFC 2460, December 1998. 742 Authors' Addresses 744 Pascal Thubert 745 Cisco Systems Technology Center 746 Village d'Entreprises Green Side 747 400, Avenue Roumanille 748 Biot - Sophia Antipolis 06410 749 FRANCE 751 EMail: pthubert@cisco.com 753 Marco Molteni 754 Cisco Systems Technology Center 755 Village d'Entreprises Green Side 756 400, Avenue Roumanille 757 Biot - Sophia Antipolis 06410 758 FRANCE 760 EMail: mmolteni@cisco.com 762 Patrick Wetterwald 763 Cisco Systems Technology Center 764 Village d'Entreprises Green Side 765 400, Avenue Roumanille 766 Biot - Sophia Antipolis 06410 767 FRANCE 769 EMail: pwetterw@cisco.com 771 Full Copyright Statement 773 Copyright (C) The Internet Society (2003). All Rights Reserved. 775 This document and translations of it may be copied and furnished to 776 others, and derivative works that comment on or otherwise explain it 777 or assist in its implementation may be prepared, copied, published 778 and distributed, in whole or in part, without restriction of any 779 kind, provided that the above copyright notice and this paragraph are 780 included on all such copies and derivative works. However, this 781 document itself may not be modified in any way, such as by removing 782 the copyright notice or references to the Internet Society or other 783 Internet organizations, except as needed for the purpose of 784 developing Internet standards in which case the procedures for 785 copyrights defined in the Internet Standards process must be 786 followed, or as required to translate it into languages other than 787 English. 789 The limited permissions granted above are perpetual and will not be 790 revoked by the Internet Society or its successors or assigns. 792 This document and the information contained herein is provided on an 793 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 794 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 795 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 796 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 797 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 799 Acknowledgement 801 Funding for the RFC Editor function is currently provided by the 802 Internet Society.