idnits 2.17.1 draft-ietf-behave-v6v4-framework-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 date (February 7, 2010) is 5192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.bagnulo-behave-nat64' is defined on line 1227, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-04 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-05 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-00 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-06 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 == Outdated reference: A later version (-02) exists of draft-venaas-behave-mcast46-01 == Outdated reference: A later version (-07) exists of draft-xli-behave-dns46-for-stateless-00 -- 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: 1 error (**), 0 flaws (~~), 9 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: August 11, 2010 C. Bao 6 CERNET Center/Tsinghua University 7 K. Yin 8 Cisco Systems 9 February 7, 2010 11 Framework for IPv4/IPv6 Translation 12 draft-ietf-behave-v6v4-framework-06 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 11, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7 65 1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 8 66 2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 10 67 2.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 11 68 2.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . . . 12 69 2.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 13 70 2.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . . . 14 71 2.5. Scenario 5: an IPv6 network to an IPv4 network . . . . . . 15 72 2.6. Scenario 6: an IPv4 network to an IPv6 network . . . . . . 15 73 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . . . 16 74 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . . . 17 75 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 3.1. Translation Components . . . . . . . . . . . . . . . . . . 18 77 3.1.1. Address Translation . . . . . . . . . . . . . . . . . 18 78 3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 19 79 3.1.3. Maintaining Translation State . . . . . . . . . . . . 19 80 3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 19 81 3.1.5. ALGs for Other Applications Layer Protocols . . . . . 20 82 3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 20 83 3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 20 84 3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 21 85 3.3. Layout of the Related Documents . . . . . . . . . . . . . 23 86 4. Translation in Operation . . . . . . . . . . . . . . . . . . . 25 87 5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 26 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 This note describes a framework for IPv4/IPv6 translation. This is 99 in the context of replacing NAT-PT [RFC2766], which was deprecated by 100 [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a 101 somewhat rational manner while transitioning to an IPv6-only network. 103 NAT-PT was deprecated to inform the community that NAT-PT had 104 operational issues and was not considered a viable medium- or long- 105 term strategy for either coexistence or transition. It wasn't 106 intended to say that IPv4<->IPv6 translation was bad, but the way 107 that NAT-PT did it was bad, and in particular using NAT-PT as a 108 general-purpose solution was bad. As with the deprecation of the RIP 109 routing protocol [RFC1923] at the time the Internet was converting to 110 CIDR, the point was to encourage network operators to actually move 111 away from technology with known issues. 113 [RFC4213] describes the IETF's view of the most sensible transition 114 model. The IETF recommends, in short, that network operators 115 (transit providers, service providers, enterprise networks, small and 116 medium businesses, SOHO and residential customers, and any other kind 117 of network that may currently be using IPv4) obtain an IPv6 prefix, 118 turn on IPv6 routing within their networks and between themselves and 119 any peer, upstream, or downstream neighbors, enable it on their 120 computers, and use it in normal processing. This should be done 121 while leaving IPv4 stable, until a point is reached that any 122 communication that can be carried out could use either protocol 123 equally well. At that point, the economic justification for running 124 both becomes debatable, and network operators can justifiably turn 125 IPv4 off. This process is comparable to that of [RFC4192], which 126 describes how to renumber a network using the same address family 127 without a flag day. While running stably with the older system, 128 deploy the new. Use the coexistence period to work out such kinks as 129 arise. When the new is also running stably, shift production to it. 130 When network and economic conditions warrant, remove the old, which 131 is now no longer necessary. 133 The question arises: what if that is infeasible due to the time 134 available to deploy or other considerations? What if the process of 135 moving a network and its components or customers is starting too late 136 for contract cycles to affect IPv6 turn-up on important parts at a 137 point where it becomes uneconomical to deploy global IPv4 addresses 138 in new services? How does one continue to deploy new services 139 without balkanizing the network? 141 This document describes translation as one of the tools networks 142 might use to facilitate coexistence and ultimate transition. 144 1.1. Why Translation? 146 Besides dual-stack deployment, there are two fundamental approaches 147 one could take to interworking between IPv4 and IPv6: tunneling and 148 translation. One could - and in the 6NET we did - build an overlay 149 network that tunnels one protocol over the other. Various proposals 150 take that model, including 6to4 [RFC3056], Teredo [RFC4380], ISATAP 151 [RFC5214], and DS-Lite [I-D.durand-softwire-dual-stack-lite]. The 152 advantage of doing so is that the new is enabled to work without 153 disturbing the old protocol, providing connectivity between users of 154 the new protocol. There are two disadvantages to tunneling: 156 o Users of the new architecture that don't support the old protocol, 157 and those users are unable to use the services of the underlying 158 infrastructure - it is just bandwidth, and 160 o It doesn't enable new protocol users to communicate with old 161 protocol users without dual-stack hosts. 163 As noted, in this work, we look at Internet Protocol translation as a 164 transition strategy. [RFC4864] forcefully makes the point that many 165 of the reasons people use Network Address Translators are met as well 166 by routing or protocol mechanisms that preserve the end-to-end 167 addressability of the Internet. What it did not consider is the case 168 in which there is an ongoing requirement to communicate with IPv4 169 systems, but for example configuring IPv4 routing is not in the 170 network operator's view the most desirable strategy, or is infeasible 171 due to a shortage of global address space. Translation enables the 172 client of a network, whether a transit network, an access network, or 173 an edge network, to access the services of the network and 174 communicate with other network users regardless of their protocol 175 usage - within limits. Like NAT-PT, IPv4/IPv6 translation under this 176 rubric is not a long-term support strategy, but it is a medium-term 177 coexistence strategy that can be used to facilitate a long-term 178 program of transition. 180 1.2. Terminology 182 The following terminology is used in this document and other 183 documents related to it. 185 An IPv4 network: A specific network that has an IPv4-only 186 deployment. This could be an enterprise's IPv4-only network, an 187 ISP's IPv4-only network or even an IPv4-only host. The IPv4 188 Internet is the set of all interconnected IPv4 networks. 190 An IPv6 network: A specific network that has an IPv6-only 191 deployment. This could be an enterprise's IPv6-only network, an 192 ISP's IPv6-only network or even an IPv6-only host. The IPv6 193 Internet is the set of all interconnected IPv6 networks. 195 DNS46: A DNS translator that translates AAAA record to A record. 197 DNS64: A DNS translater that translates A record to AAAA record. 199 Dual-Stack implementation: A Dual-Stack implementation, in this 200 context, comprises an IPv4/IPv6 enabled end system stack, 201 applications plus routing in the network. It implies that two 202 application instances are capable of communicating using either 203 IPv4 or IPv6 - they have stacks, they have addresses, and they 204 have any necessary network support including routing. 206 IPv4-converted addresses: They are IPv6 addresses used to represent 207 IPv4 addresses. They have an explicit mapping relationship to 208 IPv4 addresses. Both stateless and stateful translators use IPv4- 209 converted addresses to represent IPv4 addresses. 211 IPv4-only: An IPv4-only implementation, in this context, comprises 212 an IPv4-enabled end system stack, applications directly or 213 indirectly using that IPv6 stack, plus routing in the network. It 214 implies that two application instances are capable of 215 communicating using IPv4, but not IPv6 - they have an IPv4 stack, 216 addresses, and network support including IPv4 routing and 217 potentially IPv4/IPv4 translation, but some element is missing 218 that prevents communication with IPv6 hosts. 220 IPv4-translatable addresses: They are the IPv6 addresses to be 221 assigned to IPv6 nodes behind one or more stateless translators. 222 They have an explicit mapping relationship to IPv4 addresses. A 223 stateless translator uses the corresponding IPv4 addresses to 224 represent the IPv6 addresses. A stateful translator does not use 225 this kind of addresses, since IPv6 hosts are represented by the 226 IPv4 address pool in the translator via dynamic state. 228 IPv6-only: An IPv6-only implementation, in this context, comprises 229 an IPv6-enabled end system stack, applications directly or 230 indirectly using that IPv6 stack, plus routing in the network. It 231 implies that two application instances are capable of 232 communicating using IPv6, but not IPv4 - they have an IPv6 stack, 233 addresses, and network support including routing in IPv6, but some 234 element is missing that prevents communication with IPv4 hosts. 236 Network-Specific Prefix (NSP): From an IPv6 prefix assigned to a 237 network operator, the operator chooses a longer prefix for use by 238 the operator's translator(s). Hence a given IPv4 address would 239 have different IPv6 representations in different networks that use 240 different network-specific prefixes. A network-specific prefix is 241 also known as a Local Internet Registry (LIR) prefix. 243 State: "State" refers to dynamic information that is stored in a 244 network element. For example, if two systems are communicating 245 using a TCP connection, each stores information about the 246 connection, which is called "connection state". In this context, 247 the term refers to dynamic correlations between IP addresses on 248 either side of a translator, or {IP address, transport protocol, 249 transport port number} tuples on either side of the translator. 250 Of stateful algorithms, there are at least two major flavors 251 depending on the kind of state they maintain: 253 Hidden state: the existence of this state is unknown outside the 254 network element that contains it. 256 Known state: the existence of this state is known by other 257 network elements. 259 Stateful Translation: A translation algorithm may be said to 260 "require state in a network element" or be "stateful" if the 261 transmission or reception of a packet creates or modifies a data 262 structure in the relevant network element. 264 Stateful Translator: A translator that uses stateful translation for 265 either the source or destination address. A stateful translator 266 typically also uses a stateless translation algorithm for the 267 other type of address. 269 Stateless Translation: A translation algorithm that is not 270 "stateful" is "stateless". It derives its needed information 271 algorithmically from the messages it is translating, and pre- 272 configured information. 274 Stateless Translator: A translator that uses only stateless 275 translation for both destination address and source address. 277 Well-Known Prefix (WKP): A prefix assigned by IANA. In this case, 278 there would be a single representation of a public IPv4 address in 279 the IPv6 address space. 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in [RFC2119]. 285 1.3. Translation Objectives 287 In any translation model, there is a question of objectives. 288 Ideally, one would like to make any system and any application 289 running on it able to "talk with" - exchange datagrams supporting 290 applications with - any other system running the same application 291 regardless of whether they have an IPv4 stack and connectivity or 292 IPv6 stack and connectivity. That was the model for NAT-PT, and the 293 things it necessitated led to scaling and operational difficulties 294 [RFC4966]. 296 So the question comes back to what different kinds of connectivity 297 can be easily supported and what kinds are harder, and what 298 technologies are needed to at least pick the low-hanging fruit. We 299 observe that applications today fall into two main categories: 301 Client/Server Application: Per whatis.com, "'Client/server' 302 describes the relationship between two computer programs in which 303 one program, the client, makes a service request from another 304 program, the server, which fulfills the request." In networking, 305 the behavior of the applications is that connections are initiated 306 from client software and systems to server software and systems. 307 Examples include mail handling between an end user and his mail 308 system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name 309 resolution. 311 Peer-to-Peer (P2P) Application: A P2P application is an application 312 that uses the same endpoint to initiate outgoing sessions to 313 peering hosts as well as accept incoming sessions from peering 314 hosts. These in turn fall broadly into two categories: 316 Peer-to-peer infrastructure applications: Examples of 317 "infrastructure applications" include SMTP between MTAs, 318 Network News, and SIP. Any MTA might open an SMTP session with 319 any other at any time; any SIP Proxy might similarly connect 320 with any other SIP Proxy. An important characteristic of these 321 applications is that they use ephemeral sessions - they open 322 sessions when they are needed and close them when they are 323 done. 325 Peer-to-peer file exchange applications: Examples of these 326 include Limewire, BitTorrent, and UTorrent. These are 327 applications that open some sessions between systems and leave 328 them open for long periods of time, and where ephemeral 329 sessions are important, are able to learn about the reliability 330 of peers from history or by reputation. They use the long-term 331 sessions to map content availability. Short-term sessions are 332 used to exchange content. They tend to prefer to ask for 333 content from servers that they find reliable and available. 335 If the goal is the ability to open connections between systems, then 336 one must ask who opens connections. 338 o We need a technology that will enable systems that act as clients 339 to be able to open sessions with other systems that act as 340 servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 341 direction. Ideally, this is stateless; especially in a carrier 342 infrastructure, the preponderance of accesses will be to servers, 343 and this optimizes access to them. However, a stateful algorithm 344 is acceptable if the complexity is minimized and a stateless 345 algorithm cannot be constructed. 347 o We also need a technology that will allow peers to connect with 348 each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 349 direction. Again, it would be ideal if this was stateless, but a 350 stateful algorithm is acceptable if the complexity is minimized 351 and a stateless algorithm cannot be constructed. 353 o In some situations, hosts are purely clients. In those 354 situations, we do not need an algorithm to enable connections to 355 those hosts. 357 The complexity arguments bring us in the direction of hidden state: 358 if state must be shared between the application and the translator or 359 between translation components, complexity and deployment issues are 360 greatly magnified. The objective of the translators is to aviod, as 361 much as possible, any software changes in hosts or applications 362 necessary to support translation. 364 NAT-PT is an example of a facility with known state - at least two 365 software components (the data plane translator and the DNS 366 Application Layer Gateway, which may be implemented in the same or 367 different systems) share and must coordinate translation state. A 368 typical IPv4/IPv4 NAT implements an algorithm with hidden state. 369 Obviously, stateless translation requires less computational overhead 370 than stateful translation, and less memory to maintain the state, 371 because the translation tables and their associated methods and 372 processes exist in a stateful algorithm and don't exist in a 373 stateless one. 375 1.4. Transition Plan 377 While the design of IPv4 made it impossible for IPv6 to be compatible 378 on the wire, the designers intended that it would coexist with IPv4 379 during a period of transition. The primary mode of coexistence was 380 dual-stack operation - routers would be dual-stacked so that the 381 network could carry both address families, and IPv6-capable hosts 382 could be dual-stack to maintain access to IPv4-only partners. The 383 goal was that the preponderance of hosts and routers in the Internet 384 would be IPv6-capable long before IPv4 address space allocation was 385 completed. At this time, it appears the exhaustion of IPv4 address 386 space will occur before significant IPv6 adoption. 388 Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three- 389 phase progression: 391 Preparation Phase (current): characterized by pilot use of IPv6, 392 primarily through transition mechanisms defined in [RFC4213], and 393 planning activities. 395 Transition Phase (2010 through 2011): characterized by general 396 availability of IPv6 in provider networks which SHOULD be native 397 IPv6; organizations SHOULD provide IPv6 connectivity for their 398 Internet-facing servers, but SHOULD still provide IPv4-based 399 services via a separate service name. 401 Post-Transition Phase (2012 and beyond): characterized by a 402 preponderance of IPv6-based services and diminishing support for 403 IPv4-based services. 405 Various timelines have been discussed, but most will agree with the 406 pattern of the above three transition phases, also known as an "S" 407 curve transition pattern. 409 In each of these phases, the coexistence problem and solution space 410 has a different focus: 412 Preparation Phase: Coexistence tools are needed to facilitate early 413 adopters by removing impediments to IPv6 deployment, and to assure 414 that nothing is lost by adopting IPv6, in particular that the IPv6 415 adopter has unfettered access to the global IPv4 Internet 416 regardless of whether they have a global IPv4 address (or any IPv4 417 address or stack at all). While it might appear reasonable for 418 the cost and operational burden to be borne by the early adopter, 419 the shared goal of promoting IPv6 adoption would argue against 420 that model. Additionally, current IPv4 users should not be forced 421 to retire or upgrade their equipment and the burden remains on 422 service providers to carry and route native IPv4. This is known 423 as the early stage of the "S" curve. 425 Transition Phase: During the middle stage of "S" curve, while IPv6 426 adoption can be expected to accelerate, there will still be a 427 significant portion of the Internet operating IPv4-only or 428 preferring IPv4. During this phase the norm shifts from IPv4 to 429 IPv6, and coexistence tools evolve to ensure interoperability 430 between domains that may be restricted to IPv4 or IPv6. 432 Post-Transition Phase: This is the last stage of "S" curve. In this 433 phase, IPv6 is ubiquitous and the burden of maintaining 434 interoperability shifts to those who choose to maintain IPv4-only 435 systems. While these systems should be allowed to live out their 436 economic life cycles, the IPv4-only legacy users at the edges 437 should bear the cost of coexistence tools, and at some point 438 service provider networks should not be expected to carry and 439 route native IPv4 traffic. 441 The choice between the terms "transition" versus "coexistence" has 442 engendered long philosophical debate. "Transition" carries the sense 443 that one is going somewhere, while "coexistence" seems more like one 444 is sitting somewhere. Historically with the IETF, "transition" has 445 been the term of choice [RFC4213][RFC5211], and the tools for 446 interoperability have been called "transition mechanisms". There is 447 some perception or conventional wisdom that adoption of IPv6 is being 448 impeded by the deficiency of tools to facilitate interoperability of 449 nodes or networks that are constrained (in some way, fully or 450 partially) from full operation in one of the address families. In 451 addition, it is apparent that transition will involve a period of 452 coexistence; the only real question is how long that will last. 454 Thus, coexistence is an integral part of the transition plan, not in 455 conflict with it, but there will be a balancing act. It starts out 456 being a way for early IPv6 adopters to easily exploit the bigger IPv4 457 Internet, and ends up being a way for late/never adopters to hang on 458 with IPv4 (at their own expense, with minimal impact or visibility to 459 the Internet). One way to look at solutions is that cost incentives 460 (both monetary cost and the operational overhead for the end user) 461 should encourage IPv6 and discourage IPv4. That way natural market 462 forces will keep the transition moving - especially as the legacy 463 IPv4-only stuff ages out of use. There will come a time to set a 464 date after which no one is obligated to carry native IPv4 but it 465 would be premature to attempt to do so yet. The end goal should not 466 be to eliminate IPv4 by fiat, but rather render it redundant through 467 ubiquitous IPv6 deployment. IPv4 may never go away completely, but 468 rational plans should move the costs of maintaining IPv4 to those who 469 insist on using it after wide adoption of IPv6. 471 2. Scenarios for IPv4/IPv6 Translation 473 It is important to note that the choice of translation solution and 474 the assumptions about the network where they are used impact the 475 consequences. A translator for the general case has a number of 476 issues that a translator for a more specific situation may not have 477 at all. 479 The intention of this document is to focus on translation solutions 480 under all kinds of situations. All IPv4/IPv6 translation cases can 481 be easily described in terms of "interoperation between a set of 482 systems (applications) that only communicate using IPv4 and a set of 483 systems that only communicate using IPv6", but the differences at a 484 detailed level make them interesting. 486 Based on the transition plan described in Section 1.4, there are four 487 types of IPv4/IPv6 translation scenarios: 489 a. Interoperation between an IPv6 network and the IPv4 Internet 491 b. Interoperation between an IPv4 network and the IPv6 Internet 493 c. Interoperation between an IPv6 network and an IPv4 network 495 d. Interoperation between the IPv6 Internet and the IPv4 Internet 497 Each one of the above can be divided into two scenarios, depending on 498 whether the IPv6 side or the IPv4 side initiates communication, so 499 there are a total of eight scenarios. 501 Scenario 1: an IPv6 network to the IPv4 Internet 503 Scenario 2: the IPv4 Internet to an IPv6 network 505 Scenario 3: the IPv6 Internet to an IPv4 network 507 Scenario 4: an IPv4 network to the IPv6 Internet 509 Scenario 5: an IPv6 network to an IPv4 network 511 Scenario 6: an IPv4 network to an IPv6 network 513 Scenario 7: the IPv6 Internet to the IPv4 Internet 515 Scenario 8: the IPv4 Internet to the IPv6 Internet 517 We will discuss each scenario in detail in the next section. 519 2.1. Scenario 1: an IPv6 network to the IPv4 Internet 521 Due to the lack of IPv4 addresses or under other technical or 522 economical constraints, the network is IPv6-only, but the hosts in 523 the network require communicating with the global IPv4 Internet. 525 This is the typical scenario for what we sometimes call "green-field" 526 deployments. One example is an enterprise network that wishes to 527 operate only IPv6 for operational simplicity, but still wishes to 528 reach the content in the IPv4 Internet. The green-field enterprise 529 scenario is different from an ISP's network in the sense that there 530 is only one place that the enterprise can easily modify: the border 531 between its network and the IPv4 Internet. Obviously, the IPv4 532 Internet operates the way it already does. But in addition, the 533 hosts in the enterprise network are commercially available devices, 534 personal computers with existing operating systems. This restriction 535 drives us to a "one box" type of solution, where IPv6 can be 536 translated into IPv4 to reach the public Internet. 538 Other cases that have been mentioned include wireless ISP networks 539 and sensor networks. These bear a striking resemblance to this 540 scenario as well, if one considers the ISP network to simply be a 541 very special kind of enterprise network. 543 -------- 544 // \\ ----------- 545 / \ // \\ 546 / +----+ \ 547 | |XLAT| | 548 | The IPv4 +----+ An IPv6 | 549 | Internet +----+ Network | XLAT: IPv6/IPv4 550 | |DNS | | Translator 551 \ +----+ / DNS: DNS64 552 \ / \\ // 553 \\ // ----------- 554 -------- 555 <==== 557 Figure 1: Scenario 1 559 Both sateless [I-D.ietf-behave-v6v4-xlate] and stateful 560 [I-D.ietf-behave-v6v4-xlate-stateful] solutions can support Scenario 561 1. 563 2.2. Scenario 2: the IPv4 Internet to an IPv6 network 565 When the enterprise networks or ISP networks adopt Scenario 1, the 566 IPv6-only users will not only want to access servers on the IPv4 567 Internet but also want to setup their own servers in the network 568 which are accessable by the users on the IPv4 Internet, since the 569 majority of the Internet users are still in the IPv4 Internet. Thus, 570 with a translation solution for this scenario, the benefits would be 571 clear. Not only could servers move directly to IPv6 without trudging 572 through a difficult transition period, but they could do so without 573 risk of losing connectivity with the IPv4-only Internet. 575 -------- 576 // \\ ---------- 577 / \ // \\ 578 / +----+ \ 579 | |XLAT| | 580 | The IPv4 +----+ An IPv6 | 581 | Internet +----+ Network | XLAT: IPv4/IPv6 582 | |DNS | | Translator 583 \ +----+ / DNS: DNS46 584 \ / \\ // 585 \\ // ---------- 586 -------- 587 ====> 589 Figure 2: Scenario 2 591 In general, this scenario presents a hard case for translation. 592 Stateful translation such as NAT-PT [RFC2766] can be used in this 593 scenario, but it requires a tightly coupled DNS ALG in the translator 594 and this technique was deprecated by the IETF [RFC4966]. 596 The stateless translation solution [I-D.ietf-behave-v6v4-xlate] in 597 Scenario 1 can also work in Scenario 2, since it can support IPv4- 598 initiated communications with a subset of the IPv6 addresses (IPv4- 599 translatable addresses) in an IPv6 network. 601 2.3. Scenario 3: the IPv6 Internet to an IPv4 network 603 There is a requirement for a legacy IPv4 network to provide services 604 to IPv6 hosts. 606 ----------- 607 ---------- // \\ 608 // \\ / \ 609 / +----+ \ 610 | |XLAT| | 611 | An IPv4 +----+ The IPv6 | 612 | Network +----+ Internet | XLAT: IPv6/IPv4 613 | |DNS | | Translator 614 \ +----+ / DNS: DNS64 615 \\ // \ / 616 --------- \\ // 617 ----------- 618 <==== 620 Figure 3: Scenario 3 622 Stateless translation will not work for this scenario, because an 623 IPv4 network needs to communicate with all of the IPv6 Internet, not 624 just a small subset, and stateless can only support a subset of the 625 IPv6 addresses. However, IPv6-initiated communication can be 626 achieved through stateful translation 627 [I-D.ietf-behave-v6v4-xlate-stateful]. 629 2.4. Scenario 4: an IPv4 network to the IPv6 Internet 631 Due to technical or economical constraints, the network is IPv4-only, 632 and IPv4-only hosts (applications) may require communicating with the 633 global IPv6 Internet. 635 ----------- 636 ---------- // \\ 637 // \\ / \ 638 / +----+ \ 639 | |XLAT| | 640 | An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6 641 | Network +----+ Internet | Translator 642 | |DNS | | DNS: DNS46 643 \ +----+ / 644 \\ // \ / 645 --------- \\ // 646 ---------- 647 =====> 649 Figure 4: Scenario 4 651 In general, this scenario presents a hard case for translation. 652 Stateful translation such as NAT-PT [RFC2766] can be used in this 653 scenario, but it requires a tightly coupled DNS ALG in the translator 654 and this technique was deprecated by the IETF [RFC4966]. 656 From the transition phase discussion in Section 1.4, this scenario 657 will probably only occur when we are well past the early stage of the 658 "S" curve and the IPv4/IPv6 transition has already moved to the right 659 direction. Therefore, in-network translation is not considered 660 viable for this scenario and other techniques should be considered. 662 2.5. Scenario 5: an IPv6 network to an IPv4 network 664 In this scenario, both an IPv4 network and an IPv6 network are within 665 the same organization. 667 The IPv4 addresses used are either public IPv4 addresses or [RFC1918] 668 addresses. The IPv6 addresses used are either public IPv6 addresses 669 or ULAs (Unique Local Addresses) [RFC4193]. 671 --------- --------- 672 // \\ // \\ 673 / +----+ \ 674 | |XLAT| | 675 | An IPv4 +----+ An IPv6 | 676 | Network +----+ Network | XLAT: IPv6/IPv4 677 | |DNS | | Translator 678 \ +----+ / DNS: DNS64 679 \\ // \\ // 680 -------- --------- 681 <==== 683 Figure 5: Scenario 5 685 The translation requirement from this scenario has no significant 686 difference from scenario 1, so both the stateful and stateless 687 translation schemes discussed in Section 2.1 apply here. 689 2.6. Scenario 6: an IPv4 network to an IPv6 network 691 This is another scenario when both an IPv4 network and an IPv6 692 network are within the same organization. 694 The IPv4 addresses used are either public IPv4 addresses or [RFC1918] 695 addresses. The IPv6 addresses used are either public IPv6 addresses 696 or ULAs (Unique Local Addresses) [RFC4193]. 698 -------- --------- 699 // \\ // \\ 700 / +----+ \ 701 | |XLAT| | 702 | An IPv4 +----+ An IPv6 | 703 | Network +----+ Network | XLAT: IPv4/IPv6 704 | |DNS | | Translator 705 \ +----+ / DNS: DNS46 706 \\ // \\ // 707 -------- --------- 708 ====> 710 Figure 6: Scenario 6 712 The translation requirement from this scenario has no significant 713 difference from scenario 2, so the translation scheme discussed in 714 Section 2.2 applies here. 716 2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet 718 This seems the ideal case for in-network translation technology, 719 where any IPv6-only host or application on the global Internet can 720 initiate communication with any IPv4-only host or application on the 721 global Internet. 723 -------- --------- 724 // \\ // \\ 725 / \ / \ 726 / +----+ \ 727 | |XLAT| | 728 | The IPv4 +----+ The IPv6 | 729 | Internet +----+ Internet | XLAT: IPv6/IPv4 730 | |DNS | | Translator 731 \ +----+ / DNS: DNS64 732 \ / \ / 733 \\ // \\ // 734 -------- --------- 735 <==== 737 Figure 7: Scenario 7 739 Due to the huge difference in size between the address spaces of the 740 IPv4 Internet and the IPv6 Internet, there is no viable translation 741 technique to handle unlimited IPv6 address translation. 743 If we ever run into this scenario, fortunately, the IPv4/IPv6 744 transition has already passed the early stage of the "S" curve. 745 Therefore, there is no obvious business reason to demand a 746 translation solution as the only transition strategy. 748 2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet 750 This case is very similar to Scenario 7. The analysis and 751 conclusions for Scenario 7 also applies for this scenario. 753 -------- --------- 754 // \\ // \\ 755 / \ / \ 756 / +----+ \ 757 | |XLAT| | 758 | The IPv4 +----+ The IPv6 | 759 | Internet +----+ Internet | XLAT: IPv4/IPv6 760 | |DNS | | Translator 761 \ +----+ / DNS: DNS46 762 \ / \ / 763 \\ // \\ // 764 -------- --------- 765 ====> 767 Figure 8: Scenario 8 769 3. Framework 771 Having laid out the preferred transition model and the options for 772 implementing it (Section 1.1), defined terms (Section 1.2), 773 considered the requirements (Section 1.3), considered the transition 774 model (Section 1.4), and considered the kinds of scenarios the 775 facility would support (Section 2), we now turn to a framework for 776 IPv4/IPv6 translation. The framework contains the following 777 components: 779 o Address translation 781 o IP and ICMP translation 783 o Maintaining translation state 785 o DNS64 and DNS46 786 o ALGs for other application-layer protocols (e.g., FTP) 788 3.1. Translation Components 790 3.1.1. Address Translation 792 When IPv6/IPv4 translation is performed, we should specify how an 793 individual IPv6 address is translated to a corresponding IPv4 794 address, and vice versa, in cases where an algorithmic mapping is 795 used. This includes the choice of IPv6 prefix and the choice of 796 method by which the remainder of the IPv6 address is derived from an 797 IPv4 address [I-D.ietf-behave-address-format]. 799 Note that translating IPv4 addresses to IPv6 addresses and 800 translating IPv6 addresses to IPv4 addresses are different for 801 stateless translation and stateful translation. 803 o For stateless translation, an algorithmic mapping table is used to 804 translate IPv6 destination addresses (IPv4-converted addresses) to 805 IPv4 destination addresses in IPv6 to IPv4 direction and translate 806 IPv4 source addresses to IPv6 source addresses (IPv4-converted 807 addresses) in IPv4 to IPv6 direction. The same algorithmic 808 mapping table is used to translate IPv6 source addresses (IPv4- 809 translatable addresses) to IPv4 source addresses in IPv6 to IPv4 810 direction and translate IPv4 destination addresses to IPv6 811 destination addresses (IPv4-translatable addresses) in IPv4 to 812 IPv6 direction. In this case, blocks of service provider's IPv4 813 addresses are mapped into IPv6 and used by physical IPv6 nodes. 814 The original IPv4 form of these blocks of service provider's IPv4 815 addresses are used to represent the physical IPv6 nodes in IPv4. 816 Note that stateless translation supports both IPv6 initiated as 817 well as IPv4 initiated communications. 819 o For stateful translation, an algorithmic mapping table is used to 820 translate IPv6 destination addresses (IPv4-converted addresses) to 821 IPv4 destination addresses in IPv6 to IPv4 direction and translate 822 IPv4 source addresses to IPv6 source addresses (IPv4-converted 823 addresses) in IPv4 to IPv6 direction. A state table is used to 824 translate IPv6 source addresses to IPv4 source addresses in IPv6 825 to IPv4 direction and translate IPv4 destination addresses to IPv6 826 destination addresses in IPv4 to IPv6 direction. In this case, 827 blocks of the service provider's IPv4 addresses are maintained in 828 the translator as the IPv4 address pools and are dynamically bound 829 to specific IPv6 addresses. The original IPv4 form of these 830 blocks of service provider's IPv4 addresses is used to represent 831 the IPv6 address in IPv4. However, due to the dynamic binding, 832 stateful translation in general only supports IPv6-initiated 833 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). 842 The IP and ICMP translation document [I-D.ietf-behave-v6v4-xlate] 843 discusses header translation for both stateless and stateful modes, 844 but does not cover maintaining state in the stateful mode. In the 845 stateless mode, translation information is carried in the address 846 itself plus configuration in the translator, permitting both 847 IPv4->IPv6 and IPv6->IPv4 session establishment. In the stateful 848 mode, translation state is maintained between IPv4 address/transport 849 port tuples and IPv6 address/transport port tuples, enabling IPv6 850 systems to open sessions with IPv4 systems. The choice of 851 operational mode is made by the operator deploying the network and is 852 critical to the operation of the applications using it. 854 3.1.3. Maintaining Translation State 856 For the stateful translator, besides IP and ICMP translation, special 857 action must be taken to maintain the translation states. 858 [I-D.ietf-behave-v6v4-xlate-stateful] describes a mechanism for 859 maintaining state. 861 3.1.4. DNS64 and DNS46 863 DNS64 [I-D.ietf-behave-dns64] and possible future DNS46 documents 864 describe the mechanisms by which a DNS translator is intended to 865 operate. It is designed to operate on the basis of known address 866 translation algorithms defined in [I-D.ietf-behave-address-format] 868 There are at least two possible implementations of a DNS64 and DNS46: 870 Static records: One could literally populate DNS with corresponding 871 A and AAAA records. This mechanism works for scenarios 2, 3, 5 872 and 6. 874 Dynamic Translation of static records: In more general operation, 875 the preferred behavior is an A record to be (retrieved and) 876 translated to an AAAA record by the DNS64 if and only if no 877 reachable AAAA record exists, or for an AAAA record to be 878 (retrieved and) translated to an A record by the DNS46 if and only 879 if no reachable A record exists. 881 3.1.5. ALGs for Other Applications Layer Protocols 883 In addition, some applications require special support. An example 884 is FTP. FTP's active mode doesn't work well across NATs without 885 extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it 886 generally uses passive mode. However, the designers of FTP wrote 887 different and incompatible passive mode implementations for IPv4 and 888 IPv6 networks. Hence, either they need to fix FTP, or a translator 889 must be written for the application. Other applications may be 890 similarly broken. 892 As a general rule, a simple operational recommendation will work 893 around many application issues, which is that there should be a 894 server in each domain or an instance of the server should have an 895 interface in each domain. For example, an SMTP MTA may be confused 896 by finding an IPv6 address in its HELO when it is connected to using 897 IPv4 (or vice versa), but would work perfectly well if it had an 898 interface in both the IPv4 and IPv6 domains and was used as an 899 application-layer bridge between them. 901 3.2. Operation Mode for Specific Scenarios 903 Currently, the proposed solutions for IPv6/IPv4 translation are 904 classified into stateless translation and stateful translation. 906 3.2.1. Stateless Translation 908 For stateless translation, the translation information is carried in 909 the address itself plus configuration in the translators, permitting 910 both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless 911 translation supports end-to-end address transparency and has better 912 scalability compared with stateful translation. 913 [I-D.ietf-behave-v6v4-xlate]. 915 Although the stateless translation mechanisms typically put 916 constraints on what IPv6 addresses can be assigned to IPv6 nodes that 917 want to communicate with IPv4 destinations using an algorithmic 918 mapping. For Scenario 1 ("an IPv6 network to the IPv4 Internet"), it 919 is not a serious drawback, since the address assignment policy can be 920 applied to satisfy this requirement for the IPv6 notes that need to 921 communicate with the IPv4 Internet. In addition, stateless 922 translation supports Scenario 2 ("the IPv4 Internet to an IPv6 923 network"), which means that not only could servers move directly to 924 IPv6 without trudging through a difficult transition period, but they 925 could do so without risk of losing connectivity with the IPv4-only 926 Internet. 928 Stateless translation can be used for Scenarios 1, 2, 5 and 6, i.e., 929 it supports "an IPv6 network to the IPv4 Internet", "the IPv4 930 Internet to an IPv6 network", "an IPv6 network to an IPv4 network" 931 and "an IPv4 network to an IPv6 network". 933 -------- 934 // \\ ----------- 935 / \ // \\ 936 / +----+ \ 937 | |XLAT| | 938 | The IPv4 +----+ An IPv6 | 939 | Internet +----+ Network | XLAT: Stateless IPv4/IPv6 940 | |DNS | (address | Translator 941 \ +----+ subset) / DNS: DNS64/DNS46 942 \ / \\ // 943 \\ // ---------- 944 -------- 945 <====> 947 Figure 9: Stateless translation for Scenarios 1 and 2 949 -------- --------- 950 // \\ // \\ 951 / +----+ \ 952 | |XLAT| | 953 | An IPv4 +----+ An IPv6 | 954 | Network +----+ Network | XLAT: Stateless IPv4/IPv6 955 | |DNS | (address | Translator 956 \ +----+ subset) / DNS: DNS64/DNS46 957 \\ // \\ // 958 -------- --------- 959 <====> 961 Figure 10: Stateless translation for Scenarios 5 and 6 963 The implementation of the stateless translator needs to refer to 964 [I-D.ietf-behave-v6v4-xlate], and [I-D.ietf-behave-address-format]. 966 3.2.2. Stateful Translation 968 For stateful translation, the translation state is maintained between 969 IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 970 systems to open sessions with IPv4 systems 971 [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful]. 973 Stateful translator can be used for Scenarios 1, 3 and 5, i.e., it 974 supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet 975 to an IPv4 network" and "an IPv6 network to an IPv4 network". 977 For Scenario 1, any IPv6 addresses in an IPv6 network can use 978 stateful translation, however it typically only supports initiation 979 from the IPv6 side itdoesn't support IPv4-initiation, and does not 980 result in stable addresses of IPv6 nodes that can be used in DNS, 981 other protocols and applications that do not deal well with highly 982 dynamic addresses. 984 -------- 985 // \\ ----------- 986 / \ // \\ 987 / +----+ \ 988 | |XLAT| | 989 | The IPv4 +----+ An IPv6 | 990 | Internet +----+ Network | XLAT: Stateful IPv4/IPv6 991 | |DNS | | Translator 992 \ +----+ / DNS: DNS64 993 \ / \\ // 994 \\ // ----------- 995 -------- 996 <==== 998 Figure 11: Stateful translation for Scenario 1 1000 For scenario 3, the servers using IPv4 private addresses [RFC1918] 1001 and being reached from the IPv6 Internet basically includes the cases 1002 that for whatever reason the servers cannot be upgraded to IPv6 and 1003 they don't have public IPv4 addresses and it would be useful to allow 1004 IPv6 nodes in the IPv6 Internet to reach those servers. 1006 ----------- 1007 ---------- // \\ 1008 // \\ / \ 1009 / +----+ \ 1010 | |XLAT| | 1011 | An IPv4 +----+ The IPv6 | 1012 | Network +----+ Internet | XLAT: Stateful IPv4/IPv6 1013 | |DNS | | Translator 1014 \ +----+ / DNS: DNS64 1015 \\ // \ / 1016 --------- \\ // 1017 ----------- 1018 <==== 1020 Figure 12: Stateful translation for Scenario 3 1022 Similarly, stateful translation can also be used for Scenario 5. 1024 -------- --------- 1025 // \\ // \\ 1026 / +----+ \ 1027 | |XLAT| | 1028 | An IPv4 +----+ An IPv6 | 1029 | Network +----+ Network | XLAT: Stateful IPv4/IPv6 1030 | |DNS | | Translator 1031 \ +----+ / DNS: DNS64 1032 \\ // \\ // 1033 -------- --------- 1034 <==== 1036 Figure 13: Stateful translation for Scenario 5 1038 The implementation of the stateful translator needs to refer to 1039 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 1040 and [I-D.ietf-behave-address-format]. 1042 3.3. Layout of the Related Documents 1044 Based on the above analysis, the IPv4/IPv6 translation series 1045 consists of the following documents. 1047 o Framework for IPv4/IPv6 Translation (this document). 1049 o Address translation (the choice of IPv6 prefix and the choice of 1050 method by which the remainder of the IPv6 address is derived from 1051 an IPv4 address, part of the SIIT update) 1052 [I-D.ietf-behave-address-format]. 1054 o IP and ICMP Translation (header translation and ICMP handling, 1055 part of the SIIT update) [I-D.ietf-behave-v6v4-xlate]. 1057 o Xlate-stateful (stateful translation including session database 1058 and mapping table handing) [I-D.ietf-behave-v6v4-xlate-stateful]. 1060 o DNS64 (DNS64: A to AAAA mapping and DNSSec discussion) 1061 [I-D.ietf-behave-dns64]. 1063 o DNS46 (AAAA to A mapping and DNSSec discussion) 1064 [I-D.xli-behave-dns46-for-stateless]. 1066 o FTP ALG [I-D.ietf-behave-ftp64]. 1068 o Others (Multicast, etc). 1070 The relationship among these documents is shown in the following 1071 figure. 1073 ----------------------------------------- 1074 | Framework for IPv4/IPv6 Translation | 1075 ----------------------------------------- 1076 || || 1077 ------------------------------------------------------------------- 1078 | || stateless and stateful || | 1079 | -------------------- --------------------- | 1080 | |Address Translation | <======== | IP/ICMP Translation | | 1081 | -------------------- --------------------- | 1082 | /\ /\ | 1083 | || ------------------||------------ | 1084 | || | stateful \/ | 1085 | ----------------- | --------------------- | 1086 | | DNS64/DNS46 | | | Table Maintenance | | 1087 | ----------------- | --------------------- | 1088 ------------------------------------------------------------------- 1089 /\ /\ 1090 || || 1091 ----------------- -------------------- 1092 | FTP ALG | | Others | 1093 ----------------- -------------------- 1094 Figure 14: Document Layout 1096 In the document layout, the IP/ICMP Translation and DNS64/DNS46 1097 normatively refer to Address Translation. The Table Maintenance and 1098 IP/ICMP Translation normatively refer to each other. 1100 The FTP ALG and other documents normatively refer to the Address 1101 Format, IP/ICMP Translation and Table Maintenance documents. 1103 4. Translation in Operation 1105 Operationally, there are two ways that translation could be used - as 1106 a permanent solution making transition "the other guy's problem", and 1107 as a temporary solution for a new part of one's network while 1108 bringing up IPv6 services in the remaining parts of one's network. 1109 We obviously recommend the latter at the present stage. For the IPv4 1110 parts of the network, [RFC4213]'s recommendation holds: bringing IPv6 1111 up in those domains, moving production to it, and then taking down 1112 the now-unnecessary IPv4 service when economics warrant remains the 1113 least risk approach to transition. 1115 ---------------------- 1116 ////// \\\\\\ 1117 /// IPv4 or Dual Stack \\\ 1118 || +----+ Routing +-----+ || 1119 | |IPv4| |IPv4+| | 1120 | |Host| |IPv6 | | 1121 || +----+ |Host | || 1122 \\\ +-----+ /// 1123 \\\\\----+----+-+-----+ +----+-///// 1124 |XLAT|-|DNS64|-|FTP | 1125 | |-|DNS46|-|ALG | 1126 /////----+----+ +-----+ +----+-\\\\\ 1127 /// \\\ 1128 || +-----+ +----+ || 1129 | |IPv4+| |IPv6| | 1130 | |IPv6 | |Host| | 1131 || |Host | +----+ || 1132 \\\ +-----+ IPv6-only Routing /// 1133 \\\\\\ ////// 1134 ---------------------- 1136 Figure 15: Translation Operational Model 1138 During the coexistence phase, as shown in Figure 15, one expects a 1139 combination of hosts - IPv6-only gaming devices and handsets, older 1140 computer operating systems that are IPv4-only, and modern mainline 1141 operating systems that support both, as well as a combination of 1142 applications including ones that are IPv4-only and modern 1143 applications that support both. One also expects a combination of 1144 networks - dual-stack devices operating in single-stack networks are 1145 effectively single-stack, whether that stack is IPv4 or IPv6, as the 1146 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 IPv4 address sharing for the stateless 1154 translation. 1156 6. IANA Considerations 1158 This memo requires no parameter assignment by the IANA. 1160 Note to RFC Editor: This section will have served its purpose if it 1161 correctly tells IANA that no new assignments or registries are 1162 required, or if those assignments or registries are created during 1163 the RFC publication process. From the author's perspective, it may 1164 therefore be removed upon publication as an RFC at the RFC Editor's 1165 discretion. 1167 7. Security Considerations 1169 This document is the framework of IPv4/IPv6 translation. The 1170 security issues are addressed in individual IPv4/IPv6 translation 1171 documents, i.e. [I-D.ietf-behave-address-format], 1172 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 1173 [I-D.ietf-behave-dns64], [I-D.xli-behave-dns46-for-stateless] and 1174 [I-D.ietf-behave-ftp64]. 1176 8. Acknowledgements 1178 This is under development by a large group of people. Those who have 1179 posted to the list during the discussion include Andrew Sullivan, 1180 Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, 1181 Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, Iljitsch van 1182 Beijnum, John Schnizlein, Magnus Westerlund, Marcelo Bagnulo Braun, 1183 Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, 1184 Remi Denis-Courmont and Remi Despres. 1186 Ed Jankiewicz described the transition plan. 1188 9. References 1190 9.1. Normative References 1192 [I-D.ietf-behave-address-format] 1193 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1194 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1195 draft-ietf-behave-address-format-04 (work in progress), 1196 January 2010. 1198 [I-D.ietf-behave-dns64] 1199 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1200 "DNS64: DNS extensions for Network Address Translation 1201 from IPv6 Clients to IPv4 Servers", 1202 draft-ietf-behave-dns64-05 (work in progress), 1203 December 2009. 1205 [I-D.ietf-behave-ftp64] 1206 Beijnum, I., "IPv6-to-IPv4 translation FTP 1207 considerations", draft-ietf-behave-ftp64-00 (work in 1208 progress), December 2009. 1210 [I-D.ietf-behave-v6v4-xlate] 1211 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1212 Algorithm", draft-ietf-behave-v6v4-xlate-06 (work in 1213 progress), January 2010. 1215 [I-D.ietf-behave-v6v4-xlate-stateful] 1216 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1217 NAT64: Network Address and Protocol Translation from IPv6 1218 Clients to IPv4 Servers", 1219 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 1220 progress), January 2010. 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, March 1997. 1225 9.2. Informative References 1227 [I-D.bagnulo-behave-nat64] 1228 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 1229 Address and Protocol Translation from IPv6 Clients to IPv4 1230 Servers", draft-bagnulo-behave-nat64-03 (work in 1231 progress), March 2009. 1233 [I-D.durand-softwire-dual-stack-lite] 1234 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 1235 "Dual-stack lite broadband deployments post IPv4 1236 exhaustion", draft-durand-softwire-dual-stack-lite-01 1237 (work in progress), November 2008. 1239 [I-D.venaas-behave-mcast46] 1240 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 1241 IPv4 - IPv6 multicast translator", 1242 draft-venaas-behave-mcast46-01 (work in progress), 1243 July 2009. 1245 [I-D.xli-behave-dns46-for-stateless] 1246 Li, X. and C. Bao, "DNS46 for the IPv4/IPv6 Stateless 1247 Translator", draft-xli-behave-dns46-for-stateless-00 (work 1248 in progress), October 2009. 1250 [I-D.xli-behave-ivi] 1251 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1252 CERNET IVI Translation Design and Deployment for the IPv4/ 1253 IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 1254 (work in progress), January 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 1319 Xing Li 1320 CERNET Center/Tsinghua University 1321 Room 225, Main Building, Tsinghua University 1322 Beijing, 100084 1323 China 1325 Phone: +86 10-62785983 1326 Email: xing@cernet.edu.cn 1328 Congxiao Bao 1329 CERNET Center/Tsinghua University 1330 Room 225, Main Building, Tsinghua University 1331 Beijing, 100084 1332 China 1334 Phone: +86 10-62785983 1335 Email: congxiao@cernet.edu.cn 1337 Kevin Yin 1338 Cisco Systems 1339 No. 2 Jianguomenwai Ave, Chaoyang District 1340 Beijing, 100022 1341 China 1343 Phone: +86-10-8515-5094 1344 Email: kyin@cisco.com