idnits 2.17.00 (12 Aug 2021) /tmp/idnits56729/draft-ietf-v6ops-transition-comparison-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (5 April 2022) is 39 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 1220, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-lencse-v6ops-transition-benchmarking-00 -- Duplicate reference: RFC4814, mentioned in 'LEN2020b', was also mentioned in 'RFC4814'. -- Duplicate reference: RFC8219, mentioned in 'SIITperf', was also mentioned in 'RFC8219'. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops G. Lencse 3 Internet-Draft BUTE 4 Intended status: Informational J. Palet Martinez 5 Expires: 7 October 2022 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 5 April 2022 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-ietf-v6ops-transition-comparison-03 17 Abstract 19 Several IPv6 transition technologies have been developed to provide 20 customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only 21 access and/or core network. All these technologies have their 22 advantages and disadvantages, and depending on existing topology, 23 skills, strategy and other preferences, one of these technologies may 24 be the most appropriate solution for a network operator. 26 This document examines the five most prominent IPv4aaS technologies 27 considering a number of different aspects to provide network 28 operators with an easy to use reference to assist in selecting the 29 technology that best suits their needs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 7 October 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 66 2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 6 69 2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. High-level Architectures and their Consequences . . . . . . . 8 72 3.1. Service Provider Network Traversal . . . . . . . . . . . 8 73 3.2. Network Address Translation . . . . . . . . . . . . . . . 9 74 3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 10 75 3.4. IPv4 Pool Size Considerations . . . . . . . . . . . . . . 11 76 3.5. CE Provisioning Considerations . . . . . . . . . . . . . 13 77 3.6. Support for Multicast . . . . . . . . . . . . . . . . . . 13 78 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 14 79 4.1. Architectural Differences . . . . . . . . . . . . . . . . 14 80 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 14 81 4.2. Tradeoff between Port Number Efficiency and Stateless 82 Operation . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.3. Support for Public Server Operation . . . . . . . . . . . 17 84 4.4. Support and Implementations . . . . . . . . . . . . . . . 18 85 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 18 86 4.4.2. Support in Cellular and Broadband Networks . . . . . 18 87 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 19 88 4.5. Typical Deployment and Traffic Volume Considerations . . 19 89 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 19 90 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 19 91 4.5.3. Wireline Networks with 464XLAT . . . . . . . . . . . 20 92 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 20 93 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 4.8. Optimization for IPv4-only devices/applications . . . . . 22 95 5. Performance Comparison . . . . . . . . . . . . . . . . . . . 22 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 101 9.2. Informative References . . . . . . . . . . . . . . . . . 28 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 103 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 31 106 A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 31 108 A.6. 06 - 00-WG Item . . . . . . . . . . . . . . . . . . . . . 31 109 A.7. 00 - 01 . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 A.8. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 A.9. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 114 1. Introduction 116 As the deployment of IPv6 becomes more prevalent, it follows that 117 network operators will move to building single-stack IPv6 core and 118 access networks to simplify network planning and operations. 119 However, providing customers with IPv4 services continues to be a 120 requirement for the foreseeable future. To meet this need, the IETF 121 has standardized a number of different IPv4aaS technologies for this 122 [LEN2019] based on differing requirements and deployment scenarios. 124 The number of technologies that have been developed makes it time 125 consuming for a network operator to identify the most appropriate 126 mechanism for their specific deployment. This document provides a 127 comparative analysis of the most commonly used mechanisms to assist 128 operators with this problem. 130 Five different IPv4aaS solutions are considered. The following IPv6 131 transition technologies are covered: 133 1. 464XLAT [RFC6877] 135 2. Dual Stack Lite [RFC6333] 137 3. lw4o6 (Lightweight 4over6) [RFC7596] 139 4. MAP-E [RFC7597] 141 5. MAP-T [RFC7599] 142 We note that [RFC6180] gives guidelines for using IPv6 transition 143 mechanisms during IPv6 deployment addressing a much broader topic, 144 whereas this document focuses on a small part of it. 146 2. Overview of the Technologies 148 The following sections introduce the different technologies analyzed 149 in this document, describing some of their most important 150 characteristics. 152 2.1. 464XLAT 154 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 155 or single translation (stateful NAT64), depending on different 156 factors, such as the use of DNS by the applications and the 157 availability of a DNS64 function (in the host or in the service 158 provider network). 160 The customer-side translator (CLAT) is located in the customer's 161 device, and it performs stateless NAT64 translation [RFC7915] (more 162 precisely, stateless NAT46, a stateless IP/ICMP translation from IPv4 163 to IPv6). IPv4-embedded IPv6 addresses [RFC6052] are used for both 164 source and destination addresses. Commonly, a /96 prefix (either the 165 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 166 as the IPv6 destination for the IPv4-embedded client traffic. 168 In the operator's network, the provider-side translator (PLAT) 169 performs stateful NAT64 [RFC6146] to translate the traffic. The 170 destination IPv4 address is extracted from the IPv4-embedded IPv6 171 packet destination address and the source address is from a pool of 172 public IPv4 addresses. 174 Alternatively, when a dedicated /64 is not available for translation, 175 the CLAT device uses a stateful NAT44 translation before the 176 stateless NAT46 translation. 178 In general, state close to the end-user network (i.e. at the CE - 179 Customer Edge router) is not perceived as problematic as state in the 180 operators network. 182 In typical deployments, 464XLAT is used together with DNS64 183 [RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client 184 or application communicates with an IPv4-only server, the DNS64 185 server returns the IPv4-embedded IPv6 address of the IPv4-only 186 server. In this case, the IPv6-only client sends out IPv6 packets, 187 and the CLAT functions as an IPv6 router and the PLAT performs a 188 stateful NAT64 for these packets. In this case, there is a single 189 translation. 191 Alternatively, one can say that DNS64 + stateful NAT64 is used to 192 carry the traffic of the IPv6-only client and the IPv4-only server, 193 and the CLAT is used only for the IPv4 traffic from applications or 194 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 196 Private +----------+ Translated +----------+ _______ 197 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 198 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 199 |Device|<-------| NAT46 |<------------| NAT64 | (________) 200 +------+ +----------+ ^ +----------+ 201 | 202 Operator IPv6 203 network 205 Figure 1: Overview of the 464XLAT architecture 207 Note: in mobile networks, CLAT is commonly implemented in the user's 208 equipment (UE or smartphone). 210 2.2. Dual-Stack Lite 212 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 213 transition mechanisms to be developed. DS-Lite uses a 'Basic 214 Broadband Bridging' (B4) function in the customer's CE router that 215 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 216 service-provider network to a centralized 'Address Family Transition 217 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 218 4in6 [RFC2473] traffic and translates the IPv4 payload to public IPv4 219 source address using a stateful NAPT44 [RFC2663] function. 221 +-------------+ 222 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 223 +------+ IPv4 | B4 | tunnel |------+------+ _______ 224 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 225 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 226 +------+ +----------+ ^ |Decap.| 44 | (________) 227 | +------+------+ 228 Operator IPv6 229 network 231 Figure 2: Overview of the DS-Lite architecture 233 2.3. Lightweight 4over6 235 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 236 difference is that the stateful NAPT44 function is relocated from the 237 centralized AFTR to the customer's B4 element (called a lwB4). The 238 AFTR (called a lwAFTR) function therefore only performs A+P routing 239 and 4in6 encapsulation/decapsulation. 241 Routing to the correct client and IPv4 address sharing is achieved 242 using the Address + Port (A+P) model [RFC6346] of provisioning each 243 lwB4 with a unique tuple of IPv4 address and a unique range of 244 layer-4 ports. The client uses these for NAPT44. 246 The lwAFTR implements a binding table, which has a per-client entry 247 linking the customer's source IPv4 address and allocated range of 248 layer-4 ports to their IPv6 tunnel endpoint address. The binding 249 table allows egress traffic from customers to be validated (to 250 prevent spoofing) and ingress traffic to be correctly encapsulated 251 and forwarded. As there needs to be a per-client entry, an lwAFTR 252 implementation needs to be optimized for performing a per-packet 253 lookup on the binding table. 255 Direct communication (that is, without translation) between two lwB4s 256 is performed by hair-pinning traffic through the lwAFTR. 258 +-------------+ +----------+ 259 Private | lwB4 | IPv4-in-IPv6| Stateless| 260 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 261 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 262 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 263 +------+ | 44 |Decap.| ^ | routing) | (________) 264 +------+------+ | +----------+ 265 Operator IPv6 266 network 268 Figure 3: Overview of the lw4o6 architecture 270 2.4. MAP-E 272 Like 464XLAT (Section 2.1), MAP-E and MAP-T use [RFC6052] 273 IPv4-embedded IPv6 addresses to represent IPv4 hosts outside the MAP 274 domain. 276 MAP-E and MAP-T use a stateless algorithm to embed portions of the 277 customer's allocated IPv4 address (or part of an address with A+P 278 routing) into the IPv6 prefix delegated to the client. This allows 279 for large numbers of clients to be provisioned using a single MAP 280 rule (called a MAP domain). The algorithm also allows for direct 281 IPv4 peer-to-peer communication between hosts provisioned with common 282 MAP rules. 284 The CE (Customer-Edge) router typically performs stateful NAPT44 285 [RFC2663] to translate the private IPv4 source addresses and source 286 ports into an address and port range defined by applying the MAP rule 287 to the delegated IPv6 prefix. The client address/port allocation 288 size is a design parameter. The CE router then encapsulates the IPv4 289 packet in an IPv6 packet [RFC2473] and sends it directly to another 290 host in the MAP domain (for peer-to-peer) or to a Border Router (BR) 291 if the IPv4 destination is not covered in one of the CE's MAP rules. 293 The MAP BR is provisioned with the set of MAP rules for the MAP 294 domains it serves. These rules determine how the MAP BR is to 295 decapsulate traffic that it receives from client, validating the 296 source IPv4 address and layer 4 ports assigned, as well as how to 297 calculate the destination IPv6 address for ingress IPv4 traffic. 299 +-------------+ +----------+ 300 Private | MAP CE | IPv4-in-IPv6| Stateless| 301 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 302 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 303 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 304 +------+ | 44 |Decap.| ^ | routing) | (________) 305 +------+------+ | +----------+ 306 Operator IPv6 307 network 309 Figure 4: Overview of the MAP-E architecture 311 2.5. MAP-T 313 MAP-T uses the same mapping algorithm as MAP-E. The major difference 314 is that double stateless translation (NAT46 in the CE and NAT64 in 315 the BR) is used to traverse the ISP's IPv6 single-stack network. 316 MAP-T can also be compared to 464XLAT when there is a double 317 translation. 319 A MAP CE router typically performs stateful NAPT44 to translate 320 traffic to a public IPv4 address and port-range calculated by 321 applying the provisioned Basic MAP Rule (BMR - a set of inputs to the 322 algorithm) to the delegated IPv6 prefix. The CE then performs 323 stateless translation from IPv4 to IPv6 [RFC7915]. The MAP BR is 324 provisioned with the same BMR as the client, enabling the received 325 IPv6 traffic to be statelessly NAT64 translated back to the public 326 IPv4 source address used by the client. 328 Using translation instead of encapsulation also allows IPv4-only 329 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 330 have IPv4-embedded IPv6 addresses. 332 +-------------+ +----------+ 333 Private | MAP CE | Translated | Stateless| 334 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 335 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 336 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 337 +------+ | 44 |NAT46 | ^ | routing) | (________) 338 +------+------+ | +----------+ 339 Operator IPv6 340 network 342 Figure 5: Overview of the MAP-T architecture 344 3. High-level Architectures and their Consequences 346 3.1. Service Provider Network Traversal 348 For the data-plane, there are two approaches for traversing the IPv6 349 provider network: 351 * 4-6-4 translation 353 * 4-in-6 encapsulation 355 +==============+=========+=========+=======+=======+=======+ 356 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 357 +==============+=========+=========+=======+=======+=======+ 358 | 4-6-4 trans. | X | | | | X | 359 +--------------+---------+---------+-------+-------+-------+ 360 | 4-6-4 encap. | | X | X | X | | 361 +--------------+---------+---------+-------+-------+-------+ 363 Table 1: Available Traversal Mechanisms 365 In the scope of this document, all of the encapsulation based 366 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 367 tunneling mechanism which does not require any additional tunnel 368 headers. 370 It should be noted that both of these approaches result in an 371 increase in the size of the packet that needs to be transported 372 across the operator's network when compared to native IPv4. 4-6-4 373 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 374 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 375 overhead (an IPv6 header is prepended to the IPv4 header). 377 The increase in packet size can become a significant problem if there 378 is a link with a smaller MTU in the traffic path. This may result in 379 traffic needing to be fragmented at the ingress point to the IPv6 380 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 381 also result in the need to implement buffering and fragment re- 382 assembly in the BR node. 384 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 385 these mechanisms: It is strongly recommended that the MTU in the 386 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 387 side interface be set so that no fragmentation occurs within the 388 boundary of the IPv6-only domain. 390 3.2. Network Address Translation 392 For the high-level solution of IPv6 service provider network 393 traversal, MAP-T uses double stateless translation. First at the CE 394 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 395 service provider network. 397 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 398 or single translation (stateful NAT64), depending on different 399 factors, such as the use of DNS by the applications and the 400 availability of a DNS64 function (in the host or in the service 401 provider network). For deployment guidelines, please refer to 402 [RFC8683]. 404 The first step for the double translation mechanisms is a stateless 405 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 406 Translation Algorithm) [RFC7915], which does not translate IPv4 407 header options and/or multicast IP/ICMP packets. With encapsulation- 408 based technologies the header is transported intact and multicast can 409 also be carried. 411 Single and double translation results in native IPv6 traffic with a 412 layer-4 next-header. The fields in these headers can be used for 413 functions such as hashing across equal-cost multipaths or ACLs. For 414 encapsulation, there is an IPv6 header followed by an IPv4 header. 415 This results in less entropy for hashing algorithms, and may mean 416 that devices in the traffic path that perform header inspection (e.g. 417 router ACLs or firewalls) require the functionality to look into the 418 payload header. 420 Solutions using double translation can only carry port-aware IP 421 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 422 address sharing (please refer to Section 4.3 for more details). 423 Encapsulation based solutions can carry any other protocols over IP, 424 too. 426 An in-depth analysis of stateful NAT64 can be found in [RFC6889]. 428 3.3. IPv4 Address Sharing 430 As public IPv4 address exhaustion is a common motivation for 431 deploying IPv6, transition technologies need to provide a solution 432 for allowing public IPv4 address sharing. 434 In order to fulfill this requirement, a stateful NAPT function is a 435 necessary function in all of the mechanisms. The major 436 differentiator is where in the architecture this function is located. 438 The solutions compared by this document fall into two categories: 440 * CGN-based approaches (DS-Lite, 464XLAT) 442 * A+P-based approaches (lw4o6, MAP-E, MAP-T) 444 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 445 the NAPT44 function and maintains per-session state for all of the 446 active client's traffic. The customer's device does not require per- 447 session state for NAPT. 449 In the A+P-based model, a device (usually a CE) performs stateful 450 NAPT44 and maintains per-session state only co-located devices, e.g. 451 in the customer's home network. Here, the centralized network 452 function (lwAFTR or BR) only needs to perform stateless 453 encapsulation/decapsulation or NAT64. 455 Issues related to IPv4 address sharing mechanisms are described in 456 [RFC6269] and should also be considered. 458 The address sharing efficiency of the five technologies is 459 significantly different, it is discussed in Section 4.2. 461 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 462 sharing, see the details in Section 4.3. However, in that case, 463 there is no advantage in terms of public IPv4 address saving. In the 464 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 466 Conversely, both MAP-E and MAP-T may be configured to provide more 467 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 468 /32) to customers. 470 Dynamic DNS issues in address-sharing contexts and their possible 471 solutions using PCP (Port Control Protocol) are discussed in detail 472 in [RFC7393]. 474 3.4. IPv4 Pool Size Considerations 476 In most networks, it is possible to, using existing data about flows 477 to CDNs/caches or other well-known IPv6-enabled destinations, 478 calculate the percentage of traffic that would turn into IPv6 if it 479 is enabled on that network or part of it. 481 Knowing that, it is possible to calculate the IPv4 pool size required 482 for a given number of subscribers, depending on the IPv4aaS 483 technology being used. 485 Often it is assumed that each user-device (computer, tablet, 486 smartphone) behind a NAT, could simultaneously use about 300 ports. 487 Typically, in the case of a residential subscriber, there will be a 488 maximum of 4 of those devices in use simultaneously, which means a 489 total of 1,200 ports. 491 If for example, 80% of the traffic is expected towards IPv6 492 destinations, only 20% will actually be using IPv4 ports, so in our 493 example, that will mean 240 ports required per subscriber. 495 From the 65,535 ports available per IPv4 address, we could even 496 consider reserving 1,024 ports, in order to allow customers that need 497 EAMT entries for incoming connections to System Ports (0-1023, also 498 called well-known ports) [RFC7605], which means 64,511 ports actually 499 available per each IPv4 address. 501 According to this, a /22 (1.024 public IPv4 addresses) will be 502 sufficient for over 275,000 subscribers 503 (1,024x64,511/240=275,246.93). 505 Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient 506 for over 4,403,940 subscribers, and so on. 508 This is a conservative approach, which is valid in the case of 509 464XLAT, because ports are assigned dynamically by the NAT64, so it 510 is not necessary to consider if one user is actually using more or 511 less ports: Average values work well. 513 As the deployment of IPv6 progresses, the use of NAT64, and therefore 514 of public IPv4 addresses, decreases (more IPv6/ports, less IPv4/ 515 ports), so either more subscribers can be accommodated with the same 516 number of IPv4 addresses, or some of those addressed can be retired 517 from the NAT64. 519 For comparison, if dual-stack is being used, any given number of 520 users will require the same number of public IPv4 addresses. For 521 instance, a /14 will provide 262,144 IPv4 public addresses for 522 262,144 subscribers, versus 275,000 subscribers being served with a 523 only a /22. 525 In the other IPv4aaS technologies, this calculation will only match 526 if the assignment of ports per subscriber can be done dynamically, 527 which is not always the case (depending on the vendor 528 implementation). 530 An alternative approximation for the other IPv4aaS technologies, when 531 dynamically assignment of addresses is not possible, must ensure 532 sufficient number of ports per subscriber. That means 1,200 ports, 533 and typically, it comes to 2,000 ports in many deployments. In that 534 case, assuming 80% of IPv6 traffic, as above, which will allow only 535 30 subscribers per each IPv4 address, so the closer approximation to 536 275,000 subscribers per our example with 464XLAT (with a /22), will 537 be using a /19, which serves 245,760 subscribers (a /19 has 8,192 538 addresses, 30 subscribers with 2,000 ports each, per address). 540 If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E 541 and MAP-T) make use of a 5-tuple for tracking the NAT connections, 542 the number of ports required per subscriber can be limited as low as 543 4 ports per subscriber. However, the practical limit depends on the 544 desired limit for parallel connections that any single host behind 545 the NAT can have to the same address and port in Internet. Note that 546 it is becoming more common that applications use AJAX and similar 547 mechanisms, so taking that extreme limit is probably not a very a 548 safe choice. 550 This extremely reduced number of ports "feature" could also be used 551 in case the CLAT-enabled CE with 464XLAT makes use of the 5-tuple NAT 552 connections tracking, and could also be further extended if the NAT64 553 also use the 5-tuple. 555 3.5. CE Provisioning Considerations 557 All of the technologies require some provisioning of customer 558 devices. The table below shows which methods currently have 559 extensions for provisioning the different mechanisms. 561 +==============+===========+===========+=======+=======+=======+ 562 | Provisioning | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 563 | Method | | | | | | 564 +==============+===========+===========+=======+=======+=======+ 565 | DHCPv6 | | X | X | X | X | 566 | [RFC8415] | | | | | | 567 +--------------+-----------+-----------+-------+-------+-------+ 568 | RADIUS | | [RFC6519] | X | X | X | 569 | [RFC8658] | | | | | | 570 +--------------+-----------+-----------+-------+-------+-------+ 571 | TR-069 | * | X | * | X | X | 572 +--------------+-----------+-----------+-------+-------+-------+ 573 | DNS64 | X | | | | | 574 | [RFC7050] | | | | | | 575 +--------------+-----------+-----------+-------+-------+-------+ 576 | YANG | [RFC8512] | X | X | X | X | 577 | [RFC7950] | | | | | | 578 +--------------+-----------+-----------+-------+-------+-------+ 579 | DHCP4o6 | | | X | X | | 580 | [RFC7341] | | | | | | 581 +--------------+-----------+-----------+-------+-------+-------+ 583 Table 2: Available Provisioning Mechanisms 585 *: Work started at BroadBand Forum (2021). 587 X: Supported by the provisioning method. 589 3.6. Support for Multicast 591 The solutions covered in this document are all intended for unicast 592 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 593 multicast traffic over an IPv6 multicast network. This could be 594 deployed in parallel to any of the operator's chosen IPv4aaS 595 mechanism. 597 4. Detailed Analysis 599 4.1. Architectural Differences 601 4.1.1. Basic Comparison 603 The five IPv4aaS technologies can be classified into 2x2=4 categories 604 on the basis of two aspects: 606 * Technology used for service provider network traversal. It can be 607 single/double translation or encapsulation. 609 * Presence or absence of NAPT44 per-flow state in the operator 610 network. 612 +================+=========+=========+=======+=======+=======+ 613 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 614 +================+=========+=========+=======+=======+=======+ 615 | 4-6-4 trans. | X | | | | X | 616 +----------------+---------+---------+-------+-------+-------+ 617 | 4-in-4 encap. | | X | X | X | | 618 +----------------+---------+---------+-------+-------+-------+ 619 | Per-flow state | X | X | | | | 620 | in op. network | | | | | | 621 +----------------+---------+---------+-------+-------+-------+ 623 Table 3: Available Provisioning Mechanisms 625 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 627 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 628 respectively. This may cause scalability issues for the number of 629 clients or volume of traffic, but does not impose a limitation on the 630 number of ports per user, as they can be allocated dynamically on- 631 demand and the allocation policy can be centrally managed/adjusted. 633 A+P based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in 634 the service provider network. However, this means that the number of 635 ports provided to each user (and hence the effective IPv4 address 636 sharing ratio) must be pre-provisioned to the client. 638 Changing the allocated port ranges with A+P based technologies, 639 requires more planning and is likely to involve re-provisioning both 640 hosts and operator side equipment. It should be noted that due to 641 the per-customer binding table entry used by lw4o6, a single customer 642 can be re-provisioned (e.g., if they request a full IPv4 address) 643 without needing to change parameters for a number of customers as in 644 a MAP domain. 646 It is also worth noting that there is a direct relationship between 647 the efficiency of customer public port-allocations and the 648 corresponding logging overhead that may be necessary to meet data- 649 retention requirements. This is considered in Section 4.7 below. 651 Determining the optimal number of ports for a fixed port set is not 652 an easy task, and may also be impacted by local regulatory law, which 653 may define a maximum number of users per IP address, and consequently 654 a minimum number of ports per user. 656 On the one hand, the "lack of ports" situation may cause serious 657 problems in the operation of certain applications. For example, 658 Miyakawa has demonstrated the consequences of the session number 659 limitation due to port number shortage on the example of Google Maps 660 [MIY2010]. When the limit was 15, several blocks of the map were 661 missing, and the map was unusable. This study also provided several 662 examples for the session numbers of different applications (the 663 highest one was Apple's iTunes: 230-270 ports). 665 The port number consumption of different applications is highly 666 varying and e.g. in the case of web browsing it depends on several 667 factors, including the choice of the web page, the web browser, and 668 sometimes even the operating system [REP2014]. For example, under 669 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 670 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 671 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 673 There may be several users behind a CE router, especially in the 674 broadband case (e.g. Internet is used by different members of a 675 family simultaneously), so sufficient ports must be allocated to 676 avoid impacting user experience. 678 Furthermore, assigning too many ports per CE router will result in 679 waste of public IPv4 addresses, which is a scarce and expensive 680 resource. Clearly this is a big advantage in the case of 464XLAT 681 where they are dynamically managed, so that the number of IPv4 682 addresses for the sharing-pool is smaller while the availability of 683 ports per user don't need to be pre-defined and is not a limitation 684 for them. 686 There is a direct tradeoff between the optimization of client port 687 allocations and the associated logging overhead. Section 4.7 688 discusses this in more depth. 690 We note that common CE router NAT44 implementations utilizing 691 Netfilter, multiplexes active sessions using a 3-tuple (source 692 address, destination address, and destination port). This means that 693 external source ports can be reused for unique internal source and 694 destination address and port sessions. It is also noted, that 695 Netfilter cannot currently make use of multiple source port ranges 696 (i.e. several blocks of ports distributed across the total port space 697 as is common in MAP deployments), this may influence the design when 698 using stateless technologies. 700 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 701 therefore be much more efficient in terms of port allocation and thus 702 public IP address saving. The price is the stateful operation in the 703 service provider network, which allegedly does not scale up well. It 704 should be noticed that in many cases, all those factors may depend on 705 how it is actually implemented. 707 Measurements have been started to examine the scalability of a few 708 stateful solutions in two areas: 710 * How their performance scales up with the number of CPU cores? 712 * To what extent their performance degrades with the number of 713 concurrent connections? 715 The details of the measurements and their results are available from 716 [I-D.lencse-v6ops-transition-scalability]. 718 We note that some CGN-type solutions can allocate ports dynamically 719 "on the fly". Depending on configuration, this can result in the 720 same customer being allocated ports from different source addresses. 721 This can cause operational issues for protocols and applications that 722 expect multiple flows to be sourced from the same address. E.g., 723 ECMP hashing, STUN, gaming, content delivery networks. However, it 724 should be noticed that this is the same problem when a network has a 725 NAT44 with multiple public IPv4 addresses, or even when applications 726 in a dual-stack case, behave wrongly if happy eyeballs is flapping 727 the flow address between IPv4 and IPv6. 729 The consequences of IPv4 address sharing [RFC6269] may impact all 730 five technologies. However, when ports are allocated statically, 731 more customers may get ports from the same public IPv4 address, which 732 may results in negative consequences with higher probability, e.g. 733 many applications and service providers (Sony PlayStation Network, 734 OpenDNS, etc.) permanently blocking IPv4 ranges if they detect that 735 they are used for address sharing. 737 Both cases are, again, implementation dependent. 739 We note that although it is not of typical use, one can do 740 deterministic, stateful NAT and reserve a fixed set of ports for each 741 customer, as well. 743 4.3. Support for Public Server Operation 745 Mechanisms that rely on operator side per-flow state do not, by 746 themselves, offer a way for customers to present services on publicly 747 accessible layer-4 ports. 749 Port Control Protocol (PCP) [RFC6887] provides a mechanism for a 750 client to request an external public port from a CGN device. For 751 server operation, it is required with NAT64/464XLAT, and it is 752 supported in some DS-Lite AFTR implementations. 754 A+P based mechanisms distribute a public IPv4 address and restricted 755 range of layer-4 ports to the client. In this case, it is possible 756 for the user to configure their device to offer a publicly accessible 757 server on one of their allocated ports. It should be noted that 758 commonly operators do not assign the Well-Known-Ports to users 759 (unless they are allocating a full IPv4 address), so the user will 760 need to run the service on an allocated port, or configure port 761 translation. 763 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 764 full IPv4 address, allowing exclusive use of all ports, and non-port- 765 based layer 4 protocols. Thus, they may also be used to support 766 server/services operation on their default ports. However, when 767 public IPv4 addresses are assigned to the CE router without address 768 sharing, obviously there is no advantage in terms of IPv4 public 769 addresses saving. 771 It is also possible to configure specific ports mapping in 464XLAT/ 772 NAT64 using EAMT [RFC7757], which means that only those ports are 773 "lost" from the pool of addresses, so there is a higher maximization 774 of the total usage of IPv4/port resources. 776 4.4. Support and Implementations 778 4.4.1. OS Support 780 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 781 (including Android), Windows Mobile, Chrome OS and iOS, but at the 782 time of writing is not available in MacOS. 784 The remaining four solutions are commonly deployed as functions in 785 the CE device only, however in general, except DS-Lite, the vendors 786 support is poor. 788 The OpenWRT Linux based open-source OS designed for CE devices offers 789 a number of different 'opkg' packages as part of the distribution: 791 * '464xlat' enables support for 464XLAT CLAT functionality 793 * 'ds-lite' enables support for DSLite B4 functionality 795 * 'map' enables support for MAP-E and lw4o6 CE functionality 797 * 'map-t' enables support for MAP-T CE functionality 799 At the time of publication some free open-source implementations 800 exist for the operator side functionality: 802 * Jool [jool] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR). 804 * VPP/fd.io [vpp] (MAP-BR, lwAFTR, CGN, CLAT, NAT64). 806 * Snabb [snabb] (lwAFTR). 808 * AFTR [aftr] (DSLite AFTR). 810 4.4.2. Support in Cellular and Broadband Networks 812 Several cellular networks use 464XLAT, whereas there are no 813 deployments of the four other technologies in cellular networks, as 814 they are neither standardised nor implemented in UE devices. 816 In broadband networks, there are some deployments of 464XLAT, MAP-E 817 and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite 818 being the most common, but lw4o6 taking over in the last years. 820 Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of 821 deployment information. 823 4.4.3. Implementation Code Sizes 825 As hint to the relative complexity of the mechanisms, the following 826 code sizes are reported from the OpenWRT implementations of each 827 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 828 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 829 (https://openwrt.org/packages/start). 831 We note that the support for all five technologies requires much less 832 code size than the total sum of the above quantities, because they 833 contain a lot of common functions (data plane is shared among several 834 of them). 836 4.5. Typical Deployment and Traffic Volume Considerations 838 4.5.1. Deployment Possibilities 840 Theoretically, all five IPv4aaS technologies could be used together 841 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 842 the CE router would treat the traffic between an IPv6-only client and 843 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 844 gateway would do a single translation, thus offloading this kind of 845 traffic from the IPv4aaS technology. The cost of this solution would 846 be the need for deploying also DNS64 + stateful NAT64. 848 However, this has not been implemented in clients or actual 849 deployments, so only 464XLAT always uses this optimization and the 850 other four solutions do not use it at all. 852 4.5.2. Cellular Networks with 464XLAT 854 Figures from existing deployments (end of 2018), show that the 855 typical traffic volumes in an IPv6-only cellular network, when 856 464XLAT technology is used together with DNS64, are: 858 * 75% of traffic is IPv6 end-to-end (no translation) 860 * 24% of traffic uses DNS64 + NAT64 (1 translation) 862 * Less than 1% of traffic uses the CLAT in addition to NAT64 (2 863 translations), due to an IPv4 socket and/or IPv4 literal. 865 Without using DNS64, 25% of the traffic would undergo double 866 translation. 868 4.5.3. Wireline Networks with 464XLAT 870 Figures from several existing deployments (end of 2020), mainly with 871 residential customers, show that the typical traffic volumes in an 872 IPv6-only network, when 464XLAT is used with DNS64, are in the 873 following ranges: 875 * 65%-85% of traffic is IPv6 end-to-end (no translation) 877 * 14%-34% of traffic uses DNS64 + NAT64 (1 translation) 879 * Less than 1-2% of traffic uses the CLAT in addition to NAT64 (2 880 translations), due to an IPv4 socket and/or IPv4 literal. 882 Without using DNS64, 16%-35% of the traffic would undergo double 883 translation. 885 4.6. Load Sharing 887 If multiple network-side devices are needed as PLAT/AFTR/BR for 888 capacity, then there is a need for a load sharing mechanism. ECMP 889 (Equal-Cost Multi-Path) load sharing can be used for all 890 technologies, however stateful technologies will be impacted by 891 changes in network topology or device failure. 893 Technologies utilizing DNS64 can also distribute load across PLAT/ 894 AFTR devices, evenly or unevenly, by using different prefixes. 895 Different network specific prefixes can be distributed for 896 subscribers in appropriately sized segments (like split-horizon DNS, 897 also called DNS views). 899 Stateless technologies, due to the lack of per-flow state, can make 900 use of anycast routing for load sharing and resiliency across 901 network-devices, both ingress and egress; flows can take asymmetric 902 paths through the network, i.e., in through one lwAFTR/BR and out via 903 another. 905 Mechanisms with centralized NAPT44 state have a number of challenges 906 specifically related to scaling and resilience. As the total amount 907 of client traffic exceeds the capacity of a single CGN instance, 908 additional nodes are required to handle the load. As each CGN 909 maintains a stateful table of active client sessions, this table may 910 need to be syncronized between CGN instances. This is necessary for 911 two reasons: 913 * To prevent all active customer sessions being dropped in event of 914 a CGN node failure. 916 * To ensure a matching state table entry for an active session in 917 the event of asymmetric routing through different egress and 918 ingress CGN nodes. 920 4.7. Logging 922 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 923 address and port combination will vary over time, therefore, logging 924 is necessary to meet data retention laws. Each entry in the PLAT/ 925 AFTR's generates a logging entry. As discussed in Section 4.2, a 926 client may open hundreds of sessions during common tasks such as web- 927 browsing, each of which needs to be logged so the overall logging 928 burden on the network operator is significant. In some countries, 929 this level of logging is required to comply with data retention 930 legislation. 932 One common optimization available to reduce the logging overhead is 933 the allocation of a block of ports to a client for the duration of 934 their session. This means that logging entry only needs to be made 935 when the client's port block is released, which dramatically reducing 936 the logging overhead. This comes as the cost of less efficient 937 public address sharing as clients need to be allocated a port block 938 of a fixed size regardless of the actual number of ports that they 939 are using. 941 Stateless technologies that pre-allocate the IPv4 addresses and ports 942 only require that copies of the active MAP rules (for MAP-E and MAP- 943 T), or binding-table (for lw4o6) are retained along with timestamp 944 information of when they have been active. Support tools (e.g., 945 those used to serve data retention requests) may need to be updated 946 to be aware of the mechanism in use (e.g., implementing the MAP 947 algorithm so that IPv4 information can be linked to the IPv6 prefix 948 delegated to a client). As stateless technologies do not have a 949 centralized stateful element which customer traffic needs to pass 950 through, so if data retention laws mandate per-session logging, there 951 is no simple way of meeting this requirement with a stateless 952 technology alone. Thus a centralized NAPT44 model may be the only 953 way to meet this requirement. 955 Deterministic CGN [RFC7422] was proposed as a solution to reduce the 956 resource consumption of logging. 958 4.8. Optimization for IPv4-only devices/applications 960 When IPv4-only devices or applications are behind a CE connected with 961 IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, 962 be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 963 E) and will reach the IPv4 address of the destination, even if that 964 service supports dual-stack. This means that the traffic flow will 965 cross thru the AFTR, lwAFTR or BR, depending on the specific 966 transition mechanism being used. 968 Even if those services are directly connected to the operator network 969 (for example, CDNs, caches), or located internally (such as VoIP, 970 etc.), it is not possible to avoid that overhead. 972 However, in the case of those mechanism that use a NAT46 function, in 973 the CE (464XLAT and MAP-T), it is possible to take advantage of 974 optimization functionalities, such as the ones described in 975 [I-D.ietf-v6ops-464xlat-optimization]. 977 Using those optimizations, because the NAT46 has already translated 978 the IPv4-only flow to IPv6, and the services are dual-stack, they can 979 be reached without the need to translate them back to IPv4. 981 5. Performance Comparison 983 We plan to compare the performances of the most prominent free 984 software implementations of the five IPv6 transition technologies 985 using the methodology described in "Benchmarking Methodology for IPv6 986 Transition Technologies" [RFC8219]. 988 The Dual DUT Setup of [RFC8219] makes it possible to use the existing 989 "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] 990 compliant measurement devices, however, this solution has two kinds 991 of limitations: 993 * Dual DUT setup has the drawback that the performances of the CE 994 and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) 995 are measured together. In order to measure the performance of 996 only one of them, we need to ensure that the desired one is the 997 bottleneck. 999 * Measurements procedures for PDV and IPDV measurements are missing 1000 from the legacy devices, and the old measurement procedure for 1001 Latency has been redefined in [RFC8219]. 1003 The Single DUT Setup of [RFC8219] makes it possible to benchmark the 1004 selected device separately, but it either requires a special Tester 1005 or some trick is need, if we want to use legacy Testers. An example 1006 for the latter is our stateless NAT64 measurements testing Througput 1007 and Frame Loss Rate using a legacy [RFC5180] compliant commercial 1008 tester [LEN2020a] 1010 Siitperf, an [RFC8219] compliant DPDK-based software Tester for 1011 benchmarking stateless NAT64 gateways has been developed recently and 1012 it is available from GitHub [SIITperf] as free software and 1013 documented in [LEN2021]. Originally, it literally followed the test 1014 frame format of [RFC2544] including "hard wired" source and 1015 destination port numbers, and then it has been complemented with the 1016 random port feature required by [RFC4814]. The new version is 1017 documented in [LEN2020b] 1019 Further DPDK-based, [RFC8219] compliant software testers are being 1020 developed at the Budapest University of Technology and Economics as 1021 student projects. They are planned to be released as free software, 1022 too. 1024 Information about the benchmarking tools, measurements and results 1025 will be made available in [I-D.lencse-v6ops-transition-benchmarking]. 1027 6. Acknowledgements 1029 The authors would like to thank Ole Troan and Warren Kumari for their 1030 thorough review of this draft and acknowledge the inputs of Mark 1031 Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron 1032 Byrne, Tore Anderson, Mikael Abrahamsson, Gert Doering, Satoru 1033 Matsushima, Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and 1034 Havard Eidnes. 1036 7. IANA Considerations 1038 This document does not make any request to IANA. 1040 8. Security Considerations 1042 According to the simplest model, the number of bugs is proportional 1043 to the number of code lines. Please refer to Section 4.4.3 for code 1044 sizes of CE implementations. 1046 For all five technologies, the CE device typically contains a DNS 1047 proxy. However, the user may change DNS settings. If it happens and 1048 lw4o6, MAP-E and MAP-T are used with significantly restricted port 1049 set, which is required for an efficient public IPv4 address sharing, 1050 the entropy of the source ports is significantly lowered (e.g. from 1051 16 bits to 10 bits, when 1024 port numbers are assigned to each 1052 subscriber) and thus these technologies are theoretically less 1053 resilient against cache poisoning, see [RFC5452]. However, an 1054 efficient cache poisoning attack requires that the subscriber 1055 operates an own caching DNS server and the attack is performed in the 1056 service provider network. Thus, we consider the chance of the 1057 successful exploitation of this vulnerability as low. 1059 An in-depth security analysis of all five IPv6 transition 1060 technologies and their most prominent free software implementations 1061 according to the methodology defined in [LEN2018] is planned. 1063 As the first step, an initial security analysis of 464XLAT was done 1064 in [Azz2021]. 1066 9. References 1068 9.1. Normative References 1070 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1071 Requirement Levels", BCP 14, RFC 2119, 1072 DOI 10.17487/RFC2119, March 1997, 1073 . 1075 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1076 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1077 December 1998, . 1079 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1080 Network Interconnect Devices", RFC 2544, 1081 DOI 10.17487/RFC2544, March 1999, 1082 . 1084 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1085 Translator (NAT) Terminology and Considerations", 1086 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1087 . 1089 [RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 1090 Factors in Network Device Benchmarking", RFC 4814, 1091 DOI 10.17487/RFC4814, March 2007, 1092 . 1094 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 1095 Dugatkin, "IPv6 Benchmarking Methodology for Network 1096 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 1097 2008, . 1099 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 1100 Resilient against Forged Answers", RFC 5452, 1101 DOI 10.17487/RFC5452, January 2009, 1102 . 1104 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1105 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1106 DOI 10.17487/RFC6052, October 2010, 1107 . 1109 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1110 NAT64: Network Address and Protocol Translation from IPv6 1111 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1112 April 2011, . 1114 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1115 Beijnum, "DNS64: DNS Extensions for Network Address 1116 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1117 DOI 10.17487/RFC6147, April 2011, 1118 . 1120 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1121 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1122 DOI 10.17487/RFC6180, May 2011, 1123 . 1125 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1126 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1127 DOI 10.17487/RFC6269, June 2011, 1128 . 1130 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1131 Stack Lite Broadband Deployments Following IPv4 1132 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1133 . 1135 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1136 the IPv4 Address Shortage", RFC 6346, 1137 DOI 10.17487/RFC6346, August 2011, 1138 . 1140 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 1141 Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 1142 2012, . 1144 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1145 Combination of Stateful and Stateless Translation", 1146 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1147 . 1149 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1150 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1151 DOI 10.17487/RFC6887, April 2013, 1152 . 1154 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1155 "Analysis of Stateful 64 Translation", RFC 6889, 1156 DOI 10.17487/RFC6889, April 2013, 1157 . 1159 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1160 the IPv6 Prefix Used for IPv6 Address Synthesis", 1161 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1162 . 1164 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1165 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 1166 RFC 7341, DOI 10.17487/RFC7341, August 2014, 1167 . 1169 [RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, 1170 "Using the Port Control Protocol (PCP) to Update Dynamic 1171 DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, 1172 . 1174 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 1175 and O. Vautrin, "Deterministic Address Mapping to Reduce 1176 Logging in Carrier-Grade NAT Deployments", RFC 7422, 1177 DOI 10.17487/RFC7422, December 2014, 1178 . 1180 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1181 Farrer, "Lightweight 4over6: An Extension to the Dual- 1182 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1183 July 2015, . 1185 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1186 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1187 Port with Encapsulation (MAP-E)", RFC 7597, 1188 DOI 10.17487/RFC7597, July 2015, 1189 . 1191 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1192 and T. Murakami, "Mapping of Address and Port using 1193 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1194 2015, . 1196 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1197 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1198 August 2015, . 1200 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1201 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1202 DOI 10.17487/RFC7757, February 2016, 1203 . 1205 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1206 "IP/ICMP Translation Algorithm", RFC 7915, 1207 DOI 10.17487/RFC7915, June 2016, 1208 . 1210 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1211 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1212 . 1214 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1215 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1216 over an IPv6 Multicast Network", RFC 8114, 1217 DOI 10.17487/RFC8114, March 2017, 1218 . 1220 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1221 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1222 May 2017, . 1224 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 1225 Methodology for IPv6 Transition Technologies", RFC 8219, 1226 DOI 10.17487/RFC8219, August 2017, 1227 . 1229 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1230 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1231 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1232 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1233 . 1235 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1236 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1237 Address Translation (NAT) and Network Prefix Translation 1238 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1239 . 1241 [RFC8658] Jiang, S., Ed., Fu, Y., Ed., Xie, C., Li, T., and M. 1242 Boucadair, Ed., "RADIUS Attributes for Softwire Mechanisms 1243 Based on Address plus Port (A+P)", RFC 8658, 1244 DOI 10.17487/RFC8658, November 2019, 1245 . 1247 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 1248 NAT64/464XLAT in Operator and Enterprise Networks", 1249 RFC 8683, DOI 10.17487/RFC8683, November 2019, 1250 . 1252 9.2. Informative References 1254 [aftr] ISC, "ISC implementation of AFTR", 2022, 1255 . 1257 [Azz2021] Al-Azzawi, A. and G. Lencse, "Identification of the 1258 Possible Security Issues of the 464XLAT IPv6 Transition 1259 Technology", Infocommunications Journal, vol. 13, no. 4, 1260 pp. 10-18, DOI: 10.36244/ICJ.2021.4.2, December 2021, 1261 . 1263 [I-D.ietf-v6ops-464xlat-optimization] 1264 Martinez, J. P. and A. D'Egidio, "464XLAT/MAT-T 1265 Optimization", Work in Progress, Internet-Draft, draft- 1266 ietf-v6ops-464xlat-optimization-03, 28 July 2020, 1267 . 1270 [I-D.lencse-v6ops-transition-benchmarking] 1271 Lencse, G., "Performance Analysis of IPv6 Transition 1272 Technologies for IPv4aaS", Work in Progress, Internet- 1273 Draft, draft-lencse-v6ops-transition-benchmarking-00, 16 1274 October 2021, . 1277 [I-D.lencse-v6ops-transition-scalability] 1278 Lencse, G., "Scalability of IPv6 Transition Technologies 1279 for IPv4aaS", Work in Progress, Internet-Draft, draft- 1280 lencse-v6ops-transition-scalability-02, 7 March 2022, 1281 . 1284 [jool] NIC.MX, "Open Source SIIT and NAT64 for Linux", 2022, 1285 . 1287 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 1288 identification of potential security issues of different 1289 IPv6 transition technologies: Threat analysis of DNS64 and 1290 stateful NAT64", Computers & Security (Elsevier), vol. 1291 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 1292 1 August 2018, 1293 . 1296 [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of 1297 IPv6 Transition Technologies: A Subjective Classification 1298 for Security Analysis", IEICE Transactions on 1299 Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: 1300 10.1587/transcom.2018EBR0002, 1 October 2019, 1301 . 1304 [LEN2020a] Lencse, G., "Benchmarking Stateless NAT64 Implementations 1305 with a Standard Tester", Telecommunication Systems, vol. 1306 75, pp. 245-257, DOI: 10.1007/s11235-020-00681-x, 15 June 1307 2020, . 1310 [LEN2020b] Lencse, G., "Adding RFC 4814 Random Port Feature to 1311 Siitperf: Design, Implementation and Performance 1312 Estimation", International Journal of Advances in 1313 Telecommunications, Electrotechnics, Signals and Systems, 1314 vol 9, no 3, pp. 18-26, DOI: 10.11601/ijates.v9i3.291, 1315 2020, 1316 . 1318 [LEN2021] Lencse, G., "Design and Implementation of a Software 1319 Tester for Benchmarking Stateless NAT64 Gateways", IEICE 1320 Transactions on Communications, DOI: 1321 10.1587/transcom.2019EBN0010, 2021, 1322 . 1325 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation 1326 schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp. 1327 1078-1084, DOI:10.1587/transcom.E93.B.10, May 2010, 1328 . 1331 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 1332 consumption of the NAT64 IPv6 transition 1333 technology", Proc. 37th Internat. Conf. on 1334 Telecommunications and Signal Processing (TSP 2014), 1335 Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July 1336 2014, . 1339 [SIITperf] Lencse, G., "Siitperf: an RFC 8219 compliant SIIT 1340 (stateless NAT64) tester", November 2019, 1341 . 1343 [snabb] Igalia, "Snabb implementation of lwAFTR", 2022, 1344 . 1346 [vpp] "VPP Implementations of IPv6-only with IPv4aaS", 2022, 1347 . 1349 Appendix A. Change Log 1351 A.1. 01 - 02 1353 * Ian Farrer has joined us as an author. 1355 * Restructuring: the description of the five IPv4aaS technologies 1356 was moved to a separate section. 1358 * More details and figures were added to the description of the five 1359 IPv4aaS technologies. 1361 * Section titled "High-level Architectures and their Consequences" 1362 has been completely rewritten. 1364 * Several additions/clarification throughout Section titled 1365 "Detailed Analysis". 1367 * Section titled "Performance Analysis" was dropped due to lack of 1368 results yet. 1370 * Word based text ported to XML. 1372 * Further text cleanups, added text on state sync and load 1373 balancing. Additional comments inline that should be considered 1374 for future updates. 1376 A.2. 02 - 03 1378 * The suggestions of Mohamed Boucadair are incorporated. 1380 * New considerations regarding possible optimizations. 1382 A.3. 03 - 04 1384 * Section titled "Performance Analysis" was added. It mentions our 1385 new benchmarking tool, siitperf, and highlights our plans. 1387 * Some references were updated or added. 1389 A.4. 04 - 05 1391 * Some references were updated or added. 1393 A.5. 05 - 06 1395 * Some references were updated or added. 1397 A.6. 06 - 00-WG Item 1399 * Stats dated and added for Broadband deployments. 1401 * Other clarifications and references. 1403 * New section: IPv4 Pool Size. 1405 * Typos. 1407 A.7. 00 - 01 1409 To facilitate WGLC, the unfinished parts were moved to two new 1410 drafts: 1412 * New I-D for scale up measurements. (Including the results of 1413 iptables.) 1415 * New I-D for benchmarking measurements. (Only a stub.) 1417 A.8. 01 - 02 1419 Update on the basis of the AD review. 1421 Update of the references. 1423 A.9. 02 - 03 1425 Nits and changes from IESG review. 1427 Updated wrong reference to PCP. 1429 Authors' Addresses 1431 Gabor Lencse 1432 Budapest University of Technology and Economics 1433 Budapest 1434 Magyar tudosok korutja 2. 1435 H-1117 1436 Hungary 1437 Email: lencse@hit.bme.hu 1439 Jordi Palet Martinez 1440 The IPv6 Company 1441 Molino de la Navata, 75 1442 28420 La Navata - Galapagar Madrid 1443 Spain 1444 Email: jordi.palet@theipv6company.com 1445 URI: http://www.theipv6company.com/ 1447 Lee Howard 1448 Retevia 1449 9940 Main St., Suite 200 1450 Fairfax, Virginia 22031 1451 United States of America 1452 Email: lee@asgard.org 1454 Richard Patterson 1455 Sky UK 1456 1 Brick Lane 1457 London 1458 EQ 6PU 1459 United Kingdom 1460 Email: richard.patterson@sky.uk 1462 Ian Farrer 1463 Deutsche Telekom AG 1464 Landgrabenweg 151 1465 53227 Bonn 1466 Germany 1467 Email: ian.farrer@telekom.de