RFC 6127

IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios

📅 published May 2011, from ietf

Abstract ✨

When IPv6 was designed, everyone expected the switch from IPv4 to IPv6 to go way smoother and faster than it actually has 😭. The IPv4 Internet keeps growing, and the free pool of IPv4 address blocks is running low on a horizon we can actually see, so we urgently need to rethink IPv6 deployment models 🔥. This doc gives an overview of deployment scenarios so we can figure out what extra tools the industry needs to help IPv4 and IPv6 co-exist and transition 🦋.

This document was originally written as input for the Montreal co-existence interim meeting in October 2008. That meeting led to the Behave and Softwire working groups being rechartered to take on new IPv4 and IPv6 co-existence work 🌸. It's published as a historical record of how people were thinking back then, but hopefully it also helps you understand why today's IETF co-existence and transition tools look the way they do 💜.

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published for informational purposes 🌈.

This document is a product of the Internet Engineering Task Force (IETF). 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; see Section 2 of RFC 5741 💅.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6127 🧚.

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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶.

Table of Contents 📋

1. Introduction ....................................................2
2. Scenarios .......................................................4
   2.1. Reaching the IPv4 Internet .................................4
        2.1.1. NAT444 ..............................................5
        2.1.2. Distributed NAT .....................................6
        2.1.3. Recommendation ......................................8
   2.2. Running Out of IPv4 Private Address Space ..................9
   2.3. Enterprise IPv6-Only Networks .............................11
   2.4. Reaching Private IPv4-Only Servers ........................13
   2.5. Reaching IPv6-Only Servers ................................14
3. Security Considerations ........................................16
4. Conclusions ....................................................16
5. References .....................................................17
   5.1. Normative References ......................................17
   5.2. Informative References ....................................17
Appendix A. Acknowledgments .......................................20

1. Introduction ✨

This document was originally written as input for the Montreal co-existence interim meeting in October 2008. That meeting led to the Behave and Softwire working groups being rechartered to take on new IPv4 and IPv6 co-existence work. It's published as a historical record of the thinking at the time, but hopefully it'll also help you understand the reasoning behind today's IETF tools for co-existence and transition 🦋.

So when IPv6 was designed, the plan was that IPv6 would be turned on, partly or fully, while IPv4 kept running side-by-side on the same network nodes and hosts. This is called "dual-stack" [RFC4213], and it's been the dominant approach driving the IPv6 specs and tools so far 💅.

Large-scale IPv6 deployment takes time, effort, and a lot of investment, and experience has shown that 🥲. With IPv4 address pool depletion on the horizon [HUSTON-IPv4], network operators and Internet Service Providers are being pushed to consider network designs that don't assume the same level of access to unique global IPv4 addresses anymore. IPv6 alone doesn't fix this, because it's based on the assumption that all hosts and nodes will be dual-stack until IPv4-only equipment is eventually phased out 💀. Basically, the timelines for the IPv4 Internet's growth, the universal rollout of dual-stack IPv4 and IPv6, and the final move to an IPv6-dominant Internet don't line up with what was originally expected 😭.

Dual-stack is still the most well-understood way to deploy IPv6 today, but current realities mean we need to re-assess the tools available for other deployment models that are likely to pop up 🌈. In particular, we have to think about what happens when you deploy multiple layers of IPv4 address translation, and also about translation between IPv4 and IPv6. That second one is why [RFC2766] got deprecated, as detailed in [RFC4966] 🙈. This document walks through some scenarios where these address and protocol translation mechanisms could be useful. It also covers situations where carrying IPv4 over IPv6 might help with the transition to IPv6 and co-existence with IPv4. We're purposefully not describing classic dual-stack methods or IPv6-over-IPv4 tunneling. Instead, we're focusing on scenarios that are driving tools we haven't historically been developing standard solutions for 🧚.

Keep in mind that the scenarios here are new deployment models, meant to complement existing ones, not replace them. For example, dual-stack is still the most recommended deployment model 👑. Dual-stack also isn't limited to situations where every host can get a public IPv4 address. A really common setup is running dual-stack on the IPv6 side with public addresses, and on the IPv4 side with just one public address and a traditional IPv4 NAT 🎀. Generally speaking, when there's enough address space available, native connectivity with both IP versions is preferred over translation or tunneling mechanisms ✨.

2. Scenarios 💜

This section identifies five deployment scenarios that we believe have a significant level of near-to-medium-term demand somewhere on the globe. We'll discuss each one in the following sections, while walking through a bit of the design space so you can get a sense of the types of tools that could be built to solve each. We especially want you to think about, for each scenario, what kind of new equipment must be introduced into the network, and where; which nodes must be changed in some way; and which nodes must work together in an interoperable manner via a new or existing protocol 🧠.

The five scenarios are:

  • Reaching the IPv4 Internet with less than one global IPv4 address per subscriber or subscriber household available (Section 2.1) 🌍.
  • Running a large network that needs more addresses than are available in private RFC 1918 address space (Section 2.2) 🏠.
  • Running an IPv6-only network for operational simplicity compared to dual-stack, while still needing access to the global IPv4 Internet for some, but not all, connectivity (Section 2.3) 🧑‍💻.
  • Reaching one or more privately addressed IPv4-only servers via IPv6 (Section 2.4) 🔒.
  • Accessing IPv6-only servers from IPv4-only clients (Section 2.5) 🔁.

2.1. Reaching the IPv4 Internet 🌐

                   +----+                       +---------------+
  IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
                   +----+                       +---------------+

  <---private v4--->NAT<--------------public v4----------------->

               Figure 1: Accessing the IPv4 Internet Today

Figure 1 shows the typical model for accessing the IPv4 Internet today. The gateway device implements a Network Address and Port Translation (NAPT, or more simply referred to in this document as NAT) 🎀. The NAT function serves a few purposes, one of which is to let more hosts sit behind the gateway (GW) than there are IPv4 addresses shown to the Internet. This multiplexing of IP addresses comes at a great cost to the original end-to-end model of the Internet, but it's still the dominant method of access today, especially for residential subscribers 😭.

Take the typical residential subscriber as an example: each subscriber line is allocated one global IPv4 address to use with as many devices as the NAT GW and local network 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. And honestly? In some deployments, this is already the case 🥺💀

2.1.1. NAT444 🎀

okay so bestie, when there's less than one address per subscriber at any given time, somebody has to multiplex addresses somewhere that can actually see more than one subscriber 👀 The most obvious spot is inside the service provider's own network, which means the SP has to buy and run NAT gear so addresses can be shared across lots of subscribers. But if the customer owns and runs the GW, that becomes operational overhead for the Internet Service Provider (ISP), and the ISP can no longer lean on the customer or the company that sold them the GW device. not ideal, ngl 😭

This new address translation box is called a "Carrier Grade NAT", or CGN [NISHITANI-CGN]. Here's where the CGN slots into the ISP network 💅

                +----+                   +---+  +-------------+
IPv4 host(s)-----+ GW +------IPv4---------+CGN+--+IPv4 Internet|
                +----+                   +---+  +-------------+

<---private v4--->NAT<----private v4------>NAT<----public v4--->

            Figure 2: Employing Two NAT Devices: NAT444

This setup is called "NAT444" or "Double-NAT" and it's covered more in [NAT-PT]. 🦋

Now the important tea ☕ Even though IPv4 addresses are getting multiplexed at multiple levels here, there's zero aggregation of NAT state between the GW and the CGN. Every flow that starts in the subscriber home gets stored as duplicate state in both the GW and the CGN. Like, if there are 4 PCs in one home and each has 25 open TCP sessions, then the GW and the CGN both have to track 100 sessions each for that subscriber line. that's a lot of bookkeeping, babe 💀

NAT444 has this super tempting vibe where it looks like you can just drop a CGN in without changing the GW or anything else in the network. And yeah, a GW that's willing to accept a lease for a global IPv4 address would probably also accept a translated IPv4 address. BUT the CGN is not transparent to the GW or to the subscriber 🙈 Offering a translated address is a totally different service model than offering a global one, so it's not a freebie. Plenty of things will keep working in both setups, but some end-host applications may break, and GW port-mapping functionality will likely stop working reliably. Also, if the addresses on the subscriber network and the service provider network overlap [ISP-SHARED-ADDR], the GW could get confused by ambiguous routes and send traffic to the wrong place or black-hole it entirely. Fixing that overlap by allocating new private address space is hard, because a lot of existing devices depend on knowing which ranges count as private [IPv4-SPACE-ISSUES]. the drama is real 😤

Also, a bunch of network operations that used to be tied to one IPv4 address per subscriber will need a second look when you deploy NAT444. That includes troubleshooting, operations, accounting, logging and legal intercept, Quality of Service (QoS) functions, anti-spoofing and security, backoffice systems, and so on. Ironically, some of these headaches overlap with the ones you'd have to deal with when deploying IPv6 🙃

Consequences aside, NAT444 is already showing up in some networks for residential broadband service, and it's safe to assume that trend will likely keep going as IPv4 addresses get tighter. So the operational considerations of NAT444 really need to be well-documented 📝

NAT444 assumes the global IPv4 address currently given to a residential subscriber will just be swapped out for a single translated address. Here's the twist 🧠 To avoid doing NAT twice, and since the address is no longer global, a service provider could start offering a subnet of translated IPv4 addresses, hoping the subscriber will route IPv4 in the GW instead of NAT. Same deal if the GW is known to be an IP-unaware bridge. But this makes assumptions about whether the ISP can enforce policies, or even identify specific capabilities, of the GW. Once we open the door to changing the GW, the design space gets a lot bigger 🌈 The next section covers the same problem of reaching the IPv4 Internet during IPv4 address depletion, but with the extra wrinkle that the GW can be updated or replaced along with deploying a CGN (or CGN-like) node. ✨

2.1.2. Distributed NAT 🦋

Service providers offering "triple-play" services are increasingly the ones who own and manage a highly functional GW in the subscriber home 🏠 These managed GWs usually have pretty tight integration with the service provider network and applications. In these deployments, we can start thinking about what else is possible besides NAT444, by assuming the CGN and the GW can work together cooperatively 🫶

If the connection between the GW and the CGN is a point-to-point link (which is a common setup between the GW and the "IP edge" in a bunch of access architectures), then NAT-like functionality can be "split" between the GW and the CGN, instead of doing NAT444 like in the previous section 🍓

             one frac addr            one public addr
                +----+                   +---+  +-------------+
IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
                +----+                   +---+  +-------------+

<---private v4--->            NAT             <----public v4--->
                         (distributed,
                       over a p2p link)

                 Figure 3: Distributed-NAT Service

In this approach, multiple GWs share one common public IPv4 address, but each gets its own separate, non-overlapping port range. Each address/port range pair is called a "fractional address". Each home gateway can use the address as if it were its own public address, except that it only gets a limited port range 💜 The CGN knows about the port ranges, and they can be assigned in different ways, like during DHCP lease acquisition or dynamically when ports are needed [v6OPS-APBP]. The CGN sends traffic aimed at the fractional address to that subscriber's GW device. The big perk here is that the more complicated parts of NAT (Application Level Gateways (ALGs), port mapping, etc.) stay in the GW, and the only thing that changes is the restricted port range allocated to the fractional address for that GW. The CGN gets to be pretty stateless, forwarding traffic based on IP address and port ranges, and it isn't tracking any individual flows from inside the subscriber network. Scaling benefits within the CGN node are obvious, but the tradeoff is complexity, since more nodes and protocols have to work together in an interoperable way 🧩 Also, the GW is still getting a global IPv4 address, just a "portion" of one in terms of available port usage. There are still open questions about protocols that run directly over IP and can't use the divided port number ranges, and about how to handle fragmented packets. Still, the upside is that we're no longer stuck with two layers of NAT like in NAT444 🙌

Not every access architecture gives you a natural point-to-point link between the GW and the CGN to plug into. And even in networks that do have point-to-point links, the CGN might not be built into the IP edge device. For these cases, we can build our own point-to-point link with a tunnel. A tunnel is basically a point-to-point link that we create when we need it [INTAREA-TUNNELS]. Here's how that looks in Figure 4 🌸

             one frac addr            one public addr
                +----+                   +---+  +-------------+
IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
                +----+                   +---+  +-------------+

<---private v4--->            NAT             <----public v4--->
                        (distributed,
                        over a tunnel)

      Figure 4: Point-to-Point Link Created through a Tunnel

Figure 4 is basically the same as Figure 3, except the data link is created with a tunnel. The tunnel could be set up in any number of ways, depending on the underlying network 🔧

So at this point, we're using a tunnel or point-to-point link with coordinated operation between the GW and the CGN, so that most of the NAT functionality can stay in the GW 💅

Since we're assuming a point-to-point link between the GW and the CGN, the CGN could do the NAT function instead, which allows private, overlapping space for all subscribers. For example, every subscriber GW could be assigned the same 10.0.0.0/8 address space (or all RFC 1918 [RFC1918] space, for that matter). The GW then becomes a simple "tunneling router", and the CGN takes on the full NAT role. You can think of this design as basically a layer-3 VPN, but with Virtual-NAT tables instead of Virtual-Routing tables 👑

2.1.3. Recommendation 🌟

This section is strictly about reaching the IPv4 Internet when each device in a network has limited public address space. We looked at combining NAT functions and tunnels between the GW and the CGN to get similar results, just with different design tradeoffs ⚖️ The methods can be summed up like this:

a. Double-NAT (NAT444)

b. Single-NAT at CGN with a subnet and routing at the GW

c. Tunnel/link + fractional IP (NAT at GW, port-routing at CGN)

d. Tunnel/link + Single-NAT with overlapping RFC 1918 ("Virtual NAT" tables and routing at the GW)

With all of the methods above, the GW could be logically moved into a single host, which could potentially get rid of one level of NAT just by doing that 🧚 As long as the hosts themselves only need a single IPv4 address, methods b and d are obviously of little interest. That leaves methods a and c as the more interesting options in cases where there's no analogous GW device, like on a campus network 🎓

This document recommends developing new guidelines and specifications to address the methods above. Cases where the home gateway both can and cannot be modified should both be addressed 💖

2.2. Running Out of IPv4 Private Address Space ✨

okay so public IPv4 isn't the only thing running low 😭 Very large privately addressed networks are also running out of RFC 1918 space on their local networks. Huge service provider networks are the prime suspects here 💅 ISPs use private space locally for a few things:

  • Control and management of service provider devices in subscriber premises (cable modems, set-top boxes, and so on).
  • Addressing the subscriber's NAT devices in a Double-NAT arrangement.
  • "Walled garden" data, voice, or video services.

Some providers handle this by splitting their network into parts, with each part on its own copy of the private space 🧩 But that limits how services can be deployed and what management systems can reach what devices. It's also operationally messy, because network operators have to keep track of which private scope they're in 🙈

Tunnels came up in the previous section as a way to share a single global IPv4 address across multiple endpoints without NAT, or to let overlapping address space reach GWs or hosts connected to a CGN. The kind of tunnel or link wasn't specified. If the tunnel carries IPv4 over IPv6, the part of the IPv6 network it crosses doesn't need to be IPv4-capable, and it doesn't need IPv4 addresses, private or public, to carry the tunnel traffic 🦋 Figure 5 shows this:

                        IPv6-only network
                +----+                     +---+  +-------------+
IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
                +----+                     +---+  +-------------+

<---private v4---->  <-----  v4 over v6 ----->  <---public v4---->

          Figure 5: Running IPv4 over an IPv6-Only Network

Each of the four approaches (a, b, c, and d) from the Section 2.1 scenario could be applied here 🌸 For brevity, each iteration isn't spelled out in full. The models are basically the same, except the tunnel runs over an IPv6 network and carries IPv4 traffic. Note that while there are loads of solutions for carrying IPv6 over IPv4, this reverse mode is kind of its own exception 👑 (one notable exception is the Softwire working group, as seen in [RFC4925]).

Once we have IPv6 to the GW (or to the host, if we think of the GW as embedded in the host) 🧚, enabling IPv6 and IPv4 over the IPv6 tunnel gives you dual-stack operation at the host or the network behind the GW device. Figure 6 shows it:

                +----+                               +-------------+
  IPv6 host-----+    |            +------------------+IPv6 Internet|
                |    +---IPv6-----+                  +-------------+
dual-stack host-+ GW |
                |    |                        +---+  +-------------+
  IPv4 host-----+    +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
                +----+                        +---+  +-------------+

<-----------private v4 (partially in tunnel)-->NAT<---public v4---->
<-----------------------------public v6---------------------------->

   Figure 6: "Dual-Stack Lite" Operation over an IPv6-Only Network

[DUAL-STACK-LITE] calls this "dual-stack lite" 💖 The name is a nod to the fact that it's dual-stack at the gateway, but not at the network. As introduced in Section 2.1, if the CGN here is a full functioning NAT, hosts behind a dual-stack lite gateway can run IPv4-only and IPv6-enabled applications across an IPv6-only network, and nobody has to provision a unique IPv4 address for each gateway. In fact, every gateway may have the same address 🤯

While the big-picture problem in this scenario is how to ease local use of IPv4 addresses inside a service provider network, the IPv6-based direction has some really interesting operational properties worth pointing out ✨ When IPv4 is tunneled over IPv6 across the provider network, three separate problems get decoupled: moving the provider network to IPv6, deploying IPv6 to subscribers, and continuing to offer IPv4 service. The provider could deploy IPv6 internally, turn off IPv4 internally, and still carry IPv4 traffic across the IPv6 core for end users 🎀 In the extreme case, none of that IPv4 traffic needs a different IPv4 address for each endpoint, since there's no IPv4 routing or forwarding inside the network. So there are no issues with IPv4 renumbering, address space allocation, and so on within the network itself 💅

It is recommended that the IETF develop tools for this scenario, for both a host and the GW. It is assumed that both endpoints of the tunnel can be modified to support these new tools 🫶

2.3. Enterprise IPv6-Only Networks 🌈

This scenario is about letting an IPv6-only host, or a host with no interfaces connected to an IPv4 network, reach servers on the IPv4 Internet 🦋 It's a big deal for what people call "greenfield" deployments. A classic example is an enterprise network that wants to run only IPv6 for operational simplicity, but still needs the content on the IPv4 Internet. Say a brand-new office building gets provisioned with IPv6 only 🏢 Figure 7 shows it:

                         +----+                  +-------------+
                         |    +------------------+IPv6 Internet+
                         |    |                  +-------------+
IPv6 host-----------------+ GW |
                         |    |                  +-------------+
                         |    +------------------+IPv4 Internet+
                         +----+                  +-------------+

<-------------------------public v6----------------------------->
<-------public v6--------->NAT<----------public v4-------------->

              Figure 7: Enterprise IPv6-Only Network

Other cases people have mentioned include "greenfield" wireless service provider networks and sensor networks 🧚 This enterprise IPv6-only scenario is also strikingly similar to the Section 2.2 scenario, if you imagine a really large enterprise network that starts to look like a service provider network 👑

In the Section 2.2 scenario, we dipped into the design space enough to show that the service provider could run an IPv6-only network to ease its addressing problems through tunneling. That came at a cost, though: two devices on the edges of the network, the GW and the CGN, both have to support IPv6 and the tunneling mechanism over IPv6 😭 The greenfield enterprise scenario is different, because there's only one place the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet keeps working the way it already does 🌸 On top of that, the hosts in the enterprise network are commercially available devices, personal computers running existing operating systems. We're assuming all the devices on the network are "modern" dual-stack-capable devices, but we don't want to rely on kernel-level modifications to those operating systems 🙈 That restriction pushes us toward a "one box" solution, where IPv6 gets translated into IPv4 to reach the public Internet. This is one situation where new or improved IETF specifications could really change the user experience on these networks 🔥 To be fair, even a network-based solution will take time and effort to deploy. Basically, it's a tradeoff between adding one new piece of equipment to the network, or getting two devices to cooperate 💜

One approach for this environment is an application-level proxy at the edge of the network (the GW) 🍓 For example, if the only application that needs to reach the IPv4 Internet is the web, then an HTTP/HTTPS proxy can easily convert traffic from IPv6 into IPv4 on the outside 💖

Another, more generic approach is an IPv6-to-IPv4 translator device. Different types of translation schemes are discussed in [NAT-PT], [RFC6144], [RFC6145], and [RFC6052]. NAT64 is one example of a translation scheme in this category [RFC6147] [RFC6146] ✨

Translation will in most cases have some negative consequences for the end-to-end operation of Internet protocols 😬 For instance, the issues with Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] have been described in [RFC4966]. It's important to note that the choice of translation solution, and the assumptions about the network it's used in, affect those consequences. A translator built for the general case has a bunch of issues that a translator for a more specific situation may not have at all 🦋

It is recommended that the IETF develop tools for this scenario. These tools need to let existing IPv6 hosts operate unchanged 🫶

2.4. Reaching Private IPv4-Only Servers ✨

Okay bestie, this section is about IPv4-only server farms that can't get enough public addresses anymore 😭. Individual servers should still be able to get addresses for a long time in a pretty easy way 💅. But a big server farm might need a block so large that it's either not feasible to get, or it becomes economically desirable to use those addresses for other stuff 🫶.

Another use case: a service provider can get enough IPv4 addresses, and has already done so 🌸. But they also just want to start offering an IPv6 service without touching the server farm (so, without upgrading the server farm to IPv6) 🦋.

One option is to move those servers and their clients to IPv6. But moving to IPv6 isn't just the cost of IPv6 connectivity, it's also the cost of moving the application itself from IPv4 to IPv6 🙈. So in this case the server farm is IPv4-only, IPv4 connectivity keeps getting more expensive, and moving the server infrastructure to IPv6 is an expensive bill 💀. What can be done? 🤔

If the clients are IPv4-only too, it's a hard one 😭. Section 2.5 digs into that more. BUT, there are important cases where large sets of clients are IPv6-capable 🎀. In those cases, you can place the server farm in private IPv4 space and set up some gateway service from IPv6 to IPv4 to reach the servers. This is shown in Figure 8 👑.

                                 +----+
IPv6 host(s)-------(Internet)-----+ GW +------Private IPv4 servers
                                 +----+

<---------public v6--------------->NAT<------private v4---------->

          Figure 8: Reaching Servers in Private IPv4 Space

One way to do this is to use NAT64 to translate IPv6 into private IPv4 addresses. The private IPv4 addresses get mapped into IPv6 addresses within one or more known prefixes. The GW at the edge of the server farm knows the mapping, and so does the Domain Name System (DNS) 🧚. AAAA records for each server name are given an IPv6 address that matches the mapped private IPv4 address. So each privately addressed IPv4 server gets a public IPv6 presentation ✨. No Application Level Gateway for DNS (DNS-ALG) is needed in this case, unlike what NAT-PT would require, for instance 💅.

This is very similar to the Section 2.3 scenario, where we usually think of a small site with IPv6 needing to reach the public IPv4 Internet. The difference here is that we assume it's not a small IPv6 site, but the whole IPv6 Internet needing to reach a small IPv4 site 🌈. This example was driven by the enterprise network with IPv4 servers, but it could be scaled down all the way to the individual subscriber home level too 🏠. Here, the same technique could be used to, say, access an IPv4 webcam in the home from the IPv6 Internet 📷. All that's needed is the ability to update AAAA records appropriately, an IPv6 client (which could use Teredo [RFC4380] or some other method to get IPv6 reachability), and the NAT64 mechanism. In this sense, this method looks a lot like a "NAT/firewall bypass" function 🦋.

An argument could be made that since the host is likely dual-stack, existing port-mapping services or NAT traversal techniques could be used to reach the private space instead of IPv6. That would have to be done anyway if the hosts aren't all IPv6-capable or connected 🙄. But when the hosts are all IPv6-capable, the alternative techniques force extra limitations on the use of port numbers 😤. With IPv6-to-IPv4 translation, the full port space would be available for each server, even in the private space 🔥.

It is recommended that the IETF develop tools to address this scenario. These tools need to allow existing IPv4 servers to operate unchanged 🫶.

2.5. Reaching IPv6-Only Servers 🌙

This scenario is predicted to become more and more important, as IPv4 global connectivity that's good enough to support server-oriented content gets way harder to get than global IPv6 connectivity 📈. Historically, the expectation has been that for connectivity to IPv6-only devices, devices would either need to be IPv6-connected, or dual-stack with the ability to set up an IPv6-over-IPv4 tunnel to access the IPv6 Internet 🛸. Lots of "modern" device stacks can do this, and for them this scenario isn't a problem as long as a suitable gateway to terminate the tunnel and route the IPv6 packets is available ✨. But for the server operator, it may be a tough call to leave all the IPv4-only devices without reachability 😬. So if a solution for IPv4-only devices to reach IPv6-only servers were doable, the benefits would be super clear 💖. Servers could move straight to IPv6 without trudging through a painful dual-stack period, and they could do it without the risk of losing connectivity with the IPv4-only Internet 🙌.

Unfortunately, this goal is complicated by the fact that IPv4 to IPv6 is considered "hard", since of course IPv6 has a much larger address space than IPv4 🥲. So representing 128 bits in 32 bits is not possible, barring techniques similar to NAT64, which uses IPv6 addresses to represent IPv4 addresses as well 🧩.

The main questions for this scenario are about timing and priority ⏰. The idea that this scenario may matter one day is totally acceptable 💅. But at the time of writing, there are few or no IPv6-only servers of importance (beyond some contrived cases) that the authors are aware of 🤷‍♀️. The tricky part about deciding on this case is that, quite possibly, by the time there's enough pressure on IPv4 that we do see IPv6-only servers, the vast majority of hosts will either have IPv6 connectivity or the ability to tunnel IPv6 over IPv4 in one way or another 🎀.

This discussion also makes assumptions about what a "server" is. For the majority of applications seen on the IPv4 Internet to date, that distinction has been more or less clear 👀. That clarity is probably partly due to the overhead today of creating a truly end-to-end application when you've got the fragmented addressing and reachability brought on by the various NATs and firewalls out there 😮‍💨. But current notions of a "server" are starting to shift, as we see more and more pressure to connect people to one another in an end-to-end way (with peer-to-peer techniques, for instance) rather than just content server to client 🫂. So if we think of an "IPv6-only server" as what we classically consider an "IPv4 server" today, there may not be a lot of demand for it in the near future 😌. But with a more distributed model of the Internet in mind, there may be more chances to use IPv6-only "servers" that we'd normally extrapolate from past application experience 🌸.

It is recommended that the IETF address this scenario, though perhaps with a slightly lower priority than the others. In any case, when new tools are developed to support this, it should be obvious that we cannot assume any support for updating legacy IPv4 hosts in order to reach the IPv6-only servers 🚫.

3. Security Considerations 🔐

Security aspects of the individual solutions are discussed in more depth elsewhere, for instance in [DUAL-STACK-LITE], [RFC6144], [RFC6147], [RFC6145], [RFC6146], [NAT-PT], and [RFC4966]. This document highlights just three issues 🚨:

  • Any type of translation may have an impact on how certain protocols can pass through. For example, IPsec needs support for NAT traversal, and the proliferation of NATs implies an even higher reliance on these mechanisms. It may also require additional support for new types of translation 😱.
  • Some solutions have a need to modify results obtained from DNS. This may have an impact on DNS security, as discussed in [RFC4966]. Minimization or even elimination of such problems is essential, as discussed in [RFC6147] 🧨.
  • Tunneling solutions have their own security issues, for instance the need to secure tunnel endpoint discovery or to avoid opening up denial-of-service or reflection vulnerabilities [RFC6169] 💀.

4. Conclusions 🎉

The authors believe that the scenarios outlined in this document are among the top of the list of those that the IETF community should address in short order ⭐. For each scenario, there are clearly different solution approaches, each with implementation, operations, and deployment tradeoffs. Further, some approaches rely on existing or well-understood technology, while others require new protocols and changes to established network architecture 🧠. It's essential that these tradeoffs be considered, understood by the community at large, and in the end well-documented as part of the solution design 📝.

After writing the initial version of this document, the Softwire working group was rechartered to address the Section 2.2 scenario with a combination of existing tools (tunneling, IPv4 NATs) and some minor new ones (DHCP options) [DUAL-STACK-LITE] 🛠️. Similarly, the Behave working group was rechartered to address scenarios from Sections 2.3, 2.4, and 2.5 🙌. At the time this document was published, proposals to address scenarios from Section 2.1 were still under consideration for new IETF work items 🤞.

This document set out to list scenarios that are important for the Internet community. While it introduces some design elements to help understand and discuss tradeoffs, it does not list detailed requirements. Mostly, the authors believe that exhaustive and detailed requirements wouldn't be helpful, since they'd come at the expense of getting on with solutions, given our current state of affairs 🏃‍♀️. We don't expect any of the solutions to be perfect when measured from all vantage points. When we're looking for chances to deploy IPv6, reaching too far for perfection could make us lose those chances if we aren't paying attention 👀. Our goal with this document is to support the development of tools that help minimize the tangible problems we're experiencing now, as well as the problems we can best anticipate down the road, in hopes of steering the Internet on its best course from here 🌈💜.

5. References 📚

5.1. Normative References

  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

5.2. Informative References ✨

Okay bestie, these are the informative references 🦋 Basically the "go read this if you want more" pile. Here's the whole stack, in the original order:

  • [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
  • [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
  • [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 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.
  • [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
  • [NAT-PT] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
  • [DUAL-STACK-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, 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. van 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. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
  • [INTAREA-TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
  • [v6OPS-APBP] Despres, R., "A Scalable IPv4-IPv6 Transition Architecture Need for an Address-Port-Borrowing-Protocol (APBP)", Work in Progress, July 2008.
  • [HUSTON-IPv4] Huston, G., "IPv4 Address Report", available at http://www.potaroo.net, December 2010.
  • [NISHITANI-CGN] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for IP Address Sharing Schemes", Work in Progress, March 2011.
  • [ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, September 2010.
  • [IPv4-SPACE-ISSUES] Azinger, M. and L. Vegoda, "Issues Associated with Designating Additional Private IPv4 Address Space", Work in Progress, January 2011.
  • [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.

Appendix A. Acknowledgments 🌸

A big thank-you to everyone who helped make this one happen 🫶 The list includes Dave Thaler, Thomas Narten, Marcelo Bagnulo, Fred Baker, Remi Despres, Lorenzo Colitti, Dan Wing, and Brian Carpenter. Their discussions were essential to the content in this document, and so was the feedback from the Internet Area open meeting at IETF 72. Iconic crew, honestly 👑

Authors' Addresses 💜

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Mark Townsley
Cisco
Paris  75006
France

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