Pros and Cons of IPv6 Transition Technologies for IPv4aaS

2.1. 464XLAT

464XLAT may use double translation (stateless NAT46 + stateful NAT64) or single translation (stateful NAT64), depending on different factors, such as the use of DNS by the applications and the availability of a DNS64 function (in the host or in the service provider network).¶

The customer-side translator (CLAT) is located in the customer's device, and it performs 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. Commonly, a /96 prefix (either the 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used as the IPv6 destination for the IPv4-embedded client traffic.¶

In deployments where NAT64 load-balancing [RFC7269] section 4.2 is enabled, multiple WKPs [RFC8215] may be used.¶

In the operator's network, the provider-side translator (PLAT) performs stateful NAT64 [RFC6146] to translate the traffic. The destination IPv4 address is extracted from the IPv4-embedded IPv6 packet destination address and the source address is from a pool of public IPv4 addresses.¶

Alternatively, when a dedicated /64 is not available for translation, the CLAT device uses a stateful NAT44 translation before the stateless NAT46 translation.¶

In general, keeping state in devices close to the end-user network (i.e. at the CE - Customer Edge router) is not perceived 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 application communicates with an IPv4-only server, the DNS64 server returns the IPv4-embedded IPv6 address of the IPv4-only server. In this case, the IPv6-only client sends out IPv6 packets, and the CLAT functions as an IPv6 router and the PLAT performs a stateful NAT64 for these packets. In this case, there is a single translation.¶

Similarly, when an IPv4-only client or application communicates with an IPv4-only server, the CLAT will statelessly translate to IPv6 so it can traverse the ISP network up to the PLAT (NAT64), which in turn will translate to IPv4.¶

Alternatively, one can say that DNS64 + stateful NAT64 is used to carry the traffic of the IPv6-only client and the IPv4-only server, and the CLAT is used only for the IPv4 traffic from applications 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

Note: in mobile networks, CLAT is commonly implemented in the user's equipment (UE or smartphone), please refer to Figure 2 of [RFC6877].¶

Often NAT64 vendors support direct communication (that is, without translation) between two CLATs by means of hair-pinning through the NAT64.¶

2.2. Dual-Stack Lite

Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered transition mechanisms to be developed. DS-Lite uses a 'Basic Bridging BroadBand' (B4) function in the customer's CE router that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native service-provider network to an 'Address Family Transition Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 4in6 [RFC2473] traffic and translates the IPv4 source address in the inner IPv4 packet to 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

Some AFTR vendors support direct communication between two B4s by means of hair-pinning through the AFTR.¶

2.3. Lightweight 4over6

Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main difference is that the stateful NAPT44 function is relocated from the centralized AFTR to the customer's B4 element (called a lwB4). The AFTR (called a lwAFTR) function therefore only performs A+P routing [RFC6346] and 4in6 encapsulation/decapsulation.¶

Routing to the correct client and IPv4 address sharing is achieved using the Address + Port (A+P) model [RFC6346] of provisioning each lwB4 with a unique tuple of IPv4 address and a unique range of transport layer ports. The client uses these for NAPT44.¶

The lwAFTR implements a binding table, which has a per-client entry linking the customer's source IPv4 address and allocated range of transport layer ports to their IPv6 tunnel endpoint address. The binding table allows egress traffic from customers to be validated (to prevent spoofing) and ingress traffic to be correctly encapsulated and forwarded. As there needs to be a per-client entry, an lwAFTR implementation needs to be optimized for performing a per-packet lookup on the binding table.¶

Direct communication (that is, without translation) between two lwB4s is performed by hair-pinning 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

2.4. MAP-E

Like 464XLAT (Section 2.1), MAP-E and MAP-T use [RFC6052] IPv4-embedded IPv6 addresses to represent IPv4 hosts outside the MAP domain.¶

MAP-E and MAP-T use a stateless algorithm to embed portions of the customer's allocated IPv4 address (or part of an address with A+P routing) into the IPv6 prefix delegated to the client. This allows for large numbers of clients to be provisioned using a single MAP rule (called a MAP domain). The algorithm also allows for direct IPv4 peer-to-peer communication between hosts provisioned with common MAP rules.¶

The CE (Customer-Edge) router typically performs stateful NAPT44 [RFC2663] to translate the private IPv4 source addresses and source ports into an address and port range defined by applying the MAP rule to the delegated IPv6 prefix. The client address/port allocation size is a configuration parameter. The CE router then encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it directly to another host in the MAP domain (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is not covered in one of the CE's MAP rules.¶

The MAP BR is provisioned with the set of MAP rules for the MAP domains it serves. These rules determine how the MAP BR is to decapsulate traffic that it receives from client, validating the source IPv4 address and transport layer ports assigned, as well as how to calculate 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

Some BR vendors support direct communication between two MAP CEs by means of hair-pinning through the BR.¶

2.5. MAP-T

MAP-T uses the same mapping algorithm as MAP-E. The major difference is that double stateless translation (NAT46 in the CE and NAT64 in the BR) is used to traverse the ISP's IPv6 single-stack network. MAP-T can also be compared to 464XLAT when there is a double translation.¶

A MAP CE router typically performs stateful NAPT44 to translate traffic to a public IPv4 address and port-range calculated by applying the provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) to the delegated IPv6 prefix. The CE then performs stateless translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned with the same BMR as the client, enabling the received IPv6 traffic to be statelessly NAT64 translated back to the public IPv4 source address used by the client.¶

Using translation instead of encapsulation also allows IPv4-only nodes to correspond directly with 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

Some BR vendors support direct communication between two MAP CEs by means of hair-pinning through the BR.¶

3.1. Service Provider Network Traversal

For the data-plane, there are two approaches for traversing the IPv6 provider network:¶

• 4-6-4 translation¶
• 4-in-6 encapsulation¶

In the scope of this document, all of the encapsulation based mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless tunneling mechanism which does not require any additional overhead.¶

It should be noted that both of these approaches result in an increase in the size of the packet that needs to be transported across the operator's network when compared to native IPv4. 4-6-4 translation adds a 20-bytes overhead (the 20-byte IPv4 header is replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte overhead (an IPv6 header is prepended to the IPv4 header).¶

The increase in packet size can become a significant problem if there is a link with a smaller MTU in the traffic path. This may result in traffic needing to be fragmented at the ingress point to the IPv6 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also result in the need to implement buffering and fragment re-assembly in the PLAT/AFTR/lwAFTR/BR node.¶

The advice given in [RFC7597] Section 8.3.1 is applicable to all of these mechanisms: It is strongly recommended that the MTU in the IPv6-only domain be well managed (it should have 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 occurs within 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. First at the CE from IPv4 to IPv6 (NAT46), and then 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 different factors, such as the use of DNS by the applications and the availability of a DNS64 function (in the host or in the service provider network). For deployment guidelines, please refer to [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], which does not translate IPv4 header options and/or multicast IP/ICMP packets. With encapsulation-based technologies the header is transported intact and multicast can also be carried.¶

Single and double translation results in native IPv6 traffic with a transport layer next-header. The fields in these headers can be used for functions such as hashing across equal-cost multipaths or access control list (ACL) filtering. Encapsulation technologies, in contrast, may hinder hashing algorithms or other functions relying on header inspection.¶

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

An in-depth analysis of stateful NAT64 can be found in [RFC6889].¶

As stateful NAT interferes with the port numbers, [I-D.ietf-tsvwg-natsupp] explains how NATs can handle SCTP (Stream Control Transmission Protocol).¶

3.3. IPv4 Address Sharing

As public IPv4 address exhaustion is a common motivation for deploying IPv6, transition technologies need to provide a solution for allowing public IPv4 address sharing.¶

In order to fulfill this requirement, a stateful NAPT function is a necessary function in all of the mechanisms. The major differentiator is where in the architecture this function is located.¶

The solutions compared by this document fall into two categories:¶

• CGN-based approaches (DS-Lite, 464XLAT)¶
• A+P-based approaches (lw4o6, MAP-E, MAP-T)¶

In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs the NAPT44 function and maintains per-session state for all of the active client's traffic. The customer's device does not require per-session state for NAPT.¶

In the A+P-based model, a device (usually a CE) performs stateful NAPT44 and maintains per-session state only co-located devices, e.g. in the customer's home network. Here, the centralized network function (lwAFTR or BR) only needs to perform stateless encapsulation/decapsulation or NAT64.¶

Issues related to IPv4 address sharing mechanisms are described in [RFC6269] and should also be considered.¶

The address sharing efficiency of the five technologies is significantly different, it is discussed in Section 4.2.¶

lw4o6, MAP-E and MAP-T can also be configured without IPv4 address sharing, see the details in Section 4.3. However, in that case, there is no advantage in terms of public IPv4 address saving. In the case of 464XLAT, this can be achieved as well 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 IPv4 prefix shorter than a /32) to customers.¶

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

3.4. IPv4 Pool Size Considerations

In this section we do some simple calculations regarding port numbers, however, technical limitations are not the only point to consider for port sharing, there are also local regulations or BCP.¶

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

In most networks, it is possible to, using existing data about flows to CDNs/caches or other well-known IPv6-enabled destinations, calculate the percentage of traffic that would turn into IPv6 if it is enabled on that network or part of it.¶

Knowing that, it is possible to calculate the IPv4 pool size required for a given number of subscribers, depending on the IPv4aaS technology 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] the downloading of some web pages may consume up to 200 port numbers.) If the extended NAPT algorithm is used, which includes the full five tuple into the connection tracking table, then the port numbers are reused, when the destinations are different. Therefore, we need to consider the number of "port hungry" applications that are accessing the same destination simultaneously. We estimate that in the case of a residential subscriber, there will be typically no more than 4 of port hungry applications communicating with the same destination simultaneously, which means a total of 1,200 ports.¶

If for example, 80% of the traffic is expected towards IPv6 destinations, only 20% will actually be using IPv4 ports, so in our example, that will mean 240 ports required per subscriber.¶

From the 65,535 ports available per IPv4 address, we could even consider reserving 1,024 ports, in order to allow customers that need EAMT entries for incoming connections to System Ports (0-1023, also called well-known ports) [RFC7605], which means 64,511 ports actually available per 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 is not necessary to consider if one user is actually using more or less ports: Average values work well.¶

As the deployment of IPv6 progresses, the use of NAT64, and therefore of public IPv4 addresses, decreases (more IPv6/ports, less IPv4/ports), so either more subscribers can be accommodated with the same number of IPv4 addresses, or some of those addressed 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).¶

An alternative approximation for the other IPv4aaS technologies, when dynamically assignment of addresses is not possible, must ensure 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% of IPv6 traffic, as above, which will allow only 30 subscribers 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, 30 subscribers with 2,000 ports each, per address).¶

If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E and MAP-T) make use of a 5-tuple for tracking the NAT connections, the number of ports required per subscriber can be limited as low as 4 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 in Internet. Note that it is becoming more common that applications use AJAX (Asynchronous JavaScript and XML) and similar mechanisms, so taking that extreme limit is probably not a safe choice.¶

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

Please also refer to [RFC6888] for in-depth information about the requirements for sizing Carrier-Grade NAT 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.¶

*: 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 mechanism.¶