RFC 9313

Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)

📅 published October 2022, from ietf

RFC 9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) 🎀

Part 1 of 7 💖

okay bestie, this RFC is the ultimate comparison guide for ISPs that are going IPv6-only but still need to give customers IPv4 🌸. so the title block: it's by G. Lencse (BUTE), J. Palet Martinez (The IPv6 Company), L. Howard (Retevia), R. Patterson (Sky UK), and I. Farrer (Deutsche Telekom AG) ✨. it's Informational (so not a Standards Track spec, just helpful info 🧚), it's an IETF document, the ISSN is 2070-1721, and it's dated October 2022 📅. it doesn't list anything it obsoletes or updates, so it's standing on its own 💅.

Abstract

okay so the abstract is giving "here's the tea" 🫖. ISPs with IPv6-only access and/or core networks need a way to give customers IPv4-as-a-Service (IPv4aaS) ✨. there are a few technologies for this, and each one has pros and cons 💜. which one is best depends on your topology, your skills, your strategy, and your preferences, so there's no one-size-fits-all 🙈.

this doc looks at the five most prominent IPv4aaS technologies and compares them across a bunch of aspects, so operators get an easy-to-use reference for picking the one that fits their needs 🦋.

Status of This Memo

it's not on the Standards Track, it's published just for information 🍓.

this is an IETF product, it reflects the IETF community's consensus, it got public review, and the IESG approved it for publication 🫶. not every IESG-approved doc can become an Internet Standard, see Section 2 of RFC 7841 for the details 🌈.

you can find the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9313 🔥.

© 2022 IETF Trust and the document authors, all rights reserved 💅.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date ✨. please actually read those, because they spell out your rights and restrictions for this doc 📜. any Code Components you pull out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 🔐.

Table of Contents

1.  Introduction
2.  Overview of the Technologies
  2.1.  464XLAT
  2.2.  Dual-Stack Lite
  2.3.  Lightweight 4over6
  2.4.  MAP-E
  2.5.  MAP-T
3.  High-Level Architectures and Their Consequences
  3.1.  Service Provider Network Traversal
  3.2.  Network Address Translation among the Different IPv4aaS
        Technologies
  3.3.  IPv4 Address Sharing
  3.4.  IPv4 Pool Size Considerations
  3.5.  CE Provisioning Considerations
  3.6.  Support for Multicast
4.  Detailed Analysis
  4.1.  Architectural Differences
    4.1.1.  Basic Comparison
  4.2.  Trade-Off between Port Number Efficiency and Stateless
        Operation
  4.3.  Support for Public Server Operation
  4.4.  Support and Implementations
    4.4.1.  Vendor Support
    4.4.2.  Support in Cellular and Broadband Networks
    4.4.3.  Implementation Code Sizes
  4.5.  Typical Deployment and Traffic Volume Considerations
    4.5.1.  Deployment Possibilities
    4.5.2.  Cellular Networks with 464XLAT
    4.5.3.  Wireline Networks with 464XLAT
  4.6.  Load Sharing
  4.7.  Logging
  4.8.  Optimization for IPv4-Only Devices and Applications
5.  Performance Comparison
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction

so as IPv6 keeps spreading, it's getting more obvious that network operators are going to build single-stack IPv6 core and access networks to keep planning and operations simple 🧚. but giving customers IPv4 is still a must for the foreseeable future 😭. the IETF has standardized a bunch of IPv4aaS technologies for exactly this, based on different requirements and deployment scenarios (see [LEN2019]) 💖.

the problem? there are so many of them that it takes forever for an operator to figure out which one fits their deployment 🙈. this doc gives a comparative analysis of the most commonly used mechanisms, so operators have an easier time with that decision ✨.

five IPv4aaS solutions get the spotlight:

  1. 464XLAT [RFC6877]
  2. Dual-Stack Lite [RFC6333]
  3. Lightweight 4over6 (lw4o6) [RFC7596]
  4. Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597]
  5. Mapping of Address and Port using Translation (MAP-T) [RFC7599]

also, [RFC6180] has guidelines for using IPv6 transition mechanisms while IPv6 is being deployed 📚. that doc covers a much broader topic, while this one zooms in on a small slice of it 🦋.

2. Overview of the Technologies

these next sections introduce each technology analyzed here and cover some of its most important characteristics 💅.

2.1. 464XLAT

okay 464XLAT is a bit of a chameleon 🦎. depending on things like whether the apps use DNS and whether there's a DNS64 function (in the host or the service provider network), it can do double translation (stateless NAT46 + stateful NAT64) or single translation (stateful NAT64) 🌈.

the customer-side translator (CLAT) lives in the customer's device and does stateless NAT46 translation [RFC7915] (more precisely, a stateless IP/ICMP translation from IPv4 to IPv6) ✨. IPv4-embedded IPv6 addresses [RFC6052] are used for both source and destination addresses 💜. usually, a /96 prefix is used as the IPv6 destination for the IPv4-embedded client traffic, and that prefix is either the 64:ff9b::/96 Well-Known Prefix (WKP) or a Network-Specific Prefix 🫶.

if NAT64 load balancing is turned on (see Section 4.2 of [RFC7269]), multiple WKPs [RFC8215] can be used 🎀.

in the operator's network, the provider-side translator (PLAT) does stateful NAT64 [RFC6146] to translate the traffic 🔥. the destination IPv4 address gets pulled out of the IPv4-embedded IPv6 packet destination address, and the source address comes from a pool of public IPv4 addresses 🍓.

if there isn't a dedicated /64 available for translation, the CLAT device does a stateful NAT44 translation before the stateless NAT46 translation 🙈.

generally speaking, keeping state in devices close to the end user (like the CE (Customer Edge) router) isn't seen as nearly as problematic as keeping state in the operator's network 🧚.

in typical deployments, 464XLAT is used together with DNS64 [RFC6147]; see Section 3.1.2 of [RFC8683] 💖. when an IPv6-only client or app talks to an IPv4-only server, the DNS64 server returns the IPv4-embedded IPv6 address of that server 🌸. then the IPv6-only client sends out IPv6 packets, the CLAT acts as an IPv6 router, and the PLAT does stateful NAT64 on those packets. that's a single translation 💅.

the same goes the other way: when an IPv4-only client or app talks to an IPv4-only server, the CLAT statelessly translates to IPv6 so the traffic can cross the ISP network up to the PLAT (NAT64), which then translates it to IPv4 ✨.

or, put another way, DNS64 + stateful NAT64 carries the traffic of the IPv6-only client and the IPv4-only server, while the CLAT only handles IPv4 traffic from apps or devices that use literal IPv4 addresses or non-IPv6-compliant APIs 👑.

         Private +----------+ Translated  +----------+     _______
 +------+  IPv4  |   CLAT   |    4-6-4    |   PLAT   |    ( IPv4  )
 | IPv4 |------->| Stateless|------------>| Stateful +--( Internet )
 |Device|<-------|   NAT46  |<------------|   NAT64  |   (________)
 +------+        +----------+      ^      +----------+
                                   |
                             Operator IPv6
                               Network

Figure 1: Overview of the 464XLAT Architecture 🦋

a quick note: in mobile networks the CLAT usually runs in the user equipment (UE) or the smartphone, so check Figure 2 in [RFC6877] 📱.

some NAT64 vendors support direct communication (no translation involved) between two CLATs by hairpinning through the NAT64 🌈.

2.2. Dual-Stack Lite

Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the transition mechanisms we're looking at to get developed 👑. DS-Lite uses a Basic Bridging BroadBand (B4) function in the customer's CE router 🎀. that function encapsulates IPv4 in IPv6 traffic and sends it across the IPv6 native service provider network to an Address Family Transition Router (AFTR) 🧚. the AFTR handles the encapsulation/decapsulation of the 4in6 [RFC2473] traffic, and it translates the IPv4 source address in the inner IPv4 packet to a public IPv4 source address using a stateful NAPT44 [RFC2663] function 💅.

                                        +-------------+
       Private +----------+ IPv4-in-IPv6|Stateful AFTR|
+------+  IPv4  |    B4    |    Tunnel   |------+------+     _______
| IPv4 |------->| Encap./  |------------>|Encap.|      |    ( IPv4  )
|Device|<-------|  Decap.  |<------------|  /   | NAPT +--( Internet )
+------+        +----------+      ^      |Decap.|  44  |   (________)
                                 |      +------+------+
                           Operator IPv6
                             Network

Figure 2: Overview of the DS-Lite Architecture 💜

last bit for this part: some AFTR vendors support direct communication between two B4s by hairpinning through the AFTR 🫶.

that's part 1 done, bestie! 🌟 more parts are coming, so stay tuned for the next chunk 💖✨

2.3. Lightweight 4over6 🎀

okay bestie, lw4o6 (Lightweight 4over6) is basically DS-Lite's cooler cousin 💅 the big difference is that the stateful NAPT44 function moves out of the centralized AFTR and into the customer's B4 element, which is called an "lwB4" ✨ so the AFTR (now called an "lwAFTR") only does A+P (Address plus Port) routing [RFC6346] and 4in6 encapsulation/decapsulation. lowkey less work for the middle box 🧚

routing to the right client and sharing IPv4 addresses both work through the A+P model [RFC6346]. every lwB4 gets its own unique combo of an IPv4 address and a unique range of transport-layer ports, and the client uses those for NAPT44 🦋

the lwAFTR keeps a binding table with one entry per client. each entry links the customer's source IPv4 address and their allocated port range to their IPv6 tunnel endpoint address. this table is what lets egress traffic get validated (so nobody can spoof 🙅‍♀️), and it's how ingress traffic gets encapsulated and forwarded to the right place. since there's a per-client entry, an lwAFTR implementation needs to be optimized for doing a per-packet lookup on the binding table. no cap, that's a lot of lookups 💀

direct communication between two lwB4s (that is, without translation) happens by hairpinning the traffic through the lwAFTR 🔁

                  +-------------+             +----------+
          Private |    lwB4     | IPv4-in-IPv6| Stateless|
  +------+  IPv4  |------+------|    Tunnel   |  lwAFTR  |     _______
  | IPv4 |------->|      |Encap.|------------>|(encap/A+P|    ( IPv4  )
  |Device|<-------| NAPT |  /   |<------------|bind. tab +--( Internet )
  +------+        |  44  |Decap.|      ^      | routing) |   (________)
                  +------+------+      |      +----------+
                                Operator IPv6
                                    Network

               Figure 3: Overview of the lw4o6 Architecture

2.4. MAP-E 🌸

like 464XLAT (Section 2.1), MAP-E and MAP-T use IPv4-embedded IPv6 addresses [RFC6052] to represent IPv4 hosts that live outside the MAP domain. it's giving consistency 🫶

MAP-E and MAP-T use a stateless algorithm to squish portions of the customer's allocated IPv4 address (or part of an address when A+P routing is in play) into the IPv6 prefix delegated to the client. this means a huge number of clients can be provisioned using one single MAP rule, which is called a "MAP domain" 👑 the algorithm also lets hosts that share common MAP rules talk directly to each other over IPv4 peer-to-peer 💜

the CE router typically does stateful NAPT44 [RFC2663] to translate the private IPv4 source addresses and source ports into an address and port range. that range comes from applying the MAP rule to the delegated IPv6 prefix. the client address/port allocation size is a configuration parameter ⭐ then the CE router encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it either straight to another host in the MAP domain (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination isn't covered by any of the CE's MAP rules 🚀

the MAP BR gets provisioned with the set of MAP rules for the MAP domains it serves. those rules decide how the MAP BR decapsulates traffic it receives from the client, validates the source IPv4 address and transport-layer ports that were assigned, and works out the destination IPv6 address for ingress IPv4 traffic 🧠

                  +-------------+             +----------+
          Private |   MAP CE    | IPv4-in-IPv6| Stateless|
  +------+  IPv4  |------+------|    tunnel   |  MAP BR  |     _______
  | IPv4 |------->|      |Encap.|------------>|(encap/A+P|    ( IPv4  )
  |Device|<-------| NAPT |  /   |<------------|algorithm +--( Internet )
  +------+        |  44  |Decap.|      ^      | routing) |   (________)
                  +------+------+      |      +----------+
                                Operator IPv6
                                    Network

               Figure 4: Overview of the MAP-E Architecture

some BR vendors support direct communication between two MAP CEs by hairpinning through the BR 🔁

2.5. MAP-T 🦋

MAP-T uses the same mapping algorithm as MAP-E 🙌 the big difference is that it uses double stateless translation (NAT46 in the CE and NAT64 in the BR) to get across the ISP's IPv6 single-stack network. MAP-T can also be compared to 464XLAT when there's a double translation, so there's a family resemblance going on ✨

a MAP CE router typically does stateful NAPT44 to translate traffic to a public IPv4 address and port range. that range is calculated by applying the provisioned Basic MAP Rule (BMR) to the delegated IPv6 prefix. the BMR is a set of inputs to the algorithm 🧮 then the CE does stateless translation from IPv4 to IPv6 [RFC7915]. the MAP BR gets provisioned with the same BMR as the client, which means it can translate the received IPv6 traffic (using stateless NAT64) back to the public IPv4 source address the client used 💖

using translation instead of encapsulation also lets IPv4-only nodes talk directly to IPv6 nodes in the MAP-T domain that have IPv4-embedded IPv6 addresses 🌈

                  +-------------+             +----------+
          Private |   MAP CE    |  Translated | Stateless|
  +------+  IPv4  |------+------|    4-6-4    |  MAP BR  |     _______
  | IPv4 |------->|      |State-|------------>|(NAT64/A+P|    ( IPv4  )
  |Device|<-------| NAPT | less |<------------|algorithm +--( Internet )
  +------+        |  44  |NAT46 |      ^      | routing) |   (________)
                  +------+------+      |      +----------+
                                Operator IPv6
                                    Network

               Figure 5: Overview of the MAP-T Architecture

some BR vendors support direct communication between two MAP CEs by hairpinning through the BR 💅

3. High-Level Architectures and Their Consequences 🧩

3.1. Service Provider Network Traversal 🛣️

for the data plane, there are two approaches for getting across the IPv6 provider network:

  • 4-6-4 translation
  • 4in6 encapsulation
    +====================+=========+=========+=======+=======+=======+
    |                    | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
    +====================+=========+=========+=======+=======+=======+
    | 4-6-4 translation  |    X    |         |       |       |   X   |
    +--------------------+---------+---------+-------+-------+-------+
    | 4in6 encapsulation |         |    X    |   X   |   X   |       |
    +--------------------+---------+---------+-------+-------+-------+

                 Table 1: Available Traversal Mechanisms

in the scope of this document, all of the encapsulation-based mechanisms use IP-in-IP tunneling [RFC2473]. it's a stateless tunneling mechanism that doesn't need any extra overhead, so it's pretty chill 😌

it's worth noting that both of these approaches make the packet bigger when it's carried across the operator's network, compared to native IPv4. 4-6-4 translation adds a 20-byte overhead (the 20-byte IPv4 header gets replaced with a 40-byte IPv6 header). encapsulation has a 40-byte overhead (an IPv6 header gets prepended to the IPv4 header) 📦

the packet size increase can become a major problem if there's a link with a smaller MTU in the traffic path. that might mean the traffic needs to be fragmented at the ingress point to the IPv6-only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). it could also mean you have to implement buffering and fragment reassembly in the PLAT/AFTR/lwAFTR/BR node 😭

the advice in Section 8.3.1 of [RFC7597] applies to all of these mechanisms: it is strongly recommended that the MTU in the IPv6-only domain be well managed (it should have a sufficiently large MTU to support tunneling and/or translation), and that the IPv6 MTU on the CE WAN-side interface be set so that no fragmentation happens inside the boundary of the IPv6-only domain 🎯

3.2. Network Address Translation among the Different IPv4aaS Technologies 🔄

for the high-level solution of IPv6 service provider network traversal, MAP-T uses double stateless translation. the first translation is from IPv4 to IPv6 (NAT46) at the CE, and the second is from IPv6 to IPv4 (NAT64) at the service provider network 🫶

464XLAT may use double translation (stateless NAT46 + stateful NAT64) or single translation (stateful NAT64), depending on things like whether the applications use DNS and whether a DNS64 function is available (in the host or in the service provider network). for deployment guidelines, check out [RFC8683] 📚

the first step for the double translation mechanisms is a stateless NAT from IPv4 to IPv6, implemented as SIIT (Stateless IP/ICMP Translation Algorithm) [RFC7915]. it doesn't translate IPv4 header options and/or multicast IP/ICMP packets. with encapsulation-based technologies, the header gets transported intact, and multicast can be carried too 🌸

single and double translation both result in native IPv6 traffic with a transport-layer next header. the fields in those headers can be used for things like hashing across equal-cost multipaths or Access Control List (ACL) filtering 🔍 encapsulation technologies, on the other hand, may get in the way of hashing algorithms or anything else that relies on header inspection 🙈

solutions using double translation can only carry port-aware IP protocols (e.g., TCP and UDP) and ICMP when they're used with IPv4 address sharing (please refer to Section 4.3 for more details). encapsulation-based solutions can also carry any other protocols over IP 🧚

an in-depth analysis of stateful NAT64 can be found in [RFC6889] 🧐

as stateful NAT interferes with the port numbers, [NAT-SUPP] explains how NATs can handle SCTP (Stream Control Transmission Protocol) 💜

3.3. IPv4 Address Sharing 🦋

okay so public IPv4 address exhaustion is literally the reason everyone's rushing to IPv6, which means transition techs NEED a way to let public IPv4 addresses be shared 💅

To pull that off, a stateful NAPT function is a necessary function in all of the mechanisms. The big differentiator is where in the architecture that NAPT function lives 👑

The solutions in this doc fall into two categories:

  • Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)
  • Approaches based on A+P (lw4o6, MAP-E, MAP-T)

In the CGN-based model, a device such as a CGN/AFTR or NAT64 does the NAPT44 function and keeps per-session state for ALL of the active client's traffic. The customer's device doesn't need per-session state for NAPT at all 🫶

In the A+P-based model, a device (usually a CE) does stateful NAPT44 and only keeps per-session state for co-located devices, e.g., stuff in the customer's home network 🏠. Then the centralized network function (lwAFTR or BR) only has to do stateless encapsulation/decapsulation or NAT64. Very chill for the core 😌

Issues related to IPv4 address-sharing mechanisms are described in [RFC6269] and should also be considered, so don't skip that one bestie 📚

The address-sharing efficiency of the five technologies is significantly different, and we dig into it in Section 4.2. Spoiler: it's NOT the same across the board 👀

Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address sharing; see the details in Section 4.3. Real talk though, in that case there's no advantage in terms of public IPv4 address saving 💀. And for 464XLAT, one-to-one mapping can also be achieved through EAMT (Explicit Address Mapping Table) [RFC7757] ✨

Conversely, both MAP-E and MAP-T may be configured to provide more than one public IPv4 address (i.e., an address with an IPv4 prefix shorter than a /32) to customers. Giving someone a whole prefix instead of one address? That's a whole vibe 🌈

Dynamic DNS issues in address-sharing contexts, plus their possible solutions using PCP (Port Control Protocol), are discussed in detail in [RFC7393] 🧚

3.4. IPv4 Pool Size Considerations 🧮

Okay math time, but make it cute 🎀 In this section we do some simple calculations regarding port numbers. BUT technical limits aren't the only thing to think about for port sharing. There are also local regulations and best current practices, so don't just vibe-check the numbers 🙈

Note: By "port numbers", we mean TCP/UDP port numbers or ICMP identifiers.

In most networks, you can use existing data about flows to Content Delivery Networks (CDNs), caches, or other well-known IPv6-enabled destinations to calculate the percentage of traffic that would turn into IPv6 if IPv6 is enabled on that network or on part of it 📊

Knowing that, you can calculate the IPv4 pool size required for a given number of subscribers, depending on which IPv4aaS technology is being used 💖

According to [MIY2010], each user device (computer, tablet, smartphone) behind a NAT could simultaneously use up to 300 ports 📱. (Table 1 of [MIY2010] lists the port number usage of various applications. According to [REP2014], downloading some web pages may consume up to 200 port numbers 🌸.) If the extended NAPT algorithm is used, which includes the full 5-tuple in the connection tracking table, then port numbers get reused when the destinations are different. So we need to think about the number of "port-hungry" applications accessing the SAME destination at the same time 🤔. We estimate that for a residential subscriber there will typically be no more than four port-hungry applications communicating with the same destination simultaneously, which adds up to a total of 1,200 ports 🍓

For example, if 80% of the traffic is expected towards IPv6 destinations, only 20% will actually be using IPv4 ports. So in our example, 240 ports are required for each subscriber ✨

From the 65,535 ports available per IPv4 address, we could even consider reserving 1,024 ports for customers that need EAMT entries for incoming connections to System ports (0-1023, also called "well-known ports") [RFC7605] 🔐. This means that 64,511 ports are actually available for each IPv4 address 🧠

According to this, a /22 (1.024 public IPv4 addresses) will be sufficient for over 275,000 subscribers (1,024x64,511/240=275,246.93) 🎉

Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient for over 4,403,940 subscribers, and so on 🚀

This is a conservative approach, which is valid in the case of 464XLAT because ports are assigned dynamically by the NAT64. So it's not necessary to consider whether one user is actually using more or fewer ports. Average values work well here 😌

As the deployment of IPv6 progresses, the use of NAT64, and therefore of public IPv4 addresses, decreases (more IPv6 ports, fewer IPv4 ports). So either more subscribers can be accommodated with the same number of IPv4 addresses, or some of those addresses can be retired from the NAT64 ♻️

For comparison, if dual-stack is being used, any given number of users will require the same number of public IPv4 addresses. For instance, a /14 will provide 262,144 IPv4 public addresses for 262,144 subscribers, versus 275,000 subscribers being served with only a /22 😳

In the other IPv4aaS technologies, this calculation will only match if the assignment of ports per subscriber can be done dynamically, which is not always the case (depending on the vendor implementation) 🙃

When dynamic assignment of addresses is not possible, an alternative approximation for the other IPv4aaS technologies must ensure a sufficient number of ports per subscriber. That means 1,200 ports, and typically it comes to 2,000 ports in many deployments 💅. In that case, assuming 80% is IPv6 traffic (as above), only 30 subscribers will be allowed per each IPv4 address. So the closer approximation to 275,000 subscribers per our example with 464XLAT (with a /22) will be using a /19, which serves 245,760 subscribers (a /19 has 8,192 addresses and 30 subscribers with 2,000 ports each per address) 🧁

If the CGN (in the case of DS-Lite) or the CE (in the case of lw4o6, MAP-E, and MAP-T) makes use of a 5-tuple for tracking the NAT connections, the number of ports required per subscriber can be limited as low as four ports per subscriber 🤯. However, the practical limit depends on the desired limit for parallel connections that any single host behind the NAT can have to the same address and port on the Internet. Also, it's becoming more common for apps to use AJAX (Asynchronous JavaScript and XML) and similar mechanisms, so taking that extreme limit is probably NOT a safe choice 🙅‍♀️

This feature of an extremely reduced number of ports could also be used in case the CLAT-enabled CE with 464XLAT makes use of tracking 5-tuple NAT connections, and it could be further extended if the NAT64 also uses the 5-tuple 🦋

Please also refer to [RFC6888] for in-depth information about the requirements for sizing CGN gateways 📖

3.5. CE Provisioning Considerations 📬

All of the technologies require some provisioning of customer devices. The table below shows which methods currently have extensions for provisioning the different mechanisms 💌

   +==============+=========+=========+=========+==========+===========+
   |Provisioning  | 464XLAT | DS-Lite |  lw4o6  |  MAP-E   |   MAP-T   |
   |Method        |         |         |         |          |           |
   +==============+=========+=========+=========+==========+===========+
   |DHCPv6        |         |    X    |    X    |    X     |     X     |
   |[RFC8415]     |         |         |         |          |           |
   +--------------+---------+---------+---------+----------+-----------+
   |RADIUS        |         |[RFC6519]|    X    |    X     |     X     |
   |[RFC8658]     |         |         |         |          |           |
   +--------------+---------+---------+---------+----------+-----------+
   |TR-069        |    *    |    X    |    *    |    X     |     X     |
   |[TR-069]      |         |         |         |          |           |
   +--------------+---------+---------+---------+----------+-----------+
   |DNS64         |    X    |         |         |          |           |
   |[RFC7050]     |         |         |         |          |           |
   +--------------+---------+---------+---------+----------+-----------+
   |YANG [RFC7950]|[RFC8512]|[RFC8513]|[RFC8676]|[RFC8676] | [RFC8676] |
   +--------------+---------+---------+---------+----------+-----------+
   |DHCP 4o6      |         |         |    X    |    X     |           |
   |[RFC7341]     |         |         |         |          |           |
   +--------------+---------+---------+---------+----------+-----------+

Table 2: Available Provisioning Mechanisms

*: Work started at Broadband Forum (2021)

X: Supported by the provisioning method

3.6. Support for Multicast 📡

The solutions covered in this document are all intended for unicast traffic 💜. [RFC8114] describes a method for carrying encapsulated IPv4 multicast traffic over an IPv6 multicast network. This could be deployed in parallel to any of the operator's chosen IPv4aaS mechanisms 🌟

4. Detailed Analysis 🔍

4.1. Architectural Differences 🏗️

4.1.1. Basic Comparison 💫

The five IPv4aaS technologies can be classified based on two aspects:

  • Technology used for service provider network traversal. It can be single/double translation or encapsulation.
  • Presence or absence of per-flow state in the operator network.
    +====================+=========+=========+=======+=======+=======+
    |                    | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
    +====================+=========+=========+=======+=======+=======+
    | Translation (T) or |    T    |    E    |   E   |   E   |   T   |
    | Encapsulation (E)  |         |         |       |       |       |
    +--------------------+---------+---------+-------+-------+-------+
    | Presence (+) of    |    +    |    +    |       |       |       |
    | Per-Flow State in  |         |         |       |       |       |
    | Operator Network   |         |         |       |       |       |
    +--------------------+---------+---------+-------+-------+-------+

Table 3: Basic Comparison among the Analyzed Technologies

4.2. Trade-Off between Port Number Efficiency and Stateless Operation 💅

okay so 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, respectively 🧚 ngl this can cause scalability issues for the number of clients or the volume of traffic, but it doesn't limit the number of ports per user. the ports get allocated dynamically on-demand, and the allocation policy can be centrally managed and adjusted ✨

A+P-based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in the service provider network 🦋 but that means the number of ports given to each user (and so the effective IPv4 address-sharing ratio) has to be pre-provisioned to the client. it's giving planning energy 📋

changing the allocated port ranges with A+P-based technologies takes more planning and is likely to mean reprovisioning both hosts and operator-side equipment 🙈 bestie, also worth knowing: because lw4o6 uses a per-customer binding table entry, a single customer can be reprovisioned (for example, if they request a full IPv4 address) without changing parameters for a bunch of customers like you'd have to do in a MAP domain 💖

there's also a direct relationship between how efficiently public ports are allocated to customers and the logging overhead that might be needed to meet data-retention requirements. this is covered in Section 4.7 🌸

figuring out the optimal number of ports for a fixed port set is not an easy task 😭 it can also be affected by local regulatory law (and in the Belgian case, it's not a law but more of a memorandum of understanding or best current practice). that stuff may define a maximum number of users per IP address and therefore a minimum number of ports per user 📜

on one hand, the "lack of ports" situation can cause serious problems for certain applications 💀 for example, Miyakawa showed the consequences of the session number limitation caused by a port number shortage using Google Maps [MIY2010]. when the limit was 15, several blocks of the map were missing and the map was unusable 🗺️ that study also gave several examples of session numbers for different applications (the highest was Apple's iTunes at 230-270 ports) 🎵

the port number consumption of different applications is highly varying 🌈 for web browsing, it depends on a few things, including the web page you pick, the web browser, and sometimes the operating system [REP2014]. under certain conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux), and in other cases only 3-12 ports were used (URL: twitter.com, browser: Iceweasel under Debian Linux) 🍓

there may be several users behind a CE router, especially in the broadband case (e.g., the Internet is used by different members of a family at the same time) 👑 so enough ports must be allocated to avoid hurting user experience.

in general, assigning too few source port numbers to an end user can lead to unexpected and hard-to-debug consequences 😱 so if the number of ports per end user is fixed, we recommend assigning a conservatively large number of ports. for example, the developers of Jool used 2048 ports per user in their MAP-T example [JOOL-MAPT] 🫶

⚠️ however, assigning too many ports per CE router wastes public IPv4 addresses, which are scarce and expensive resources. this is a big advantage for 464XLAT, where addresses are dynamically managed. that means the sharing pool can be smaller, and the ports per user don't need to be pre-defined and aren't a limitation 💅

there's a direct trade-off between optimizing client port allocations and the associated logging overhead. Section 4.7 goes into this in more depth 🦋

we note that common NAT44 implementations using Netfilter at the CE router multiplex active sessions using a 3-tuple (source address, destination address, and destination port) 🧠 this means external source ports can be reused for unique internal source and destination addresses and port sessions. it's also noted that Netfilter can't currently make use of multiple source port ranges (several blocks of ports spread across the total port space, which is common in MAP deployments). this may influence the design when using stateless technologies 🎀

stateful technologies (464XLAT, DS-Lite, and NAT444) can therefore be much more efficient in terms of port allocation, and so in public IP address saving ✨ the price is the stateful operation in the service provider network, which allegedly doesn't scale up well 🥲 it should be noted that, in many cases, all of these factors may depend on how it's actually implemented 🛠️

measurements have started to examine how well a few stateful solutions scale in two areas:

  • how their performance scales with the number of CPU cores
  • to what extent their performance degrades with the number of concurrent connections

the details of the measurements and their results are available from [IPv4aaS-SCALE-TECH] 📊

we note that some CGN-type solutions can allocate ports dynamically "on the fly" 🏃‍♀️ depending on configuration, the same customer can end up being allocated ports from different source addresses. this can cause operational issues for protocols and applications that expect multiple flows to come from the same address (e.g., ECMP hashing, STUN, gaming, and content delivery networks) 😵 however, this is the same problem when a network has NAT44 with multiple public IPv4 addresses, or even when applications in a dual-stack setup misbehave if Happy Eyeballs is flapping the flow address between IPv4 and IPv6 🙃

the consequences of IPv4 address sharing [RFC6269] may impact all five technologies 🌍 but when ports are allocated statically, more customers may get ports from the same public IPv4 address, which can have negative consequences with higher probability. for example, many applications and service providers (Sony PlayStation Network, OpenDNS, etc.) can permanently block IPv4 ranges if they detect they're used for address sharing 🚫

both cases are, again, implementation-dependent 🤷‍♀️

we note that although it isn't typical, you can do deterministic, stateful NAT and reserve a fixed set of ports for each customer as well 🧸

4.3. Support for Public Server Operation 🖥️

mechanisms that rely on operator-side per-flow state don't, by themselves, give customers a way to present services on publicly accessible transport-layer ports 🙅‍♀️

the Port Control Protocol (PCP) [RFC6887] provides a mechanism for a client to request an external public port from a CGN device. for server operation, it is required with 464XLAT/NAT64, and it's supported in some DS-Lite AFTR implementations 💫

A+P-based mechanisms hand the client a public IPv4 address and a restricted range of transport-layer ports 🎁 in this case, the user can configure their device to offer a publicly accessible server on one of their allocated ports. it should be noted that operators commonly don't assign the well-known ports to users (unless they're allocating a full IPv4 address), so the user will need to run the service on an allocated port or configure port translation 🔧

lw4o6, MAP-E, and MAP-T may be configured to give clients a full IPv4 address, which allows exclusive use of all ports and non-port-based transport-layer protocols 👑 so they can also be used to support server/services operation on their default ports. however, when public IPv4 addresses are assigned to the CE router without address sharing, there's obviously no advantage in terms of saving public IPv4 addresses 😬

it's also possible to configure specific port mapping in 464XLAT/NAT64 using EAMT [RFC7757]. that means only those ports are "lost" from the address pool, so the total usage of IPv4 port resources is maximized more 📈

4.4. Support and Implementations 🛠️

4.4.1. Vendor Support 🏢

in general, router vendors support AFTR, MAP-E BR, MAP-T BR, and NAT64 💅 vendors of load balancers and firewalls usually support NAT64 as well, but not all of them support the other protocols 🤔

a 464XLAT client (CLAT) is implemented in Windows 10, Linux (including Android), Windows Mobile, Chrome OS, and iOS 📱 but it is not available in macOS 12.3.1 🙈

the remaining four solutions are commonly deployed only as functions in the CE device; however, vendor support is poor in general (except for DS-Lite) 😤

OpenWRT is a Linux-based open-source OS designed for CE devices 🌸 it offers a number of different 'opkg' packages as part of the distribution:

  • 464xlat enables support for 464XLAT CLAT functionality.
  • ds-lite enables support for DSLite B4 functionality.
  • map enables support for MAP-E and lw4o6 CE functionality.
  • map-t enables support for MAP-T CE functionality.

at the time of publication, some free open-source implementations exist for the operator-side functionality 🆓

  • Jool [JOOL] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR)
  • VPP/fd.io [VPP] (MAP-BR, lwAFTR, CGN, CLAT, NAT64)
  • Snabb [SNABB] (lwAFTR)
  • AFTR [AFTR] (DSLite AFTR)

4.4.2. Support in Cellular and Broadband Networks 📶

several cellular networks use 464XLAT, whereas there are no deployments of the other four technologies in cellular networks, since they aren't standardized or implemented in UE devices 📵

in broadband networks, there are some deployments of 464XLAT, MAP-E, and MAP-T 🏠 lw4o6 and DS-Lite have more deployments, with DS-Lite being the most common, but lw4o6 deployments have been rapidly increasing over the last few years 📈

please refer to Tables 2 and 3 of [LEN2019] for a limited set of deployment information 📚

4.4.3. Implementation Code Sizes 📏

as a hint to the relative complexity of the mechanisms, the code sizes reported from the OpenWRT implementations of each technology are 17 kB, 35 kB, 15 kB, 35 kB, and 48 kB for 464XLAT, lw4o6, DS-Lite, MAP-E, and MAP-T, respectively (see https://openwrt.org/packages/start) 🧮

we note that supporting all five technologies takes much less code than the total of those numbers, because they share a lot of common functions (e.g., the data plane is shared among several of them) 🧩

4.5. Typical Deployment and Traffic Volume Considerations 🚚

4.5.1. Deployment Possibilities 🗺️

theoretically, all five IPv4aaS technologies could be used together with DNS64 + stateful NAT64, as is done in 464XLAT 🤯 in this case, the CE router would treat traffic between an IPv6-only client and an IPv4-only server as normal IPv6 traffic, and the stateful NAT64 gateway would do a single translation. that offloads this kind of traffic from the IPv4aaS technology ✨ the cost of this solution is the need to also deploy DNS64 + stateful NAT64 💸

however, this hasn't been implemented in clients or actual deployments 😭 so only 464XLAT always uses this optimization, and the other four solutions don't use it at all 🫶

4.5.2. Cellular Networks with 464XLAT ✨

Okay so, bestie, here are the real numbers from existing deployments (through the end of 2018) for typical traffic in an IPv6-only cellular network that uses 464XLAT together with DNS64 🥹📱:

  • 75% of traffic is IPv6 end-to-end (no translation). 💖
  • 24% of traffic uses DNS64 + NAT64 (one translation). 🦋
  • Less than 1% of traffic uses the CLAT in addition to NAT64 (two translations), due to an IPv4 socket and/or IPv4 literal. 🙈

Without using DNS64, 25% of the traffic would undergo double translation. Yikes 💀

4.5.3. Wireline Networks with 464XLAT 🌸

Now for the wireline side! These figures come from several existing deployments (through the end of 2020), mostly with residential customers, and they show the ranges of typical traffic in an IPv6-only network when 464XLAT is used with DNS64 🧚:

  • 65%-85% of traffic is IPv6 end-to-end (no translation). ✨
  • 14%-34% of traffic uses DNS64 + NAT64 (one translation). 🌈
  • Less than 1-2% of traffic uses the CLAT in addition to NAT64 (two translations), due to an IPv4 socket and/or IPv4 literal. 🍓

Without using DNS64, 16%-35% of the traffic would undergo double translation. 😭

This data lines up with non-public information from real deployments, and honestly it makes sense once you see why. When a wireline ISP mostly has residential customers, the IPv6-enabled content providers and CDNs (Google/YouTube, Netflix, Facebook, Akamai, etc.) usually account for 65-85% of the traffic on the network. So when the subscribers are IPv6 enabled, about the same percentage of traffic ends up being IPv6. It's giving math that checks out 👑

4.6. Load Sharing 🦋

Okay, so if you need several network-side devices working as PLAT/AFTR/BR for capacity, you need a load-sharing mechanism. ECMP (Equal-Cost Multipath) load sharing can be used for all technologies, bestie. The catch is that stateful technologies get affected by changes in network topology or device failure 😬

Technologies that use DNS64 can also spread load across PLAT/AFTR devices, either evenly or unevenly, by using different prefixes. Different network-specific prefixes can be handed out to subscribers in appropriately sized segments. This is like split-horizon DNS, which is also called "DNS views" 🌷

Stateless technologies don't keep per-flow state, so they can use anycast routing for load sharing and resiliency across network devices, both ingress and egress. The result is that flows can take asymmetric paths through the network, meaning they go in through one lwAFTR/BR and come out through another. Main character routing 🧚‍♀️

Mechanisms with centralized NAPT44 state have a bunch of challenges around scaling and resilience. Once the total amount of client traffic is more than a single CGN instance can handle, you need additional nodes. Each CGN keeps a stateful table of active client sessions, and that table may need to be synchronized between CGN instances. This matters for two reasons:

  • To prevent all active customer sessions from being dropped in the event of a CGN node failure. 😱
  • To ensure a matching state table entry for an active session in the event of asymmetric routing through different egress and ingress CGN nodes. 🫶

4.7. Logging 📝

With 464XLAT and DS-Lite, the user behind any given public IPv4 address and port combination changes over time. That's why logging is necessary to meet data-retention laws 🔍 Each entry in the PLAT/AFTR generates a logging entry. As discussed in Section 4.2, a client can open hundreds of sessions during everyday stuff like web browsing, and each one needs to be logged. So the overall logging burden on the network operator is significant. In some countries, this level of logging is required to comply with data-retention legislation 🥲

One common optimization for cutting down on logging overhead is allocating a block of ports to a client for the duration of their session. A logging entry then only needs to be made when the client's port block is released, which dramatically reduces the overhead 🙌 The tradeoff is less efficient public address sharing, since clients get a port block of a fixed size whether or not they actually use all those ports.

Stateless technologies that pre-allocate IPv4 addresses and ports only need to keep copies of the active MAP rules (for MAP-E and MAP-T) or the binding table (for lw4o6), along with timestamp information about when they were active. Support tools (for example, the ones used to serve data-retention requests) may need updating so they know which mechanism is in use. For example, they might implement the MAP algorithm so IPv4 information can be linked to the IPv6 prefix delegated to a client. Stateless technologies don't have a centralized stateful element that customer traffic has to pass through. So if data-retention laws mandate per-session logging, there's no simple way to meet that requirement with a stateless technology alone. Thus, a centralized NAPT44 model may be the only way to meet this requirement 💜

Deterministic CGN [RFC7422] was proposed as a solution to reduce the resource consumption of logging. 🧠

Please also refer to Section 4 of [RFC6888] for more information about requirements for logging CGN gateways. 📚

4.8. Optimization for IPv4-Only Devices and Applications 💅

When IPv4-only devices or applications sit behind a CE that's connected with IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily be encapsulated/decapsulated (in the case of DS-Lite, lw4o6, and MAP-E). They'll reach the IPv4 address of the destination, even if that service supports dual-stack. This means the traffic flow crosses through the AFTR, lwAFTR, or BR, depending on which transition mechanism is being used 🌀

Even if those services are directly connected to the operator network (like CDNs and caches) or located internally (like VoIP, etc.), it's not possible to avoid that overhead 😤

However, for the mechanisms that use a NAT46 function in the CE (464XLAT and MAP-T), you can take advantage of optimization functionalities, such as the ones described in [OP-464XLAT/MAP-T]. ✨

Here's the glow-up part: because the NAT46 has already translated the IPv4-only flow to IPv6, and the services are dual-stack, these optimizations let the services be reached without translating the flow back to IPv4. Iconic 👑

5. Performance Comparison 🔥

We plan to compare the performance of the most prominent free software implementations of the five IPv6 transition technologies, using the methodology described in "Benchmarking Methodology for IPv6 Transition Technologies" [RFC8219]. 📊

The dual Device Under Test (DUT) setup of [RFC8219] makes it possible to use existing measurement devices that comply with "Benchmarking Methodology for Network Interconnect Devices" [RFC2544]. It does come with two kinds of limitations though 🫠

  • The dual DUT setup has the drawback that the performance of the CE and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT) gets measured together. To measure the performance of only one of them, we need to make sure the one we want is the bottleneck.
  • Measurement procedures for Packet Delay Variation (PDV) and Inter-Packet Delay Variation (IPDV) are missing from the legacy devices, and the old latency measurement procedure has been redefined in [RFC8219].

The single DUT setup of [RFC8219] makes it possible to benchmark the selected device on its own. But you either need a special Tester, or some trick if you want to use legacy Testers. An example of the latter is our stateless NAT64 measurements testing Throughput and Frame Loss Rate, using a legacy commercial Tester [LEN2020a] that complies with [RFC5180]. 🧪

Siitperf is a DPDK-based software Tester that complies with [RFC8219] and is used for benchmarking stateless NAT64 gateways. It was developed recently. Siitperf is available from GitHub [SIITPERF] as free software and is documented in [LEN2021]. Originally, it literally followed the test frame format of [RFC2544], including "hard-wired" source and destination port numbers. Then it was complemented with the pseudorandom port feature required by [RFC4814]. The new version is documented in [LEN2020b]. 🛠️

Further DPDK-based software Testers that comply with [RFC8219] are being developed at the Budapest University of Technology and Economics as student projects. They are planned to be released as free software, too 🎓

Information about the benchmarking tools, measurements, and results will be made available in [IPv4aaS-BENCHMARK-TECH]. 🎀

6. IANA Considerations 🎀

This document has no IANA actions. 🤍

7. Security Considerations 🔒

Okay, this section is serious business, bestie 😤 As discussed in Section 4.7, the different technologies have varying logging capabilities and limitations. Care should be taken when storing, transmitting, and providing access to log entries that may be considered personally identifiable information. It should be noted, though, that those issues aren't specific to the IPv4aaS IPv6 transition technologies. They apply to logging functionalities in general.

For all five technologies, the CE device typically contains a DNS proxy. However, the user may change DNS settings. If this happens and lw4o6, MAP-E, and MAP-T are used with a significantly restricted port set (which is required for efficient public IPv4 address sharing), the entropy of the source ports is significantly lowered. For example, it drops from 16 bits to 10 bits when 1024 port numbers are assigned to each subscriber. These technologies are therefore theoretically less resilient against cache poisoning (see [RFC5452]) 🚨 However, an efficient cache poisoning attack requires that the subscriber operates its own caching DNS server and that the attack is performed in the service provider network. So we consider the chance of successfully exploiting this vulnerability to be low 🫶

IPv4aaS technologies based on encapsulation have no DNSSEC implications. However, those based on translation may have implications, as discussed in Section 4.1 of [RFC8683]. 🔐

An in-depth security analysis of all five IPv6 transition technologies and their most prominent free software implementations, according to the methodology defined in [LEN2018], is planned. 🕵️‍♀️

As the first step, an initial security analysis of 464XLAT was done in [AZZ2021]. 🧐

Implementers of any of the five IPv4aaS solutions should consult the Security Considerations of the respective RFCs documenting them. Read the fine print, bestie 💖

8. References 📚

8.1. Normative References 📚✨

okay bestie, these are the docs the main text leans on the hardest 💅 here's the whole normative list 🫶

[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.

[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.

[RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", RFC 4814, DOI 10.17487/RFC4814, March 2007, <https://www.rfc-editor.org/info/rfc4814>.

[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, <https://www.rfc-editor.org/info/rfc5180>.

[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[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, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.

[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, DOI 10.17487/RFC6180, May 2011, <https://www.rfc-editor.org/info/rfc6180>.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.

[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <https://www.rfc-editor.org/info/rfc6346>.

[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 2012, <https://www.rfc-editor.org/info/rfc6519>.

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.

[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.

[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, DOI 10.17487/RFC6889, April 2013, <https://www.rfc-editor.org/info/rfc6889>.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.

[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, <https://www.rfc-editor.org/info/rfc7269>.

[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>.

[RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, "Using the Port Control Protocol (PCP) to Update Dynamic DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, <https://www.rfc-editor.org/info/rfc7393>.

[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", RFC 7422, DOI 10.17487/RFC7422, December 2014, <https://www.rfc-editor.org/info/rfc7422>.

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.

[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <https://www.rfc-editor.org/info/rfc7599>.

[RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, <https://www.rfc-editor.org/info/rfc7605>.

[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <https://www.rfc-editor.org/info/rfc7757>.

[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", RFC 8114, DOI 10.17487/RFC8114, March 2017, <https://www.rfc-editor.org/info/rfc8114>.

[RFC8215] Anderson, T., "Local-Use IPv4/IPv6 Translation Prefix", RFC 8215, DOI 10.17487/RFC8215, August 2017, <https://www.rfc-editor.org/info/rfc8215>.

[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", RFC 8219, DOI 10.17487/RFC8219, August 2017, <https://www.rfc-editor.org/info/rfc8219>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.

[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, <https://www.rfc-editor.org/info/rfc8513>.

[RFC8658] Jiang, S., Ed., Fu, Y., Ed., Xie, C., Li, T., and M. Boucadair, Ed., "RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)", RFC 8658, DOI 10.17487/RFC8658, November 2019, <https://www.rfc-editor.org/info/rfc8658>.

[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, DOI 10.17487/RFC8676, November 2019, <https://www.rfc-editor.org/info/rfc8676>.

[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks", RFC 8683, DOI 10.17487/RFC8683, November 2019, <https://www.rfc-editor.org/info/rfc8683>.

8.2. Informative References ✨

okay bestie, this is the extra reading list 📚🦋 These are the informative refs. You don't need them to get the spec, but if you want to go deep, they're giving rabbit hole in the best way 💜

Acknowledgements

the authors gave a huge shoutout 🫶 to Ole Troan, Warren Kumari, Dan Romascanu, Brian Trammell, Joseph Salowey, Roman Danyliw, Erik Kline, Lars Eggert, Zaheduzzaman Sarker, Robert Wilton, Éric Vyncke and Martin Duke for reviewing the document ✨ They also thanked everyone who contributed inputs: Mark Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, Yutianpeng (Tim), Mohamed Boucadair, Nick Hilliard, Joel Jaeggli, Kristian McColm, Tom Petch, Yannis Nikolopoulos, Havard Eidnes, Yann-Ju Chu, Barbara Stark, Vasilenko Eduard, Chongfeng Xie, Henri Alves de Godoy, Magnus Westerlund, Michael Tüxen, Philipp S. Tiesel, Brian E. Carpenter, and Joe Touch. Everyone on this list is iconic 👑

Authors' Addresses

Gábor Lencse 🌸

Gábor Lencse
Budapest University of Technology and Economics
Budapest
Magyar tudósok körútja 2
H-1117
Hungary
Email: lencse@hit.bme.hu
URI:   http://www.hit.bme.hu/~lencse/index_en.htm

Jordi Palet Martinez 🦋

Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar Madrid
Spain
Email: jordi.palet@theipv6company.com
URI:   http://www.theipv6company.com/

Lee Howard 🧚

Lee Howard
Retevia
9940 Main St., Suite 200
Fairfax, Virginia 22031
United States of America
Email: lee@asgard.org

Richard Patterson 💜

Richard Patterson
Sky UK
1 Brick Lane
London
EQ 6PU
United Kingdom
Email: richard.patterson@sky.uk

Ian Farrer 🎀

Ian Farrer
Deutsche Telekom AG
Landgrabenweg 151
53227 Bonn
Germany
Email: ian.farrer@telekom.de
📦 where this page comes from