RFC 6180

Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment

📅 published May 2011, from ietf

RFC 6180 🎀 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment

Authors: J. Arkko (Ericsson) and F. Baker (Cisco Systems) 👩‍💻

Category: Informational 🌸

ISSN: 2070-1721

Date: May 2011 📅

Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙅‍♀️

Abstract ✨

okay so the internet keeps growing past what IPv4 can handle 😭 we need more address space, like, yesterday. IPv6 brings more prefixes and more addresses in each subnet, plus better address management, so it's basically the only real option on the table 💅 but deploying it takes some effort, resources, and expertise 🧠 part of the reason is that there are lots of different deployment models to pick from. This document talks through those models and the migration tools, and it recommends the ones that have worked well in real operational networks in common situations 🦋

Status of This Memo 🫶

this document is not an Internet Standards Track specification 🙅‍♀️ it's published for informational purposes, so it's more of a "here's what we learned" vibe than a rulebook.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🌈 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🤓

for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6180 🔗

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at http://trustee.ietf.org/license-info. those rules were in effect on the date this was published, so give them a careful read because they spell out your rights and restrictions for this document 📜

if you pull Code Components out of this document, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🧚

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Principles . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.2.  Choosing a Deployment Model  . . . . . . . . . . . . . . .  6
4.  Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . .  7
  4.1.  Native Dual Stack  . . . . . . . . . . . . . . . . . . . .  8
  4.2.  Crossing IPv4 Islands  . . . . . . . . . . . . . . . . . . 10
  4.3.  IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
  4.4.  IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.  Further Reading  . . . . . . . . . . . . . . . . . . . . . . . 15
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 20

1. Introduction 🌸

okay bestie, the internet keeps outgrowing IPv4 🥺 all that success has stretched the IPv4 address space way too thin, and it isn't enough for future growth anymore. when this was written, in August 2010, the IANA "free pool" had only 14 unallocated unicast IPv4 /8 prefixes left 😬 credible estimates based on past behavior say the Regional Internet Registries (RIRs) will run out of their remaining space by early 2012, unless a market in IPv4 address space shows up first. so yeah, an expansion in the address space is clearly required, and with more prefixes and addresses per subnet plus better address management, IPv6 is the only real option on the table 💅

John Curran's "An Internet Transition Plan" [RFC5211] gives estimated dates for the big milestones in the transition 📆 the tail end will probably be long, but it's clear that deployment is a present reality and a requirement, not a someday thing 🫶

so lots of organizations have already used IPv6 or are planning to use it in their networks ✨ deploying it still takes effort, resources, and expertise, but honestly this is mostly just part of maintaining and evolving a network. changing requirements get folded into normal planning, procurement, and update cycles 🔄 and very large networks have adopted IPv6 alongside IPv4 with surprisingly little effort, which is iconic 👑

that said, making the transition successfully does need some new expertise 🧠 you'll need different kinds of experience: a basic understanding of IPv6 mechanisms, debugging tools, product capabilities and caveats when you use IPv6, and so on 🔍 the number of IPv6 deployment models and tools is another reason expertise matters. these models and tools were developed over the years at the IETF, some for specific circumstances and others for more general use. they differ a lot in their principles of operation, and views about the best ways to use them have changed over time 🌈 with so many options, network managers are understandably confused 😵‍💫 so they need guidance on recommended approaches to IPv6 deployment, and that's what this doc is for 🎀

the rest of the document is laid out like this: Section 2 introduces some terminology 📖 Section 3 talks about the general principles behind choosing particular deployment models and tools 🧭 Section 4 goes through the recommended deployment models for common situations 🗺️ and Section 5 wraps up with some concluding remarks about choosing between these models 🦋

many networks can follow one of the four scenarios described in this document 🙌 but the details will vary, and there will be questions, like which tunneling solution to pick, that have no "one size fits all" answer 🙈 network managers each have to take responsibility for choosing the best solution for their own case. this document doesn't try to cover every possible networking situation 🤷‍♀️ also, a systematic operational plan for the transition is required, but the details depend entirely on the individual network 📋

2. Terminology 📚

in this document, these terms are used:

  • IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663]. 🔁
  • Dual Stack: refers to a technique for providing complete support for both Internet protocols, IPv4 and IPv6, in hosts and routers [RFC4213]. 💜
  • Dual Stack Lite: also called "DS-Lite", refers to a technique that uses tunneling and IPv4/IPv4 NAT to provide IPv4 connectivity over IPv6 networks [DS-lite]. 🚇
  • IPv4-only domain: as defined in [RFC6144], this is a routing domain where applications can only use IPv4 to communicate, whether because of host limitations, application limitations, or network limitations. 🌐
  • IPv6-only domain: as defined in [RFC6144], this is a routing domain where applications can only use IPv6 to communicate, whether because of host limitations, application limitations, or network limitations. 🌐
  • NAT-PT: refers to a specific, old design of a Network Address Translator - Protocol Translator defined in [RFC2766], which got deprecated for the reasons stated in [RFC4966]. 🪦

3. Principles 🧭

the primary goal is to help the networking industry keep growing and get Internet technology deployed at relatively low capital and operational expense, without destabilizing deployed services or hurting the customer experience 💖 this is at risk with IPv4 because of the address runout. economics teaches us that when a finite resource gets stressed, it becomes expensive, either in the actual cost of the resource or in the complexity of the technology and processes needed to manage it 😩 it's also at risk while IPv4 and IPv6 are both deployed in parallel, because running two technologies costs more than running one 💸

so, since IPv4 clearly won't scale to meet our insatiable requirements 🔥 the primary technical goals are global deployment of IPv6 in the network, in its service infrastructure, and by applications. that would end the requirement to deploy two IP versions and make the transitional mechanisms obsolete 🦋 the temporary goals that support this focus on enabling parts of the Internet to use IPv6 and turn off IPv4 before the entire Internet has done the same 🌈

more soon, bestie! 🫶 this is part 1 of 5 💜

3.1. Goals ✨

okay so the end goal is native IPv6 everywhere 💖 that means the transition tools based on encapsulation, tunnels, or translation eventually become obsolete, and IPv4 does too 🦋 the transition tools are basically just a way to make life easier for network admins while everyone gets there.

BUT (and this is important bestie 🫶) every network has different goals, constraints, and opportunities, so there is no single right model for IPv6 deployment. It's like how there's no one perfect model for IPv4 network design either 🌸 we can still give some guidelines though! Common models that work well are covered in Section 4, and the small set of standardized IETF migration tools supports those models. First, it's useful to talk about some general principles that shape what a good deployment model looks like 🎀

Starting the deployment in a timely manner matters a lot ⭐ most of the work is practical stuff like network audits, picking components, network management, planning, and implementation. At the time of writing, that's reasonably easy to achieve. There's no real advantage to avoiding IPv6 as part of your normal network planning cycle 💅 the migration tools already exist, and even though new features keep getting developed, they're not expected to radically change what networks have to do. So honestly? There's no point in waiting for an improved design 😭

There are only a few exceptional networks where coexistence with IPv4 isn't a consideration at all 🧚 these are usually new deployments, tightly controlled by a central authority, with no need to deal with legacy devices. For example, specialized machine-to-machine networks that only talk to designated servers, like Smart Grids, can easily be IPv6-only 💜 Mobile telephone network operators, especially those using 3GPP (Third Generation Partnership Project), have seriously considered IPv6-only operation, and some have actually deployed it 👑 Research networks that can be separated from the IPv4 Internet to find out what happens are also a candidate 🔥 In most other networks though, IPv4 has to be considered. A typical requirement is that older, IPv4-only applications, systems, or services must be accommodated. Most networks that cross administrative boundaries or allow end-user equipment have requirements like this 🙈 Even when a network only has new, IPv6-capable devices, it's typically required that those devices can still communicate with the IPv4 Internet. Main character energy? Not even close, IPv4 is still in the chat 💀

It's expected that after a period of supporting both IPv4 and IPv6, IPv4 can eventually be turned off ✨ but this should happen gradually 🌈 For instance, a service provider network might stop providing IPv4 service inside its own network, while still letting its IPv6 customers reach the rest of the IPv4 Internet through overlay, proxy, or translation services. Regardless of progress with IPv6, it's widely expected that some legacy applications and some networks will keep running only over IPv4 for many years 🍓 So every deployment scenario needs to deal with this reality, periodt 💅

Heads up: IPv4 is not leaving the group chat anytime soon, so every plan has to account for it 💖

3.2. Choosing a Deployment Model 🦋

okay the first requirement is that the model or tool actually lets communications flow and lets services get delivered to customers without any perceived degradation 💖 I know, it sounds too obvious to even say out loud, but it's sometimes not easy to make sure a proposed model doesn't have failure modes related to supporting older devices, for instance 😭 A network that isn't serving all of its users isn't doing its job, full stop.

Being able to communicate is way more important than fine-grained performance differences ✨ Honestly, it's not productive to obsess over optimizing a design that's meant to be temporary, and a migration solution necessarily is. So existing tools are often preferred over new ones, even if for some specific situation it would be possible to build a slightly more efficient design 🎀

Similarly, migration tools that can be thrown away after a period of coexistence are preferred over tools that need more permanent changes 🌸 Those permanent changes can keep costing you even after the transition to IPv6 is done, and nobody wants that bill 💸

Looking back at how Internet technology got deployed, some of the factors described in [RFC5218] and [Baker.Shanghai] that have been important for success include:

  • The ability to offer a valuable service. For the Internet, connectivity has been this service 💜
  • The ability to deploy the solution in an incremental fashion. 🧚
  • Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols 🍓
  • Openly available implementations. These make it easier for researchers, start-ups, and others to build on or improve existing components 🔥
  • The ability to scale. The IPv4 Internet grew way bigger than its original designers expected, and scaling limits only became apparent 20-30 years later 😭
  • The design supports robust interoperability rather than mere correctness. This matters so the solution works in different circumstances and in an imperfectly controlled world 👑

Similar factors are also important when choosing IPv6 migration tools 💅 Success factors should be evaluated in the context of a migration solution. For instance, incremental deployability and a lack of dependencies on components that are under someone else's control are key factors 🫶

It's also essential that any chosen designs let the network be maintained, serviced, diagnosed, and measured ✨ The ability to keep running under many different circumstances and surprising conditions is a key thing, and any large network that uses brittle components will rack up serious support costs 💀

A properly executed IPv6 deployment normally involves a step-wise approach, where individual functions or parts of the network get updated at different times 🌈 For instance, IPv6 connectivity has to be established and tested before DNS entries with IPv6 addresses can be provisioned. Or, specific services can be moved to support IPv6 earlier than others 🦋 In general, most deployment models use a very similar network architecture for both IPv4 and IPv6. The principle of changing only the minimum amount necessary is applied here 🎀 As a result, some features of IPv6, like the ability to have an effectively unlimited number of hosts on a subnet, may not be available in the short term. Patience, bestie 🌸

4. Guidelines for IPv6 Deployment ✨

okay this section is where we get into the actual scenarios 💖 It presents a number of common situations along with recommended deployment tools for each one. We start with the most obvious case, where native connectivity is available and both IP versions are used 🦋 Since native IPv6 connectivity isn't available in every network, our second scenario looks at ways of arranging that connectivity over the IPv4 Internet 🎀 The third scenario is more advanced: it looks at a service provider network that runs only on IPv6 but is still capable of providing both IPv6 and IPv4 services 👑 The fourth and most advanced scenario focuses on translation, at either the application or the network layer 🔥

Quick note: there are lots of other possible deployment models, and existing specifications that support them 🧚 Those other models aren't necessarily frowned upon 💅 However, they aren't expected to be the mainstream deployment models, so the associated specifications typically aren't IETF Standards Track RFCs. Network managers should not adopt these non-mainstream models lightly though, because there's little guarantee that they work well 😬 There are also models that are believed to be problematic. An older model of IPv6-IPv4 translation (NAT-PT) [RFC2766] suffers from a number of drawbacks, arising from, for example, its attempt to capture DNS queries on path [RFC4966] 💀 Another example, about the preference to employ tunneling instead of double translation, will be discussed later in this document 🙈

4.1. Native Dual Stack ✨

okay so the simplest deployment model is dual stack 💖 you just turn on IPv6 across your existing IPv4 network and let apps using the two protocols vibe side by side like ships in the night 🚢 this works for basically any network: home, enterprise, service provider, or content provider 🏠

the whole point here is to support any kind of device and communication, and to make it an end-to-end choice which IP version gets used between the peers 🦋 there are minimal assumptions about what the hosts in these networks can do or how they're configured. native connectivity skips the drama of tunnel setup and Maximum Transmission Unit (MTU) settings 🙈 so these networks end up being robust and reliable, which is why this is the recommended deployment model for most networks 🫶 it's backed by IETF standards like dual stack [RFC4213] and address selection [RFC3484]. ngl there are still some remaining challenges, but lots of service providers and network managers prefer this model too [RFC6036] [IPv6-only-experience] 💅

the challenges with this model are twofold, bestie 🌸 first, dual stack lets each network deploy IPv6 on its own, but actual use still needs everyone between the peers to participate 😭 the peer has to be reachable over IPv6, have its own IPv6 address, and advertise that address in the relevant naming service (like the DNS). this can lead to a situation where IPv6 is turned on in a network but there's barely any real traffic 💀 one direct way to fix that is making sure the major traffic destinations are ready to receive IPv6 traffic. current Internet traffic is super concentrated on a handful of content provider networks, so changing even a small number of them can have big effects 🔥 this got noticed when YouTube started supporting IPv6 [networkworld.youtube]. there are scenarios where these means aren't enough, so the next sections talk about deployment models that let parts of the network adopt IPv6 faster than other parts 🧚

the second challenge is that not every application handles it gracefully when one of the alternative destination addresses works unreliably 😬 like, if IPv6 connectivity is flaky, some apps can take a really long time to switch over to IPv4. so lots of content providers are shying away from advertising IPv6 addresses in DNS, and that makes the first challenge worse 💜 long term, modern application toolkits and APIs solve this problem. in the short term, some content providers and user network managers have made mutual agreements to resolve names to IPv6 addresses. these agreements work like peering agreements and many content providers have seen them as necessary 🤝 these "whitelisting" practices have some downsides though, because they create a dependency on an external party for moving traffic to IPv6 🙃 still, there are many types of traffic on the Internet, and only some of it needs that careful coordination. popular peer-to-peer systems can automatically and reliably use IPv6 connectivity where it's available, for instance ✨

even with all that, the native dual-stack connectivity model is still the recommended approach 👑 it's responsible for a big chunk of the worldwide IPv6 deployment progress so far. the largest IPv6 networks, like national research and education networks, Internet II, RENATER, and others, use this approach 🌈

the original plan for dual stack was to deploy both IP versions side by side before IPv4 addresses ran out. as we all know, that never happened, so deployment now has to happen with limited IPv4 addresses 😩 using dual stack together with a traditional IPv4 address translator (IPv4/IPv4 NAT) is a super common setup 🎀 if the address translator is acceptable for the network from a pure IPv4 perspective, this model can be recommended from a dual-stack perspective too. the IPv6 advantage here is that it allows direct addressing of specific nodes in the network, which is a contrast to translated IPv4 service, as noted in [RFC2993] and [shared-addressing-issues]. so it allows building IPv6-based applications with more functionality 🦋

there may also be situations where a traditional IPv4 address translator isn't enough anymore 🥺 for example, in typical residential networks each subscriber gets one global IPv4 address, and the subscriber's IPv4/IPv4 NAT device may use that address with as many devices as it can handle. as IPv4 address space gets more constrained, and without substantial movement to IPv6, service providers are expected to be pressured into assigning a single global IPv4 address to multiple subscribers. honestly, in some deployments this is already happening 😭 the dual-stack model still applies in these networks, but the IPv4/IPv4 Network Address Transition (NAT) functionality may need to be relocated and enhanced 🔧 on some networks it's possible to use overlapping private address space [L2-NAT] [DS-extra-lite]. other networks may need a combo of IPv4/IPv4 NAT enhancements and tunneling. these scenarios get more detail in Section 4.3 💖

4.2. Crossing IPv4 Islands 🏝️

native IPv6 connectivity isn't always available, but luckily it can be established using tunnels 🚇 tunneling adds some extra complexity, and it also makes it more likely that the Path MTU algorithm gets used, since lots of implementations derive their default MTU from the Ethernet frame size. ICMP filtering interacts poorly with the Path MTU algorithm in [RFC1981] 😵‍💫 but the benefit is that tunneling decouples addressing inside and outside the tunnel, so it's easy to deploy IPv6 without having to modify routers along the path 🙌 tunneling should be used when native connectivity can't be established, like when you're crossing another administrative domain or a router that can't be easily reconfigured.

there are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], the use of Virtual Private Networks (VPNs) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844], and many others 🧩 more advanced solutions provide a mesh-based framework of tunnels [RFC5565] 🕸️

on a managed network, there aren't major challenges with tunneling beyond the possible configuration and MTU problems. tunneling is very widely deployed, both for IPv6 connectivity and for other reasons, and it's well understood 📚 in general, the IETF recommends that tunneling be used if it's necessary to cross a segment of IP version X when communicating from IP version Y to Y. an alternative design would be to use protocol translation twice. however, that design has problems similar to the ones created by IPv4 address translation, and it's largely untried technology at any larger scale 🫠

on an unmanaged network, though, there have been a bunch of problems 😤 in general, solutions aimed at early adopters (like 6to4) have sometimes made IPv6 connectivity look available on a network when there's actually no connectivity. this in turn has led content providers to serve IPv6 results for DNS queries only to trusted peers with known high-quality connectivity 🥀

the IPv6 Rapid Deployment (6RD) [RFC5969] approach is a newer version of the 6to4 tunneling solution that doesn't have those drawbacks, and it's giving glow-up 🌟 it offers systematic IPv6 tunneling over IPv4 across an ISP, correspondence between IPv4 and IPv6 routing, and it can be deployed within an ISP without needing to rely on other parties 👑

4.3. IPv6-Only Core Network 💜

an emerging deployment model uses IPv6 as the dominant protocol at a service provider network, and tunnels IPv4 through this network in a way that's the converse of the one from the previous section 🔄 there are several motivations for choosing this model:

  • there may not be enough public or private IPv4 addresses to support network management functions in an end-to-end fashion, without segmenting the network into small parts with overlapping address space 😩
  • IPv4 address sharing among subscribers may involve new address translation nodes within the service provider's network. IPv6 can be used to reach these nodes. normal IPv4 routing isn't enough for this purpose, since the same addresses would be used in several parts of the network 🗺️
  • it may be simpler for the service provider to employ a single-version network 🧁

the recommended tool for this model is Dual Stack Lite [DS-lite] 🎀 Dual Stack Lite both provides relief for the IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6 ✨ given the IPv6 connectivity that Dual Stack Lite runs over, it becomes easy to provide IPv6 connectivity all the way to the end users as well 💖

4.4. IPv6-Only Deployment 🦋

Okay bestie, this last deployment model is the spicy one 🌶️ It breaks the rule that everybody has to upgrade to IPv6 before any end-to-end communication can use IPv6. It only makes sense when both of these are true:

  • There is a fact or requirement that there be an IPv4-only domain and an IPv6-only domain.
  • There is a requirement that hosts in the IPv4-only domain access servers or peers in the IPv6-only domain, and vice versa.

It's giving corporate or mobile network, honestly. Picture a network that runs IPv6-only, but the users still want to reach content on the IPv4 Internet 👀

When we say "IPv4-only" or "IPv6-only," we mean the applications can only talk over IPv4 or only over IPv6 🫶 That could be because the applications, host stacks, or the network can't do the other one. Different reasons, same result. Why would someone switch to an IPv6-only network? Maybe they want to test that setup, or maybe they just want a simpler network ✨ The document expects the second reason to get more common as IPv6 deployment keeps going, which is so relatable. One especially big reason to look at an IPv6-only domain is overlapping private address space messing with applications 😭 This comes up in networks that have run out of both public and private IPv4 addresses, where setting up an IPv6-only network is easier than dealing with overlapping addresses inside the apps.

Now the catch 💅 An IPv6-only domain only works if every device is actually IPv6 capable. In today's mixed networks with legacy devices, that can't always be guaranteed. It can be arranged, though, in networks where a central authority controls all the devices. Like, a brand-new corporate network can make sure the latest device versions are in use. Some networks can also be built to offer different services on top of one underlying network, so they can do IPv6-only more easily. A cellular network, for example, might offer IPv4-only connectivity for the existing installed base of devices and IPv6-only connectivity for newer IPv6-capable handsets as they grow. A broadband ISP might offer dual-stack connectivity to customers who need both IPv4 and IPv6, and IPv6-only plus NAT64 service to everyone else. With 3GPP and DOCSIS 3.0 access networks, the access network architecture lets operators run different services in parallel to suit both the customer and the network operator 🌈

The network operator also needs some understanding of which applications are being used on the network 🧚 That way they can make sure any communication exchange is predictable, able to use IPv6, and translatable. If all that checks out, full interoperability can be expected. This has been shown to work with some mobile devices, for example. Also, the requirements on applications here are similar to the ones in networks that use IPv4 NAT technology.

There's one obvious IPv6-only approach for applications that include proxies or relays 🎀 You could put a web proxy, a mail server, or a SIP (Session Initiation Protocol) and media stream back-to-back user agent right across the boundary between the IPv4 and IPv6 domains. That way the application ends IPv4 sessions on one side and IPv6 sessions on the other. This keeps the communication end-to-end from the gateway all the way to the peer, which is a huge win. For obvious reasons, this solution is preferred over putting Application Layer Gateways inside network-layer translators.

The other approach is network-layer IPv4/IPv6 translation, described in "IPv4/IPv6 Translation" [RFC6144] [RFC6145] [RFC6146] [RFC6052] [RFC6147] [FTP64]. Network-layer translation is pretty similar to IPv4/IPv4 translation, with similar pros and cons 💜 It lets a network give IPv6-only hosts two kinds of service:

  • a relatively small set of systems may be configured with IPv4-mapped addresses, enabling stateless interoperation between IPv4-only and IPv6-only domains, each of which can use the other as peers or servers, and
  • a larger set of systems with global IPv6 addresses, which can access IPv4 servers using stateful translation but which are inaccessible as peers or servers from the IPv4-only domain.

The first service is used today in some university networks, and the second one shows up in some corporate and mobile networks. The stateless service is naturally better suited for servers, while the stateful service is better for large numbers of client devices. The second one usually shows up in a public network access setting. You can totally use both services together too 🍓 In this setup, network-layer translation gives straightforward service for most applications that cross the IPv4-only/IPv6-only boundary.

There are some challenges here, though 😤 The first is that as long as IPv4 addresses are still shared, you'll get problems similar to the ones caused by IPv4 NATs [shared-addressing-issues]. The second is about IPv4 referrals. IPv4-literals inside certain protocols and formats, like HTML, will fail when they get passed to IPv6-only hosts. That's because the host doesn't have an IPv4 address to source IPv4 communications from, or an IPv4 route. Measurements on the public Internet show that literals show up in a tiny but measurable part of web pages [IPv6-only-experience], though whether that's actually a practical problem is debatable 🤷‍♀️ If it is a particular problem for the applications you're running, you could change the proxy configurations to send that traffic through a proxy, modify hosts so they understand how to map IPv4-literals to IPv6 addresses, or just use native dual stack instead.

5. Conclusions 👑

The big fundamental recommendation? Turn on IPv6 🔥 Section 4 covered four deployment models to do that, listed in rough order of how common they are in the world at the time of writing. The first two are the most widely deployed today. All four models are recommended by the IETF, though again, the first two should take priority wherever they apply.

As noted in Section 1, details vary, and network managers are ultimately in charge of picking the best solution for their own situation 💖 The benefits and challenges from the previous sections should be considered when weighing deployment options. The transition mechanisms operators have deployed have been a mixed blessing ngl 😭 Native dual-stack deployments aren't used to their full extent if peers haven't upgraded, tunnel mechanisms that don't follow the routing of the underlying network have been problematic, and translation has its faults too. Even so, operators have successfully deployed very large networks with these models ✨

Here are some extra considerations 🌸

  • There's a tradeoff between being able to connect as many different types of devices as possible and being able to move forward with deployment as independently as possible. For example, native dual stack gives the best connectivity but needs updates on peer systems before actual traffic flows over IPv6. On the flip side, IPv6-only networks are very sensitive to what kinds of devices they can support, but they can be deployed without expecting any updates on peer systems.
  • "Greenfield" networks and networks with existing IPv4 devices and users need to be treated differently. For the latter, turning on IPv6 in addition to IPv4 seems like the rational choice. For the former, an IPv6-only model may make sense.
  • The right deployment model choices also change as time goes by 🧚 For example, a tunneling solution that makes sense today may become a native dual-stack solution as the network and its devices evolve. Or an IPv6-only network becomes feasible once a sufficient fraction of client devices are IPv6-enabled.

No matter which deployment model you pick, a lot of the important IPv6 implications live elsewhere in the network 🦋 IPv6 needs to be taken into account in network management systems and operations, address assignments, service agreements, firewalls, intrusion detection systems, and so on.

6. Further Reading 📚

Several documents cover different aspects of IPv6 deployment 💜 Of particular interest might be the basic dual-stack definition [RFC4213], application aspects [RFC4038], deployment in Internet service provider networks [RFC4029] [RFC6036], deployment in enterprise networks [RFC4057] [RFC4852], IPv6-only deployment [IPv6-only-experience], and considerations for specific access networks, like cellular networks [RFC3314] [RFC3574] [RFC4215] [v6-in-mobile] or 802.16 networks [RFC5181].

This document gives general guidance on IPv6 deployment models that have been found suitable for most organizations. It is not meant to list every special circumstance that might call for a different deployment model, or to go into the details of the necessary transition tools. A lot of the special cases and details are covered in the documents above 🫶

7. Security Considerations 🔐

Okay, security time, and I need you to take this seriously 😤 There are detailed differences between the security properties and vulnerabilities of IPv4 and IPv6, but in general they give a very similar level of security and face the same threats. With both protocols, specific security issues are more likely to show up at the practical level than in the specifications 💀 The practical issues include things like bugs, or the security mechanisms available on a given product. When you deploy IPv6, it's important to make sure the necessary security capabilities exist on the network components even when they're handling IPv6 traffic. For example, firewall capabilities have often been a challenge in IPv6 deployments.

This document has no impact on the security properties of specific IPv6 transition tools. The security considerations for those tools are described in the relevant documents, for instance, [RFC4213], [RFC6147], [DS-lite], and [RFC6169].

8. References 📖

8.1. Normative References

[RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
           Translator (NAT) Terminology and Considerations",
           RFC 2663, August 1999.

[RFC3484]  Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
           for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, December 2005.

[RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
           Network Address Translations (NATs)", RFC 4380,
           February 2006.

[RFC5454]  Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile
           IPv4", RFC 5454, March 2009.

[RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
           Routers", RFC 5555, June 2009.

[RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
           Framework", RFC 5565, June 2009.

8.2. Informative References ✨

okay bestie, this is the reading list 📚 these aren't required to implement anything, they're the receipts and background that the document points to. here's every single one, copied exactly as written 💅

[Baker.Shanghai]
           Baker, F., "The view from IPv6 Operations WG (and we'll
           talk about translation)", Presentation in the China Mobile
           Workshop on IPv6 Deployment in Cellular Networks,
           Shanghai, China, November 2009, <http://ipv6ws.arkko.com/
           presentations/3GPP-IETF-V6OPS-Discussion.pdf>.

[DS-extra-lite]
           Arkko, J., Eggert, L., and M. Townsley, "Scalable
           Operation of Address Translators with Per-Interface
           Bindings", Work in Progress, February 2011.

[DS-lite]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
           Stack Lite Broadband Deployments Following IPv4
           Exhaustion", Work in Progress, August 2010.

[FTP64]    Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
           Work in Progress, March 2011.

[IPv6-only-experience]
           Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
           Network", Work in Progress, April 2011.

[L2-NAT]   Miles, D. and M. Townsley, "Layer2-Aware NAT", Work
           in Progress, March 2009.

[RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
           for IP version 6", RFC 1981, August 1996.

[RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
           Translation - Protocol Translation (NAT-PT)", RFC 2766,
           February 2000.

[RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
           November 2000.

[RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
           Tunnel Broker", RFC 3053, January 2001.

[RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
           via IPv4 Clouds", RFC 3056, February 2001.

[RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
           Generation Partnership Project (3GPP) Standards",
           RFC 3314, September 2002.

[RFC3574]  Soininen, J., "Transition Scenarios for 3GPP Networks",
           RFC 3574, August 2003.

[RFC4029]  Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
           Savola, "Scenarios and Analysis for Introducing IPv6 into
           ISP Networks", RFC 4029, March 2005.

[RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
           Castro, "Application Aspects of IPv6 Transition",
           RFC 4038, March 2005.

[RFC4057]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
           June 2005.

[RFC4215]  Wiljakka, J., "Analysis on IPv6 Transition in Third
           Generation Partnership Project (3GPP) Networks", RFC 4215,
           October 2005.

[RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
           "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
           Provider Edge Routers (6PE)", RFC 4798, February 2007.

[RFC4852]  Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
           Green, "IPv6 Enterprise Network Analysis - IP Layer 3
           Focus", RFC 4852, April 2007.

[RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
           Address Translator - Protocol Translator (NAT-PT) to
           Historic Status", RFC 4966, July 2007.

[RFC5181]  Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
           Deployment Scenarios in 802.16 Networks", RFC 5181,
           May 2008.

[RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
           July 2008.

[RFC5218]  Thaler, D. and B. Aboba, "What Makes For a Successful
           Protocol?", RFC 5218, July 2008.

[RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
           Mobile IPv6", RFC 5844, May 2010.

[RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
           Infrastructures (6rd) -- Protocol Specification",
           RFC 5969, August 2010.

[RFC6036]  Carpenter, B. and S. Jiang, "Emerging Service Provider
           Scenarios for IPv6 Deployment", RFC 6036, October 2010.

[RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
           Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
           October 2010.

[RFC6127]  Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6
           Co-Existence Scenarios", RFC 6127, May 2011.

[RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
           IPv4/IPv6 Translation", RFC 6144, April 2011.

[RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
           Algorithm", RFC 6145, April 2011.

[RFC6146]  Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
           NAT64: Network Address and Protocol Translation from IPv6
           Clients to IPv4 Servers", RFC 6146, April 2011.

[RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
           "DNS64: DNS extensions for Network Address Translation
           from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.

[RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
           Concerns with IP Tunneling", RFC 6169, April 2011.

[networkworld.youtube]
           Marsan, C., "YouTube support of IPv6 seen in dramatic
           traffic spike", Network World article, February 2010,
           <http://www.networkworld.com/news/2010/
           020110-youtube-ipv6.html>.

[shared-addressing-issues]
           Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
           Roberts, "Issues with IP Address Sharing", Work in
           Progress, March 2011.

[v6-in-mobile]
           Koodli, R., "Mobile Networks Considerations for IPv6
           Deployment", Work in Progress, May 2011.

Appendix A. Acknowledgments 🎀

the authors gave a huge shoutout to everyone who's been chatting about this topic over the years 🫶 some of the material here actually started with Fred Baker's talk at a workshop in Shanghai [Baker.Shanghai] 🌸 they also thanked Mark Townsley, who co-wrote an earlier doc with Jari Arkko [RFC6127] 💜

Brian Carpenter did a super in-depth review and wrote a ton of new text, which is so iconic 😭 Cameron Byrne gave really valuable feedback on the key recommendations in this memo 🔥 and the authors also want to thank Dave Thaler, Alain Durand, Randy Bush, and Dan Wing, who have always been there with great guidance in this field 🧚

last but not least, a big thank you to Suresh Krishnan, Fredrik Garneij, Mohamed Boucadair, Remi Despres, Kurtis Lindqvist, Shawn Emery, Dan Romascanu, Tim Polk, Ralph Droms, Sean Turner, Tina Tsou, Nevil Brownlee, and Joel Jaeggli, who gave comments on early versions of this memo 👑✨

Authors' Addresses 🦋

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Fred Baker
Cisco Systems
Santa Barbara, California  93117
USA

EMail: fred@cisco.com
📦 where this page comes from