idnits 2.17.1 draft-ietf-behave-v6v4-framework-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 17, 2010) is 5001 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-04 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-20 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: February 18, 2011 C. Bao 6 CERNET Center/Tsinghua University 7 K. Yin 8 Cisco Systems 9 August 17, 2010 11 Framework for IPv4/IPv6 Translation 12 draft-ietf-behave-v6v4-framework-10 14 Abstract 16 This note describes a framework for IPv4/IPv6 translation. This is 17 in the context of replacing NAT-PT, which was deprecated by RFC 4966, 18 and to enable networks to have IPv4 and IPv6 coexist in a somewhat 19 rational manner while transitioning to an IPv6 network. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 18, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7 59 1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 8 60 2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 10 61 2.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 11 62 2.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . . . 12 63 2.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 13 64 2.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . . . 14 65 2.5. Scenario 5: an IPv6 network to an IPv4 network . . . . . . 15 66 2.6. Scenario 6: an IPv4 network to an IPv6 network . . . . . . 15 67 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . . . 16 68 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . . . 17 69 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 3.1. Translation Components . . . . . . . . . . . . . . . . . . 18 71 3.1.1. Address Translation . . . . . . . . . . . . . . . . . 18 72 3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 19 73 3.1.3. Maintaining Translation State . . . . . . . . . . . . 20 74 3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 20 75 3.1.5. ALGs for Other Applications Layer Protocols . . . . . 20 76 3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 21 77 3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 21 78 3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 22 79 3.3. Layout of the Related Documents . . . . . . . . . . . . . 24 80 4. Translation in Operation . . . . . . . . . . . . . . . . . . . 25 81 5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 26 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 90 1. Introduction 92 This note describes a framework for IPv4/IPv6 translation. This is 93 in the context of replacing NAT-PT (Network Address Translation - 94 Protocol Translation) [RFC2766], which was deprecated by [RFC4966], 95 and to enable networks to have IPv4 and IPv6 coexist in a somewhat 96 rational manner while transitioning to an IPv6-only network. 98 NAT-PT was deprecated to inform the community that NAT-PT had 99 operational issues and was not considered a viable medium- or long- 100 term strategy for either coexistence or transition. It wasn't 101 intended to say that IPv4<->IPv6 translation was bad, but the way 102 that NAT-PT did it was bad, and in particular using NAT-PT as a 103 general-purpose solution was bad. As with the deprecation of the RIP 104 routing protocol [RFC1923] at the time the Internet was converting to 105 CIDR, the point was to encourage network operators to actually move 106 away from technology with known issues. 108 [RFC4213] describes the IETF's view of the most sensible transition 109 model. The IETF recommends, in short, that network operators 110 (transit providers, service providers, enterprise networks, small and 111 medium businesses, SOHO and residential customers, and any other kind 112 of network that may currently be using IPv4) obtain an IPv6 prefix, 113 turn on IPv6 routing within their networks and between themselves and 114 any peer, upstream, or downstream neighbors, enable it on their 115 computers, and use it in normal processing. This should be done 116 while leaving IPv4 stable, until a point is reached that any 117 communication that can be carried out could use either protocol 118 equally well. At that point, the economic justification for running 119 both becomes debatable, and network operators can justifiably turn 120 IPv4 off. This process is comparable to that of [RFC4192], which 121 describes how to renumber a network using the same address family 122 without a flag day. While running stably with the older system, 123 deploy the new. Use the coexistence period to work out such kinks as 124 arise. When the new is also running stably, shift production to it. 125 When network and economic conditions warrant, remove the old, which 126 is now no longer necessary. 128 The question arises: what if that is infeasible due to the time 129 available to deploy or other considerations? What if the process of 130 moving a network and its components or customers is starting too late 131 for contract cycles to effect IPv6 turn-up on important parts at a 132 point where it becomes uneconomical to deploy global IPv4 addresses 133 in new services? How does one continue to deploy new services 134 without balkanizing the network? 136 This document describes translation as one of the tools networks 137 might use to facilitate coexistence and ultimate transition. 139 1.1. Why Translation? 141 Besides dual-stack deployment, there are two fundamental approaches 142 one could take to interworking between IPv4 and IPv6: tunneling and 143 translation. One could - and in the [6NET] we did - build an overlay 144 network that tunnels one protocol over the other. Various proposals 145 take that model, including 6to4 [RFC3056], Teredo [RFC4380], ISATAP 146 [RFC5214], and DS-Lite [I-D.ietf-softwire-dual-stack-lite]. The 147 advantage of doing so is that the new is enabled to work without 148 disturbing the old protocol, providing connectivity between users of 149 the new protocol. There are two disadvantages to tunneling: 151 o Users of the new architecture are unable to use the services of 152 the underlying infrastructure - it is just bandwidth, and 154 o It doesn't enable new protocol users to communicate with old 155 protocol users without dual-stack hosts. 157 As noted, in this work, we look at Internet Protocol translation as a 158 transition strategy. [RFC4864] forcefully makes the point that many 159 of the reasons people use Network Address Translators are met as well 160 by routing or protocol mechanisms that preserve the end-to-end 161 addressability of the Internet. What it did not consider is the case 162 in which there is an ongoing requirement to communicate with IPv4 163 systems, but for example configuring IPv4 routing is not in the 164 network operator's view the most desirable strategy, or is infeasible 165 due to a shortage of global address space. Translation enables the 166 client of a network, whether a transit network, an access network, or 167 an edge network, to access the services of the network and 168 communicate with other network users regardless of their protocol 169 usage - within limits. Like NAT-PT, IPv4/IPv6 translation under this 170 rubric is not a long-term support strategy, but it is a medium-term 171 coexistence strategy that can be used to facilitate a long-term 172 program of transition. 174 1.2. Terminology 176 The following terminology is used in this document and other 177 documents related to it. 179 An IPv4 network: A specific network that has an IPv4-only 180 deployment. This could be an enterprise's IPv4-only network, an 181 ISP's IPv4-only network or even an IPv4-only host. The IPv4 182 Internet is the set of all interconnected IPv4 networks. 184 An IPv6 network: A specific network that has an IPv6-only 185 deployment. This could be an enterprise's IPv6-only network, an 186 ISP's IPv6-only network or even an IPv6-only host. The IPv6 187 Internet is the set of all interconnected IPv6 networks. 189 DNS46: A DNS translator that translates AAAA record to A record. 191 DNS64: A DNS translator that translates A record to AAAA record. 193 Dual-Stack implementation: A Dual-Stack implementation, in this 194 context, comprises an IPv4/IPv6 enabled end system stack, 195 applications plus routing in the network. It implies that two 196 application instances are capable of communicating using either 197 IPv4 or IPv6 - they have stacks, they have addresses, and they 198 have any necessary network support including routing. 200 IPv4-converted addresses: IPv6 addresses used to represent IPv4 201 nodes in an IPv6 network. They have an explicit mapping 202 relationship to IPv4 addresses. Both stateless and stateful 203 translators use IPv4-converted addresses to represent IPv4 204 addresses. 206 IPv4-only: An IPv4-only implementation, in this context, comprises 207 an IPv4-enabled end system stack, applications directly or 208 indirectly using that IPv4 stack, plus routing in the network. It 209 implies that two application instances are capable of 210 communicating using IPv4, but not IPv6 - they have an IPv4 stack, 211 addresses, and network support including IPv4 routing and 212 potentially IPv4/IPv4 translation, but some element is missing 213 that prevents communication with IPv6 hosts. 215 IPv4-translatable addresses: IPv6 addresses to be assigned to IPv6 216 nodes for use with stateless translation. They have an explicit 217 mapping relationship to IPv4 addresses. A stateless translator 218 uses the corresponding IPv4 addresses to represent the IPv6 219 addresses. A stateful translator does not use this kind of 220 addresses, since IPv6 hosts are represented by the IPv4 address 221 pool in the translator via dynamic state. 223 IPv6-only: An IPv6-only implementation, in this context, comprises 224 an IPv6-enabled end system stack, applications directly or 225 indirectly using that IPv6 stack, plus routing in the network. It 226 implies that two application instances are capable of 227 communicating using IPv6, but not IPv4 - they have an IPv6 stack, 228 addresses, and network support including routing in IPv6, but some 229 element is missing that prevents communication with IPv4 hosts. 231 Network-Specific Prefix (NSP): From an IPv6 prefix assigned to a 232 network operator, the operator chooses a longer prefix for use by 233 the operator's translator(s). Hence a given IPv4 address would 234 have different IPv6 representations in different networks that use 235 different network-specific prefixes. A network-specific prefix is 236 also known as a Local Internet Registry (LIR) prefix. 238 State: "State" refers to dynamic information that is stored in a 239 network element. For example, if two systems are communicating 240 using a TCP connection, each stores information about the 241 connection, which is called "connection state". In this context, 242 the term refers to dynamic correlations between IP addresses on 243 either side of a translator, or {IP address, transport protocol, 244 transport port number} tuples on either side of the translator. 245 Of stateful algorithms, there are at least two major flavors 246 depending on the kind of state they maintain: 248 Hidden state: the existence of this state is unknown outside the 249 network element that contains it. 251 Known state: the existence of this state is known by other 252 network elements. 254 Stateful Translation: A translation algorithm may be said to 255 "require state in a network element" or be "stateful" if the 256 transmission or reception of a packet creates or modifies a data 257 structure in the relevant network element. 259 Stateful Translator: A translator that uses stateful translation for 260 either the source or destination address. A stateful translator 261 typically also uses a stateless translation algorithm for the 262 other type of address. 264 Stateless Translation: A translation algorithm that is not 265 "stateful" is "stateless". It derives its needed information 266 algorithmically from the messages it is translating, and pre- 267 configured information. 269 Stateless Translator: A translator that uses only stateless 270 translation for both destination address and source address. 272 Well-Known Prefix (WKP): The IPv6 prefix defined in 273 [I-D.ietf-behave-address-format] for use in an algorithmic 274 mapping. 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 278 document are to be interpreted as described in [RFC2119]. 280 1.3. Translation Objectives 282 In any translation model, there is a question of objectives. 283 Ideally, one would like to make any system and any application 284 running on it able to "talk with" - exchange datagrams supporting 285 applications with - any other system running the same application 286 regardless of whether they have an IPv4 stack and connectivity or 287 IPv6 stack and connectivity. That was the model for NAT-PT, and the 288 things it necessitated led to scaling and operational difficulties 289 [RFC4966]. 291 So the question comes back to what different kinds of connectivity 292 can be easily supported and what kinds are harder, and what 293 technologies are needed to at least pick the low-hanging fruit. We 294 observe that applications today fall into two main categories: 296 Client/Server Application: Per whatis.com, "'Client/server' 297 describes the relationship between two computer programs in which 298 one program, the client, makes a service request from another 299 program, the server, which fulfills the request." In networking, 300 the behavior of the applications is that connections are initiated 301 from client software and systems to server software and systems. 302 Examples include mail handling between an end user and his mail 303 system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name 304 resolution. 306 Peer-to-Peer (P2P) Application: A P2P application is an application 307 that uses the same endpoint to initiate outgoing sessions to 308 peering hosts as well as accept incoming sessions from peering 309 hosts. These in turn fall broadly into two categories: 311 Peer-to-peer infrastructure applications: Examples of 312 "infrastructure applications" include SMTP between MTAs, 313 Network News, and SIP. Any MTA might open an SMTP session with 314 any other at any time; any SIP Proxy might similarly connect 315 with any other SIP Proxy. An important characteristic of these 316 applications is that they use ephemeral sessions - they open 317 sessions when they are needed and close them when they are 318 done. 320 Peer-to-peer file exchange applications: Examples of these 321 include Limewire, BitTorrent, and UTorrent. These are 322 applications that open some sessions between systems and leave 323 them open for long periods of time, and where ephemeral 324 sessions are important, are able to learn about the reliability 325 of peers from history or by reputation. They use the long-term 326 sessions to map content availability. Short-term sessions are 327 used to exchange content. They tend to prefer to ask for 328 content from peers that they find reliable and available. 330 If the goal is the ability to open connections between systems, then 331 one must ask who opens connections. 333 o We need a technology that will enable systems that act as clients 334 to be able to open sessions with other systems that act as 335 servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 336 direction. Ideally, this is stateless; especially in a carrier 337 infrastructure, the preponderance of accesses will be to servers, 338 and this optimizes access to them. However, a stateful algorithm 339 is acceptable if the complexity is minimized and a stateless 340 algorithm cannot be constructed. 342 o We also need a technology that will allow peers to connect with 343 each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 344 direction. Again, it would be ideal if this was stateless, but a 345 stateful algorithm is acceptable if the complexity is minimized 346 and a stateless algorithm cannot be constructed. 348 o In some situations, hosts are purely clients. In those 349 situations, we do not need an algorithm to enable connections to 350 those hosts. 352 The complexity arguments bring us in the direction of hidden state: 353 if state must be shared between the application and the translator or 354 between translation components, complexity and deployment issues are 355 greatly magnified. The objective of the translators is to avoid, as 356 much as possible, any software changes in hosts or applications 357 necessary to support translation. 359 NAT-PT is an example of a facility with known state - at least two 360 software components (the data plane translator and the DNS 361 Application Layer Gateway, which may be implemented in the same or 362 different systems) share and must coordinate translation state. A 363 typical IPv4/IPv4 NAT implements an algorithm with hidden state. 364 Obviously, stateless translation requires less computational overhead 365 than stateful translation, and less memory to maintain the state, 366 because the translation tables and their associated methods and 367 processes exist in a stateful algorithm and don't exist in a 368 stateless one. 370 1.4. Transition Plan 372 While the design of IPv4 made it impossible for IPv6 to be compatible 373 on the wire, the designers intended that it would coexist with IPv4 374 during a period of transition. The primary mode of coexistence was 375 dual-stack operation - routers would be dual-stacked so that the 376 network could carry both address families, and IPv6-capable hosts 377 could be dual-stack to maintain access to IPv4-only partners. The 378 goal was that the preponderance of hosts and routers in the Internet 379 would be IPv6-capable long before IPv4 address space allocation was 380 completed. At this time, it appears the exhaustion of IPv4 address 381 space will occur before significant IPv6 adoption. 383 Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three- 384 phase progression: 386 Preparation Phase (current): characterized by pilot use of IPv6, 387 primarily through transition mechanisms defined in [RFC4213], and 388 planning activities. 390 Transition Phase (2010 through 2011): characterized by general 391 availability of IPv6 in provider networks which should be native 392 IPv6; organizations should provide IPv6 connectivity for their 393 Internet-facing servers, but should still provide IPv4-based 394 services via a separate service name. 396 Post-Transition Phase (2012 and beyond): characterized by a 397 preponderance of IPv6-based services and diminishing support for 398 IPv4-based services. 400 Various timelines have been discussed, but most will agree with the 401 pattern of the above three transition phases, also known as an "S" 402 curve transition pattern. 404 In each of these phases, the coexistence problem and solution space 405 has a different focus: 407 Preparation Phase: Coexistence tools are needed to facilitate early 408 adopters by removing impediments to IPv6 deployment, and to assure 409 that nothing is lost by adopting IPv6, in particular that the IPv6 410 adopter has unfettered access to the global IPv4 Internet 411 regardless of whether they have a global IPv4 address (or any IPv4 412 address or stack at all). While it might appear reasonable for 413 the cost and operational burden to be borne by the early adopter, 414 the shared goal of promoting IPv6 adoption would argue against 415 that model. Additionally, current IPv4 users should not be forced 416 to retire or upgrade their equipment and the burden remains on 417 service providers to carry and route native IPv4. This is known 418 as the early stage of the "S" curve. 420 Transition Phase: During the middle stage of "S" curve, while IPv6 421 adoption can be expected to accelerate, there will still be a 422 significant portion of the Internet operating IPv4-only or 423 preferring IPv4. During this phase the norm shifts from IPv4 to 424 IPv6, and coexistence tools evolve to ensure interoperability 425 between domains that may be restricted to IPv4 or IPv6. 427 Post-Transition Phase: This is the last stage of "S" curve. In this 428 phase, IPv6 is ubiquitous and the burden of maintaining 429 interoperability shifts to those who choose to maintain IPv4-only 430 systems. While these systems should be allowed to live out their 431 economic life cycles, the IPv4-only legacy users at the edges 432 should bear the cost of coexistence tools, and at some point 433 service provider networks should not be expected to carry and 434 route native IPv4 traffic. 436 The choice between the terms "transition" versus "coexistence" has 437 engendered long philosophical debate. "Transition" carries the sense 438 that one is going somewhere, while "coexistence" seems more like one 439 is sitting somewhere. Historically with the IETF, "transition" has 440 been the term of choice [RFC4213][RFC5211], and the tools for 441 interoperability have been called "transition mechanisms". There is 442 some perception or conventional wisdom that adoption of IPv6 is being 443 impeded by the deficiency of tools to facilitate interoperability of 444 nodes or networks that are constrained (in some way, fully or 445 partially) from full operation in one of the address families. In 446 addition, it is apparent that transition will involve a period of 447 coexistence; the only real question is how long that will last. 449 Thus, coexistence is an integral part of the transition plan, not in 450 conflict with it, but there will be a balancing act. It starts out 451 being a way for early IPv6 adopters to easily exploit the bigger IPv4 452 Internet, and ends up being a way for late/never adopters to hang on 453 with IPv4 (at their own expense, with minimal impact or visibility to 454 the Internet). One way to look at solutions is that cost incentives 455 (both monetary cost and the operational overhead for the end user) 456 should encourage IPv6 and discourage IPv4. That way natural market 457 forces will keep the transition moving - especially as the legacy 458 IPv4-only stuff ages out of use. The end goal should not be to 459 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 translation solutions 473 under all kinds of situations. All IPv4/IPv6 translation cases can 474 be easily described in terms of "interoperation between a set of 475 systems (applications) that only communicate using IPv4 and a set of 476 systems that only communicate using IPv6", but the differences at a 477 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 of 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 IPv4 addresses or under other technical or 515 economical constraints, the network is IPv6-only, but the hosts in 516 the network require communicating with the global IPv4 Internet. 518 This is the typical scenario for what we sometimes call "green-field" 519 deployments. One example is an enterprise network that wishes to 520 operate only IPv6 for operational simplicity, but still wishes to 521 reach the content in the IPv4 Internet. The green-field enterprise 522 scenario is different from an ISP's network in the sense that there 523 is only one place that the enterprise can easily modify: the border 524 between its network and the IPv4 Internet. Obviously, the IPv4 525 Internet operates the way it already does. But in addition, the 526 hosts in the enterprise network are commercially available devices, 527 personal computers with existing operating systems. This restriction 528 drives us to a "one box" type of solution, where IPv6 can be 529 translated into IPv4 to reach the public Internet. 531 Other cases that have been mentioned include wireless ISP networks 532 and sensor networks. These bear a striking resemblance to this 533 scenario as well, if one considers the ISP network to simply be a 534 very special kind of enterprise network. 536 -------- 537 // \\ ----------- 538 / \ // \\ 539 / +----+ \ 540 | |XLAT| | 541 | The IPv4 +----+ An IPv6 | 542 | Internet +----+ Network | XLAT: IPv6/IPv4 543 | |DNS | | Translator 544 \ +----+ / DNS: DNS64 545 \ / \\ // 546 \\ // ----------- 547 -------- 548 <==== 550 Figure 1: Scenario 1 552 Both stateless [I-D.ietf-behave-v6v4-xlate] and stateful 553 [I-D.ietf-behave-v6v4-xlate-stateful] solutions can support Scenario 554 1. 556 2.2. Scenario 2: the IPv4 Internet to an IPv6 network 558 When the enterprise networks or ISP networks adopt Scenario 1, the 559 IPv6-only users will not only want to access servers on the IPv4 560 Internet but also want to setup their own servers in the network 561 which are accessible by the users on the IPv4 Internet, since the 562 majority of the Internet users are still in the IPv4 Internet. Thus, 563 with a translation solution for this scenario, the benefits would be 564 clear. Not only could servers move directly to IPv6 without trudging 565 through a difficult transition period, but they could do so without 566 risk of losing connectivity with the IPv4-only Internet. 568 -------- 569 // \\ ---------- 570 / \ // \\ 571 / +----+ \ 572 | |XLAT| | 573 | The IPv4 +----+ An IPv6 | 574 | Internet +----+ Network | XLAT: IPv4/IPv6 575 | |DNS | | Translator 576 \ +----+ / DNS: DNS46 577 \ / \\ // 578 \\ // ---------- 579 -------- 580 ====> 582 Figure 2: Scenario 2 584 In general, this scenario presents a hard case for translation. 585 Stateful translation such as NAT-PT [RFC2766] can be used in this 586 scenario, but it requires a tightly coupled DNS ALG in the translator 587 and this technique was deprecated by the IETF [RFC4966]. 589 The stateless translation solution [I-D.ietf-behave-v6v4-xlate] in 590 Scenario 1 can also work in Scenario 2, since it can support IPv4- 591 initiated communications with a subset of the IPv6 addresses (IPv4- 592 translatable addresses) in an IPv6 network. 594 2.3. Scenario 3: the IPv6 Internet to an IPv4 network 596 There is a requirement for a legacy IPv4 network to provide services 597 to IPv6 hosts. 599 ----------- 600 ---------- // \\ 601 // \\ / \ 602 / +----+ \ 603 | |XLAT| | 604 | An IPv4 +----+ The IPv6 | 605 | Network +----+ Internet | XLAT: IPv6/IPv4 606 | |DNS | | Translator 607 \ +----+ / DNS: DNS64 608 \\ // \ / 609 --------- \\ // 610 ----------- 611 <==== 613 Figure 3: Scenario 3 615 Stateless translation will not work for this scenario, because an 616 IPv4 network needs to communicate with all of the IPv6 Internet, not 617 just a small subset, and stateless can only support a subset of the 618 IPv6 addresses. However, IPv6-initiated communication can be 619 achieved through stateful translation 620 [I-D.ietf-behave-v6v4-xlate-stateful]. In this case, a Network 621 Specific Prefix assigned to the translator will give the hosts unique 622 IPv4-converted IPv6 addresses, no matter the legacy IPv4 network uses 623 public IPv4 addresses or [RFC1918] addresses. Also there is no need 624 to synthesizing AAAA from A records, since static AAAA records can be 625 put in the regular DNS to represent these IPv4-only hosts as 626 discussed in Section 7.3 of [I-D.ietf-behave-dns64]. 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: IPv4/IPv6 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 IPv4/IPv6 transition has already moved to the right 658 direction. Therefore, in-network translation is not considered 659 viable for this scenario and other techniques should be considered. 661 2.5. Scenario 5: an IPv6 network to an IPv4 network 663 In this scenario, both an IPv4 network and an IPv6 network are within 664 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: IPv6/IPv4 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: IPv4/IPv6 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: IPv6/IPv4 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 passed 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 case is very similar to Scenario 7. The analysis and 750 conclusions for Scenario 7 also applies for this scenario. 752 -------- --------- 753 // \\ // \\ 754 / \ / \ 755 / +----+ \ 756 | |XLAT| | 757 | The IPv4 +----+ The IPv6 | 758 | Internet +----+ Internet | XLAT: IPv4/IPv6 759 | |DNS | | Translator 760 \ +----+ / DNS: DNS46 761 \ / \ / 762 \\ // \\ // 763 -------- --------- 764 ====> 766 Figure 8: Scenario 8 768 3. Framework 770 Having laid out the preferred transition model and the options for 771 implementing it (Section 1.1), defined terms (Section 1.2), 772 considered the requirements (Section 1.3), considered the transition 773 model (Section 1.4), and considered the kinds of scenarios the 774 facility would support (Section 2), we now turn to a framework for 775 IPv4/IPv6 translation. The framework contains the following 776 components: 778 o Address translation 780 o IP and ICMP translation 782 o Maintaining translation state 784 o DNS64 and DNS46 785 o ALGs for other application-layer protocols (e.g., FTP) 787 3.1. Translation Components 789 3.1.1. Address Translation 791 When IPv6/IPv4 translation is performed, we should specify how an 792 individual IPv6 address is translated to a corresponding IPv4 793 address, and vice versa, in cases where an algorithmic mapping is 794 used. This includes the choice of IPv6 prefix and the choice of 795 method by which the remainder of the IPv6 address is derived from an 796 IPv4 address [I-D.ietf-behave-address-format]. The usages of the 797 IPv6 addresses are shown in the following figures. 799 ------------ 800 H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4- 801 (IPv4 ------------ translatable address 802 address) \ 803 -------------- 804 |Stateless XLAT| 805 -------------- 806 \ 807 ----------- 808 IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4- 809 ----------- translatable address) 811 Figure 9: IPv6 address representation for stateless translation 813 ------------ 814 H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool 815 (IPv4 ------------ 816 address) \ 817 -------------- 818 |Stateful XLAT | 819 -------------- 820 \ 821 ----------- 822 IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address) 823 ----------- 825 Figure 10: IPv6 address representation for stateful translation 827 For both stateless and stateful translation, an algorithmic mapping 828 table is used to translate IPv6 destination addresses (IPv4-converted 829 addresses) to IPv4 destination addresses in IPv6 to IPv4 direction 830 and translate IPv4 source addresses to IPv6 source addresses (IPv4- 831 converted addresses) in IPv4 to IPv6 direction. Note that 832 translating IPv6 source addresses to IPv4 source addresses in IPv6 to 833 IPv4 direction and translating IPv4 destination addresses to IPv6 834 destination addresses in IPv4 to IPv6 direction will be different for 835 stateless translation and stateful translation. 837 o For stateless translation, the same algorithmic mapping table is 838 used to translate IPv6 source addresses (IPv4-translatable 839 addresses) to IPv4 source addresses in IPv6 to IPv4 direction and 840 translate IPv4 destination addresses to IPv6 destination addresses 841 (IPv4-translatable addresses) in IPv4 to IPv6 direction. In this 842 case, blocks of service provider's IPv4 addresses are mapped into 843 IPv6 and used by physical IPv6 nodes. The original IPv4 form of 844 these blocks of service provider's IPv4 addresses are used to 845 represent the physical IPv6 nodes in IPv4. Note that stateless 846 translation supports both IPv6 initiated as well as IPv4 initiated 847 communications. 849 o For stateful translation, the algorithmic mapping table is not 850 used to translate source addresses in IPv6 to IPv4 direction and 851 destination addresses in IPv4 to IPv6 direction. Instead, a state 852 table is used to translate IPv6 source addresses to IPv4 source 853 addresses in IPv6 to IPv4 direction and translate IPv4 destination 854 addresses to IPv6 destination addresses in IPv4 to IPv6 direction. 855 In this case, blocks of the service provider's IPv4 addresses are 856 maintained in the translator as the IPv4 address pools and are 857 dynamically bound to specific IPv6 addresses. The original IPv4 858 form of these blocks of service provider's IPv4 addresses is used 859 to represent the IPv6 address in IPv4. However, due to the 860 dynamic binding, stateful translation in general only supports 861 IPv6-initiated communication. 863 3.1.2. IP and ICMP Translation 865 The IPv4/IPv6 translator is based on the update to the Stateless IP/ 866 ICMP Translation Algorithm (SIIT) described in [RFC2765]. The 867 algorithm translates between IPv4 and IPv6 packet headers (including 868 ICMP headers). 870 The IP and ICMP translation document [I-D.ietf-behave-v6v4-xlate] 871 discusses header translation for both stateless and stateful modes, 872 but does not cover maintaining state in the stateful mode. In the 873 stateless mode, translation information is carried in the address 874 itself plus configuration in the translator, permitting both 875 IPv4->IPv6 and IPv6->IPv4 session establishment. In the stateful 876 mode, translation state is maintained between IPv4 address/transport 877 port tuples and IPv6 address/transport port tuples, enabling IPv6 878 systems to open sessions with IPv4 systems. The choice of 879 operational mode is made by the operator deploying the network and is 880 critical to the operation of the applications using it. 882 3.1.3. Maintaining Translation State 884 For the stateful translator, besides IP and ICMP translation, special 885 action must be taken to maintain the translation states. 886 [I-D.ietf-behave-v6v4-xlate-stateful] describes a mechanism for 887 maintaining state. 889 3.1.4. DNS64 and DNS46 891 DNS64 [I-D.ietf-behave-dns64] and possible future DNS46 documents 892 describe the mechanisms by which a DNS translator is intended to 893 operate. It is designed to operate on the basis of known address 894 translation algorithms defined in [I-D.ietf-behave-address-format] 896 There are at least two possible implementations of a DNS64 and DNS46: 898 Static records: One could literally populate DNS with corresponding 899 A and AAAA records. This mechanism works for scenarios 2, 3, 5 900 and 6. 902 Dynamic Translation of static records: In more general operation, 903 the preferred behavior is an A record to be (retrieved and) 904 translated to an AAAA record by the DNS64 if and only if no 905 reachable AAAA record exists, or for an AAAA record to be 906 (retrieved and) translated to an A record by the DNS46 if and only 907 if no reachable A record exists. 909 3.1.5. ALGs for Other Applications Layer Protocols 911 In addition, some applications require special support. An example 912 is FTP. FTP's active mode doesn't work well across NATs without 913 extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it 914 generally uses passive mode. However, the designers of FTP wrote 915 different and incompatible passive mode implementations for IPv4 and 916 IPv6 networks. Hence, either they need to fix FTP, or a translator 917 must be written for the application. Other applications may be 918 similarly broken. 920 As a general rule, a simple operational recommendation will work 921 around many application issues, which is that there should be a 922 server in each domain or an instance of the server should have an 923 interface in each domain. For example, an SMTP MTA may be confused 924 by finding an IPv6 address in its HELO when it is connected to using 925 IPv4 (or vice versa), but would work perfectly well if it had an 926 interface in both the IPv4 and IPv6 domains and was used as an 927 application-layer bridge between them. 929 3.2. Operation Mode for Specific Scenarios 931 Currently, the proposed solutions for IPv6/IPv4 translation are 932 classified into stateless translation and stateful translation. 934 3.2.1. Stateless Translation 936 For stateless translation, the translation information is carried in 937 the address itself plus configuration in the translators, permitting 938 both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless 939 translation supports end-to-end address transparency and has better 940 scalability compared with stateful translation. 941 [I-D.ietf-behave-v6v4-xlate]. 943 The stateless translation mechanisms typically put constraints on 944 what IPv6 addresses can be assigned to IPv6 nodes that want to 945 communicate with IPv4 destinations using an algorithmic mapping. For 946 Scenario 1 ("an IPv6 network to the IPv4 Internet"), it is not a 947 serious drawback, since the address assignment policy can be applied 948 to satisfy this requirement for the IPv6 nodes that need to 949 communicate with the IPv4 Internet. In addition, stateless 950 translation supports Scenario 2 ("the IPv4 Internet to an IPv6 951 network"), which means that not only could servers move directly to 952 IPv6 without trudging through a difficult transition period, but they 953 could do so without risk of losing connectivity with the IPv4-only 954 Internet. 956 Stateless translation can be used for Scenarios 1, 2, 5 and 6, i.e., 957 it supports "an IPv6 network to the IPv4 Internet", "the IPv4 958 Internet to an IPv6 network", "an IPv6 network to an IPv4 network" 959 and "an IPv4 network to an IPv6 network". 961 -------- 962 // \\ ----------- 963 / \ // \\ 964 / +----+ \ 965 | |XLAT| | 966 | The IPv4 +----+ An IPv6 | 967 | Internet +----+ Network | XLAT: Stateless IPv4/IPv6 968 | |DNS | (address | Translator 969 \ +----+ subset) / DNS: DNS64/DNS46 970 \ / \\ // 971 \\ // ---------- 972 -------- 973 <====> 975 Figure 11: Stateless translation for Scenarios 1 and 2 977 -------- --------- 978 // \\ // \\ 979 / +----+ \ 980 | |XLAT| | 981 | An IPv4 +----+ An IPv6 | 982 | Network +----+ Network | XLAT: Stateless IPv4/IPv6 983 | |DNS | (address | Translator 984 \ +----+ subset) / DNS: DNS64/DNS46 985 \\ // \\ // 986 -------- --------- 987 <====> 989 Figure 12: Stateless translation for Scenarios 5 and 6 991 The implementation of the stateless translator needs to refer to 992 [I-D.ietf-behave-v6v4-xlate], and [I-D.ietf-behave-address-format]. 994 3.2.2. Stateful Translation 996 For stateful translation, the translation state is maintained between 997 IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 998 systems to open sessions with IPv4 systems 999 [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful]. 1001 Stateful translator can be used for Scenarios 1, 3 and 5, i.e., it 1002 supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet 1003 to an IPv4 network" and "an IPv6 network to an IPv4 network". 1005 For Scenario 1, any IPv6 addresses in an IPv6 network can use 1006 stateful translation, however it typically only supports initiation 1007 from the IPv6 side. In addition, it does not result in stable 1008 addresses of IPv6 nodes that can be used in DNS, which may cause 1009 problems for the protocols and applications that do not deal well 1010 with highly dynamic addresses. 1012 -------- 1013 // \\ ----------- 1014 / \ // \\ 1015 / +----+ \ 1016 | |XLAT| | 1017 | The IPv4 +----+ An IPv6 | 1018 | Internet +----+ Network | XLAT: Stateful IPv4/IPv6 1019 | |DNS | | Translator 1020 \ +----+ / DNS: DNS64 1021 \ / \\ // 1022 \\ // ----------- 1023 -------- 1024 <==== 1026 Figure 13: Stateful translation for Scenario 1 1028 Scenario 3 handles servers using IPv4 private addresses [RFC1918] and 1029 being reached from the IPv6 Internet. This includes cases of servers 1030 that for some reason cannot be upgraded to IPv6 and don't have public 1031 IPv4 addresses and yet need to be reached by IPv6 nodes in the IPv6 1032 Internet. 1034 ----------- 1035 ---------- // \\ 1036 // \\ / \ 1037 / +----+ \ 1038 | |XLAT| | 1039 | An IPv4 +----+ The IPv6 | 1040 | Network +----+ Internet | XLAT: Stateful IPv4/IPv6 1041 | |DNS | | Translator 1042 \ +----+ / DNS: DNS64 1043 \\ // \ / 1044 --------- \\ // 1045 ----------- 1046 <==== 1048 Figure 14: Stateful translation for Scenario 3 1050 Similarly, stateful translation can also be used for Scenario 5. 1052 -------- --------- 1053 // \\ // \\ 1054 / +----+ \ 1055 | |XLAT| | 1056 | An IPv4 +----+ An IPv6 | 1057 | Network +----+ Network | XLAT: Stateful IPv4/IPv6 1058 | |DNS | | Translator 1059 \ +----+ / DNS: DNS64 1060 \\ // \\ // 1061 -------- --------- 1062 <==== 1064 Figure 15: Stateful translation for Scenario 5 1066 The implementation of the stateful translator needs to refer to 1067 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 1068 and [I-D.ietf-behave-address-format]. 1070 3.3. Layout of the Related Documents 1072 Based on the above analysis, the IPv4/IPv6 translation series 1073 consists of the following documents. 1075 o Framework for IPv4/IPv6 Translation (this document). 1077 o Address translation (the choice of IPv6 prefix and the choice of 1078 method by which the remainder of the IPv6 address is derived from 1079 an IPv4 address, part of the SIIT update) 1080 [I-D.ietf-behave-address-format]. 1082 o IP and ICMP Translation (header translation and ICMP handling, 1083 part of the SIIT update) [I-D.ietf-behave-v6v4-xlate]. 1085 o Xlate-stateful (stateful translation including session database 1086 and mapping table handling) [I-D.ietf-behave-v6v4-xlate-stateful]. 1088 o DNS64 (DNS64: A to AAAA mapping and DNSSec discussion) 1089 [I-D.ietf-behave-dns64]. 1091 o FTP ALG [I-D.ietf-behave-ftp64]. 1093 o Others (DNS46, Multicast, etc). 1095 The relationship among these documents is shown in the following 1096 figure. 1098 ----------------------------------------- 1099 | Framework for IPv4/IPv6 Translation | 1100 ----------------------------------------- 1101 || || 1102 ------------------------------------------------------------------- 1103 | || stateless and stateful || | 1104 | -------------------- --------------------- | 1105 | |Address Translation | <======== | IP/ICMP Translation | | 1106 | -------------------- --------------------- | 1107 | /\ /\ | 1108 | || ------------------||------------ | 1109 | || | stateful \/ | 1110 | ----------------- | --------------------- | 1111 | | DNS64/DNS46 | | | Table Maintenance | | 1112 | ----------------- | --------------------- | 1113 ------------------------------------------------------------------- 1114 /\ /\ 1115 || || 1116 ----------------- -------------------- 1117 | FTP ALG | | Others | 1118 ----------------- -------------------- 1120 Figure 16: Document Layout 1122 In the document layout, the IP/ICMP Translation and DNS64/DNS46 1123 normatively refer to Address Translation. The Table Maintenance and 1124 IP/ICMP Translation normatively refer to each other. 1126 The FTP ALG and other documents normatively refer to the Address 1127 Format, IP/ICMP Translation and Table Maintenance documents. 1129 4. Translation in Operation 1131 Operationally, there are two ways that translation could be used - as 1132 a permanent solution making transition "the other guy's problem", and 1133 as a temporary solution for a new part of one's network while 1134 bringing up IPv6 services in the remaining parts of one's network. 1135 We obviously recommend the latter at the present stage. For the IPv4 1136 parts of the network, [RFC4213]'s recommendation holds. Bring IPv6 1137 up in those domains, move production to it, and then take down the 1138 now-unnecessary IPv4 service when economics warrant. This approach 1139 to transition entails the least risk. 1141 ---------------------- 1142 ////// \\\\\\ 1143 /// IPv4 or Dual Stack \\\ 1144 || +----+ Routing +-----+ || 1145 | |IPv4| |IPv4+| | 1146 | |Host| |IPv6 | | 1147 || +----+ |Host | || 1148 \\\ +-----+ /// 1149 \\\\\----+----+-+-----+ +----+-///// 1150 |XLAT|-|DNS64|-|FTP | 1151 | |-|DNS46|-|ALG | 1152 /////----+----+ +-----+ +----+-\\\\\ 1153 /// \\\ 1154 || +-----+ +----+ || 1155 | |IPv4+| |IPv6| | 1156 | |IPv6 | |Host| | 1157 || |Host | +----+ || 1158 \\\ +-----+ IPv6-only Routing /// 1159 \\\\\\ ////// 1160 ---------------------- 1162 Figure 17: Translation Operational Model 1164 Figure 17 shows that, during the coexistence phase, one expects a 1165 combination of hosts, applications, and networks. Hosts might 1166 include IPv6-only gaming devices and handsets, older computer 1167 operating systems that are IPv4-only, and modern mainline operating 1168 systems that support both. Applications might include ones that are 1169 IPv4-only and modern applications that support both IPv4 and IPv6. 1170 Networks might include dual-stack devices operating in single-stack 1171 networks, whether that stack is IPv4 or IPv6 and fully functional 1172 dual-stack networks. 1174 5. Unsolved Problems 1176 The framework does not cover all possible scenarios, and may be 1177 extended in the future to address them. 1179 6. IANA Considerations 1181 This memo requires no parameter assignment by the IANA. 1183 Note to RFC Editor: This section will have served its purpose if it 1184 correctly tells IANA that no new assignments or registries are 1185 required, or if those assignments or registries are created during 1186 the RFC publication process. From the author's perspective, it may 1187 therefore be removed upon publication as an RFC at the RFC Editor's 1188 discretion. 1190 7. Security Considerations 1192 This document is the framework of IPv4/IPv6 translation. The 1193 security issues are addressed in individual IPv4/IPv6 translation 1194 documents, i.e. [I-D.ietf-behave-address-format], 1195 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 1196 [I-D.ietf-behave-dns64], and [I-D.ietf-behave-ftp64]. 1198 8. Acknowledgements 1200 This is under development by a large group of people. Those who have 1201 posted to the list during the discussion include Andrew Sullivan, 1202 Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, 1203 David Harrington, Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, 1204 Iljitsch van Beijnum, John Schnizlein, Magnus Westerlund, Marcelo 1205 Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts, 1206 Philip Matthews, Remi Denis-Courmont and Remi Despres. 1208 Ed Jankiewicz described the transition plan. 1210 9. References 1212 9.1. Normative References 1214 [I-D.ietf-behave-address-format] 1215 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1216 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1217 draft-ietf-behave-address-format-10 (work in progress), 1218 August 2010. 1220 [I-D.ietf-behave-dns64] 1221 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1222 "DNS64: DNS extensions for Network Address Translation 1223 from IPv6 Clients to IPv4 Servers", 1224 draft-ietf-behave-dns64-10 (work in progress), July 2010. 1226 [I-D.ietf-behave-ftp64] 1227 Beijnum, I., "IPv6-to-IPv4 translation FTP 1228 considerations", draft-ietf-behave-ftp64-04 (work in 1229 progress), July 2010. 1231 [I-D.ietf-behave-v6v4-xlate] 1232 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1233 Algorithm", draft-ietf-behave-v6v4-xlate-20 (work in 1234 progress), May 2010. 1236 [I-D.ietf-behave-v6v4-xlate-stateful] 1237 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1238 NAT64: Network Address and Protocol Translation from IPv6 1239 Clients to IPv4 Servers", 1240 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1241 progress), July 2010. 1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, March 1997. 1246 9.2. Informative References 1248 [6NET] "Website: http://www.6net.org/". 1250 [I-D.ietf-softwire-dual-stack-lite] 1251 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1252 Stack Lite Broadband Deployments Following IPv4 1253 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 1254 in progress), August 2010. 1256 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1257 E. Lear, "Address Allocation for Private Internets", 1258 BCP 5, RFC 1918, February 1996. 1260 [RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement 1261 for Historic Status", RFC 1923, March 1996. 1263 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1264 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1265 March 1996. 1267 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1268 (SIIT)", RFC 2765, February 2000. 1270 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1271 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1272 February 2000. 1274 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1275 via IPv4 Clouds", RFC 3056, February 2001. 1277 [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 1278 RFC 3089, April 2001. 1280 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1281 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1282 September 2005. 1284 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1285 Addresses", RFC 4193, October 2005. 1287 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1288 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1290 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1291 Network Address Translations (NATs)", RFC 4380, 1292 February 2006. 1294 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1295 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1296 May 2007. 1298 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1299 Address Translator - Protocol Translator (NAT-PT) to 1300 Historic Status", RFC 4966, July 2007. 1302 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 1303 July 2008. 1305 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1306 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1307 March 2008. 1309 Authors' Addresses 1311 Fred Baker 1312 Cisco Systems 1313 Santa Barbara, California 93117 1314 USA 1316 Phone: +1-408-526-4257 1317 Fax: +1-413-473-2403 1318 Email: fred@cisco.com 1320 Xing Li 1321 CERNET Center/Tsinghua University 1322 Room 225, Main Building, Tsinghua University 1323 Beijing, 100084 1324 China 1326 Phone: +86 10-62785983 1327 Email: xing@cernet.edu.cn 1329 Congxiao Bao 1330 CERNET Center/Tsinghua University 1331 Room 225, Main Building, Tsinghua University 1332 Beijing, 100084 1333 China 1335 Phone: +86 10-62785983 1336 Email: congxiao@cernet.edu.cn 1338 Kevin Yin 1339 Cisco Systems 1340 No. 2 Jianguomenwai Ave, Chaoyang District 1341 Beijing, 100022 1342 China 1344 Phone: +86-10-8515-5094 1345 Email: kyin@cisco.com