idnits 2.17.1 draft-thubert-nemo-ipv4-traversal-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 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 2 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 111: '... MUST NOT to be used as source or de...' RFC 2119 keyword, line 206: '...ivate, the prefix distribution MUST be...' RFC 2119 keyword, line 307: '... The Mobile Node MUST be tuned to send...' RFC 2119 keyword, line 319: '...e, a Mobile Node MUST encapsulate the ...' RFC 2119 keyword, line 405: '... with a suffix of ::1. The router MAY...' (1 more instance...) 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 (May 22, 2003) is 7645 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: '1' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 550, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 553, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 559, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 571, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 592, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 596, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2185 (ref. '2') ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '5') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2893 (ref. '9') (Obsoleted by RFC 4213) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-01 -- Possible downref: Normative reference to a draft: ref. '14' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-03) exists of draft-petrescu-nemo-mrha-02 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 7 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: November 20, 2003 P. Wetterwald 5 Cisco Systems 6 May 22, 2003 8 IPv4 traversal for MIPv6 based Mobile Routers 9 draft-thubert-nemo-ipv4-traversal-01 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 November 20, 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 Address Translations (NAT), reverse NAT, and even Port 47 Address Translation (PAT), in order to cope with the reality of 48 today's Internet. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and concepts . . . . . . . . . . . . . . . . . . 3 54 2.1 Doors Handle . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2 Other definitions . . . . . . . . . . . . . . . . . . . . . 5 56 3. MIPv6 Doors support . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Known Restrictions . . . . . . . . . . . . . . . . . . . . . 7 58 3.2 Operation for a MIPv6 Mobile Node roaming over IPv4 . . . . 7 59 3.2.1 MR Sending packets over the Doors tunnel . . . . . . . . . . 8 60 3.2.2 MR Receiving packets over the Doors tunnel . . . . . . . . . 9 61 3.3 Operation for the Door . . . . . . . . . . . . . . . . . . . 9 62 3.3.1 Door Receiving packets over the Doors tunnel . . . . . . . . 10 63 3.3.2 Door Sending packets over the Doors tunnel . . . . . . . . . 11 64 3.4 Advantages of the Doors protocol . . . . . . . . . . . . . . 12 65 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 12 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 This document assumes that the reader is familiar with Mobile IPv6 74 defined in [12], with the concept of Mobile Router (MR) and with the 75 Nemo terminology defined in [13], as well as IPv4 Network Address 76 Translation (NAT) and Port Address Translation (PAT). 78 During the transition phase from IPv4 to IPv6, hot spots that 79 actually provide IPv6 connectivity will be scarce and Mobile Routers 80 should support an alternate roaming technology over IPv4. 82 There is an existing panel of solutions from the V6 ops (ISATAP, 83 6to4, TEREDO), but these solutions fail to traverse in a simple 84 fashion all types of NAT and PAT that are heavily deployed today. 86 There is a real value in combining MIPv6 and IPv4 traversal 87 technologies. MIP brings a MN-HA tunnel and a binding cache into the 88 picture, as well as a keep alive procedure. The MIP cache can be 89 used to store the PAT/NAT states, while the Binding flow can be tuned 90 to keep the PAT/NAT active. As a result, it is possible for a IPv6 91 Mobile Router to traverse PAT/NAT with no protocol overhead or 92 additional states in the network. 94 The Doors Protocol developed in this draft extends Mobile IPv6 and is 95 more particularily aimed at the Nemo problem space. Some 96 restrictions apply that could be circumvented by additional work. 98 2. Terminology and concepts 100 2.1 Doors Handle 102 Doors inherits from 6to4 [10], that uses synthetized IPv6 addresses 103 to build automatic tunnels across IPv4. In the Doors case, that IPv6 104 global unicast address is named a Doors Handle. The Doors Handle 105 follows the 6to4 formatting rules, but it points on a IPv4 (UDP) 106 tunnel, as opposed to an interface on a machine. 108 Due to a NAT/PAT or reverse NAT traversal, the handle may be subject 109 to IPv6 level Address Translation. Since we do not want to 110 reintroduce the complexity of Application Level Gateways, the handle 111 MUST NOT to be used as source or destination address as seen by upper 112 layer protocols. 114 Rather, the only use of a Handle is as a CareOf address for Mobile 115 IPv6 as defined in [12]. Note that some ICMP messages such as DHAAD 116 may be need the Handle as source or destination. In that case, the 117 ICMP layer chacksum must be updated when the Handle is modified. 119 The Doors Handle has the following format: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | 001 | TLA ID == 2 (6to4) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Door IPv4 address | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | SLA ID | well-known Doors Port | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | MN IPv4 address | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | MN UDP Port | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Doors Handle 137 001 139 Format Prefix (3 bit) for Aggregatable Global Unicast Addresses 141 TLA ID 143 Top-Level Aggregation Identifier (13 bits). Set to 2 as 144 prescribed by RCF 3046 [10]. 146 Door IPv4 Address 148 32-bits public IPv4 address of the door, that the MN learns 149 dynamically while roaming, using DHCP or IPCP extension (TBD), or 150 that is statically configured on the MN. 152 SLA ID 154 Site-Level Aggregation Identifier 156 Doors Port 158 16-bits UDP Destination port. A well known value DOORSPORT to be 159 assigned by IANA (434 in the meantime). 161 Mobile Node IPv4 address and UDP port 163 The parameters of the socket on the MN side, generally obtained 164 dynamically by the mobile Node. 166 2.2 Other definitions 168 DoG 170 The Doors Gateway (DoG) is the function that terminates the Doors 171 Tunnel on both Home and Mobile ends. The DoG performs IPv4/UDP 172 automatic tunneling and a IPv6 level Network Address Translation. 174 DooR 176 A Doors Router (DooR) is a router that implements the Doors 177 Gateway. The Door is connected to the Home Network via the IPv6 178 infrastructure. A Home Door may be implemented at the ingress of 179 the Home Network. But Exit Doors may also be implemented at by 180 private networks in order to avoid IPv4 NAT and PAT operations. 181 In that case, the IPv4 address of the Exit Door should be 182 available dynamically, for instance by means of DHCP or IPCP 183 extensions. 185 Doors Tunnel 187 The Doors Tunnel is an IPv4/UDP automatic tunnel that encapsulates 188 a Mobile IPv6 tunnel. The Tunnel has two Directions, InDoors and 189 OutDoors. 191 InDoors and OutDoors 193 A packet going InDoors flows between the Mobile Node and the Door. 194 A packet going OutDoors flows between the Door and the Mobile 195 Node. In both cases, the packet is formed by an IPv6 packet that 196 is encapsulated over IPv4 and UDP. A packet flowing InDoors as a 197 source IPv6 address that is a Doors Handle. Reciprocally, a 198 packet flowing OutDoors as a destination IPv6 address that is a 199 Doors Handle. InDoors and OutDoors are mutually exclusive. 201 Doors Prefix 203 The prefix of a Doors Handle. It is a /64 prefix built with the 204 Door IPv4 address an an arbotrary the SLA ID. This prefix is 205 assigned to the interface that owns the associated IPv4 address. 206 if the IPv4 address is private, the prefix distribution MUST be 207 limited accordingly, which prevents Route Optimization. 209 3. MIPv6 Doors support 211 With Doors, a roaming MIPv6 Mobile Node generates a Doors Handle and 212 uses it as CareOf to Bind over a Doors Tunnel to its Home Agent. 214 +-----------------+ 215 | Correspondent | ^ 216 +-----------------+ | 217 | | IPv6 Connectivity 218 +++++++++++ | 219 +-----+ + IPv6 + | 220 | HA |--+ Network + | ^ 221 +-----+ ++++++++++++++ | | 222 | | | 223 +-----------------+ | | 224 | Door | | ^ | 225 +-----------------+ | | 226 |Door_prefix::1/64 | | 227 +++++++++++ | | 228 + private IPv4 + | | 229 + Network + . | | 230 ++++++++++++++ . | | 231 | . | | 232 +-----------------+ | | 233 | reverse NAT | . | | 234 +-----------------+ . | | 235 | . | | MR's 236 +++++++++++ | | tunnel 237 + public IPv4 + | | 238 + Network + . | Doors | 239 ++++++++++++ | Tunnel | 240 | . | | 241 +-----------------+ | | 242 | PAT / NAT | . | | 243 +-----------------+ | | 244 | . | | 245 +++++++++++ . | | 246 +---+ private IPv4 + | | 247 | + Network + . | | 248 | ++++++++++?+++ | | 249 | | . | | 250 +----+------+ +-------------+ | | 251 | DoG | | DoG | v v 252 |Mobile Node| |Mobile Router| | 253 +-----------+ +-------------+ | 254 | | 255 +++++++++++ | 256 +-----+ + IPv6 + | 257 | MNN |--+ Mobile + v 258 +-----+ + Network + 259 ++++++++++++ 261 Doors Model (worst case!!) 263 3.1 Known Restrictions 265 Since the CareOf can be translated on the way, it may cause problems 266 to Authentication Header and upper layer checksum computations. So 267 the CareOf can not be included in the signed information. As a 268 result, the reference packet for AH is always a packet where the IPv6 269 source and destination addresses are the Home Address of the MN and 270 the address of the HA, and the slots and segment left of a Routing 271 Header are set to 0. This is true for RH type 2 and the Reverse 272 Routing Header defined in [14]. 274 In any case, the Doors prefix must be reachable at IPv6 level from 275 the Home Agent, and from the Correspondent Nodes in case of Route 276 Optimization (RO). This is why RO may not be possible if the Handle 277 is based on a private address, which may occur if the Door is behind 278 a reverse NAT. 280 3.2 Operation for a MIPv6 Mobile Node roaming over IPv4 282 A MN roaming generates its Doors Handle as follows: 284 16 32 16 16 32 16 bits 285 +------+--------------+-----++------+--------------+------+ 286 | | Door | || Door | MN | MN | 287 | 2002 | IPv4 | SLA || UDP | private | UDP | 288 | | addr | || Port | addr | Port | 289 +------+--------------+-----++------+--------------+------+ 291 MR Doors Handle 293 Door IPv4 address: the public address of the door. 295 Doors Port: DOORSPORT 297 MN IPv4 address: the private IPv4 CoA obtained by the mobile 298 router on his roaming interface by any mechanism (configuration, 299 DHCP, IPCP, ...). Maybe private. 301 MN UDP port: A value chosen dynamically by the Mobile Node. It 302 may be a signature used for verification purposes. 304 The Mobile Node may recompute a new port periodically, build a new 305 CareOf and rebind. 307 The Mobile Node MUST be tuned to send Binding Updates often enough to 308 make sure that the NAT/PAT states are kept alive. As a result, there 309 is no additional control traffic for that purpose. 311 3.2.1 MR Sending packets over the Doors tunnel 313 The Doors Tunnel can be seen as an internal hop between the Mobile 314 Node and its CareOf. With that acceptation, the MIPv6 model, between 315 the CareOf and either the Home Agent or an arbitrary Correspondent 316 Node, still applies. 318 When sending or forwarding a IPv6 packet with a Source address that 319 is a Doors Handle, a Mobile Node MUST encapsulate the packet into a 320 IPv4/UDP tunnel using the following settings: 322 <-- outer IPv4 header -> <-UDP ports-> 323 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 324 | | | | | | | | | | | | 325 |oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload 326 | | | | | | | | | | | | 327 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 329 InDoors Packet 331 NAF represents the Non-Address Fields of a IP header 333 Sport is the UDP Source port, set to the MN UDP port from the 334 Handle 336 DPort is the UDP Destination Port, set to the Doors Port from the 337 Handle 339 SRCV4 is the Source IPv4 address, set to the MN IPv4 address from 340 the Handle 342 DESTV4 is the Destination IPv4 address, set to the Door IPv4 343 address from the Handle. 345 SRC is the IPv6 Source Address, set to CoA == Doors Handle 347 DEST is the Home Agent Address 349 The Payload may be Home Address Dest Option and a Mobility Header 350 or a IPv6 packet from a Node in the Mobile Network 352 This causes packets in the MN-HA tunnel to be automatically 353 reencapsulated into an IPv4/UDP tunnel to the HA IPv4 address, as 354 long as the CareOf Address is a Doors Handle. 356 Fragmentation may occur at IPv6 and/or at IPv4 encapsulation level. 357 the rules defined in [7] and [10] apply respectively. 359 3.2.2 MR Receiving packets over the Doors tunnel 361 The process of terminating the Doors tunnel on the MN side is: 363 Decapsulating the IPv6 packet from the IPv4/UDP encapsulation 365 Recomposing the original IPv6 address as known on the MN side. 367 Recomputing the checksum of ICMP messages. 369 When receiving a packet over UDP with Source Port equal to DOORSPORT, 370 a Mobile Node checks whether there's an inner IPv6 packet with a 371 Destination IPv6 address that is actually a Doors Handle. 373 If so, the MN restores it by: 375 Overwriting the MN IPv4 address and UDP port fields in the handle 376 with the IPv4 Destination information from the received packet 378 Overwriting the Door address and UDP port fields in the handle 379 with the UDP Source information from the received packet 381 If the generated Doors Handle does not match its CareOf, the node 382 drops the packet. 384 Otherwise, the node decapsulates the UDP tunnel and receives the 385 resulting IPv6 packet. The next step is either yet an other level of 386 decapsulation, or, if a RH type 2 is present, a forwarding to the 387 next hop in the RH, that should be the node's home address. 389 This causes the MN-HA tunnel to be automatically decapsulated from an 390 IPv4/UDP tunnel as long as the Doors Handle is the CareOf. 392 3.3 Operation for the Door 394 The Door does not need to keep any PAT/NAT related state since that 395 information is stored as CareOf in the Binding Cache by the Home 396 Agent and the Correspondent Nodes. 398 The Binding Cache Entries are created regarlessly whether the CareOf 399 is a Handle or a plain IPv6 address. As a result, the gating factor 400 to Doors scalability is MIP itself. 402 When the support of Door is configured on a dual stack interface of a 403 router, an IPv6 address is configured manually or automatically on 404 that interface, based on the Door Prefix associated to the IPv4 405 address of that interface, with a suffix of ::1. The router MAY 406 start redistributing the Doors prefix at that time. 408 3.3.1 Door Receiving packets over the Doors tunnel 410 The process of terminating the Doors Tunnel on the Door side is: 412 Decapsulating the IPv6 packet from the IPv4/UDP encapsulation 414 Translating the original source IPv6 address into an OutDoors 415 Handle. 417 Recomputing the checksum of ICMP messages. 419 When receiving a packet over UDP with Source Port equal to DOORSPORT, 420 the DoG function in a HA checks whether there's an inner IPv6 packet 421 with a Source IPv6 address that is actually a Doors Handle. 423 If so, the Door translates the Handle by: 425 Overwriting the MN IPv4 address and UDP port fields in the handle 426 with the IPv4 Source information from the received packet. 428 Overwriting the Door IPv4 address and UDP port fields in the 429 habdle with the IPv4 Destination information from the received 430 packet. 432 As a result, the layout of the OutDoors Handle is as follows: 434 16 32 16 16 32 16 bits 435 +------+--------------+-----++------+--------------+------+ 436 | | Door | || Door | MN | MN | 437 | 2002 | IPv4 | SLA || UDP | public | PATd | 438 | | addr | || Port | (NATd) addr | Port | 439 +------+--------------+-----++------+--------------+------+ 441 Door Handle 443 Doors Port: DOORSPORT 445 Door IPv4 address: The IPv4 address of the Door. Maybe private. 447 MN IPv4 address: the public IPv4 address of the MN. 449 MN UDP port: May have been PATed 451 After computing the OutDoors Handle, the DoG decapsulates the UDP 452 tunnel and forwards the resulting IPv6 packet. If the HA or CN is 453 collocated with the DoG, the packet is received, and in any case the 454 OutDoors Handle is used as CareOf and stored in the binding cache of 455 the destination. 457 3.3.2 Door Sending packets over the Doors tunnel 459 Since the Door advertises the Door prefix, and since the OutDoors 460 Handle belongs to that prefix, normal IPv6 routing take place between 461 the HA or CN and the Door on the way to the MN. 463 When forwarding a packet to a destination that is a OutDoors Handle, 464 a router running as a Door checks whether it has an IPv6 connected 465 route to that prefix. If so, instead of looking up the Link Layer 466 address of the Handle, it MUST encapsulate the packet over IPv4/UDP 467 using the following settings: 469 <-- outer IPv4 header -> <-UDP ports-> 470 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 471 | | | | | | | | | | | | 472 |oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload 473 | | | | | | | | | | | | 474 +----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+------- 476 OutDoors 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 3.4 Advantages of the Doors protocol 506 This solution presents a number of advantages: 508 This solution does not keep states in the gateways. The NATed 509 addresses are stored and maintained in the MIP binding cache, only 510 as long as they are needed, by the Mobile IPv6 protocol. Note 511 that in case of a symmetrical PAT, the CNs and the HAs may not see 512 the same CareOf for a same MN. 514 The MN may swap its Doors Gateway whenever it needs, since this 515 will seen as yet an other roaming. In particular, the address of 516 a local Doors Gateway may be available in a DHCP or a IPCP 517 extension. 519 The transition between Doors or between IPv4 and IPv6 roaming is 520 smooth, handled by the DoG function, transparently to the HA and 521 CN support. 523 There is only one entry in the NAT/PAT gateway for a full Nested 524 Nemo configuration with no route optimization. This limits the 525 size of the tables that the NAT gateway has to maintain. 527 4. IANA considerations 529 A port number value is required for DOORSPORT. Note that this 530 requirement could be alleviated by a common configuration on both 531 sides, but this makes the deployment a bit more complex. 533 Today we use TLA of 02 which is reserved to 6to4. We see Doors as a 534 subset of the general 6to4 prefix, but a Door can not function as a 535 general purpose 6to4 gateway. Is that worth using a different TLA? 537 5. Acknowledgements 539 The authors wish to thank: 541 Ole Troan, Vincent Ribiere, Massimo Lucchina, Daniel Shell, Ravi 542 Samprathi, William Ivancic and the coffee machine for their various 543 contributions. 545 References 547 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 548 1981. 550 [2] Callon, R. and D. Haskin, "Routing Aspects Of IPv6 Transition", 551 RFC 2185, September 1997. 553 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", RFC 2373, July 1998. 556 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 557 Specification", RFC 2460, December 1998. 559 [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 560 for IP Version 6 (IPv6)", RFC 2461, December 1998. 562 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 563 Autoconfiguration", RFC 2462, December 1998. 565 [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 566 Specification", RFC 2473, December 1998. 568 [8] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 569 Domains without Explicit Tunnels", RFC 2529, March 1999. 571 [9] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 572 Hosts and Routers", RFC 2893, August 2000. 574 [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 575 IPv4 Clouds", RFC 3056, February 2001. 577 [11] Vaarala, S. and O. Levkowetz, "Mobile IP NAT/NAPT Traversal 578 using UDP Tunnelling", draft-ietf-mobileip-nat-traversal-07 579 (work in progress), November 2002. 581 [12] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 582 IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), March 583 2003. 585 [13] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 586 draft-ernst-monet-terminology-01 (work in progress), July 2002. 588 [14] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 589 its application to Mobile Networks", draft-thubert-nemo- 590 reverse-routing-header-01 (work in progress), October 2002. 592 [15] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier, 593 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- 594 ietf-mobileip-hmipv6-07 (work in progress), October 2002. 596 [16] Petrescu, A., "Issues in Designing Mobile IPv6 Network Mobility 597 with the MR-HA Bidirectional Tunnel (MRHA)", draft-petrescu- 598 nemo-mrha-02 (work in progress), March 2003. 600 Authors' Addresses 602 Pascal Thubert 603 Cisco Systems Technology Center 604 Village d'Entreprises Green Side 605 400, Avenue Roumanille 606 Biot - Sophia Antipolis 06410 607 FRANCE 609 EMail: pthubert@cisco.com 611 Marco Molteni 612 Cisco Systems Technology Center 613 Village d'Entreprises Green Side 614 400, Avenue Roumanille 615 Biot - Sophia Antipolis 06410 616 FRANCE 618 EMail: mmolteni@cisco.com 620 Patrick Wetterwald 621 Cisco Systems Technology Center 622 Village d'Entreprises Green Side 623 400, Avenue Roumanille 624 Biot - Sophia Antipolis 06410 625 FRANCE 627 EMail: pwetterw@cisco.com 629 Full Copyright Statement 631 Copyright (C) The Internet Society (2003). All Rights Reserved. 633 This document and translations of it may be copied and furnished to 634 others, and derivative works that comment on or otherwise explain it 635 or assist in its implementation may be prepared, copied, published 636 and distributed, in whole or in part, without restriction of any 637 kind, provided that the above copyright notice and this paragraph are 638 included on all such copies and derivative works. However, this 639 document itself may not be modified in any way, such as by removing 640 the copyright notice or references to the Internet Society or other 641 Internet organizations, except as needed for the purpose of 642 developing Internet standards in which case the procedures for 643 copyrights defined in the Internet Standards process must be 644 followed, or as required to translate it into languages other than 645 English. 647 The limited permissions granted above are perpetual and will not be 648 revoked by the Internet Society or its successors or assigns. 650 This document and the information contained herein is provided on an 651 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 652 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 653 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 654 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 655 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 657 Acknowledgement 659 Funding for the RFC Editor function is currently provided by the 660 Internet Society.