Budapest University of Technology and Economics

Magyar tudósok körútja 2 Budapest H-1117 Hungary lencse@hit.bme.hu http://www.hit.bme.hu/~lencse/index_en.htm

The IPv6 Company

Molino de la Navata, 75 La Navata - Galapagar Madrid 28420 Spain jordi.palet@theipv6company.com http://www.theipv6company.com/

Retevia

9940 Main St., Suite 200 Fairfax Virginia 22031 United States of America lee@asgard.org

Sky UK

1 Brick Lane London EQ 6PU United Kingdom richard.patterson@sky.uk

Deutsche Telekom AG

Landgrabenweg 151 Bonn 53227 Germany ian.farrer@telekom.de

ops v6ops IPv6 Transition Technologies Comparison IPv4aaS IPv6-only 464XLAT DNS64 Dual-Stack Lite Lightweight 4over6 MAP-E MAP-T Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs.

Status of This Memo This document is not an Internet Standards Track specification; it is 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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2022 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 () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Overview of the Technologies
  • .  464XLAT
  • .  Dual-Stack Lite
  • .  Lightweight 4over6
  • .  MAP-E
  • .  MAP-T
• .  High-Level Architectures and Their Consequences
  • .  Service Provider Network Traversal
  • .  Network Address Translation among the Different IPv4aaS Technologies
  • .  IPv4 Address Sharing
  • .  IPv4 Pool Size Considerations
  • .  CE Provisioning Considerations
  • .  Support for Multicast
• .  Detailed Analysis
  • .  Architectural Differences
    • .  Basic Comparison
  • .  Trade-Off between Port Number Efficiency and Stateless Operation
  • .  Support for Public Server Operation
  • .  Support and Implementations
    • .  Vendor Support
    • .  Support in Cellular and Broadband Networks
    • .  Implementation Code Sizes
  • .  Typical Deployment and Traffic Volume Considerations
    • .  Deployment Possibilities
    • .  Cellular Networks with 464XLAT
    • .  Wireline Networks with 464XLAT
  • .  Load Sharing
  • .  Logging
  • .  Optimization for IPv4-Only Devices and Applications
• .  Performance Comparison
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction As the deployment of IPv6 continues to be prevalent, it becomes clearer that network operators will move to building single-stack IPv6 core and access networks to simplify network planning and operations. However, providing customers with IPv4 services continues to be a requirement for the foreseeable future. To meet this need, the IETF has standardized a number of different IPv4aaS technologies for this (see ) based on differing requirements and deployment scenarios. The number of technologies that have been developed makes it time-consuming for a network operator to identify the most appropriate mechanism for their specific deployment. This document provides a comparative analysis of the most commonly used mechanisms to assist operators with this problem. Five different IPv4aaS solutions are considered:

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

We note that gives guidelines for using IPv6 transition mechanisms during IPv6 deployment; that document addresses a much broader topic, whereas this document focuses on a small part of it.

Overview of the Technologies The following sections introduce the different technologies analyzed in this document and describe some of their most important characteristics.

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 service provider network). The customer-side translator (CLAT) is located in the customer's device, and it performs stateless NAT46 translation (more precisely, a stateless IP/ICMP translation from IPv4 to IPv6). IPv4-embedded IPv6 addresses are used for both source and destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96 Well-Known Prefix (WKP) or a Network-Specific Prefix) is used as the IPv6 destination for the IPv4-embedded client traffic. In deployments where NAT64 load balancing (see ) is enabled, multiple WKPs may be used. In the operator's network, the provider-side translator (PLAT) performs stateful NAT64 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 to be as problematic as keeping state in the operator's network. In typical deployments, 464XLAT is used together with DNS64 ; see . 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, the CLAT functions as an IPv6 router, and the PLAT performs a stateful NAT64 for these packets. 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.

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

Note: In mobile networks, the CLAT is commonly implemented in the user equipment (UE) or smartphone; please refer to Figure 2 in . Some NAT64 vendors support direct communication (that is, without translation) between two CLATs by means of hairpinning through the NAT64.

Dual-Stack Lite Dual-Stack Lite (DS-Lite) 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 traffic and translates the IPv4 source address in the inner IPv4 packet to a public IPv4 source address using a stateful NAPT44 function.

Overview of the DS-Lite Architecture +-------------+ 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 hairpinning through the AFTR.

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 an "lwB4"). The AFTR (called an "lwAFTR") function therefore only performs A+P (Address plus Port) routing and 4in6 encapsulation/decapsulation. Routing to the correct client and IPv4 address sharing are achieved using the A+P model 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 an 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 hairpinning traffic through the lwAFTR.

Overview of the lw4o6 Architecture +-------------+ +----------+ 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

MAP-E Like 464XLAT (), MAP-E and MAP-T use 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 direct IPv4 peer-to-peer communication between hosts provisioned with common MAP rules. The CE router typically performs stateful NAPT44 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 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 the client, validate the source IPv4 address and transport-layer ports assigned, and calculate the destination IPv6 address for ingress IPv4 traffic.

Overview of the MAP-E Architecture +-------------+ +----------+ 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 hairpinning through the BR.

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), which is a set of inputs to the algorithm, to the delegated IPv6 prefix. The CE then performs stateless translation from IPv4 to IPv6 . The MAP BR is provisioned with the same BMR as the client, enabling the received IPv6 traffic to be translated (using stateless NAT64) 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.

Overview of the MAP-T Architecture +-------------+ +----------+ 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 hairpinning through the BR.

High-Level Architectures and Their Consequences

Service Provider Network Traversal For the data plane, there are two approaches for traversing the IPv6 provider network:

• 4-6-4 translation
• 4in6 encapsulation

Available Traversal Mechanisms

	464XLAT	DS-Lite	lw4o6	MAP-E	MAP-T
4-6-4 translation	X				X
4in6 encapsulation		X	X	X

In the scope of this document, all of the encapsulation-based mechanisms use IP-in-IP tunneling . This is a stateless tunneling mechanism that 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-byte 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 the need for traffic 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 reassembly in the PLAT/AFTR/lwAFTR/BR node. The advice given in 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.

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 translation 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 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 . The first step for the double translation mechanisms is a stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Translation Algorithm) , 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 and UDP) and ICMP when they are used with IPv4 address sharing (please refer to 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 . As stateful NAT interferes with the port numbers, explains how NATs can handle SCTP (Stream Control Transmission Protocol).

IPv4 Address Sharing As public IPv4 address exhaustion is a common motivation for deploying IPv6, transition technologies need to provide a solution that allows 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:

• 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 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 for 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 and should also be considered. The address-sharing efficiency of the five technologies is significantly different and is discussed in . Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address sharing; see the details in . However, in that case, there is no advantage in terms of public IPv4 address saving. In the case of 464XLAT, one-to-one mapping can also be achieved through EAMT (Explicit Address Mapping Table) . 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. Dynamic DNS issues in address-sharing contexts and their possible solutions using PCP (Port Control Protocol) are discussed in detail in .

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 and best current practices. Note: By "port numbers", we mean TCP/UDP port numbers or ICMP identifiers. In most networks, it is possible to 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, 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 , each user device (computer, tablet, smartphone) behind a NAT could simultaneously use up to 300 ports. (Table 1 of lists the port number usage of various applications. According to , the downloading of some web pages may consume up to 200 port numbers.) If the extended NAPT algorithm is used, which includes the full 5-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 four port-hungry applications communicating with the same destination simultaneously, which is 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. Thus, 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") . 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. Therefore, it is not necessary to consider if one user is actually using more or fewer 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, fewer IPv4 ports). Thus, 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). 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; thus, 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 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 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 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 feature of extremely reduced number of ports could also be used in case the CLAT-enabled CE with 464XLAT makes use of tracking the 5-tuple NAT connections and could also be further extended if the NAT64 also uses the 5-tuple. Please also refer to for in-depth information about the requirements for sizing CGN gateways.

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. Available Provisioning Mechanisms

Provisioning Method	464XLAT	DS-Lite	lw4o6	MAP-E	MAP-T
DHCPv6		X	X	X	X
RADIUS			X	X	X
TR-069	*	X	*	X	X
DNS64	X
YANG
DHCP 4o6			X	X

*:

Work started at Broadband Forum (2021)

X:

Supported by the provisioning method

Support for Multicast The solutions covered in this document are all intended for unicast traffic. 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.

Detailed Analysis

Architectural Differences

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.

Basic Comparison among the Analyzed Technologies

	464XLAT	DS-Lite	lw4o6	MAP-E	MAP-T
Translation (T) or Encapsulation (E)	T	E	E	E	T
Presence (+) of Per-Flow State in Operator Network	+	+

Trade-Off between Port Number Efficiency and Stateless Operation 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, respectively. This may cause scalability issues for the number of clients or volume of traffic, but it does not impose a limitation on the number of ports per user, as they can be 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. However, this means that the number of ports provided to each user (and hence the effective IPv4 address-sharing ratio) must be pre-provisioned to the client. Changing the allocated port ranges with A+P-based technologies requires more planning and is likely to involve reprovisioning both hosts and operator-side equipment. It should be noted that due to the per-customer binding table entry used by lw4o6, a single customer can be reprovisioned (e.g., if they request a full IPv4 address) without needing to change parameters for a number of customers as in a MAP domain. It is also worth noting that there is a direct relationship between the efficiency of public port allocations for customers and the corresponding logging overhead that may be necessary to meet data-retention requirements. This is considered in . Determining the optimal number of ports for a fixed port set is not an easy task and may also be impacted by local regulatory law (and in the Belgian case, it is not a law but more a memorandum of understanding or best current practice), which may define a maximum number of users per IP address and consequently a minimum number of ports per user. On the one hand, the "lack of ports" situation may cause serious problems in the operation of certain applications. For example, Miyakawa has demonstrated the consequences of the session number limitation due to port number shortage in the example of Google Maps . When the limit was 15, several blocks of the map were missing, and the map was unusable. This study also provided several examples for the session numbers of different applications (the highest one was Apple's iTunes at 230-270 ports). The port number consumption of different applications is highly varying. In the case of web browsing, it depends on several factors, including the choice of the web page, the web browser, and sometimes the operating system . For example, under certain conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux), and in some 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., Internet is used by different members of a family simultaneously), so sufficient ports must be allocated to avoid impacting user experience. In general, assigning too few source port numbers to an end user may result in unexpected and hard-to-debug consequences; therefore, if the number of ports per end user is fixed, then we recommend assigning a conservatively large number of ports. For example, the developers of Jool used 2048 ports per user in their example for MAP-T . However, assigning too many ports per CE router will result in waste of public IPv4 addresses, which are scarce and expensive resources. Clearly, this is a big advantage in the case of 464XLAT where they are dynamically managed so that the number of IPv4 addresses for the sharing pool is smaller while the availability of ports per user doesn't need to be pre-defined and is not a limitation. There is a direct trade-off between the optimization of client port allocations and the associated logging overhead. discusses this in more depth. We note that common NAT44 implementations utilizing Netfilter at the CE router multiplex active sessions using a 3-tuple (source address, destination address, and destination port). This means that external source ports can be reused for unique internal source and destination addresses and port sessions. It is also noted that Netfilter cannot currently make use of multiple source port ranges (i.e., several blocks of ports distributed across the total port space as 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 thus public IP address saving. The price is the stateful operation in the service provider network, which allegedly does not scale up well. It should be noted that, in many cases, all those factors may depend on how it is actually implemented. Measurements have been started to examine the scalability of a few stateful solutions in two areas:

• How their performance scales up 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 . We note that some CGN-type solutions can allocate ports dynamically "on the fly". Depending on configuration, this can result in the same customer being allocated ports from different source addresses. This can cause operational issues for protocols and applications that expect multiple flows to be sourced from the same address (e.g., ECMP hashing, STUN, gaming, and content delivery networks). However, it should be noted that this is the same problem when a network has a NAT44 with multiple public IPv4 addresses, or even when applications in a dual-stack case, behave wrongly if Happy Eyeballs is flapping the flow address between IPv4 and IPv6. The consequences of IPv4 address sharing may impact all five technologies. However, when ports are allocated statically, more customers may get ports from the same public IPv4 address, which may result in 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 that they are used for address sharing. Both cases are, again, implementation-dependent. We note that although it is not of typical use, one can do deterministic, stateful NAT and reserve a fixed set of ports for each customer as well.

Support for Public Server Operation Mechanisms that rely on operator-side per-flow state do not, by themselves, offer a way for customers to present services on publicly accessible transport-layer ports. The Port Control Protocol (PCP) 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 is supported in some DS-Lite AFTR implementations. A+P-based mechanisms distribute a public IPv4 address and restricted range of transport-layer ports to the client. In this case, it is possible for the user to configure their device to offer a publicly accessible server on one of their allocated ports. It should be noted that operators commonly do not assign the well-known ports to users (unless they are 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 allocated clients with a full IPv4 address, allowing exclusive use of all ports and non-port-based transport-layer protocols. Thus, they may 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 is obviously no advantage in terms of IPv4 public addresses saving. It is also possible to configure specific ports mapping in 464XLAT/NAT64 using EAMT , which means that only those ports are "lost" from the pool of addresses, so there is a higher maximization of the total usage of IPv4 port resources.

Support and Implementations

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 while not all of them have support for 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 as functions in the CE device only; however, the vendors' 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 (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR)
• VPP/fd.io (MAP-BR, lwAFTR, CGN, CLAT, NAT64)
• Snabb (lwAFTR)
• AFTR (DSLite AFTR)

Support in Cellular and Broadband Networks Several cellular networks use 464XLAT, whereas there are no deployments of the four other technologies in cellular networks, as they are neither standardized nor 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 deployments of lw4o6 have been rapidly increasing in the last few years. Please refer to Tables 2 and 3 of for a limited set of deployment information.

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 ). We note that the support for all five technologies requires a much smaller code size than the total sum of the above quantities, because they contain a lot of common functions (e.g., data plane is shared among several of them).

Typical Deployment and Traffic Volume Considerations

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 the traffic between an IPv6-only client and IPv4-only server as normal IPv6 traffic, and the stateful NAT64 gateway would do a single translation, thus offloading this kind of traffic from the IPv4aaS technology. The cost of this solution would be the need to also deploy DNS64 + stateful NAT64. However, this has not been implemented in clients or actual deployments, so only 464XLAT always uses this optimization, and the other four solutions do not use it at all.

Cellular Networks with 464XLAT Figures from existing deployments (through the end of 2018) show the typical traffic volumes in an IPv6-only cellular network when 464XLAT technology is used 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.

Wireline Networks with 464XLAT Figures from several existing deployments (through the end of 2020), mainly with residential customers, show the ranges of typical traffic volumes 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 is consistent with non-public information of actual deployments, which can be easily explained. When a wireline ISP has mainly residential customers, content providers and CDNs that are already IPv6 enabled (Google/YouTube, Netflix, Facebook, Akamai, etc.) typically account for 65-85% of the traffic in the network. Thus, when the subscribers are IPv6 enabled, about the same percentage of traffic will become IPv6.

Load Sharing If multiple network-side devices are needed as PLAT/AFTR/BR for capacity, then there is a need for a load-sharing mechanism. ECMP (Equal-Cost Multipath) load sharing can be used for all technologies; however, stateful technologies will be impacted by changes in network topology or device failure. Technologies utilizing DNS64 can also distribute load across PLAT/AFTR devices, evenly or unevenly, by using different prefixes. Different network-specific prefixes can be distributed for subscribers in appropriately sized segments (like split-horizon DNS, also called "DNS views"). Stateless technologies, due to the lack of per-flow state, can make use of anycast routing for load sharing and resiliency across network devices, both ingress and egress; flows can take asymmetric paths through the network, i.e., in through one lwAFTR/BR and out via another. Mechanisms with centralized NAPT44 state have a number of challenges specifically related to scaling and resilience. As the total amount of client traffic exceeds the capacity of a single CGN instance, additional nodes are required to handle the load. Each CGN maintains a stateful table of active client sessions, and this table may need to be synchronized between CGN instances. This is necessary 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.

Logging In the case of 464XLAT and DS-Lite, the user of any given public IPv4 address and port combination will vary over time; therefore, logging is necessary to meet data-retention laws. Each entry in the PLAT/AFTR generates a logging entry. As discussed in , a client may open hundreds of sessions during common tasks such as web browsing, each of which 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 available to reduce the logging overhead is the allocation of a block of ports to a client for the duration of their session. This means that a logging entry only needs to be made when the client's port block is released, which dramatically reduces the logging overhead. This comes as the cost of less efficient public address sharing as clients need to be allocated a port block of a fixed size regardless of the actual number of ports that they are using. Stateless technologies that pre-allocate the IPv4 addresses and ports only require that copies of the active MAP rules (for MAP-E and MAP-T) or binding table (for lw4o6) are retained along with timestamp information of when they have been active. Support tools (e.g., those used to serve data-retention requests) may need to be updated to be aware of the mechanism in use (e.g., implementing the MAP algorithm so that IPv4 information can be linked to the IPv6 prefix delegated to a client). Stateless technologies do not have a centralized stateful element that customer traffic needs to pass through, so if data-retention laws mandate per-session logging, there is no simple way of meeting this requirement with a stateless technology alone. Thus, a centralized NAPT44 model may be the only way to meet this requirement. Deterministic CGN was proposed as a solution to reduce the resource consumption of logging. Please also refer to for more information about requirements for logging CGN gateways.

Optimization for IPv4-Only Devices and Applications When IPv4-only devices or applications are behind a CE 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) and will reach the IPv4 address of the destination, even if that service supports dual-stack. This means that the traffic flow will cross through the AFTR, lwAFTR, or BR, depending on the specific transition mechanism being used. Even if those services are directly connected to the operator network (e.g., CDNs and caches) or located internally (such as VoIP, etc.), it is not possible to avoid that overhead. However, in the case of those mechanisms that use a NAT46 function, in the CE (464XLAT and MAP-T), it is possible to take advantage of optimization functionalities, such as the ones described in . Because the NAT46 has already translated the IPv4-only flow to IPv6 and the services are dual-stack, using these optimizations allows the services to be reached without the need to translate the flow back to IPv4.

Performance Comparison We plan to compare the performances of the most prominent free software implementations of the five IPv6 transition technologies using the methodology described in "Benchmarking Methodology for IPv6 Transition Technologies" . The dual Device Under Test (DUT) setup of makes it possible to use the existing measurement devices compliant with "Benchmarking Methodology for Network Interconnect Devices" ; however, this solution has two kinds of limitations:

• Dual DUT setup has the drawback that the performances of the CE and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT) are measured together. In order to measure the performance of only one of them, we need to ensure that the desired one is the bottleneck.
• Measurement procedures for Packet Delay Variation (PDV) and Inter-Packet Delay Variation (IPDV) measurements are missing from the legacy devices, and the old measurement procedure for latency has been redefined in .

The single DUT setup of makes it possible to benchmark the selected device separately, but either special Tester is required or some trick is needed if we want to use legacy Testers. An example for the latter is our stateless NAT64 measurements testing Throughput and Frame Loss Rate using a legacy commercial Tester that is compliant with . Siitperf, a DPDK-based software Tester that is compliant with and used for benchmarking stateless NAT64 gateways, has been developed recently. Siitperf is available from GitHub as free software and is documented in . Originally, it literally followed the test frame format of , including "hard-wired" source and destination port numbers, and then it was complemented with the pseudorandom port feature required by . The new version is documented in . Further DPDK-based software Testers that are compliant with 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 .

IANA Considerations This document has no IANA actions.

Security Considerations As discussed in , 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. However, it should be noted that those issues are not specific to the IPv4aaS IPv6 transition technologies but 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 (e.g., from 16 bits to 10 bits when 1024 port numbers are assigned to each subscriber), and these technologies are thus theoretically less resilient against cache poisoning (see ). However, an efficient cache poisoning attack requires that the subscriber operates its own caching DNS server and the attack is performed in the service provider network. Thus, we consider the chance of the successful exploitation of 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 . An in-depth security analysis of all five IPv6 transition technologies and their most prominent free software implementations according to the methodology defined in is planned. As the first step, an initial security analysis of 464XLAT was done in . The implementers of any of the five IPv4aaS solutions should consult the Security Considerations of the respective RFCs documenting them.

References Normative References This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK] This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community. Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community. The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community. The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK] This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes. The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes. This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK] We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community. Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK] This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787. Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo. In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use. Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports. This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document. This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite). This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. This document defines a YANG module for the Network Address Translation (NAT) function. Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document. This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements. IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications. Informative References ISC Infocommunications Journal, Vol. 13, No. 4, pp. 10-18 Szechenyi Istvan University Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines and compares the performance of some free software implementations of the five most prominent IPv4aaS technologies (464XLAT [RFC6877], Dual Stack Lite [RFC6333], Lightweight 4over6 [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599]) and DNS64 [RFC6147]. Work in Progress Szechenyi Istvan University Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the scalability of the five most prominent IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T) considering two aspects: (1) how their performance scales up with the number of CPU cores, (2) how their performance degrades, when the number of concurrent sessions is increased until hardware limit is reached. Work in Progress Computers & Security, Vol. 77, No. 1, pp. 397-411 IEICE Transactions on Communications, Vol. E102-B, No. 10, pp. 2021-2035 Telecommunication Systems, Vol. 75, pp. 245-257 International Journal of Advances in Telecommunications, Electrotechnics, Signals and Systems, Vol. 9, No. 3, pp. 18-26 IEICE Transactions on Communications, Vol. E104.B, Issue 2, pp. 128-140 IEICE Transactions on Communications, Vol. E93-B, Issue 5, pp. 1078-1084 Netflix, Inc. Münster University of Applied Sciences Münster University of Applied Sciences The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT functions for TCP that allows multiple hosts to reside behind a NAT function and yet share a single IPv4 address, even when two hosts (behind a NAT function) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions needed for the SCTP endpoints and the mechanisms for NAT functions necessary to provide similar features of NAPT in the single point and multipoint traversal scenario. Finally, a YANG module for SCTP NAT is defined. Work in Progress The IPv6 Company Telecentro Work in Progress 37th International Conference on Telecommunications and Signal Processing commit bdce0f commit 1ef72ce Broadband Forum

Acknowledgements The authors would like to thank , , , , , , , , , , and for their review of this document and acknowledge the inputs of , , , , , , , , , , , , , , , , , , , , , , , , , , and .

Authors' Addresses Budapest University of Technology and Economics

Magyar tudósok körútja 2 Budapest H-1117 Hungary lencse@hit.bme.hu http://www.hit.bme.hu/~lencse/index_en.htm

The IPv6 Company

Molino de la Navata, 75 La Navata - Galapagar Madrid 28420 Spain jordi.palet@theipv6company.com http://www.theipv6company.com/

Retevia

9940 Main St., Suite 200 Fairfax Virginia 22031 United States of America lee@asgard.org

Sky UK

1 Brick Lane London EQ 6PU United Kingdom richard.patterson@sky.uk

Deutsche Telekom AG

Landgrabenweg 151 Bonn 53227 Germany ian.farrer@telekom.de