idnits 2.17.1 draft-ietf-behave-v6v4-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 24, 2009) is 5291 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'RFC2428' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'RFC3142' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'RFC3879' is defined on line 1287, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1304, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 1311, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-01 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-02 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-02 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-venaas-behave-mcast46-01 == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-02 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 behave F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational X. Li 5 Expires: April 27, 2010 C. Bao 6 CERNET Center/Tsinghua University 7 K. Yin 8 Cisco Systems 9 October 24, 2009 11 Framework for IPv4/IPv6 Translation 12 draft-ietf-behave-v6v4-framework-03 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 27, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This note describes a framework for IPv4/IPv6 translation. This is 51 in the context of replacing NAT-PT, which was deprecated by RFC 4966, 52 and to enable networks to have IPv4 and IPv6 coexist in a somewhat 53 rational manner while transitioning to an IPv6 network. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7 61 1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 8 62 2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 10 63 2.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 11 64 2.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . . . 13 65 2.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 13 66 2.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . . . 14 67 2.5. Scenario 5: an IPv6 network to an IPv4 network . . . . . . 15 68 2.6. Scenario 6: an IPv4 network to an IPv6 network . . . . . . 15 69 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . . . 16 70 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . . . 17 71 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 3.1. Translation Components . . . . . . . . . . . . . . . . . . 18 73 3.1.1. Address Translation . . . . . . . . . . . . . . . . . 18 74 3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 19 75 3.1.3. Maintaining Translation State . . . . . . . . . . . . 19 76 3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 19 77 3.1.5. ALGs for Other Applications Layer Protocols . . . . . 20 78 3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 20 79 3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 20 80 3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 22 81 3.3. Layout of the Related Documents . . . . . . . . . . . . . 23 82 4. Translation in Operation . . . . . . . . . . . . . . . . . . . 25 83 5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 26 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction 94 This note describes a framework for IPv4/IPv6 translation. This is 95 in the context of replacing NAT-PT [RFC2766], which was deprecated by 96 [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a 97 somewhat rational manner while transitioning to an IPv6-only network. 99 NAT-PT was deprecated to inform the community that NAT-PT had 100 operational issues and was not considered a viable medium- or long- 101 term strategy for either coexistence or transition. It wasn't 102 intended to say that IPv4<->IPv6 translation was bad, but the way 103 that NAT-PT did it was bad, and in particular using NAT-PT as a 104 general-purpose solution was bad. As with the deprecation of the RIP 105 routing protocol [RFC1923] at the time the Internet was converting to 106 CIDR, the point was to encourage network operators to actually move 107 away from technology with known issues. 109 [RFC4213] describes the IETF's view of the most sensible transition 110 model. The IETF recommends, in short, that network operators 111 (transit providers, service providers, enterprise networks, small and 112 medium businesses, SOHO and residential customers, and any other kind 113 of network that may currently be using IPv4) obtain an IPv6 prefix, 114 turn on IPv6 routing within their networks and between themselves and 115 any peer, upstream, or downstream neighbors, enable it on their 116 computers, and use it in normal processing. This should be done 117 while leaving IPv4 stable, until a point is reached that any 118 communication that can be carried out could use either protocol 119 equally well. At that point, the economic justification for running 120 both becomes debatable, and network operators can justifiably turn 121 IPv4 off. This process is comparable to that of [RFC4192], which 122 describes how to renumber a network using the same address family 123 without a flag day. While running stably with the older system, 124 deploy the new. Use the coexistence period to work out such kinks as 125 arise. When the new is also running stably, shift production to it. 126 When network and economic conditions warrant, remove the old, which 127 is now no longer necessary. 129 The question arises: what if that is infeasible due to the time 130 available to deploy or other considerations? What if the process of 131 moving a network and its components or customers is starting too late 132 for contract cycles to affect IPv6 turn-up on important parts at a 133 point where it becomes uneconomical to deploy global IPv4 addresses 134 in new services? How does one continue to deploy new services 135 without balkanizing the network? 137 This document describes translation as one of the tools networks 138 might use to facilitate coexistence and ultimate transition. 140 1.1. Why Translation? 142 Besides dual-stack deployment, there are two fundamental approaches 143 one could take to interworking between IPv4 and IPv6: tunneling and 144 translation. One could - and in the 6NET we did - build an overlay 145 network using the new protocol inside tunnels. Various proposals 146 take that model, including 6to4 [RFC3056], Teredo [RFC4380], ISATAP 147 [RFC5214], and DS-Lite [I-D.durand-softwire-dual-stack-lite]. The 148 advantage of doing so is that the new is enabled to work without 149 disturbing the old protocol, providing connectivity between users of 150 the new protocol. There are two disadvantages to tunneling: 152 o Operators of old protocol networks are unable to offer services to 153 users of the new architecture, and those users are unable to use 154 the services of the underlying infrastructure - it is just 155 bandwidth, and 157 o It doesn't enable new protocol users to communicate with old 158 protocol users without dual-stack hosts. 160 As noted, in this work, we look at Internet Protocol translation as a 161 transition strategy. [RFC4864] forcefully makes the point that many 162 of the reasons people use Network Address Translators are met as well 163 by routing or protocol mechanisms that preserve the end-to-end 164 addressability of the Internet. What it did not consider is the case 165 in which there is an ongoing requirement to communicate with IPv4 166 systems, but configuring IPv4 routing is not in the network 167 operator's view the most desirable strategy, or is infeasible due to 168 a shortage of global address space. Translation enables the client 169 of a network, whether a transit network, an access network, or an 170 edge network, to access the services of the network and communicate 171 with other network users regardless of their protocol usage - within 172 limits. Like NAT-PT, IPv4/IPv6 translation under this rubric is not 173 a long-term support strategy, but it is a medium-term coexistence 174 strategy that can be used to facilitate a long-term program of 175 transition. 177 1.2. Terminology 179 The following terminology is used in this document and other 180 documents related to it. 182 An IPv4 network: A specific network that has an IPv4-only 183 deployment. This could be an enterprise's IPv4-only network or an 184 ISP's IPv4-only network. The IPv4 Internet is the set of all 185 interconnected IPv4 networks. 187 An IPv6 network: A specific network that has an IPv6-only 188 deployment. This could be an enterprise's IPv6-only network or an 189 ISP's IPv6-only network. The IPv6 Internet is the set of all 190 interconnected IPv6 networks. 192 Dual-Stack implementation: A Dual-Stack implementation, in this 193 context, comprises an IPv4/IPv6 enabled end system stack, 194 applications plus routing in the network. It implies that two 195 application instances are capable of communicating using either 196 IPv4 or IPv6 - they have stacks, they have addresses, and they 197 have any necessary network support including routing. 199 IPv4-converted addresses: They are the IPv6 addresses used to 200 represent IPv4 hosts. They have an explicit mapping relationship 201 to IPv4 addresses. This relationship is self described by mapping 202 IPv4 address in the IPv6 address. Both stateless and stateful 203 translators are using IPv4-converted IPv6 addresses to represent 204 IPv4 hosts. 206 IPv4-only: An IPv4-only implementation, in this context, comprises 207 an IPv4-enabled end system stack, applications plus routing in the 208 network. It implies that two application instances are capable of 209 communicating using IPv4, but not IPv6 - they have an IPv4 stack, 210 addresses, and network support including IPv4 routing and 211 potentially IPv4/IPv4 translation, but some element is missing 212 that prevents communication with IPv6 hosts. 214 IPv4-translatable addresses: They are the IPv6 addresses to be 215 assigned to IPv6 hosts for the stateless translator. They have an 216 explicit mapping relationship to IPv4 addresses. This 217 relationship is self described by mapping IPv4 address in the IPv6 218 address. The stateless translator is using the corresponding IPv4 219 addresses to represent the IPv6 hosts. The stateful translator 220 does not use this kind of addresses, since the IPv6 hosts are 221 represnted by the IPv4 address pool in the translator via dynamic 222 states. 224 IPv6-only: An IPv6-only implementation, in this context, comprises 225 an IPv6 enabled end system stack, applications directly or 226 indirectly using that IPv6 stack, plus routing in the network. It 227 implies that two application instances are capable of 228 communicating using IPv6, but not IPv4 - they have an IPv6 stack, 229 addresses, and network support including routing in IPv6, but some 230 element is missing that prevents communication with IPv4 hosts. 232 Network-Specific Prefix (NSP): IPv6 prefixes are assigned to a 233 network operator by its regional internet registrar (RIR). From 234 an IPv6 prefix assigned to the operator, the operator chooses a 235 longer prefix for use by the operator's translator(s). Hence a 236 given IPv4 address would have different IPv6 representations in 237 different networks that use different prefixes. A network- 238 specific prefix is also known as a Local Internet Registry (LIR) 239 prefix. 241 State: "State" refers to dynamic information that is stored in a 242 network element. For example, if two systems are connected by a 243 TCP connection, each stores information about the connection, 244 which is called "connection state". In this context, the term 245 refers to dynamic correlations between IP addresses on either side 246 of a translator, or {IP address, transport protocol, transport 247 port number} tuples on either side of the translator. Of stateful 248 algorithms, there are at least two major flavors depending on the 249 kind of state they maintain: 251 Hidden state: the existence of this state is unknown outside the 252 network element that contains it. 254 Known state: the existence of this state is known by other 255 network elements. 257 Stateful Translation: A translation algorithm may be said to 258 "require state in a network element" or be "stateful" if the 259 transmission or reception of a packet creates or modifies a data 260 structure in the relevant network element. 262 Stateful Translator: A translator that uses stateful translation for 263 either the source or destination address. A stateful translator 264 also uses a stateless translation algorithm for the other type of 265 address. 267 Stateless Translation: A translation algorithm that is not 268 "stateful" is "stateless". It derives its needed information 269 algorithmically from the messages it is translating. 271 Stateless Translator: A translator that uses only stateless 272 translation for both destination address and source address. 274 Well-Known Prefix (WKP): A prefix assigned by IANA. In this case, 275 there would be a single representation of a public IPv4 address in 276 the IPv6 address space. 278 1.3. Translation Objectives 280 In any translation model, there is a question of objectives. 281 Ideally, one would like to make any system and any application 282 running on it able to "talk with" - exchange datagrams supporting 283 applications with - any other system running the same application 284 regardless of whether they have an IPv4 stack and connectivity or 285 IPv6 stack and connectivity. That was the model for NAT-PT, and the 286 things it necessitated led to scaling and operational difficulties 287 [RFC4966] . 289 So the question comes back to what different kinds of connectivity 290 can be easily supported and what kinds are harder, and what 291 technologies are needed to at least pick the low-hanging fruit. We 292 observe that applications today fall into three main categories: 294 Client/Server Application: Per whatis.com, "'Client/server' 295 describes the relationship between two computer programs in which 296 one program, the client, makes a service request from another 297 program, the server, which fulfills the request." In networking, 298 the behavior of the applications is that connections are initiated 299 from client software and systems to server software and systems. 300 Examples include mail handling between an end user and his mail 301 system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name 302 resolution. 304 Peer-to-Peer (P2P) Application: A P2P application is an application 305 that uses the same endpoint to initiate outgoing sessions to 306 peering hosts as well as accept incoming sessions from peering 307 hosts. These in turn fall broadly into two categories: 309 Peer-to-peer infrastructure applications: Examples of 310 "infrastructure applications" include SMTP between MTAs, 311 Network News, and SIP. Any MTA might open an SMTP session with 312 any other at any time; any SIP Proxy might similarly connect 313 with any other SIP Proxy. An important characteristic of these 314 applications is that they use ephemeral sessions - they open 315 sessions when they are needed and close them when they are 316 done. 318 Peer-to-peer file exchange applications: Examples of these 319 include Limewire, BitTorrent, and UTorrent. These are 320 applications that open some sessions between systems and leave 321 them open for long periods of time, and where ephemeral 322 sessions are important, are able to learn about the reliability 323 of peers from history or by reputation. They use the long-term 324 sessions to map content availability. Short-term sessions are 325 used to exchange content. They tend to prefer to ask for 326 content from servers that they find reliable and available. 328 If the question is the ability to open connections between systems, 329 then one must ask who opens connections. 331 o We need a technology that will enable systems that act as clients 332 to be able to open sessions with other systems that act as 333 servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 334 direction. Ideally, this is stateless; especially in a carrier 335 infrastructure, the preponderance of accesses will be to servers, 336 and this optimizes access to them. However, a stateful algorithm 337 is acceptable if the complexity is minimized and a stateless 338 algorithm cannot be constructed. 340 o We also need a technology that will allow peers to connect with 341 each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 342 direction. Again, it would be ideal if this was stateless, but a 343 stateful algorithm is acceptable if the complexity is minimized 344 and a stateless algorithm cannot be constructed. 346 o In many situations, hosts are purely clients. In those 347 situations, we do not need an algorithm to enable connections to 348 those hosts 350 The complexity arguments bring us in the direction of hidden state: 351 if state must be shared between the application and the translator or 352 between translation components, complexity and deployment issues are 353 greatly magnified. The objective of the translators is to reduce, as 354 much as possible, the software changes in the hosts necessary to 355 support translation. 357 NAT-PT is an example of a facility with known state - at least two 358 software components (the data plane translator and the DNS 359 Application Layer Gateway, which may be implemented in the same or 360 different systems) share and must coordinate translation state. A 361 typical IPv4/IPv4 NAT implements an algorithm with hidden state. 362 Obviously, stateless translation requires less computational overhead 363 than stateful translation, and less memory to maintain the state, 364 because the translation tables and their associated methods and 365 processes exist in a stateful algorithm and don't exist in a 366 stateless one. 368 1.4. Transition Plan 370 While the design of IPv4 made it impossible for IPv6 to be compatible 371 on the wire, the designers intended that it would coexist with IPv4 372 during a period of transition. The primary mode of coexistence was 373 dual-stack operation - routers would be dual-stacked so that the 374 network could carry both address families, and IPv6-capable hosts 375 could be dual-stack to maintain access to IPv4-only partners. The 376 goal was that the preponderance of hosts and routers in the Internet 377 would be IPv6-capable long before IPv4 address space allocation was 378 completed. At this time, it appears the exhaustion of IPv4 address 379 space will occur before significant IPv6 adoption. 381 Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three- 382 phase progression: 384 Preparation Phase (current): characterized by pilot use of IPv6, 385 primarily through transition mechanisms defined in [RFC4213], and 386 planning activities. 388 Transition Phase (2010 through 2011): characterized by general 389 availability of IPv6 in provider networks which SHOULD be native 390 IPv6; organizations SHOULD provide IPv6 connectivity for their 391 Internet-facing servers, but SHOULD still provide IPv4-based 392 services via a separate service name. 394 Post-Transition Phase (2012 and beyond): characterized by a 395 preponderance of IPv6-based services and diminishing support for 396 IPv4-based services. 398 Various timelines have been discussed, but most will agree with the 399 pattern of the above three transition phases, also known as an "S" 400 curve transition pattern. 402 In each of these phases, the coexistence problem and solution space 403 has a different focus: 405 Preparation Phase: Coexistence tools are needed to facilitate early 406 adopters by removing impediments to IPv6 deployment, and to assure 407 that nothing is lost by adopting IPv6, in particular that the IPv6 408 adopter has unfettered access to the global IPv4 Internet 409 regardless of whether they have a global IPv4 address (or any IPv4 410 address or stack at all). While it might appear reasonable for 411 the cost and operational burden to be borne by the early adopter, 412 the shared goal of promoting IPv6 adoption would argue against 413 that model. Additionally, current IPv4 users should not be forced 414 to retire or upgrade their equipment and the burden remains on 415 service providers to carry and route native IPv4. This is known 416 as the early stage of the "S" curve. 418 Transition Phase: This is the last stage of "S" curve. During the 419 middle stage of "S" curve, while IPv6 adoption can be expected to 420 accelerate, there will still be a significant portion of the 421 Internet operating in IPv4-only or preferring IPv4. During this 422 phase the norm shifts from IPv4 to IPv6, and coexistence tools 423 evolve to ensure interoperability between domains that may be 424 restricted to IPv4 or IPv6. 426 Post-Transition Phase: In this phase, IPv6 is ubiquitous and the 427 burden of maintaining interoperability shifts to those who choose 428 to maintain IPv4-only systems. While these systems should be 429 allowed to live out their economic life cycles, the IPv4-only 430 legacy users at the edges should bear the cost of coexistence 431 tools, and at some point service provider networks should not be 432 expected to carry and route native IPv4 traffic. 434 The choice between the terms "transition" versus "coexistence" has 435 engendered long philosophical debate. "Transition" carries the sense 436 that we are going somewhere, while "coexistence" seems more like we 437 are sitting somewhere. Historically with IETF, "transition" has been 438 the term of choice [RFC4213][RFC5211], and the tools for 439 interoperability have been called "transition mechanisms". There is 440 some perception or conventional wisdom that adoption of IPv6 is being 441 impeded by the deficiency of tools to facilitate interoperability of 442 nodes or networks that are constrained (in some way, fully or 443 partially) from full operation in one of the address families. In 444 addition, it is apparent that transition will involve a period of 445 coexistence; the only real question is how long that will last. 447 Thus, coexistence is an integral part of the transition plan, not in 448 conflict with it, but there will be a balancing act. It starts out 449 being a way for early adopters to easily exploit the bigger IPv4 450 Internet, and ends up being a way for late/never adopters to hang on 451 with IPv4 (at their own expense, with minimal impact or visibility to 452 the Internet). One way to look at solutions is that cost incentives 453 (both monetary cost and the operational overhead for the end user) 454 should encourage IPv6 and discourage IPv4. That way natural market 455 forces will keep the transition moving - especially as the legacy 456 IPv4-only stuff ages out of use. There will come a time to set a 457 date after which no one is obligated to carry native IPv4 but it 458 would be premature to attempt to do so yet. The end goal should not 459 be to eliminate IPv4 by fiat, but rather render it redundant through 460 ubiquitous IPv6 deployment. IPv4 may never go away completely, but 461 rational plans should move the costs of maintaining IPv4 to those who 462 insist on using it after wide adoption of IPv6. 464 2. Scenarios for IPv4/IPv6 Translation 466 It is important to note that the choice of translation solution and 467 the assumptions about the network where they are used impact the 468 consequences. A translator for the general case has a number of 469 issues that a translator for a more specific situation may not have 470 at all. 472 The intention of this document is to focus on network-based 473 translation solutions under all kinds of situations. All IPv4/IPv6 474 translation cases can be easily described in terms of "interoperation 475 between a set of systems (applications) that only communicate using 476 IPv4 and a set of systems that only communicate using IPv6", but the 477 differences at a detailed level make them interesting. 479 Based on the transition plan described in Section 1.4, there are four 480 types of IPv4/IPv6 translation scenarios: 482 a. Interoperation between an IPv6 network and the IPv4 Internet 484 b. Interoperation between an IPv4 network and the IPv6 Internet 486 c. Interoperation between an IPv6 network and an IPv4 network 488 d. Interoperation between the IPv6 Internet and the IPv4 Internet 490 Each one in the above can be divided into two scenarios, depending on 491 whether the IPv6 side or the IPv4 side initiates communication, so 492 there are a total of eight scenarios. 494 Scenario 1: an IPv6 network to the IPv4 Internet 496 Scenario 2: the IPv4 Internet to an IPv6 network 498 Scenario 3: the IPv6 Internet to an IPv4 network 500 Scenario 4: an IPv4 network to the IPv6 Internet 502 Scenario 5: an IPv6 network to an IPv4 network 504 Scenario 6: an IPv4 network to an IPv6 network 506 Scenario 7: the IPv6 Internet to the IPv4 Internet 508 Scenario 8: the IPv4 Internet to the IPv6 Internet 510 We will discuss each scenario in detail in the next section. 512 2.1. Scenario 1: an IPv6 network to the IPv4 Internet 514 Due to the lack of the publicly routable IPv4 addresses or under 515 other technical or economical constraints, the network is IPv6-only, 516 but the hosts in the network require communicating with the global 517 IPv4 Internet. 519 This is the typical scenario for what we sometimes call "green_field" 520 deployments. One example is an enterprise network that wishes to 521 operate only IPv6 for operational simplicity, but still wishes to 522 reach the content in the IPv4 Internet. The green_field enterprise 523 scenario is different from ISP's network in the sense that there is 524 only one place that the enterprise can easily modify: the border 525 between its network and the IPv4 Internet. Obviously, the IPv4 526 Internet operates the way it already does. But in addition, the 527 hosts in the enterprise network are commercially available devices, 528 personal computers with existing operating systems. This restriction 529 drives us to a "one box" type of solution, where IPv6 can be 530 translated into IPv4 to reach the public Internet. 532 Other cases that have been mentioned include wireless ISP networks 533 and sensor networks. This bears a striking resemblance to this 534 scenario as well, if one considers the ISP network to simply be a 535 very special kind of enterprise network. 537 -------- 538 // \\ ----------- 539 / \ // \\ 540 / +----+ \ 541 | |XLAT| | 542 | The IPv4 +----+ An IPv6 | 543 | Internet +----+ Network | XLAT: v4/v6 544 | |DNS | | Translator 545 \ +----+ / DNS: DNS64 546 \ / \\ // 547 \\ // ----------- 548 -------- 549 <==== 551 Figure 1: Scenario 1 553 Currently, there are two proposed solutions for this scenario: NAT64 554 [I-D.bagnulo-behave-nat64] as the stateful translation and IVI 555 [I-D.xli-behave-ivi] as the stateless translation schemes, 556 respectively. The NAT64 can support any IPv6 addresses in an IPv6 557 network communicating with the IPv4 Internet, while IVI can support a 558 subset of the IPv6 addresses in an IPv6 network communicating with 559 the IPv4 Internet. 561 2.2. Scenario 2: the IPv4 Internet to an IPv6 network 563 This scenario is predicted to become increasingly important as the 564 network administrators are under pressure to put IPv6-only servers in 565 its network, while the majority of the Internet users are still in 566 the IPv4 Internet. For example, for an IPv6 operator, it may be a 567 difficult proposition to leave all IPv4-only devices without 568 reachability. Thus, with a translation solution for this scenario, 569 the benefits would be clear. Not only could servers move directly to 570 IPv6 without trudging through a difficult transition period, but they 571 could do so without risk of losing connectivity with the IPv4-only 572 Internet. 574 -------- 575 // \\ ---------- 576 / \ // \\ 577 / +----+ \ 578 | |XLAT| | 579 | The IPv4 +----+ An IPv6 | 580 | Internet +----+ Network | XLAT: v4/v6 581 | |DNS | | Translator 582 \ +----+ / DNS: DNS46 583 \ / \\ // 584 \\ // ---------- 585 -------- 586 ====> 588 Figure 2: Scenario 2 590 In general, this scenario presents a hard case for translation. 591 Stateful translation such as NAT-PT [RFC2766] can be used in this 592 scenario, but it requires tightly coupled DNS ALG in the translator 593 and this technique was deprecated by the IETF [RFC4966]. 595 The stateless translation solution IVI [I-D.xli-behave-ivi] in 596 Scenario 1 can also work in Scenario 2, since it can support IPv4- 597 initiated communications with a subset of the IPv6 addresses in an 598 IPv6 network. 600 2.3. Scenario 3: the IPv6 Internet to an IPv4 network 602 There is a requirement for a legacy IPv4 network to provide services 603 to IPv6 hosts. 605 ----------- 606 ---------- // \\ 607 // \\ / \ 608 / +----+ \ 609 | |XLAT| | 610 | An IPv4 +----+ The IPv6 | 611 | Network +----+ Internet | XLAT: v4/v6 612 | |DNS | | Translator 613 \ +----+ / DNS: DNS64 614 \\ // \ / 615 --------- \\ // 616 ----------- 617 <==== 619 Figure 3: Scenario 3 621 The stateless translation will not work for this scenario, because an 622 IPv4 network needs to communicate with all of the IPv6 Internet, not 623 just a small subset, and stateless can only support a small subset. 624 However, IPv6-initiated communication can be achieved through 625 stateful translation. For example, NAT64 [I-D.bagnulo-behave-nat64] 626 can support this scenario. 628 2.4. Scenario 4: an IPv4 network to the IPv6 Internet 630 Due to technical or economical constraints, the network is IPv4-only, 631 and IPv4-only hosts (applications) may require communicating with the 632 global IPv6 Internet. 634 ----------- 635 ---------- // \\ 636 // \\ / \ 637 / +----+ \ 638 | |XLAT| | 639 | An IPv4 +----+ The IPv6 | XLAT: v4/v6 640 | Network +----+ Internet | Translator 641 | |DNS | | DNS: DNS46 642 \ +----+ / 643 \\ // \ / 644 --------- \\ // 645 ---------- 646 =====> 648 Figure 4: Scenario 4 650 In general, this scenario presents a hard case for translation. 651 Stateful translation such as NAT-PT [RFC2766] can be used in this 652 scenario, but it requires a tightly coupled DNS ALG in the translator 653 and this technique was deprecated by the IETF [RFC4966]. 655 From the transition phase discussion in Section 1.4, this scenario 656 will probably only occur when we are well past the early stage of the 657 "S" curve and the v4/v6 transition has already moved to the right 658 direction. Therefore, in-network translation is not viable for this 659 scenario and other techniques should be considered. 661 2.5. Scenario 5: an IPv6 network to an IPv4 network 663 This is one of the scenarios where both an IPv4 network and an IPv6 664 network are within the same organization. 666 The IPv4 addresses used are either public IPv4 addresses or [RFC1918] 667 addresses. The IPv6 addresses used are either public IPv6 addresses 668 or ULAs (Unique Local Addresses) [RFC4193]. 670 --------- --------- 671 // \\ // \\ 672 / +----+ \ 673 | |XLAT| | 674 | An IPv4 +----+ An IPv6 | 675 | Network +----+ Network | XLAT: v4/v6 676 | |DNS | | Translator 677 \ +----+ / DNS: DNS64 678 \\ // \\ // 679 -------- --------- 680 <==== 682 Figure 5: Scenario 5 684 The translation requirement from this scenario has no significant 685 difference from scenario 1, so both the stateful and stateless 686 translation schemes discussed in Section 2.1 apply here. 688 2.6. Scenario 6: an IPv4 network to an IPv6 network 690 This is another scenario when both an IPv4 network and an IPv6 691 network are within the same organization. 693 The IPv4 addresses used are either public IPv4 addresses or [RFC1918] 694 addresses. The IPv6 addresses used are either public IPv6 addresses 695 or ULAs (Unique Local Addresses) [RFC4193]. 697 -------- --------- 698 // \\ // \\ 699 / +----+ \ 700 | |XLAT| | 701 | An IPv4 +----+ An IPv6 | 702 | Network +----+ Network | XLAT: v4/v6 703 | |DNS | | Translator 704 \ +----+ / DNS: DNS46 705 \\ // \\ // 706 -------- --------- 707 ====> 709 Figure 6: Scenario 6 711 The translation requirement from this scenario has no significant 712 difference from scenario 2, so the translation scheme discussed in 713 Section 2.2 applies here. 715 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet 717 This seems the ideal case for in-network translation technology, 718 where any IPv6-only host or application on the global Internet can 719 initiate communication with any IPv4-only host or application on the 720 global Internet. 722 -------- --------- 723 // \\ // \\ 724 / \ / \ 725 / +----+ \ 726 | |XLAT| | 727 | The IPv4 +----+ The IPv6 | 728 | Internet +----+ Internet | XLAT: v4/v6 729 | |DNS | | Translator 730 \ +----+ / DNS: DNS64 731 \ / \ / 732 \\ // \\ // 733 -------- --------- 734 <==== 736 Figure 7: Scenario 7 738 Due to the huge difference in size between the address spaces of the 739 IPv4 Internet and the IPv6 Internet, there is no viable translation 740 technique to handle unlimited IPv6 address translation. 742 If we ever run into this scenario, fortunately, the IPv4-IPv6 743 transition has already past the early stage of the "S" curve, 744 therefore, there is no obvious business reason to demand a 745 translation solution as the only transition strategy. 747 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet 749 This seems the ideal case for in-network translation technology, 750 where any IPv4-only host or application on the global Internet can 751 open connection to any IPv6-only host or application on the global 752 Internet. 754 -------- --------- 755 // \\ // \\ 756 / \ / \ 757 / +----+ \ 758 | |XLAT| | 759 | The IPv4 +----+ The IPv6 | 760 | Internet +----+ Internet | XLAT: v4/v6 761 | |DNS | | Translator 762 \ +----+ / DNS: DNS46 763 \ / \ / 764 \\ // \\ // 765 -------- --------- 766 ====> 768 Figure 8: Scenario 8 770 Due to the huge difference in size between the address spaces of the 771 IPv4 Internet and the IPv6 Internet, there is no viable translation 772 technique to handle unlimited IPv6 address translation. 774 If we ever run into this scenario, fortunately, the IPv4-IPv6 775 transition has already past the early stage of the "S" curve, 776 therefore, there is no obvious business reason to demand a 777 translation solution as the only transition strategy. 779 3. Framework 781 Having laid out the preferred transition model and the options for 782 implementing it (Section 1.1), defined terms (Section 1.2), 783 considered the requirements (Section 1.3), considered the transition 784 model (Section 1.4), and considered the kinds of scenarios the 785 facility would support (Section 2), we now turn to a framework for 786 IPv4/IPv6 translation. The framework contains the following 787 components: 789 o Address translation 791 o IP and ICMP translation 793 o Maintaining translation state 795 o DNS64 and DNS46 797 o ALGs for other application-layer protocols (e.g., FTP) 799 3.1. Translation Components 801 3.1.1. Address Translation 803 When IPv6/IPv4 translation is performed, we should specify how an 804 individual IPv6 address is translated to a corresponding IPv4 805 address, and vice versa, in cases where an algorithmic mapping is 806 used. This includes the choice of IPv6 prefix and the choice of 807 method by which the remainder of the IPv6 address is derived from an 808 IPv4 address [I-D.ietf-behave-address-format]. 810 Note that translating IPv4 address to IPv6 address and translating 811 IPv6 address to IPv4 address are different for stateless translation 812 and stateful translation. [I-D.ietf-behave-address-format]. 814 o For stateless translation, the algorithmic mapping algorithm is 815 used both to translate IPv4 addresses to IPv6 addresses and to 816 translate IPv6 addresses to IPv4 addresses. In this case, blocks 817 of service provider's IPv4 addresses are mapped into IPv6 and used 818 by physical IPv6 hosts. The original IPv4 form of these blocks of 819 service provider's IPv4 addresses are used to represent the 820 physical IPv6 hosts in IPv4. Note that the stateless translation 821 supports both IPv6 initiated as well as IPv4 initiated 822 communications. 824 o For stateful translation, the algorithmic mapping algorithm is 825 used to translate IPv4 addresses to IPv6 addresses, while a 826 session initiated state table is used to translate IPv6 addresses 827 to IPv4 addresses. In this case, blocks of service provider's 828 IPv4 addresses are maintained in the translator as the IPv4 829 address pools and dynamically bind to the specific IPv6 addresses. 830 The original IPv4 form of these blocks of service provider's IPv4 831 addresses are used to represent the physical IPv6 host in IPv4. 832 However, due to the dynamic binding, stateful translation in 833 general only supports IPv6-initiated communication. 835 3.1.2. IP and ICMP Translation 837 The IPv4/IPv6 translator is based on the update to the Stateless IP/ 838 ICMP Translation Algorithm (SIIT) described in [RFC2765]. The 839 algorithm translates between IPv4 and IPv6 packet headers (including 840 ICMP headers) [I-D.ietf-behave-v6v4-xlate]. 842 The IP and ICMP translation document [I-D.ietf-behave-v6v4-xlate] 843 addresses both stateless and stateful modes. In the stateless mode, 844 translation information is carried in the address itself, permitting 845 both IPv4->IPv6 and IPv6->IPv4 session establishment with neither 846 state nor configuration in the IP/ICMP translator. In the stateful 847 mode, translation state is maintained between IPv4 address/transport 848 port tuples and IPv6 address/transport port tuples, enabling IPv6 849 systems to open sessions with IPv4 systems. The choice of 850 operational mode is made by the operator deploying the network and is 851 critical to the operation of the applications using it. 853 3.1.3. Maintaining Translation State 855 For the stateful translator, besides IP and ICMP translation, special 856 action must be taken to maintain the translation states. NAT64 857 [I-D.ietf-behave-v6v4-xlate-stateful] describes a mechanism for 858 maintaining state. 860 3.1.4. DNS64 and DNS46 862 [I-D.ietf-behave-dns64] and possible future documents describes the 863 mechanisms by which a DNS translator is intended to operate. It is 864 designed to operate on the basis of known but fixed state: the 865 resource records, and therefore the names and addresses, are known to 866 network elements outside of the data plane translator, but the 867 process of serving them to applications does not interact with the 868 data plane translator in any way. 870 There are at least two possible implementations of a DNS64 and DNS46: 872 Static records: One could literally populate DNS with corresponding 873 A and AAAA records. This is most appropriate for stub services 874 such as access to a legacy printer pool. 876 Dynamic Translation of static records: In more general operation, 877 the expected behavior is for the application to request both A and 878 AAAA records, and for an A record to be (retrieved and) translated 879 by the DNS64 if and only if no reachable AAAA record exists, or 880 for an AAAA record to be (retrieved and) translated by the DNS46 881 if and only if no reachable A record exists. 883 3.1.5. ALGs for Other Applications Layer Protocols 885 In addition, some applications require special support. An example 886 is FTP. FTP's active mode doesn't work well across NATs without 887 extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it 888 generally uses passive mode. However, the designers of FTP 889 inexplicably wrote different and incompatible passive mode 890 implementations for IPv4 and IPv6 networks. Hence, either they need 891 to fix FTP, or a translator must be written for the application. 892 Other applications may be similarly broken. 894 As a general rule, a simple operational recommendation will work 895 around many application issues, which is that there should be a 896 server in each domain or an instance of the server should have an 897 interface in each domain. For example, an SMTP MTA may be confused 898 by finding an IPv6 address in its HELO when it is connected to using 899 IPv4 (or vice versa), but would work perfectly well if it had an 900 interface in both the IPv4 and IPv6 domains and was used as an 901 application-layer bridge between them. 903 3.2. Operation Mode for Specific Scenarios 905 Currently, the proposed solutions for IPv6/IPv4 translation are 906 classified into stateless translation and stateful translation. 908 3.2.1. Stateless Translation 910 For stateless translation, the translation information is carried in 911 the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 912 sessions establishment. The stateless translation supports end-to- 913 end address transparency and has better scalability compared with the 914 stateful translation. [I-D.ietf-behave-v6v4-xlate] 915 [I-D.xli-behave-ivi]. 917 Although the stateless translation mechanisms typically put 918 constraints on what IPv6 addresses can be assigned to IPv6 hosts that 919 want to communicate with IPv4 destinations using an algorithmic 920 mapping. For Scenario 1 ("an IPv6 network to the IPv4 Internet"), it 921 is not a serious drawback, since the address assignment policy can be 922 applied to satisfy this requirement for the IPv6 hosts which need the 923 communication ability to the IPv4 Internet. In addition, the 924 stateless translator supports Scenario 2 ("the IPv4 Internet to an 925 IPv6 network"), which means that not only could servers move directly 926 to IPv6 without trudging through a difficult transition period, but 927 they could do so without risk of losing connectivity with the IPv4- 928 only Internet. 930 Stateless translation can be used for Scenarios 1, 2, 5 and 6, i.e. 932 it supports "an IPv6 network to the IPv4 Internet", "the IPv4 933 Internet to an IPv6 network", "an IPv6 network to an IPv4 network" 934 and "an IPv4 network to an IPv6 network". 936 -------- 937 // \\ ----------- 938 / \ // \\ 939 / +----+ \ 940 | |XLAT| | 941 | The IPv4 +----+ An IPv6 | 942 | Internet +----+ Network | XLAT: Stateless v4/v6 943 | |DNS | (address | Translator 944 \ +----+ subset) / DNS: DNS64/DNS46 945 \ / \\ // 946 \\ // ---------- 947 -------- 948 <====> 950 Figure 9: Stateless translation for Scenarios 1 and 2 952 -------- --------- 953 // \\ // \\ 954 / +----+ \ 955 | |XLAT| | 956 | An IPv4 +----+ An IPv6 | 957 | Network +----+ Network | XLAT: v4/v6 958 | |DNS | | Translator 959 \ +----+ / DNS: DNS64/DNS46 960 \\ // \\ // 961 -------- --------- 962 <====> 964 Figure 10: Stateless translator for Scenarios 5 and 6 966 The implementation of the stateless translator needs to refer to 967 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-address-format], and 968 [I-D.ietf-behave-dns64]. 970 3.2.2. Stateful Translation 972 For stateful translation, the translation state is maintained between 973 IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 974 systems to open sessions with IPv4 systems 975 [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful]. 977 Stateful translator can be used for Scenarios 1, 3 and 5, i.e. it 978 supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet 979 to an IPv4 network" and "an IPv6 network to an IPv4 network". 981 For Scenario 1, any IPv6 addresses in an IPv6 network can use 982 stateful translation, however it typically only supports initiation 983 from the IPv6 side (NAT64 doesn't support IPv4-initiation), and does 984 not result in stable addresses that can be used in DNS, other 985 protocols and applications that do not deal well with highly dynamic 986 addresses. 988 -------- 989 // \\ ----------- 990 / \ // \\ 991 / +----+ \ 992 | |XLAT| | 993 | The IPv4 +----+ An IPv6 | 994 | Internet +----+ Network | XLAT: Stateful v4/v6 995 | |DNS | | Translator 996 \ +----+ / DNS: DNS64 997 \ / \\ // 998 \\ // ----------- 999 -------- 1000 <==== 1002 Figure 11: Stateful translator for Scenario 1 1004 For scenario 3, the servers using IPv4 private addresses [RFC1918] 1005 and being reached from the IPv6 Internet basically includes the cases 1006 that for whatever reason the servers cannot be upgraded to IPv6 and 1007 they don't have public IPv4 addresses and it would be useful to allow 1008 IPv6 nodes in the IPv6 Internet to reach those servers. 1010 ----------- 1011 ---------- // \\ 1012 // \\ / \ 1013 / +----+ \ 1014 | |XLAT| | 1015 | An IPv4 +----+ The IPv6 | 1016 | Network +----+ Internet | XLAT: v4/v6 1017 | |DNS | | Translator 1018 \ +----+ / DNS: DNS64 1019 \\ // \ / 1020 --------- \\ // 1021 ----------- 1022 <==== 1024 Figure 12: Stateful translator for Scenario 3 1026 Similarly, the stateful translator can also be used for Scenario 5. 1028 -------- --------- 1029 // \\ // \\ 1030 / +----+ \ 1031 | |XLAT| | 1032 | An IPv4 +----+ An IPv6 | 1033 | Network +----+ Network | XLAT: v4/v6 1034 | |DNS | | Translator 1035 \ +----+ / DNS: DNS64 1036 \\ // \\ // 1037 -------- --------- 1038 <==== 1040 Figure 13: Stateful translator for Scenario 5 1042 The implementation of the stateful translator needs to refer to 1043 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 1044 [I-D.ietf-behave-address-format], and [I-D.ietf-behave-dns64]. 1046 3.3. Layout of the Related Documents 1048 Based on the above analysis, the IPv4/IPv6 translation series 1049 consists of the following documents. 1051 o Framework for IPv4/IPv6 Translation (this document). 1053 o Address translation (The choice of IPv6 prefix and the choice of 1054 method by which the remainder of the IPv6 address is derived from 1055 an IPv4 address, part of the SIIT update) 1056 [I-D.ietf-behave-address-format], 1058 o IP and ICMP Translation (Header translation and ICMP handling, 1059 part of the SIIT update.) [I-D.ietf-behave-v6v4-xlate]. 1061 o Xlate-stateful (Stateful translation including session database 1062 and mapping table handing) [I-D.ietf-behave-v6v4-xlate-stateful]. 1064 o DNS64/DNS46 (DNS64: A to AAAA mapping and DNSSec discussion) 1065 [I-D.ietf-behave-dns64]. 1067 o FTP ALG. 1069 o Others (Multicast, etc). 1071 The relationship among these documents is shown in the following 1072 figure. 1074 ----------------------------------------- 1075 | Framework for IPv4/IPv6 Translation | 1076 ----------------------------------------- 1077 || || 1078 ------------------------------------------------------------------- 1079 | || stateless and stateful || | 1080 | -------------------- --------------------- | 1081 | |Address Translation | <======== | IP/ICMP Translation | | 1082 | -------------------- --------------------- | 1083 | /\ /\ | 1084 | || ------------------||------------ | 1085 | || | stateful \/ | 1086 | ----------------- | --------------------- | 1087 | | DNS64/DNS46 | | | Table Maintenance | | 1088 | ----------------- | --------------------- | 1089 ------------------------------------------------------------------- 1090 /\ /\ 1091 || || 1092 ----------------- -------------------- 1093 | FTP ALG | | Others | 1094 ----------------- -------------------- 1096 Figure 14: Document Layout 1098 In the document layout, the IP/ICMP Translation and DNS64/DNS46 refer 1099 to Address Translation. The Table Maintenance and IP/ICMP 1100 Translation refer to each other. 1102 The FTP ALG and other documents refer to the Address Format, IP/ICMP 1103 Translation and Table Maintenance documents. 1105 4. Translation in Operation 1107 Operationally, there are two ways that translation could be used - as 1108 a permanent solution making transition "the other guy's problem", and 1109 as a temporary solution for a new part of one's network while 1110 bringing up IPv6 services in the remaining parts of one's network. 1111 We obviously recommend the latter. For the IPv4 parts of the 1112 network, [RFC4213]'s recommendation holds: bringing IPv6 up in those 1113 domains, moving production to it, and then taking down the now- 1114 unnecessary IPv4 service when economics warrant remains the least 1115 risk approach to transition. 1117 ---------------------- 1118 ////// \\\\\\ 1119 /// IPv4 or Dual Stack \\\ 1120 || +----+ Routing +-----+ || 1121 | |IPv4| |IPv4+| | 1122 | |Host| |IPv6 | | 1123 || +----+ |Host | || 1124 \\\ +-----+ /// 1125 \\\\\+----+ +---+ +----+ +----+///// 1126 |XLAT|-|DNS|-|SMTP|-|XLAT| 1127 | |-|64 |-|MTA |-| | 1128 /////+----+ +---+ +----+ +----+\\\\\ 1129 /// \\\ 1130 || +-----+ +----+ || 1131 | |IPv4+| |IPv6| | 1132 | |IPv6 | |Host| | 1133 || |Host | +----+ || 1134 \\\ +-----+ IPv6-only Routing /// 1135 \\\\\\ ////// 1136 ---------------------- 1138 Figure 15: Translation Operational Model 1140 During the coexistence phase, as shown in Figure 15, one expects a 1141 combination of hosts - IPv6-only gaming devices and handsets, older 1142 computer operating systems that are IPv4-only, and modern mainline 1143 operating systems that support both. One also expects a combination 1144 of networks - dual-stack devices operating in single-stack networks 1145 are effectively single-stack, whether that stack is IPv4 or IPv6, as 1146 the other isn't providing communications services. 1148 5. Unsolved Problems 1150 This framework could support multicast; some discussions are in 1151 [I-D.venaas-behave-mcast46] and [I-D.xli-behave-ivi]. 1153 This framework could support stateless translation with IPv4 address 1154 and transport port number multiplexing, some discussions are in 1155 [I-D.xli-behave-ivi]. 1157 6. IANA Considerations 1159 This memo requires no parameter assignment by the IANA. 1161 Note to RFC Editor: This section will have served its purpose if it 1162 correctly tells IANA that no new assignments or registries are 1163 required, or if those assignments or registries are created during 1164 the RFC publication process. From the author's perspective, it may 1165 therefore be removed upon publication as an RFC at the RFC Editor's 1166 discretion. 1168 7. Security Considerations 1170 At this point, the editor knows of no other security issues raised by 1171 the address format that are not already applicable to the addressing 1172 architecture in general. 1174 8. Acknowledgements 1176 This is under development by a large group of people. Those who have 1177 posted to the list during the discussion include Andrew Sullivan, 1178 Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Congxiao Bao, Dan Wing, 1179 Dave Thaler, Ed Jankiewicz, Fred Baker, Gang Chen, Hui Deng, Hiroshi 1180 Miyata, Iljitsch van Beijnum, John Schnizlein, Kevin Yin, Magnus 1181 Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, 1182 Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres and 1183 Xing Li. 1185 Ed Jankiewicz described the transition plan. 1187 9. References 1189 9.1. Normative References 1191 [I-D.ietf-behave-address-format] 1192 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1193 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1194 draft-ietf-behave-address-format-00 (work in progress), 1195 August 2009. 1197 [I-D.ietf-behave-dns64] 1198 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1199 "DNS64: DNS extensions for Network Address Translation 1200 from IPv6 Clients to IPv4 Servers", 1201 draft-ietf-behave-dns64-01 (work in progress), 1202 October 2009. 1204 [I-D.ietf-behave-v6v4-xlate] 1205 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1206 Algorithm", draft-ietf-behave-v6v4-xlate-02 (work in 1207 progress), October 2009. 1209 [I-D.ietf-behave-v6v4-xlate-stateful] 1210 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 1211 Address and Protocol Translation from IPv6 Clients to IPv4 1212 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 1213 in progress), October 2009. 1215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1216 Requirement Levels", BCP 14, RFC 2119, March 1997. 1218 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1219 (IPv6) Specification", RFC 2460, December 1998. 1221 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1222 Architecture", RFC 4291, February 2006. 1224 9.2. Informative References 1226 [I-D.bagnulo-behave-nat64] 1227 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 1228 Address and Protocol Translation from IPv6 Clients to IPv4 1229 Servers", draft-bagnulo-behave-nat64-03 (work in 1230 progress), March 2009. 1232 [I-D.durand-softwire-dual-stack-lite] 1233 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 1234 "Dual-stack lite broadband deployments post IPv4 1235 exhaustion", draft-durand-softwire-dual-stack-lite-01 1236 (work in progress), November 2008. 1238 [I-D.venaas-behave-mcast46] 1239 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 1240 IPv4 - IPv6 multicast translator", 1241 draft-venaas-behave-mcast46-01 (work in progress), 1242 July 2009. 1244 [I-D.xli-behave-ivi] 1245 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1246 CERNET IVI Translation Design and Deployment for the IPv4/ 1247 IPv6 Coexistence and Transition", draft-xli-behave-ivi-02 1248 (work in progress), June 2009. 1250 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1251 E. Lear, "Address Allocation for Private Internets", 1252 BCP 5, RFC 1918, February 1996. 1254 [RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement 1255 for Historic Status", RFC 1923, March 1996. 1257 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1258 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1259 March 1996. 1261 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 1262 for IPv6 and NATs", RFC 2428, September 1998. 1264 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1265 (SIIT)", RFC 2765, February 2000. 1267 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1268 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1269 February 2000. 1271 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1272 via IPv4 Clouds", RFC 3056, February 2001. 1274 [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 1275 RFC 3089, April 2001. 1277 [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport 1278 Relay Translator", RFC 3142, June 2001. 1280 [RFC3484] Draves, R., "Default Address Selection for Internet 1281 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1283 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1284 Stevens, "Basic Socket Interface Extensions for IPv6", 1285 RFC 3493, February 2003. 1287 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1288 Addresses", RFC 3879, September 2004. 1290 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1291 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1292 September 2005. 1294 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1295 Addresses", RFC 4193, October 2005. 1297 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1298 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1300 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1301 Network Address Translations (NATs)", RFC 4380, 1302 February 2006. 1304 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1305 Address Autoconfiguration", RFC 4862, September 2007. 1307 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1308 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1309 May 2007. 1311 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1312 Extensions for Stateless Address Autoconfiguration in 1313 IPv6", RFC 4941, September 2007. 1315 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1316 Address Translator - Protocol Translator (NAT-PT) to 1317 Historic Status", RFC 4966, July 2007. 1319 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 1320 July 2008. 1322 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1323 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1324 March 2008. 1326 Authors' Addresses 1328 Fred Baker 1329 Cisco Systems 1330 Santa Barbara, California 93117 1331 USA 1333 Phone: +1-408-526-4257 1334 Fax: +1-413-473-2403 1335 Email: fred@cisco.com 1337 Xing Li 1338 CERNET Center/Tsinghua University 1339 Room 225, Main Building, Tsinghua University 1340 Beijing, 100084 1341 China 1343 Phone: +86 10-62785983 1344 Email: xing@cernet.edu.cn 1346 Congxiao Bao 1347 CERNET Center/Tsinghua University 1348 Room 225, Main Building, Tsinghua University 1349 Beijing, 100084 1350 China 1352 Phone: +86 10-62785983 1353 Email: congxiao@cernet.edu.cn 1355 Kevin Yin 1356 Cisco Systems 1357 No. 2 Jianguomenwai Ave, Chaoyang District 1358 Beijing, 100022 1359 China 1361 Phone: +86-10-8515-5094 1362 Email: kyin@cisco.com