rfc9313.original   rfc9313.txt 
v6ops G. Lencse Internet Engineering Task Force (IETF) G. Lencse
Internet-Draft BUTE Request for Comments: 9313 BUTE
Intended status: Informational J. Palet Martinez Category: Informational J. Palet Martinez
Expires: 24 November 2022 The IPv6 Company ISSN: 2070-1721 The IPv6 Company
L. Howard L. Howard
Retevia Retevia
R. Patterson R. Patterson
Sky UK Sky UK
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
23 May 2022 October 2022
Pros and Cons of IPv6 Transition Technologies for IPv4aaS Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service
draft-ietf-v6ops-transition-comparison-04 (IPv4aaS)
Abstract Abstract
Several IPv6 transition technologies have been developed to provide Several IPv6 transition technologies have been developed to provide
customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their access and/or core network. These technologies have their advantages
advantages and disadvantages, and depending on existing topology, and disadvantages. Depending on existing topology, skills, strategy,
skills, strategy and other preferences, one of these technologies may and other preferences, one of these technologies may be the most
be the most appropriate solution for a network operator. appropriate solution for a network operator.
This document examines the five most prominent IPv4aaS technologies This document examines the five most prominent IPv4aaS technologies
considering a number of different aspects to provide network and considers a number of different aspects to provide network
operators with an easy-to-use reference to assist in selecting the operators with an easy-to-use reference to assist in selecting the
technology that best suits their needs. technology that best suits their needs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 24 November 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9313.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 2. Overview of the Technologies
2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 464XLAT
2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 2.2. Dual-Stack Lite
2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 6 2.3. Lightweight 4over6
2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. MAP-E
2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. MAP-T
3. High-level Architectures and their Consequences . . . . . . . 9 3. High-Level Architectures and Their Consequences
3.1. Service Provider Network Traversal . . . . . . . . . . . 9 3.1. Service Provider Network Traversal
3.2. Network Address Translation among the Different IPv4aaS 3.2. Network Address Translation among the Different IPv4aaS
Technologies . . . . . . . . . . . . . . . . . . . . . . 10 Technologies
3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 11 3.3. IPv4 Address Sharing
3.4. IPv4 Pool Size Considerations . . . . . . . . . . . . . . 12 3.4. IPv4 Pool Size Considerations
3.5. CE Provisioning Considerations . . . . . . . . . . . . . 14 3.5. CE Provisioning Considerations
3.6. Support for Multicast . . . . . . . . . . . . . . . . . . 14 3.6. Support for Multicast
4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 15 4. Detailed Analysis
4.1. Architectural Differences . . . . . . . . . . . . . . . . 15 4.1. Architectural Differences
4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 15 4.1.1. Basic Comparison
4.2. Tradeoff between Port Number Efficiency and Stateless 4.2. Trade-Off between Port Number Efficiency and Stateless
Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 Operation
4.3. Support for Public Server Operation . . . . . . . . . . . 18 4.3. Support for Public Server Operation
4.4. Support and Implementations . . . . . . . . . . . . . . . 19 4.4. Support and Implementations
4.4.1. Vendor Support . . . . . . . . . . . . . . . . . . . 19 4.4.1. Vendor Support
4.4.2. Support in Cellular and Broadband Networks . . . . . 19 4.4.2. Support in Cellular and Broadband Networks
4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 20 4.4.3. Implementation Code Sizes
4.5. Typical Deployment and Traffic Volume Considerations . . 20 4.5. Typical Deployment and Traffic Volume Considerations
4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 20 4.5.1. Deployment Possibilities
4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 20 4.5.2. Cellular Networks with 464XLAT
4.5.3. Wireline Networks with 464XLAT . . . . . . . . . . . 21 4.5.3. Wireline Networks with 464XLAT
4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 21 4.6. Load Sharing
4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.7. Logging
4.8. Optimization for IPv4-only devices/applications . . . . . 23 4.8. Optimization for IPv4-Only Devices and Applications
5. Performance Comparison
5. Performance Comparison . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. References
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 Acknowledgements
9.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.6. 06 - 00-WG Item . . . . . . . . . . . . . . . . . . . . . 33
A.7. 00 - 01 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.8. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.9. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.10. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
As the deployment of IPv6 continues to be prevalent, it becomes As the deployment of IPv6 continues to be prevalent, it becomes
clearer that network operators will move to building single-stack clearer that network operators will move to building single-stack
IPv6 core and access networks to simplify network planning and IPv6 core and access networks to simplify network planning and
operations. However, providing customers with IPv4 services operations. However, providing customers with IPv4 services
continues to be a requirement for the foreseeable future. To meet continues to be a requirement for the foreseeable future. To meet
this need, the IETF has standardised a number of different IPv4aaS this need, the IETF has standardized a number of different IPv4aaS
technologies for this [LEN2019] based on differing requirements and technologies for this (see [LEN2019]) based on differing requirements
deployment scenarios. and deployment scenarios.
The number of technologies that have been developed makes it time- The number of technologies that have been developed makes it time-
consuming for a network operator to identify the most appropriate consuming for a network operator to identify the most appropriate
mechanism for their specific deployment. This document provides a mechanism for their specific deployment. This document provides a
comparative analysis of the most commonly used mechanisms to assist comparative analysis of the most commonly used mechanisms to assist
operators with this problem. operators with this problem.
Five different IPv4aaS solutions are considered. The following Five different IPv4aaS solutions are considered:
IPv4aaS technologies are covered:
1. 464XLAT [RFC6877] 1. 464XLAT [RFC6877]
2. Dual Stack Lite [RFC6333] 2. Dual-Stack Lite [RFC6333]
3. lw4o6 (Lightweight 4over6) [RFC7596] 3. Lightweight 4over6 (lw4o6) [RFC7596]
4. MAP-E [RFC7597] 4. Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597]
5. MAP-T [RFC7599]
5. Mapping of Address and Port using Translation (MAP-T) [RFC7599]
We note that [RFC6180] gives guidelines for using IPv6 transition We note that [RFC6180] gives guidelines for using IPv6 transition
mechanisms during IPv6 deployment addressing a much broader topic, mechanisms during IPv6 deployment; that document addresses a much
whereas this document focuses on a small part of it. broader topic, whereas this document focuses on a small part of it.
2. Overview of the Technologies 2. Overview of the Technologies
The following sections introduce the different technologies analyzed The following sections introduce the different technologies analyzed
in this document, describing some of their most important in this document and describe some of their most important
characteristics. characteristics.
2.1. 464XLAT 2.1. 464XLAT
464XLAT may use double translation (stateless NAT46 + stateful NAT64) 464XLAT may use double translation (stateless NAT46 + stateful NAT64)
or single translation (stateful NAT64), depending on different or single translation (stateful NAT64) depending on different
factors, such as the use of DNS by the applications and the factors, such as the use of DNS by the applications and the
availability of a DNS64 function (in the host or in the service availability of a DNS64 function (in the host or service provider
provider network). network).
The customer-side translator (CLAT) is located in the customer's The customer-side translator (CLAT) is located in the customer's
device, and it performs stateless NAT46 translation [RFC7915] (more device, and it performs stateless NAT46 translation [RFC7915] (more
precisely, a stateless IP/ICMP translation from IPv4 to IPv6). precisely, a stateless IP/ICMP translation from IPv4 to IPv6).
IPv4-embedded IPv6 addresses [RFC6052] are used for both source and IPv4-embedded IPv6 addresses [RFC6052] are used for both source and
destination addresses. Commonly, a /96 prefix (either the destination addresses. Commonly, a /96 prefix (either the
64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 64:ff9b::/96 Well-Known Prefix (WKP) or a Network-Specific Prefix) is
as the IPv6 destination for the IPv4-embedded client traffic. used as the IPv6 destination for the IPv4-embedded client traffic.
In deployments where NAT64 load-balancing [RFC7269] section 4.2 is In deployments where NAT64 load balancing (see Section 4.2 of
enabled, multiple WKPs [RFC8215] may be used. [RFC7269]) is enabled, multiple WKPs [RFC8215] may be used.
In the operator's network, the provider-side translator (PLAT) In the operator's network, the provider-side translator (PLAT)
performs stateful NAT64 [RFC6146] to translate the traffic. The performs stateful NAT64 [RFC6146] to translate the traffic. The
destination IPv4 address is extracted from the IPv4-embedded IPv6 destination IPv4 address is extracted from the IPv4-embedded IPv6
packet destination address and the source address is from a pool of packet destination address, and the source address is from a pool of
public IPv4 addresses. public IPv4 addresses.
Alternatively, when a dedicated /64 is not available for translation, Alternatively, when a dedicated /64 is not available for translation,
the CLAT device uses a stateful NAT44 translation before the the CLAT device uses a stateful NAT44 translation before the
stateless NAT46 translation. stateless NAT46 translation.
In general, keeping state in devices close to the end-user network In general, keeping state in devices close to the end-user network
(i.e. at the CE - Customer Edge router) is not perceived as (i.e., at the CE (Customer Edge) router) is not perceived to be as
problematic as keeping state in the operator's network. problematic as keeping state in the operator's network.
In typical deployments, 464XLAT is used together with DNS64 In typical deployments, 464XLAT is used together with DNS64
[RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client [RFC6147]; see Section 3.1.2 of [RFC8683]. When an IPv6-only client
or application communicates with an IPv4-only server, the DNS64 or application communicates with an IPv4-only server, the DNS64
server returns the IPv4-embedded IPv6 address of the IPv4-only server returns the IPv4-embedded IPv6 address of the IPv4-only
server. In this case, the IPv6-only client sends out IPv6 packets, 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 the CLAT functions as an IPv6 router, and the PLAT performs a
stateful NAT64 for these packets. In this case, there is a single stateful NAT64 for these packets. There is a single translation.
translation.
Similarly, when an IPv4-only client or application communicates with Similarly, when an IPv4-only client or application communicates with
an IPv4-only server, the CLAT will statelessly translate to IPv6 so 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 it can traverse the ISP network up to the PLAT (NAT64), which in turn
will translate to IPv4. will translate to IPv4.
Alternatively, one can say that DNS64 + stateful NAT64 is used to Alternatively, one can say that DNS64 + stateful NAT64 is used to
carry the traffic of the IPv6-only client and the IPv4-only server, 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 and the CLAT is used only for the IPv4 traffic from applications or
devices that use literal IPv4 addresses or non-IPv6 compliant APIs. devices that use literal IPv4 addresses or non-IPv6-compliant APIs.
Private +----------+ Translated +----------+ _______ Private +----------+ Translated +----------+ _______
+------+ IPv4 | CLAT | 4-6-4 | PLAT | ( IPv4 ) +------+ IPv4 | CLAT | 4-6-4 | PLAT | ( IPv4 )
| IPv4 |------->| Stateless|------------>| Stateful +--( Internet ) | IPv4 |------->| Stateless|------------>| Stateful +--( Internet )
|Device|<-------| NAT46 |<------------| NAT64 | (________) |Device|<-------| NAT46 |<------------| NAT64 | (________)
+------+ +----------+ ^ +----------+ +------+ +----------+ ^ +----------+
| |
Operator IPv6 Operator IPv6
network Network
Figure 1: Overview of the 464XLAT architecture Figure 1: Overview of the 464XLAT Architecture
Note: in mobile networks, CLAT is commonly implemented in the user's Note: In mobile networks, the CLAT is commonly implemented in the
equipment (UE or smartphone), please refer to Figure 2 of [RFC6877]. user equipment (UE) or smartphone; please refer to Figure 2 in
[RFC6877].
Often NAT64 vendors support direct communication (that is, without Some NAT64 vendors support direct communication (that is, without
translation) between two CLATs by means of hair-pinning through the translation) between two CLATs by means of hairpinning through the
NAT64. NAT64.
2.2. Dual-Stack Lite 2.2. Dual-Stack Lite
Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered
transition mechanisms to be developed. DS-Lite uses a 'Basic transition mechanisms to be developed. DS-Lite uses a Basic Bridging
Bridging BroadBand' (B4) function in the customer's CE router that BroadBand (B4) function in the customer's CE router that encapsulates
encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native IPv4 in IPv6 traffic and sends it over the IPv6 native service
service-provider network to an 'Address Family Transition Router' provider network to an Address Family Transition Router (AFTR). The
(AFTR). The AFTR performs encapsulation/decapsulation of the 4in6 AFTR performs encapsulation/decapsulation of the 4in6 [RFC2473]
[RFC2473] traffic and translates the IPv4 source address in the inner traffic and translates the IPv4 source address in the inner IPv4
IPv4 packet to public IPv4 source address using a stateful NAPT44 packet to a public IPv4 source address using a stateful NAPT44
[RFC2663] function. [RFC2663] function.
+-------------+ +-------------+
Private +----------+ IPv4-in-IPv6|Stateful AFTR| Private +----------+ IPv4-in-IPv6|Stateful AFTR|
+------+ IPv4 | B4 | tunnel |------+------+ _______ +------+ IPv4 | B4 | Tunnel |------+------+ _______
| IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 )
|Device|<-------| decap. |<------------| / | NAPT +--( Internet ) |Device|<-------| Decap. |<------------| / | NAPT +--( Internet )
+------+ +----------+ ^ |Decap.| 44 | (________) +------+ +----------+ ^ |Decap.| 44 | (________)
| +------+------+ | +------+------+
Operator IPv6 Operator IPv6
network Network
Figure 2: Overview of the DS-Lite architecture Figure 2: Overview of the DS-Lite Architecture
Some AFTR vendors support direct communication between two B4s by Some AFTR vendors support direct communication between two B4s by
means of hair-pinning through the AFTR. means of hairpinning through the AFTR.
2.3. Lightweight 4over6 2.3. Lightweight 4over6
Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main
difference is that the stateful NAPT44 function is relocated from the difference is that the stateful NAPT44 function is relocated from the
centralized AFTR to the customer's B4 element (called a lwB4). The centralized AFTR to the customer's B4 element (called an "lwB4").
AFTR (called a lwAFTR) function therefore only performs A+P routing The AFTR (called an "lwAFTR") function therefore only performs A+P
[RFC6346] and 4in6 encapsulation/decapsulation. (Address plus Port) routing [RFC6346] and 4in6 encapsulation/
decapsulation.
Routing to the correct client and IPv4 address sharing is achieved Routing to the correct client and IPv4 address sharing are achieved
using the Address + Port (A+P) model [RFC6346] of provisioning each using the A+P model [RFC6346] of provisioning each lwB4 with a unique
lwB4 with a unique tuple of IPv4 address and a unique range of tuple of IPv4 address and a unique range of transport-layer ports.
transport layer ports. The client uses these for NAPT44. The client uses these for NAPT44.
The lwAFTR implements a binding table, which has a per-client entry The lwAFTR implements a binding table, which has a per-client entry
linking the customer's source IPv4 address and allocated range of linking the customer's source IPv4 address and an allocated range of
transport layer ports to their IPv6 tunnel endpoint address. The transport-layer ports to their IPv6 tunnel endpoint address. The
binding table allows egress traffic from customers to be validated binding table allows egress traffic from customers to be validated
(to prevent spoofing) and ingress traffic to be correctly (to prevent spoofing) and ingress traffic to be correctly
encapsulated and forwarded. As there needs to be a per-client entry, encapsulated and forwarded. As there needs to be a per-client entry,
an lwAFTR implementation needs to be optimized for performing a per- an lwAFTR implementation needs to be optimized for performing a per-
packet lookup on the binding table. packet lookup on the binding table.
Direct communication (that is, without translation) between two lwB4s Direct communication (that is, without translation) between two lwB4s
is performed by hair-pinning traffic through the lwAFTR. is performed by hairpinning traffic through the lwAFTR.
+-------------+ +----------+ +-------------+ +----------+
Private | lwB4 | IPv4-in-IPv6| Stateless| Private | lwB4 | IPv4-in-IPv6| Stateless|
+------+ IPv4 |------+------| tunnel | lwAFTR | _______ +------+ IPv4 |------+------| Tunnel | lwAFTR | _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
|Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet )
+------+ | 44 |Decap.| ^ | routing) | (________) +------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+ +------+------+ | +----------+
Operator IPv6 Operator IPv6
network Network
Figure 3: Overview of the lw4o6 architecture Figure 3: Overview of the lw4o6 Architecture
2.4. MAP-E 2.4. MAP-E
Like 464XLAT (Section 2.1), MAP-E and MAP-T use [RFC6052] Like 464XLAT (Section 2.1), MAP-E and MAP-T use IPv4-embedded IPv6
IPv4-embedded IPv6 addresses to represent IPv4 hosts outside the MAP addresses [RFC6052] to represent IPv4 hosts outside the MAP domain.
domain.
MAP-E and MAP-T use a stateless algorithm to embed portions of the 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 customer's allocated IPv4 address (or part of an address with A+P
routing) into the IPv6 prefix delegated to the client. This allows routing) into the IPv6 prefix delegated to the client. This allows
for large numbers of clients to be provisioned using a single MAP for large numbers of clients to be provisioned using a single MAP
rule (called a MAP domain). The algorithm also allows for direct rule (called a "MAP domain"). The algorithm also allows direct IPv4
IPv4 peer-to-peer communication between hosts provisioned with common peer-to-peer communication between hosts provisioned with common MAP
MAP rules. rules.
The CE (Customer-Edge) router typically performs stateful NAPT44 The CE router typically performs stateful NAPT44 [RFC2663] to
[RFC2663] to translate the private IPv4 source addresses and source translate the private IPv4 source addresses and source ports into an
ports into an address and port range defined by applying the MAP rule address and port range defined by applying the MAP rule to the
to the delegated IPv6 prefix. The client address/port allocation delegated IPv6 prefix. The client address/port allocation size is a
size is a configuration parameter. The CE router then encapsulates configuration parameter. The CE router then encapsulates the IPv4
the IPv4 packet in an IPv6 packet [RFC2473] and sends it directly to packet in an IPv6 packet [RFC2473] and sends it directly to another
another host in the MAP domain (for peer-to-peer) or to a Border host in the MAP domain (for peer-to-peer) or to a Border Router (BR)
Router (BR) if the IPv4 destination is not covered in one of the CE's if the IPv4 destination is not covered in one of the CE's MAP rules.
MAP rules.
The MAP BR is provisioned with the set of MAP rules for the MAP 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 domains it serves. These rules determine how the MAP BR is to
decapsulate traffic that it receives from client, validating the decapsulate traffic that it receives from the client, validate the
source IPv4 address and transport layer ports assigned, as well as source IPv4 address and transport-layer ports assigned, and calculate
how to calculate the destination IPv6 address for ingress IPv4 the destination IPv6 address for ingress IPv4 traffic.
traffic.
+-------------+ +----------+ +-------------+ +----------+
Private | MAP CE | IPv4-in-IPv6| Stateless| Private | MAP CE | IPv4-in-IPv6| Stateless|
+------+ IPv4 |------+------| tunnel | MAP BR | _______ +------+ IPv4 |------+------| tunnel | MAP BR | _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
|Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) |Device|<-------| NAPT | / |<------------|algorithm +--( Internet )
+------+ | 44 |Decap.| ^ | routing) | (________) +------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+ +------+------+ | +----------+
Operator IPv6 Operator IPv6
network Network
Figure 4: Overview of the MAP-E architecture Figure 4: Overview of the MAP-E Architecture
Some BR vendors support direct communication between two MAP CEs by Some BR vendors support direct communication between two MAP CEs by
means of hair-pinning through the BR. means of hairpinning through the BR.
2.5. MAP-T 2.5. MAP-T
MAP-T uses the same mapping algorithm as MAP-E. The major difference 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 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. 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 MAP-T can also be compared to 464XLAT when there is a double
translation. translation.
A MAP CE router typically performs stateful NAPT44 to translate A MAP CE router typically performs stateful NAPT44 to translate
traffic to a public IPv4 address and port-range calculated by traffic to a public IPv4 address and port range calculated by
applying the provisioned Basic MAP Rule (BMR - a set of inputs to the applying the provisioned Basic MAP Rule (BMR), which is a set of
algorithm) to the delegated IPv6 prefix. The CE then performs inputs to the algorithm, to the delegated IPv6 prefix. The CE then
stateless translation from IPv4 to IPv6 [RFC7915]. The MAP BR is performs stateless translation from IPv4 to IPv6 [RFC7915]. The MAP
provisioned with the same BMR as the client, enabling the received BR is provisioned with the same BMR as the client, enabling the
IPv6 traffic to be statelessly NAT64 translated back to the public received IPv6 traffic to be translated (using stateless NAT64) back
IPv4 source address used by the client. to the public IPv4 source address used by the client.
Using translation instead of encapsulation also allows IPv4-only Using translation instead of encapsulation also allows IPv4-only
nodes to correspond directly with IPv6 nodes in the MAP-T domain that nodes to correspond directly with IPv6 nodes in the MAP-T domain that
have IPv4-embedded IPv6 addresses. have IPv4-embedded IPv6 addresses.
+-------------+ +----------+ +-------------+ +----------+
Private | MAP CE | Translated | Stateless| Private | MAP CE | Translated | Stateless|
+------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______
| IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 )
|Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) |Device|<-------| NAPT | less |<------------|algorithm +--( Internet )
+------+ | 44 |NAT46 | ^ | routing) | (________) +------+ | 44 |NAT46 | ^ | routing) | (________)
+------+------+ | +----------+ +------+------+ | +----------+
Operator IPv6 Operator IPv6
network Network
Figure 5: Overview of the MAP-T architecture Figure 5: Overview of the MAP-T Architecture
Some BR vendors support direct communication between two MAP CEs by Some BR vendors support direct communication between two MAP CEs by
means of hair-pinning through the BR. means of hairpinning through the BR.
3. High-level Architectures and their Consequences 3. High-Level Architectures and Their Consequences
3.1. Service Provider Network Traversal 3.1. Service Provider Network Traversal
For the data-plane, there are two approaches for traversing the IPv6 For the data plane, there are two approaches for traversing the IPv6
provider network: provider network:
* 4-6-4 translation * 4-6-4 translation
* 4-in-6 encapsulation * 4in6 encapsulation
+==============+=========+=========+=======+=======+=======+ +====================+=========+=========+=======+=======+=======+
| | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+==============+=========+=========+=======+=======+=======+ +====================+=========+=========+=======+=======+=======+
| 4-6-4 trans. | X | | | | X | | 4-6-4 translation | X | | | | X |
+--------------+---------+---------+-------+-------+-------+ +--------------------+---------+---------+-------+-------+-------+
| 4-6-4 encap. | | X | X | X | | | 4in6 encapsulation | | X | X | X | |
+--------------+---------+---------+-------+-------+-------+ +--------------------+---------+---------+-------+-------+-------+
Table 1: Available Traversal Mechanisms Table 1: Available Traversal Mechanisms
In the scope of this document, all of the encapsulation based In the scope of this document, all of the encapsulation-based
mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless mechanisms use IP-in-IP tunneling [RFC2473]. This is a stateless
tunneling mechanism which does not require any additional overhead. tunneling mechanism that does not require any additional overhead.
It should be noted that both of these approaches result in an It should be noted that both of these approaches result in an
increase in the size of the packet that needs to be transported 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 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 translation adds a 20-byte overhead (the 20-byte IPv4 header is
replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte
overhead (an IPv6 header is prepended to the IPv4 header). overhead (an IPv6 header is prepended to the IPv4 header).
The increase in packet size can become a significant problem if there 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 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 the need for traffic to be fragmented at the ingress point to the
only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may IPv6 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint).
also result in the need to implement buffering and fragment re- It may also result in the need to implement buffering and fragment
assembly in the PLAT/AFTR/lwAFTR/BR node. reassembly in the PLAT/AFTR/lwAFTR/BR node.
The advice given in [RFC7597] Section 8.3.1 is applicable to all of The advice given in Section 8.3.1 of [RFC7597] is applicable to all
these mechanisms: It is strongly recommended that the MTU in the of these mechanisms: It is strongly recommended that the MTU in the
IPv6-only domain be well managed (it should have sufficiently large IPv6-only domain be well managed (it should have sufficiently large
MTU to support tunneling and/or translation) and that the IPv6 MTU on 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 the CE WAN-side interface be set so that no fragmentation occurs
within the boundary of the IPv6-only domain. within the boundary of the IPv6-only domain.
3.2. Network Address Translation among the Different IPv4aaS 3.2. Network Address Translation among the Different IPv4aaS
Technologies Technologies
For the high-level solution of IPv6 service provider network For the high-level solution of IPv6 service provider network
traversal, MAP-T uses double stateless translation. First at the CE traversal, MAP-T uses double stateless translation. The first
from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the translation is from IPv4 to IPv6 (NAT46) at the CE, and the second
service provider network. translation is from IPv6 to IPv4 (NAT64) at the service provider
network.
464XLAT may use double translation (stateless NAT46 + stateful NAT64) 464XLAT may use double translation (stateless NAT46 + stateful NAT64)
or single translation (stateful NAT64), depending on different or single translation (stateful NAT64) depending on different
factors, such as the use of DNS by the applications and the factors, such as the use of DNS by the applications and the
availability of a DNS64 function (in the host or in the service availability of a DNS64 function (in the host or in the service
provider network). For deployment guidelines, please refer to provider network). For deployment guidelines, please refer to
[RFC8683]. [RFC8683].
The first step for the double translation mechanisms is a stateless The first step for the double translation mechanisms is a stateless
NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP
Translation Algorithm) [RFC7915], which does not translate IPv4 Translation Algorithm) [RFC7915], which does not translate IPv4
header options and/or multicast IP/ICMP packets. With encapsulation- header options and/or multicast IP/ICMP packets. With encapsulation-
based technologies the header is transported intact and multicast can based technologies, the header is transported intact, and multicast
also be carried. can also be carried.
Single and double translation results in native IPv6 traffic with a Single and double translation results in native IPv6 traffic with a
transport layer next-header. The fields in these headers can be used transport-layer next header. The fields in these headers can be used
for functions such as hashing across equal-cost multipaths or access for functions such as hashing across equal-cost multipaths or Access
control list (ACL) filtering. Encapsulation technologies, in Control List (ACL) filtering. Encapsulation technologies, in
contrast, may hinder hashing algorithms or other functions relying on contrast, may hinder hashing algorithms or other functions relying on
header inspection. header inspection.
Solutions using double translation can only carry port-aware IP Solutions using double translation can only carry port-aware IP
protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 protocols (e.g., TCP and UDP) and ICMP when they are used with IPv4
address sharing (please refer to Section 4.3 for more details). address sharing (please refer to Section 4.3 for more details).
Encapsulation based solutions can carry any other protocols over IP, Encapsulation-based solutions can also carry any other protocols over
too. IP.
An in-depth analysis of stateful NAT64 can be found in [RFC6889]. An in-depth analysis of stateful NAT64 can be found in [RFC6889].
As stateful NAT interferes with the port numbers, As stateful NAT interferes with the port numbers, [NAT-SUPP] explains
[I-D.ietf-tsvwg-natsupp] explains how NATs can handle SCTP (Stream how NATs can handle SCTP (Stream Control Transmission Protocol).
Control Transmission Protocol).
3.3. IPv4 Address Sharing 3.3. IPv4 Address Sharing
As public IPv4 address exhaustion is a common motivation for As public IPv4 address exhaustion is a common motivation for
deploying IPv6, transition technologies need to provide a solution deploying IPv6, transition technologies need to provide a solution
for allowing public IPv4 address sharing. that allows public IPv4 address sharing.
In order to fulfill this requirement, a stateful NAPT function is a In order to fulfill this requirement, a stateful NAPT function is a
necessary function in all of the mechanisms. The major necessary function in all of the mechanisms. The major
differentiator is where in the architecture this function is located. differentiator is where in the architecture this function is located.
The solutions compared by this document fall into two categories: The solutions compared by this document fall into two categories:
* CGN-based approaches (DS-Lite, 464XLAT) * Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)
* A+P-based approaches (lw4o6, MAP-E, MAP-T) * 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 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 the NAPT44 function and maintains per-session state for all of the
active client's traffic. The customer's device does not require per- active client's traffic. The customer's device does not require per-
session state for NAPT. session state for NAPT.
In the A+P-based model, a device (usually a CE) performs stateful 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. NAPT44 and maintains per-session state only for co-located devices,
in the customer's home network. Here, the centralized network e.g., in the customer's home network. Here, the centralized network
function (lwAFTR or BR) only needs to perform stateless function (lwAFTR or BR) only needs to perform stateless
encapsulation/decapsulation or NAT64. encapsulation/decapsulation or NAT64.
Issues related to IPv4 address sharing mechanisms are described in Issues related to IPv4 address-sharing mechanisms are described in
[RFC6269] and should also be considered. [RFC6269] and should also be considered.
The address sharing efficiency of the five technologies is The address-sharing efficiency of the five technologies is
significantly different, it is discussed in Section 4.2. significantly different and is discussed in Section 4.2.
lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 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, 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 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 case of 464XLAT, one-to-one mapping can also be achieved through EAMT
Address Mapping Table) [RFC7757]. (Explicit Address Mapping Table) [RFC7757].
Conversely, both MAP-E and MAP-T may be configured to provide more 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 than one public IPv4 address (i.e., an address with an IPv4 prefix
/32) to customers. shorter than a /32) to customers.
Dynamic DNS issues in address-sharing contexts and their possible Dynamic DNS issues in address-sharing contexts and their possible
solutions using PCP (Port Control Protocol) are discussed in detail solutions using PCP (Port Control Protocol) are discussed in detail
in [RFC7393]. in [RFC7393].
3.4. IPv4 Pool Size Considerations 3.4. IPv4 Pool Size Considerations
In this section we do some simple calculations regarding port In this section, we do some simple calculations regarding port
numbers, however, technical limitations are not the only point to numbers. However, technical limitations are not the only point to
consider for port sharing, there are also local regulations or BCP. consider for port sharing; there are also local regulations and best
current practices.
Note: under "port numbers", we mean TCP/UDP port numbers or ICMP Note: By "port numbers", we mean TCP/UDP port numbers or ICMP
identifiers. identifiers.
In most networks, it is possible to, using existing data about flows In most networks, it is possible to use existing data about flows to
to CDNs/caches or other well-known IPv6-enabled destinations, Content Delivery Networks (CDNs), caches, or other well-known
calculate the percentage of traffic that would turn into IPv6 if it IPv6-enabled destinations to calculate the percentage of traffic that
is enabled on that network or part of it. 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 Knowing that, it is possible to calculate the IPv4 pool size required
for a given number of subscribers, depending on the IPv4aaS for a given number of subscribers, depending on the IPv4aaS
technology being used. technology being used.
According to [MIY2010], each user-device (computer, tablet, According to [MIY2010], each user device (computer, tablet,
smartphone) behind a NAT, could simultaneously use up to 300 ports. smartphone) behind a NAT could simultaneously use up to 300 ports.
(Table 1 of [MIY2010] lists the port number usage of various (Table 1 of [MIY2010] lists the port number usage of various
applications. According to [REP2014] the downloading of some web applications. According to [REP2014], the downloading of some web
pages may consume up to 200 port numbers.) If the extended NAPT pages may consume up to 200 port numbers.) If the extended NAPT
algorithm is used, which includes the full five tuple into the algorithm is used, which includes the full 5-tuple into the
connection tracking table, then the port numbers are reused, when the connection tracking table, then the port numbers are reused when the
destinations are different. Therefore, we need to consider the destinations are different. Therefore, we need to consider the
number of "port hungry" applications that are accessing the same number of "port-hungry" applications that are accessing the same
destination simultaneously. We estimate that in the case of a destination simultaneously. We estimate that in the case of a
residential subscriber, there will be typically no more than 4 of residential subscriber, there will be typically no more than four
port hungry applications communicating with the same destination port-hungry applications communicating with the same destination
simultaneously, which means a total of 1,200 ports. simultaneously, which is a total of 1,200 ports.
If for example, 80% of the traffic is expected towards IPv6 For example, if 80% of the traffic is expected towards IPv6
destinations, only 20% will actually be using IPv4 ports, so in our destinations, only 20% will actually be using IPv4 ports. Thus, in
example, that will mean 240 ports required per subscriber. our example, 240 ports are required for each subscriber.
From the 65,535 ports available per IPv4 address, we could even From the 65,535 ports available per IPv4 address, we could even
consider reserving 1,024 ports, in order to allow customers that need consider reserving 1,024 ports for customers that need EAMT entries
EAMT entries for incoming connections to System Ports (0-1023, also for incoming connections to System ports (0-1023, also called "well-
called well-known ports) [RFC7605], which means 64,511 ports actually known ports") [RFC7605]. This means that 64,511 ports are actually
available per each IPv4 address. available for each IPv4 address.
According to this, a /22 (1.024 public IPv4 addresses) will be According to this, a /22 (1.024 public IPv4 addresses) will be
sufficient for over 275,000 subscribers sufficient for over 275,000 subscribers
(1,024x64,511/240=275,246.93). (1,024x64,511/240=275,246.93).
Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient
for over 4,403,940 subscribers, and so on. for over 4,403,940 subscribers, and so on.
This is a conservative approach, which is valid in the case of This is a conservative approach, which is valid in the case of
464XLAT, because ports are assigned dynamically by the NAT64, so it 464XLAT because ports are assigned dynamically by the NAT64.
is not necessary to consider if one user is actually using more or Therefore, it is not necessary to consider if one user is actually
less ports: Average values work well. using more or fewer ports; average values work well.
As the deployment of IPv6 progresses, the use of NAT64, and therefore As the deployment of IPv6 progresses, the use of NAT64, and therefore
of public IPv4 addresses, decreases (more IPv6/ports, less IPv4/ of public IPv4 addresses, decreases (more IPv6 ports, fewer IPv4
ports), so either more subscribers can be accommodated with the same ports). Thus, either more subscribers can be accommodated with the
number of IPv4 addresses, or some of those addressed can be retired same number of IPv4 addresses or some of those addressed can be
from the NAT64. retired from the NAT64.
For comparison, if dual-stack is being used, any given number of For comparison, if dual-stack is being used, any given number of
users will require the same number of public IPv4 addresses. For users will require the same number of public IPv4 addresses. For
instance, a /14 will provide 262,144 IPv4 public addresses for instance, a /14 will provide 262,144 IPv4 public addresses for
262,144 subscribers, versus 275,000 subscribers being served with 262,144 subscribers, versus 275,000 subscribers being served with
only a /22. only a /22.
In the other IPv4aaS technologies, this calculation will only match In the other IPv4aaS technologies, this calculation will only match
if the assignment of ports per subscriber can be done dynamically, if the assignment of ports per subscriber can be done dynamically,
which is not always the case (depending on the vendor which is not always the case (depending on the vendor
implementation). implementation).
An alternative approximation for the other IPv4aaS technologies, when When dynamic assignment of addresses is not possible, an alternative
dynamically assignment of addresses is not possible, must ensure approximation for the other IPv4aaS technologies must ensure a
sufficient number of ports per subscriber. That means 1,200 ports, sufficient number of ports per subscriber. That means 1,200 ports,
and typically, it comes to 2,000 ports in many deployments. In that 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 case, assuming 80% is IPv6 traffic (as above), only 30 subscribers
30 subscribers per each IPv4 address, so the closer approximation to will be allowed per each IPv4 address; thus, the closer approximation
275,000 subscribers per our example with 464XLAT (with a /22), will 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 be using a /19, which serves 245,760 subscribers (a /19 has 8,192
addresses, 30 subscribers with 2,000 ports each, per address). 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 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, 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 the number of ports required per subscriber can be limited as low as
4 ports per subscriber. However, the practical limit depends on the four ports per subscriber. However, the practical limit depends on
desired limit for parallel connections that any single host behind the desired limit for parallel connections that any single host
the NAT can have to the same address and port in Internet. Note that behind the NAT can have to the same address and port in Internet.
it is becoming more common that applications use AJAX (Asynchronous Note that it is becoming more common that applications use AJAX
JavaScript and XML) and similar mechanisms, so taking that extreme (Asynchronous JavaScript and XML) and similar mechanisms, so taking
limit is probably not a safe choice. that extreme limit is probably not a safe choice.
This extremely reduced number of ports "feature" could also be used This feature of extremely reduced number of ports could also be used
in case the CLAT-enabled CE with 464XLAT makes use of the 5-tuple NAT in case the CLAT-enabled CE with 464XLAT makes use of tracking the
connections tracking, and could also be further extended if the NAT64 5-tuple NAT connections and could also be further extended if the
also use the 5-tuple. NAT64 also uses the 5-tuple.
Please also refer to [RFC6888] for in-depth information about the Please also refer to [RFC6888] for in-depth information about the
requirements for sizing Carrier-Grade NAT gateways. requirements for sizing CGN gateways.
3.5. CE Provisioning Considerations 3.5. CE Provisioning Considerations
All of the technologies require some provisioning of customer All of the technologies require some provisioning of customer
devices. The table below shows which methods currently have devices. The table below shows which methods currently have
extensions for provisioning the different mechanisms. extensions for provisioning the different mechanisms.
+==============+=========+=========+=========+==========+===========+ +==============+=========+=========+=========+==========+===========+
|Provisioning | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | |Provisioning | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
|Method | | | | | | |Method | | | | | |
skipping to change at page 14, line 32 skipping to change at line 617
|[RFC8658] | | | | | | |[RFC8658] | | | | | |
+--------------+---------+---------+---------+----------+-----------+ +--------------+---------+---------+---------+----------+-----------+
|TR-069 | * | X | * | X | X | |TR-069 | * | X | * | X | X |
|[TR-069] | | | | | | |[TR-069] | | | | | |
+--------------+---------+---------+---------+----------+-----------+ +--------------+---------+---------+---------+----------+-----------+
|DNS64 | X | | | | | |DNS64 | X | | | | |
|[RFC7050] | | | | | | |[RFC7050] | | | | | |
+--------------+---------+---------+---------+----------+-----------+ +--------------+---------+---------+---------+----------+-----------+
|YANG [RFC7950]|[RFC8512]|[RFC8513]|[RFC8676]|[RFC8676] | [RFC8676] | |YANG [RFC7950]|[RFC8512]|[RFC8513]|[RFC8676]|[RFC8676] | [RFC8676] |
+--------------+---------+---------+---------+----------+-----------+ +--------------+---------+---------+---------+----------+-----------+
|DHCP4o6 | | | X | X | | |DHCP 4o6 | | | X | X | |
|[RFC7341] | | | | | | |[RFC7341] | | | | | |
+--------------+---------+---------+---------+----------+-----------+ +--------------+---------+---------+---------+----------+-----------+
Table 2: Available Provisioning Mechanisms Table 2: Available Provisioning Mechanisms
*: Work started at BroadBand Forum (2021). *: Work started at Broadband Forum (2021)
X: Supported by the provisioning method. X: Supported by the provisioning method
3.6. Support for Multicast 3.6. Support for Multicast
The solutions covered in this document are all intended for unicast The solutions covered in this document are all intended for unicast
traffic. [RFC8114] describes a method for carrying encapsulated IPv4 traffic. [RFC8114] describes a method for carrying encapsulated IPv4
multicast traffic over an IPv6 multicast network. This could be multicast traffic over an IPv6 multicast network. This could be
deployed in parallel to any of the operator's chosen IPv4aaS deployed in parallel to any of the operator's chosen IPv4aaS
mechanism. mechanism.
4. Detailed Analysis 4. Detailed Analysis
4.1. Architectural Differences 4.1. Architectural Differences
4.1.1. Basic Comparison 4.1.1. Basic Comparison
The five IPv4aaS technologies can be classified into 2x2=4 categories The five IPv4aaS technologies can be classified based on two aspects:
on the basis of two aspects:
* Technology used for service provider network traversal. It can be * Technology used for service provider network traversal. It can be
single/double translation or encapsulation. single/double translation or encapsulation.
* Presence or absence of NAPT44 per-flow state in the operator * Presence or absence of per-flow state in the operator network.
network.
+====================+=========+=========+=======+=======+=======+ +====================+=========+=========+=======+=======+=======+
| | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+====================+=========+=========+=======+=======+=======+ +====================+=========+=========+=======+=======+=======+
| Translation (T) or | T | E | E | E | T | | Translation (T) or | T | E | E | E | T |
| Encapsulation (E) | | | | | | | Encapsulation (E) | | | | | |
+--------------------+---------+---------+-------+-------+-------+ +--------------------+---------+---------+-------+-------+-------+
| Per-flow state in | X | X | | | | | Presence (+) of | + | + | | | |
| op. network | | | | | | | Per-Flow State in | | | | | |
| Operator Network | | | | | |
+--------------------+---------+---------+-------+-------+-------+ +--------------------+---------+---------+-------+-------+-------+
Table 3: Basic comparison among the analyzed technologies Table 3: Basic Comparison among the Analyzed Technologies
4.2. Tradeoff between Port Number Efficiency and Stateless Operation 4.2. Trade-Off between Port Number Efficiency and Stateless Operation
464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices,
respectively. This may cause scalability issues for the number of respectively. This may cause scalability issues for the number of
clients or volume of traffic, but does not impose a limitation on the clients or volume of traffic, but it does not impose a limitation on
number of ports per user, as they can be allocated dynamically on- the number of ports per user, as they can be allocated dynamically
demand and the allocation policy can be centrally managed/adjusted. 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 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 the service provider network. However, this means that the number of
ports provided to each user (and hence the effective IPv4 address ports provided to each user (and hence the effective IPv4 address-
sharing ratio) must be pre-provisioned to the client. sharing ratio) must be pre-provisioned to the client.
Changing the allocated port ranges with A+P based technologies, Changing the allocated port ranges with A+P-based technologies
requires more planning and is likely to involve re-provisioning both requires more planning and is likely to involve reprovisioning both
hosts and operator side equipment. It should be noted that due to hosts and operator-side equipment. It should be noted that due to
the per-customer binding table entry used by lw4o6, a single customer the per-customer binding table entry used by lw4o6, a single customer
can be re-provisioned (e.g., if they request a full IPv4 address) can be reprovisioned (e.g., if they request a full IPv4 address)
without needing to change parameters for a number of customers as in without needing to change parameters for a number of customers as in
a MAP domain. a MAP domain.
It is also worth noting that there is a direct relationship between It is also worth noting that there is a direct relationship between
the efficiency of customer public port-allocations and the the efficiency of public port allocations for customers and the
corresponding logging overhead that may be necessary to meet data- corresponding logging overhead that may be necessary to meet data-
retention requirements. This is considered in Section 4.7 below. retention requirements. This is considered in Section 4.7.
Determining the optimal number of ports for a fixed port set is not 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 an easy task and may also be impacted by local regulatory law (and in
in the Belgian case it is not a law but more a MoU / BCP), which may the Belgian case, it is not a law but more a memorandum of
define a maximum number of users per IP address, and consequently a understanding or best current practice), which may define a maximum
minimum number of ports per user. 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 On the one hand, the "lack of ports" situation may cause serious
problems in the operation of certain applications. For example, problems in the operation of certain applications. For example,
Miyakawa has demonstrated the consequences of the session number Miyakawa has demonstrated the consequences of the session number
limitation due to port number shortage on the example of Google Maps limitation due to port number shortage in the example of Google Maps
[MIY2010]. When the limit was 15, several blocks of the map were [MIY2010]. When the limit was 15, several blocks of the map were
missing, and the map was unusable. This study also provided several missing, and the map was unusable. This study also provided several
examples for the session numbers of different applications (the examples for the session numbers of different applications (the
highest one was Apple's iTunes: 230-270 ports). highest one was Apple's iTunes at 230-270 ports).
The port number consumption of different applications is highly The port number consumption of different applications is highly
varying and e.g. in the case of web browsing it depends on several varying. In the case of web browsing, it depends on several factors,
factors, including the choice of the web page, the web browser, and including the choice of the web page, the web browser, and sometimes
sometimes even the operating system [REP2014]. For example, under the operating system [REP2014]. For example, under certain
certain conditions, 120-160 ports were used (URL: sohu.com, browser: conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox
Firefox under Ubuntu Linux), and in some other cases it was only 3-12 under Ubuntu Linux), and in some other cases, only 3-12 ports were
ports (URL: twitter.com, browser: Iceweasel under Debian Linux). used (URL: twitter.com, browser: Iceweasel under Debian Linux).
There may be several users behind a CE router, especially in the There may be several users behind a CE router, especially in the
broadband case (e.g. Internet is used by different members of a broadband case (e.g., Internet is used by different members of a
family simultaneously), so sufficient ports must be allocated to family simultaneously), so sufficient ports must be allocated to
avoid impacting user experience. avoid impacting user experience.
In general, assigning too few source port numbers to an end user may In general, assigning too few source port numbers to an end user may
results in unexpected and hard to debug consequences, therefore, if result in unexpected and hard-to-debug consequences; therefore, if
the number of ports per end user is fixed, then we recommend to the number of ports per end user is fixed, then we recommend
assign a conservatively large number of ports. E.g. the developers assigning a conservatively large number of ports. For example, the
of Jool used 2048 ports per user in their example for MAP-T developers of Jool used 2048 ports per user in their example for
[MEX2022]. MAP-T [JOOL-MAPT].
However, assigning too many ports per CE router will result in waste However, assigning too many ports per CE router will result in waste
of public IPv4 addresses, which is a scarce and expensive resource. of public IPv4 addresses, which are scarce and expensive resources.
Clearly this is a big advantage in the case of 464XLAT where they are Clearly, this is a big advantage in the case of 464XLAT where they
dynamically managed, so that the number of IPv4 addresses for the are dynamically managed so that the number of IPv4 addresses for the
sharing-pool is smaller while the availability of ports per user sharing pool is smaller while the availability of ports per user
don't need to be pre-defined and is not a limitation for them. doesn't need to be pre-defined and is not a limitation.
There is a direct tradeoff between the optimization of client port There is a direct trade-off between the optimization of client port
allocations and the associated logging overhead. Section 4.7 allocations and the associated logging overhead. Section 4.7
discusses this in more depth. discusses this in more depth.
We note that common CE router NAT44 implementations utilizing We note that common NAT44 implementations utilizing Netfilter at the
Netfilter, multiplexes active sessions using a 3-tuple (source CE router multiplex active sessions using a 3-tuple (source address,
address, destination address, and destination port). This means that destination address, and destination port). This means that external
external source ports can be reused for unique internal source and source ports can be reused for unique internal source and destination
destination address and port sessions. It is also noted, that addresses and port sessions. It is also noted that Netfilter cannot
Netfilter cannot currently make use of multiple source port ranges currently make use of multiple source port ranges (i.e., several
(i.e. several blocks of ports distributed across the total port space blocks of ports distributed across the total port space as is common
as is common in MAP deployments), this may influence the design when in MAP deployments). This may influence the design when using
using stateless technologies. stateless technologies.
Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can Stateful technologies, 464XLAT, DS-Lite, and NAT444 can therefore be
therefore be much more efficient in terms of port allocation and thus much more efficient in terms of port allocation and thus public IP
public IP address saving. The price is the stateful operation in the address saving. The price is the stateful operation in the service
service provider network, which allegedly does not scale up well. It provider network, which allegedly does not scale up well. It should
should be noticed that in many cases, all those factors may depend on be noted that, in many cases, all those factors may depend on how it
how it is actually implemented. is actually implemented.
Measurements have been started to examine the scalability of a few Measurements have been started to examine the scalability of a few
stateful solutions in two areas: stateful solutions in two areas:
* How their performance scales up with the number of CPU cores? * How their performance scales up with the number of CPU cores
* To what extent their performance degrades with the number of * To what extent their performance degrades with the number of
concurrent connections? concurrent connections
The details of the measurements and their results are available from The details of the measurements and their results are available from
[I-D.lencse-v6ops-transition-scalability]. [IPv4aaS-SCALE-TECH].
We note that some CGN-type solutions can allocate ports dynamically We note that some CGN-type solutions can allocate ports dynamically
"on the fly". Depending on configuration, this can result in the "on the fly". Depending on configuration, this can result in the
same customer being allocated ports from different source addresses. same customer being allocated ports from different source addresses.
This can cause operational issues for protocols and applications that This can cause operational issues for protocols and applications that
expect multiple flows to be sourced from the same address. E.g., expect multiple flows to be sourced from the same address (e.g., ECMP
ECMP hashing, STUN, gaming, content delivery networks. However, it hashing, STUN, gaming, and content delivery networks). However, it
should be noticed that this is the same problem when a network has a should be noted that this is the same problem when a network has a
NAT44 with multiple public IPv4 addresses, or even when applications NAT44 with multiple public IPv4 addresses, or even when applications
in a dual-stack case, behave wrongly if happy eyeballs is flapping in a dual-stack case, behave wrongly if Happy Eyeballs is flapping
the flow address between IPv4 and IPv6. the flow address between IPv4 and IPv6.
The consequences of IPv4 address sharing [RFC6269] may impact all The consequences of IPv4 address sharing [RFC6269] may impact all
five technologies. However, when ports are allocated statically, five technologies. However, when ports are allocated statically,
more customers may get ports from the same public IPv4 address, which more customers may get ports from the same public IPv4 address, which
may results in negative consequences with higher probability, e.g. may result in negative consequences with higher probability. For
many applications and service providers (Sony PlayStation Network, example, many applications and service providers (Sony PlayStation
OpenDNS, etc.) permanently blocking IPv4 ranges if they detect that Network, OpenDNS, etc.) can permanently block IPv4 ranges if they
they are used for address sharing. detect that they are used for address sharing.
Both cases are, again, implementation dependent. Both cases are, again, implementation-dependent.
We note that although it is not of typical use, one can do 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 deterministic, stateful NAT and reserve a fixed set of ports for each
customer, as well. customer as well.
4.3. Support for Public Server Operation 4.3. Support for Public Server Operation
Mechanisms that rely on operator side per-flow state do not, by Mechanisms that rely on operator-side per-flow state do not, by
themselves, offer a way for customers to present services on publicly themselves, offer a way for customers to present services on publicly
accessible transport layer ports. accessible transport-layer ports.
Port Control Protocol (PCP) [RFC6887] provides a mechanism for a The Port Control Protocol (PCP) [RFC6887] provides a mechanism for a
client to request an external public port from a CGN device. For client to request an external public port from a CGN device. For
server operation, it is required with NAT64/464XLAT, and it is server operation, it is required with 464XLAT/NAT64, and it is
supported in some DS-Lite AFTR implementations. supported in some DS-Lite AFTR implementations.
A+P based mechanisms distribute a public IPv4 address and restricted A+P-based mechanisms distribute a public IPv4 address and restricted
range of transport layer ports to the client. In this case, it is 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 possible for the user to configure their device to offer a publicly
accessible server on one of their allocated ports. It should be accessible server on one of their allocated ports. It should be
noted that commonly operators do not assign the Well-Known-Ports to noted that operators commonly do not assign the well-known ports to
users (unless they are allocating a full IPv4 address), so the user 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 will need to run the service on an allocated port or configure port
translation. translation.
Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 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- full IPv4 address, allowing exclusive use of all ports and non-port-
based transport layer protocols. Thus, they may also be used to based transport-layer protocols. Thus, they may also be used to
support server/services operation on their default ports. However, support server/services operation on their default ports. However,
when public IPv4 addresses are assigned to the CE router without when public IPv4 addresses are assigned to the CE router without
address sharing, obviously there is no advantage in terms of IPv4 address sharing, there is obviously no advantage in terms of IPv4
public addresses saving. public addresses saving.
It is also possible to configure specific ports mapping in 464XLAT/ It is also possible to configure specific ports mapping in 464XLAT/
NAT64 using EAMT [RFC7757], which means that only those ports are NAT64 using EAMT [RFC7757], which means that only those ports are
"lost" from the pool of addresses, so there is a higher maximization "lost" from the pool of addresses, so there is a higher maximization
of the total usage of IPv4/port resources. of the total usage of IPv4 port resources.
4.4. Support and Implementations 4.4. Support and Implementations
4.4.1. Vendor Support 4.4.1. Vendor Support
In general, router vendors support AFTR, MAP-E/T BR and NAT64. Load In general, router vendors support AFTR, MAP-E BR, MAP-T BR, and
balancer and firewall vendors usually support NAT64 as well, while NAT64. Vendors of load balancers and firewalls usually support NAT64
not all of them have support for the other protocols. as well while not all of them have support for the other protocols.
A 464XLAT client (CLAT) is implemented in Windows 10, Linux A 464XLAT client (CLAT) is implemented in Windows 10, Linux
(including Android), Windows Mobile, Chrome OS and iOS, but it is not (including Android), Windows Mobile, Chrome OS, and iOS, but it is
available in macOS 12.3.1. not available in macOS 12.3.1.
The remaining four solutions are commonly deployed as functions in The remaining four solutions are commonly deployed as functions in
the CE device only, however in general, except DS-Lite, the vendors the CE device only; however, the vendors' support is poor in general
support is poor. (except for DS-Lite).
The OpenWRT Linux based open-source OS designed for CE devices offers OpenWRT is a Linux-based open-source OS designed for CE devices. It
a number of different 'opkg' packages as part of the distribution: offers a number of different 'opkg' packages as part of the
distribution:
* '464xlat' enables support for 464XLAT CLAT functionality * '464xlat' enables support for 464XLAT CLAT functionality.
* 'ds-lite' enables support for DSLite B4 functionality * 'ds-lite' enables support for DSLite B4 functionality.
* 'map' enables support for MAP-E and lw4o6 CE functionality * 'map' enables support for MAP-E and lw4o6 CE functionality.
* 'map-t' enables support for MAP-T CE functionality * 'map-t' enables support for MAP-T CE functionality.
At the time of publication some free open-source implementations At the time of publication, some free open-source implementations
exist for the operator side functionality: exist for the operator-side functionality:
* Jool [jool] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR). * Jool [JOOL] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR)
* VPP/fd.io [vpp] (MAP-BR, lwAFTR, CGN, CLAT, NAT64). * VPP/fd.io [VPP] (MAP-BR, lwAFTR, CGN, CLAT, NAT64)
* Snabb [snabb] (lwAFTR). * Snabb [SNABB] (lwAFTR)
* AFTR [aftr] (DSLite AFTR). * AFTR [AFTR] (DSLite AFTR)
4.4.2. Support in Cellular and Broadband Networks 4.4.2. Support in Cellular and Broadband Networks
Several cellular networks use 464XLAT, whereas there are no Several cellular networks use 464XLAT, whereas there are no
deployments of the four other technologies in cellular networks, as deployments of the four other technologies in cellular networks, as
they are neither standardised nor implemented in UE devices. they are neither standardized nor implemented in UE devices.
In broadband networks, there are some deployments of 464XLAT, MAP-E In broadband networks, there are some deployments of 464XLAT, MAP-E,
and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite
being the most common, but lw4o6 taking over in the last years. being the most common, but deployments of lw4o6 have been rapidly
increasing in the last few years.
Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of Please refer to Tables 2 and 3 of [LEN2019] for a limited set of
deployment information. deployment information.
4.4.3. Implementation Code Sizes 4.4.3. Implementation Code Sizes
As hint to the relative complexity of the mechanisms, the following As a hint to the relative complexity of the mechanisms, the code
code sizes are reported from the OpenWRT implementations of each sizes reported from the OpenWRT implementations of each technology
technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, are 17 kB, 35 kB, 15 kB, 35 kB, and 48 kB for 464XLAT, lw4o6, DS-
DS-Lite, MAP-E, MAP-T, and lw4o6, respectively Lite, MAP-E, and MAP-T, respectively (see
(https://openwrt.org/packages/start). <https://openwrt.org/packages/start>).
We note that the support for all five technologies requires much less We note that the support for all five technologies requires a much
code size than the total sum of the above quantities, because they smaller code size than the total sum of the above quantities, because
contain a lot of common functions (data plane is shared among several they contain a lot of common functions (e.g., data plane is shared
of them). among several of them).
4.5. Typical Deployment and Traffic Volume Considerations 4.5. Typical Deployment and Traffic Volume Considerations
4.5.1. Deployment Possibilities 4.5.1. Deployment Possibilities
Theoretically, all five IPv4aaS technologies could be used together Theoretically, all five IPv4aaS technologies could be used together
with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 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 the CE router would treat the traffic between an IPv6-only client and
IPv4-only server as normal IPv6 traffic, and the stateful NAT64 IPv4-only server as normal IPv6 traffic, and the stateful NAT64
gateway would do a single translation, thus offloading this kind of gateway would do a single translation, thus offloading this kind of
traffic from the IPv4aaS technology. The cost of this solution would traffic from the IPv4aaS technology. The cost of this solution would
be the need for deploying also DNS64 + stateful NAT64. be the need to also deploy DNS64 + stateful NAT64.
However, this has not been implemented in clients or actual However, this has not been implemented in clients or actual
deployments, so only 464XLAT always uses this optimization and the deployments, so only 464XLAT always uses this optimization, and the
other four solutions do not use it at all. other four solutions do not use it at all.
4.5.2. Cellular Networks with 464XLAT 4.5.2. Cellular Networks with 464XLAT
Figures from existing deployments (end of 2018), show that the Figures from existing deployments (through the end of 2018) show the
typical traffic volumes in an IPv6-only cellular network, when typical traffic volumes in an IPv6-only cellular network when 464XLAT
464XLAT technology is used together with DNS64, are: technology is used together with DNS64:
* 75% of traffic is IPv6 end-to-end (no translation) * 75% of traffic is IPv6 end-to-end (no translation).
* 24% of traffic uses DNS64 + NAT64 (1 translation) * 24% of traffic uses DNS64 + NAT64 (one translation).
* Less than 1% of traffic uses the CLAT in addition to NAT64 (2 * Less than 1% of traffic uses the CLAT in addition to NAT64 (two
translations), due to an IPv4 socket and/or IPv4 literal. translations), due to an IPv4 socket and/or IPv4 literal.
Without using DNS64, 25% of the traffic would undergo double Without using DNS64, 25% of the traffic would undergo double
translation. translation.
4.5.3. Wireline Networks with 464XLAT 4.5.3. Wireline Networks with 464XLAT
Figures from several existing deployments (end of 2020), mainly with Figures from several existing deployments (through the end of 2020),
residential customers, show that the typical traffic volumes in an mainly with residential customers, show the ranges of typical traffic
IPv6-only network, when 464XLAT is used with DNS64, are in the volumes in an IPv6-only network, when 464XLAT is used with DNS64:
following ranges:
* 65%-85% of traffic is IPv6 end-to-end (no translation) * 65%-85% of traffic is IPv6 end-to-end (no translation).
* 14%-34% of traffic uses DNS64 + NAT64 (1 translation) * 14%-34% of traffic uses DNS64 + NAT64 (one translation).
* Less than 1-2% of traffic uses the CLAT in addition to NAT64 (2 * Less than 1-2% of traffic uses the CLAT in addition to NAT64 (two
translations), due to an IPv4 socket and/or IPv4 literal. translations), due to an IPv4 socket and/or IPv4 literal.
Without using DNS64, 16%-35% of the traffic would undergo double Without using DNS64, 16%-35% of the traffic would undergo double
translation. translation.
This data is consistent with non-public information of actual This data is consistent with non-public information of actual
deployments, which can be easily explained. When a wireline ISP has deployments, which can be easily explained. When a wireline ISP has
mainly residential customers, content providers and CDNs which are mainly residential customers, content providers and CDNs that are
already IPv6 enabled (Google/Youtube, Netflix, Facebook, Akamai, etc) already IPv6 enabled (Google/YouTube, Netflix, Facebook, Akamai,
typically account for the 65-85% of the traffic in the network, so etc.) typically account for 65-85% of the traffic in the network.
when the subscribers are IPv6 enabled, about the same figures of Thus, when the subscribers are IPv6 enabled, about the same
traffic will become IPv6. percentage of traffic will become IPv6.
4.6. Load Sharing 4.6. Load Sharing
If multiple network-side devices are needed as PLAT/AFTR/BR for If multiple network-side devices are needed as PLAT/AFTR/BR for
capacity, then there is a need for a load sharing mechanism. ECMP capacity, then there is a need for a load-sharing mechanism. ECMP
(Equal-Cost Multi-Path) load sharing can be used for all (Equal-Cost Multipath) load sharing can be used for all technologies;
technologies, however stateful technologies will be impacted by however, stateful technologies will be impacted by changes in network
changes in network topology or device failure. topology or device failure.
Technologies utilizing DNS64 can also distribute load across PLAT/ Technologies utilizing DNS64 can also distribute load across PLAT/
AFTR devices, evenly or unevenly, by using different prefixes. AFTR devices, evenly or unevenly, by using different prefixes.
Different network specific prefixes can be distributed for Different network-specific prefixes can be distributed for
subscribers in appropriately sized segments (like split-horizon DNS, subscribers in appropriately sized segments (like split-horizon DNS,
also called DNS views). also called "DNS views").
Stateless technologies, due to the lack of per-flow state, can make Stateless technologies, due to the lack of per-flow state, can make
use of anycast routing for load sharing and resiliency across use of anycast routing for load sharing and resiliency across network
network-devices, both ingress and egress; flows can take asymmetric devices, both ingress and egress; flows can take asymmetric paths
paths through the network, i.e., in through one lwAFTR/BR and out via through the network, i.e., in through one lwAFTR/BR and out via
another. another.
Mechanisms with centralized NAPT44 state have a number of challenges Mechanisms with centralized NAPT44 state have a number of challenges
specifically related to scaling and resilience. As the total amount specifically related to scaling and resilience. As the total amount
of client traffic exceeds the capacity of a single CGN instance, of client traffic exceeds the capacity of a single CGN instance,
additional nodes are required to handle the load. As each CGN additional nodes are required to handle the load. Each CGN maintains
maintains a stateful table of active client sessions, this table may a stateful table of active client sessions, and this table may need
need to be syncronized between CGN instances. This is necessary for to be synchronized between CGN instances. This is necessary for two
two reasons: reasons:
* To prevent all active customer sessions being dropped in event of * To prevent all active customer sessions from being dropped in the
a CGN node failure. event of a CGN node failure.
* To ensure a matching state table entry for an active session in * To ensure a matching state table entry for an active session in
the event of asymmetric routing through different egress and the event of asymmetric routing through different egress and
ingress CGN nodes. ingress CGN nodes.
4.7. Logging 4.7. Logging
In the case of 464XLAT and DS-Lite, the user of any given public IPv4 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 address and port combination will vary over time; therefore, logging
is necessary to meet data retention laws. Each entry in the PLAT/ is necessary to meet data-retention laws. Each entry in the PLAT/
AFTR's generates a logging entry. As discussed in Section 4.2, a AFTR generates a logging entry. As discussed in Section 4.2, a
client may open hundreds of sessions during common tasks such as web- client may open hundreds of sessions during common tasks such as web
browsing, each of which needs to be logged so the overall logging browsing, each of which needs to be logged so the overall logging
burden on the network operator is significant. In some countries, burden on the network operator is significant. In some countries,
this level of logging is required to comply with data retention this level of logging is required to comply with data-retention
legislation. legislation.
One common optimization available to reduce the logging overhead is One common optimization available to reduce the logging overhead is
the allocation of a block of ports to a client for the duration of 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 their session. This means that a logging entry only needs to be made
when the client's port block is released, which dramatically reduces when the client's port block is released, which dramatically reduces
the logging overhead. This comes as the cost of less efficient the logging overhead. This comes as the cost of less efficient
public address sharing as clients need to be allocated a port block 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 of a fixed size regardless of the actual number of ports that they
are using. are using.
Stateless technologies that pre-allocate the IPv4 addresses and ports Stateless technologies that pre-allocate the IPv4 addresses and ports
only require that copies of the active MAP rules (for MAP-E and MAP- 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 T) or binding table (for lw4o6) are retained along with timestamp
information of when they have been active. Support tools (e.g., information of when they have been active. Support tools (e.g.,
those used to serve data retention requests) may need to be updated 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 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 algorithm so that IPv4 information can be linked to the IPv6 prefix
delegated to a client). As stateless technologies do not have a delegated to a client). Stateless technologies do not have a
centralized stateful element which customer traffic needs to pass centralized stateful element that customer traffic needs to pass
through, so if data retention laws mandate per-session logging, there through, so if data-retention laws mandate per-session logging, there
is no simple way of meeting this requirement with a stateless is no simple way of meeting this requirement with a stateless
technology alone. Thus, a centralized NAPT44 model may be the only technology alone. Thus, a centralized NAPT44 model may be the only
way to meet this requirement. way to meet this requirement.
Deterministic CGN [RFC7422] was proposed as a solution to reduce the Deterministic CGN [RFC7422] was proposed as a solution to reduce the
resource consumption of logging. resource consumption of logging.
Please also refer to Section 4 of [RFC6888] for more information Please also refer to Section 4 of [RFC6888] for more information
about requirements for logging Carrier-Grade NAT gateways. about requirements for logging CGN gateways.
4.8. Optimization for IPv4-only devices/applications 4.8. Optimization for IPv4-Only Devices and Applications
When IPv4-only devices or applications are behind a CE connected with When IPv4-only devices or applications are behind a CE connected with
IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily
be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 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 E) and will reach the IPv4 address of the destination, even if that
service supports dual-stack. This means that the traffic flow will service supports dual-stack. This means that the traffic flow will
cross through the AFTR, lwAFTR or BR, depending on the specific cross through the AFTR, lwAFTR, or BR, depending on the specific
transition mechanism being used. transition mechanism being used.
Even if those services are directly connected to the operator network Even if those services are directly connected to the operator network
(for example, CDNs, caches), or located internally (such as VoIP, (e.g., CDNs and caches) or located internally (such as VoIP, etc.),
etc.), it is not possible to avoid that overhead. it is not possible to avoid that overhead.
However, in the case of those mechanisms that use a NAT46 function, 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 in the CE (464XLAT and MAP-T), it is possible to take advantage of
optimization functionalities, such as the ones described in optimization functionalities, such as the ones described in
[I-D.ietf-v6ops-464xlat-optimization]. [OP-464XLAT/MAP-T].
Using those optimizations, because the NAT46 has already translated Because the NAT46 has already translated the IPv4-only flow to IPv6
the IPv4-only flow to IPv6, and the services are dual-stack, they can and the services are dual-stack, using these optimizations allows the
be reached without the need to translate them back to IPv4. services to be reached without the need to translate the flow back to
IPv4.
5. Performance Comparison 5. Performance Comparison
We plan to compare the performances of the most prominent free We plan to compare the performances of the most prominent free
software implementations of the five IPv6 transition technologies software implementations of the five IPv6 transition technologies
using the methodology described in "Benchmarking Methodology for IPv6 using the methodology described in "Benchmarking Methodology for IPv6
Transition Technologies" [RFC8219]. Transition Technologies" [RFC8219].
The Dual DUT Setup of [RFC8219] makes it possible to use the existing The dual Device Under Test (DUT) setup of [RFC8219] makes it possible
"Benchmarking Methodology for Network Interconnect Devices" [RFC2544] to use the existing measurement devices compliant with "Benchmarking
compliant measurement devices, however, this solution has two kinds Methodology for Network Interconnect Devices" [RFC2544]; however,
of limitations: this solution has two kinds of limitations:
* Dual DUT setup has the drawback that the performances of the CE * Dual DUT setup has the drawback that the performances of the CE
and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT) are
are measured together. In order to measure the performance of measured together. In order to measure the performance of only
only one of them, we need to ensure that the desired one is the one of them, we need to ensure that the desired one is the
bottleneck. bottleneck.
* Measurements procedures for PDV and IPDV measurements are missing * Measurement procedures for Packet Delay Variation (PDV) and Inter-
from the legacy devices, and the old measurement procedure for Packet Delay Variation (IPDV) measurements are missing from the
Latency has been redefined in [RFC8219]. legacy devices, and the old measurement procedure for latency has
been redefined in [RFC8219].
The Single DUT Setup of [RFC8219] makes it possible to benchmark the
selected device separately, but it either requires a special Tester
or some trick is need, if we want to use legacy Testers. An example
for the latter is our stateless NAT64 measurements testing Througput
and Frame Loss Rate using a legacy [RFC5180] compliant commercial
tester [LEN2020a]
Siitperf, an [RFC8219] compliant DPDK-based software Tester for
benchmarking stateless NAT64 gateways has been developed recently and
it is available from GitHub [SIITperf] as free software and
documented in [LEN2021]. Originally, it literally followed the test
frame format of [RFC2544] including "hard-wired" source and
destination port numbers, and then it has been complemented with the
random port feature required by [RFC4814]. The new version is
documented in [LEN2020b]
Further DPDK-based, [RFC8219] compliant software testers are being The single DUT setup of [RFC8219] makes it possible to benchmark the
developed at the Budapest University of Technology and Economics as selected device separately, but either special Tester is required or
student projects. They are planned to be released as free software, some trick is needed if we want to use legacy Testers. An example
too. for the latter is our stateless NAT64 measurements testing Throughput
and Frame Loss Rate using a legacy commercial Tester [LEN2020a] that
is compliant with [RFC5180].
Information about the benchmarking tools, measurements and results Siitperf, a DPDK-based software Tester that is compliant with
will be made available in [I-D.lencse-v6ops-transition-benchmarking]. [RFC8219] and used for benchmarking stateless NAT64 gateways, has
been 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, and then
it was complemented with the pseudorandom port feature required by
[RFC4814]. The new version is documented in [LEN2020b].
6. Acknowledgements Further DPDK-based software Testers that are compliant 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.
The authors would like to thank Ole Troan, Warren Kumari, Dan Information about the benchmarking tools, measurements, and results
Romascanu, Brian Trammell, Joseph Salowey, Roman Danyliw, Erik Kline, will be made available in [IPv4aaS-BENCHMARK-TECH].
Lars Eggert, Zaheduzzaman Sarker, Robert Wilton, Eric Vyncke and
Martin Duke for their review of this draft and acknowledge the inputs
of 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, Nick Hilliard, Tom Petch,
Yannis Nikolopoulos, Havard Eidnes, Yann-Ju Chu, Barbara Stark,
Vasilenko Eduard, Chongfeng Xie, Henri Alves de Godoy, Magnus
Westerlund, Michael Tuexen, Philipp S. Tiesel, Brian E Carpenter and
Joe Touch.
7. IANA Considerations 6. IANA Considerations
This document does not make any request to IANA. This document has no IANA actions.
8. Security Considerations 7. Security Considerations
As discussed in section 4.7, the different technologies have varying As discussed in Section 4.7, the different technologies have varying
logging capabilities and limitations. Care should be taken when logging capabilities and limitations. Care should be taken when
storing, transmitting, and providing access to log entries that may storing, transmitting, and providing access to log entries that may
be considered personally identifiable information. However, it be considered personally identifiable information. However, it
should be noticed that those issues are not specific to the IPv4aaS should be noted that those issues are not specific to the IPv4aaS
IPv6 transition technologies, but in general to logging IPv6 transition technologies but apply to logging functionalities in
functionalities. general.
For all five technologies, the CE device typically contains a DNS For all five technologies, the CE device typically contains a DNS
proxy. However, the user may change DNS settings. If it happens and proxy. However, the user may change DNS settings. If this happens
lw4o6, MAP-E and MAP-T are used with significantly restricted port and lw4o6, MAP-E, and MAP-T are used with a significantly restricted
set, which is required for an efficient public IPv4 address sharing, port set (which is required for efficient public IPv4 address
the entropy of the source ports is significantly lowered (e.g. from sharing), the entropy of the source ports is significantly lowered
16 bits to 10 bits, when 1024 port numbers are assigned to each (e.g., from 16 bits to 10 bits when 1024 port numbers are assigned to
subscriber) and thus these technologies are theoretically less each subscriber), and these technologies are thus theoretically less
resilient against cache poisoning, see [RFC5452]. However, an resilient against cache poisoning (see [RFC5452]). However, an
efficient cache poisoning attack requires that the subscriber efficient cache poisoning attack requires that the subscriber
operates an own caching DNS server and the attack is performed in the operates its own caching DNS server and the attack is performed in
service provider network. Thus, we consider the chance of the the service provider network. Thus, we consider the chance of the
successful exploitation of this vulnerability as low. successful exploitation of this vulnerability to be low.
IPv4aaS technologies based on encapsulation have not DNSSEC IPv4aaS technologies based on encapsulation have no DNSSEC
implications. However, those based on translation may have implications. However, those based on translation may have
implications as discussed in Section 4.1 of [RFC8683]. implications as discussed in Section 4.1 of [RFC8683].
An in-depth security analysis of all five IPv6 transition An in-depth security analysis of all five IPv6 transition
technologies and their most prominent free software implementations technologies and their most prominent free software implementations
according to the methodology defined in [LEN2018] is planned. according to the methodology defined in [LEN2018] is planned.
As the first step, an initial security analysis of 464XLAT was done As the first step, an initial security analysis of 464XLAT was done
in [Azz2021]. in [AZZ2021].
The implementers of any of the five IPv4aaS solutions should consult The implementers of any of the five IPv4aaS solutions should consult
the Security Considerations of the respective RFCs documenting them. the Security Considerations of the respective RFCs documenting them.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999, DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>. <https://www.rfc-editor.org/info/rfc2544>.
skipping to change at page 30, line 10 skipping to change at line 1332
[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for
IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676,
DOI 10.17487/RFC8676, November 2019, DOI 10.17487/RFC8676, November 2019,
<https://www.rfc-editor.org/info/rfc8676>. <https://www.rfc-editor.org/info/rfc8676>.
[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for
NAT64/464XLAT in Operator and Enterprise Networks", NAT64/464XLAT in Operator and Enterprise Networks",
RFC 8683, DOI 10.17487/RFC8683, November 2019, RFC 8683, DOI 10.17487/RFC8683, November 2019,
<https://www.rfc-editor.org/info/rfc8683>. <https://www.rfc-editor.org/info/rfc8683>.
9.2. Informative References 8.2. Informative References
[aftr] ISC, "ISC implementation of AFTR", 2022, [AFTR] ISC, "ISC Implementation of AFTR",
<https://www.isc.org/downloads/>. <https://downloads.isc.org/isc/aftr/>.
[Azz2021] Al-Azzawi, A. and G. Lencse, "Identification of the [AZZ2021] Al-Azzawi, A. and G. Lencse, "Identification of the
Possible Security Issues of the 464XLAT IPv6 Transition Possible Security Issues of the 464XLAT IPv6 Transition
Technology", Infocommunications Journal, vol. 13, no. 4, Technology", Infocommunications Journal, Vol. 13, No. 4,
pp. 10-18, DOI: 10.36244/ICJ.2021.4.2, December 2021, pp. 10-18, DOI 10.36244/ICJ.2021.4.2, December 2021,
<https://www.infocommunications.hu/2021_4_2>. <https://www.infocommunications.hu/2021_4_2>.
[I-D.ietf-tsvwg-natsupp] [IPv4aaS-BENCHMARK-TECH]
Stewart, R. R., Tüxen, M., and I. Rüngeler, "Stream
Control Transmission Protocol (SCTP) Network Address
Translation Support", Work in Progress, Internet-Draft,
draft-ietf-tsvwg-natsupp-23, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-natsupp-
23.txt>.
[I-D.ietf-v6ops-464xlat-optimization]
Martinez, J. P. and A. D'Egidio, "464XLAT/MAT-T
Optimization", Work in Progress, Internet-Draft, draft-
ietf-v6ops-464xlat-optimization-03, 28 July 2020,
<https://www.ietf.org/archive/id/draft-ietf-v6ops-464xlat-
optimization-03.txt>.
[I-D.lencse-v6ops-transition-benchmarking]
Lencse, G., "Performance Analysis of IPv6 Transition Lencse, G., "Performance Analysis of IPv6 Transition
Technologies for IPv4aaS", Work in Progress, Internet- Technologies for IPv4aaS", Work in Progress, Internet-
Draft, draft-lencse-v6ops-transition-benchmarking-01, 2 Draft, draft-lencse-v6ops-transition-benchmarking-01, 2
May 2022, <https://www.ietf.org/archive/id/draft-lencse- May 2022, <https://datatracker.ietf.org/doc/html/draft-
v6ops-transition-benchmarking-01.txt>. lencse-v6ops-transition-benchmarking-01>.
[I-D.lencse-v6ops-transition-scalability] [IPv4aaS-SCALE-TECH]
Lencse, G., "Scalability of IPv6 Transition Technologies Lencse, G., "Scalability of IPv6 Transition Technologies
for IPv4aaS", Work in Progress, Internet-Draft, draft- for IPv4aaS", Work in Progress, Internet-Draft, draft-
lencse-v6ops-transition-scalability-02, 7 March 2022, lencse-v6ops-transition-scalability-03, 30 June 2022,
<https://www.ietf.org/archive/id/draft-lencse-v6ops- <https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-
transition-scalability-02.txt>. transition-scalability-03>.
[jool] NIC.MX, "Open Source SIIT and NAT64 for Linux", 2022, [JOOL] "Jool: SIIT & NAT64", <http://www.jool.mx>.
<http://www.jool.mx>.
[JOOL-MAPT]
"MAP-T Run", <https://www.jool.mx/en/run-mapt.html>.
[LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", Computers & Security (Elsevier), vol. stateful NAT64", Computers & Security, Vol. 77, No. 1, pp.
77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018,
1 August 2018,
<http://www.hit.bme.hu/~lencse/publications/ECS-2018- <http://www.hit.bme.hu/~lencse/publications/ECS-2018-
Methodology-revised.pdf>. Methodology-revised.pdf>.
[LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of
IPv6 Transition Technologies: A Subjective Classification IPv6 Transition Technologies: A Subjective Classification
for Security Analysis", IEICE Transactions on for Security Analysis", IEICE Transactions on
Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: Communications, Vol. E102-B, No. 10, pp. 2021-2035,
10.1587/transcom.2018EBR0002, 1 October 2019, DOI 10.1587/transcom.2018EBR0002, October 2019,
<http://www.hit.bme.hu/~lencse/publications/ <http://www.hit.bme.hu/~lencse/publications/
e102-b_10_2021.pdf>. e102-b_10_2021.pdf>.
[LEN2020a] Lencse, G., "Benchmarking Stateless NAT64 Implementations [LEN2020a] Lencse, G., "Benchmarking stateless NAT64 implementations
with a Standard Tester", Telecommunication Systems, vol. with a standard tester", Telecommunication Systems, Vol.
75, pp. 245-257, DOI: 10.1007/s11235-020-00681-x, 15 June 75, pp. 245-257, DOI 10.1007/s11235-020-00681-x, June
2020, <https://link.springer.com/article/10.1007/ 2020, <https://link.springer.com/article/10.1007/
s11235-020-00681-x>. s11235-020-00681-x>.
[LEN2020b] Lencse, G., "Adding RFC 4814 Random Port Feature to [LEN2020b] Lencse, G., "Adding RFC 4814 Random Port Feature to
Siitperf: Design, Implementation and Performance Siitperf: Design, Implementation and Performance
Estimation", International Journal of Advances in Estimation", International Journal of Advances in
Telecommunications, Electrotechnics, Signals and Systems, Telecommunications, Electrotechnics, Signals and Systems,
vol 9, no 3, pp. 18-26, DOI: 10.11601/ijates.v9i3.291, Vol. 9, No. 3, pp. 18-26, DOI 10.11601/ijates.v9i3.291,
2020, 2020,
<http://ijates.org/index.php/ijates/article/view/291>. <https://ijates.org/index.php/ijates/article/view/291>.
[LEN2021] Lencse, G., "Design and Implementation of a Software [LEN2021] Lencse, G., "Design and Implementation of a Software
Tester for Benchmarking Stateless NAT64 Gateways", IEICE Tester for Benchmarking Stateless NAT64 Gateways", IEICE
Transactions on Communications, DOI: Transactions on Communications, Vol. E104.B, Issue 2, pp.
10.1587/transcom.2019EBN0010, 2021, 128-140, DOI 10.1587/transcom.2019EBN0010, 2021,
<https://www.jstage.jst.go.jp/article/transcom/E104.B/2/ <https://doi.org/10.1587/transcom.2019EBN0010>.
E104.B_2019EBN0010/_article>.
[MEX2022] Jool Developers, "Jool: Siit and NAT64", Documentation of
Jool MAP-T implementation, 2022,
<https://www.jool.mx/en/run-mapt.html>.
[MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation [MIY2010] Miyakawa, S., "IPv4 to IPv6 Transformation Schemes", IEICE
schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp. Transactions on Communications, Vol. E93-B, Issue 5, pp.
1078-1084, DOI:10.1587/transcom.E93.B.10, May 2010, 1078-1084, DOI 10.1587/transcom.E93.B.1078, 2010,
<https://www.jstage.jst.go.jp/article/transcom/E93.B/5/ <https://www.jstage.jst.go.jp/article/transcom/E93.B/5/
E93.B_5_1078/_article>. E93.B_5_1078/_article>.
[REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number [NAT-SUPP] Stewart, R. R., Tüxen, M., and I. Ruengeler, "Stream
consumption of the NAT64 IPv6 transition Control Transmission Protocol (SCTP) Network Address
technology", Proc. 37th Internat. Conf. on Translation Support", Work in Progress, Internet-Draft,
Telecommunications and Signal Processing (TSP 2014), draft-ietf-tsvwg-natsupp-23, 25 October 2021,
Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
2014, <http://www.hit.bme.hu/~lencse/publications/TSP- natsupp-23>.
[OP-464XLAT/MAP-T]
Palet Martinez, J. and A. D'Egidio, "464XLAT/MAT-T
Optimization", Work in Progress, Internet-Draft, draft-
ietf-v6ops-464xlat-optimization-03, 28 July 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
464xlat-optimization-03>.
[REP2014] Répás, S., Hajas, T., and G. Lencse, "Port Number
Consumption of the NAT64 IPv6 Transition Technology", 37th
International Conference on Telecommunications and Signal
Processing, DOI 10.1109/TSP.2015.7296411, 2014,
<http://www.hit.bme.hu/~lencse/publications/TSP-
2014-PC.pdf>. 2014-PC.pdf>.
[SIITperf] Lencse, G., "Siitperf: an RFC 8219 compliant SIIT [SIITPERF] "Siitperf: an RFC 8219 compliant SIIT (stateless NAT64)
(stateless NAT64) tester", November 2019, tester", commit bdce0f, February 2021,
<https://github.com/lencsegabor/siitperf>. <https://github.com/lencsegabor/siitperf>.
[snabb] Igalia, "Snabb implementation of lwAFTR", 2022, [SNABB] "Snabb implementation of lwAFTR", commit 1ef72ce, January
<https://github.com/Igalia/snabb>. 2022, <https://github.com/Igalia/snabb>.
[TR-069] BroadBand Forum, "TR-069: CPE WAN Management Protocol", [TR-069] Broadband Forum, "CPE WAN Management Protocol", Technical
June 2020, <https://www.broadband- Report TR-069, June 2020, <https://www.broadband-
forum.org/technical/download/TR-069.pdf>. forum.org/technical/download/TR-069.pdf>.
[vpp] "VPP Implementations of IPv6-only with IPv4aaS", 2022, [VPP] "VPP", July 2022,
<https://gerrit.fd.io/r/#/admin/projects/>. <https://wiki.fd.io/index.php?title=VPP&oldid=11809>.
Appendix A. Change Log
A.1. 01 - 02
* Ian Farrer has joined us as an author.
* Restructuring: the description of the five IPv4aaS technologies
was moved to a separate section.
* More details and figures were added to the description of the five
IPv4aaS technologies.
* Section titled "High-level Architectures and their Consequences"
has been completely rewritten.
* Several additions/clarification throughout Section titled
"Detailed Analysis".
* Section titled "Performance Analysis" was dropped due to lack of
results yet.
* Word based text ported to XML.
* Further text cleanups, added text on state sync and load
balancing. Additional comments inline that should be considered
for future updates.
A.2. 02 - 03
* The suggestions of Mohamed Boucadair are incorporated.
* New considerations regarding possible optimizations.
A.3. 03 - 04
* Section titled "Performance Analysis" was added. It mentions our
new benchmarking tool, siitperf, and highlights our plans.
* Some references were updated or added.
A.4. 04 - 05
* Some references were updated or added.
A.5. 05 - 06
* Some references were updated or added.
A.6. 06 - 00-WG Item
* Stats dated and added for Broadband deployments.
* Other clarifications and references.
* New section: IPv4 Pool Size.
* Typos.
A.7. 00 - 01
To facilitate WGLC, the unfinished parts were moved to two new
drafts:
* New I-D for scale up measurements. (Including the results of
iptables.)
* New I-D for benchmarking measurements. (Only a stub.)
A.8. 01 - 02
Update on the basis of the AD review.
Update of the references.
A.9. 02 - 03
Nits and changes from IESG review.
Updated wrong reference to PCP.
A.10. 03 - 04
Update to address the comments of further reviews. Acknowledgements
Updated Acknowledgements. The authors would like to thank 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 their review of this draft and acknowledge the inputs
of 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.
Authors' Addresses Authors' Addresses
Gabor Lencse Gábor Lencse
Budapest University of Technology and Economics Budapest University of Technology and Economics
Budapest Budapest
Magyar tudosok korutja 2. Magyar tudósok körútja 2
H-1117 H-1117
Hungary Hungary
Email: lencse@hit.bme.hu Email: lencse@hit.bme.hu
URI: http://www.hit.bme.hu/~lencse/index_en.htm URI: http://www.hit.bme.hu/~lencse/index_en.htm
Jordi Palet Martinez Jordi Palet Martinez
The IPv6 Company The IPv6 Company
Molino de la Navata, 75 Molino de la Navata, 75
28420 La Navata - Galapagar Madrid 28420 La Navata - Galapagar Madrid
Spain Spain
 End of changes. 235 change blocks. 
666 lines changed or deleted 565 lines changed or added

This html diff was produced by rfcdiff 1.48.