idnits 2.17.1 draft-ietf-v6ops-transition-comparison-00.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (April 15, 2021) is 1106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-464xlat-optimization-03 -- 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: October 17, 2021 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 April 15, 2021 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-ietf-v6ops-transition-comparison-00 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 October 17, 2021. 48 Copyright Notice 50 Copyright (c) 2021 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 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 68 2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 70 2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 6 71 2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. High-level Architectures and their Consequences . . . . . . . 8 74 3.1. Service Provider Network Traversal . . . . . . . . . . . 8 75 3.2. Network Address Translation . . . . . . . . . . . . . . . 9 76 3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 10 77 3.4. IPv4 Pool Size Considerations . . . . . . . . . . . . . . 11 78 3.5. CE Provisioning Considerations . . . . . . . . . . . . . 12 79 3.6. Support for Multicast . . . . . . . . . . . . . . . . . . 13 80 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1. Architectural Differences . . . . . . . . . . . . . . . . 13 82 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 13 83 4.2. Tradeoff between Port Number Efficiency and Stateless 84 Operation . . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.3. Support for Public Server Operation . . . . . . . . . . . 16 86 4.4. Support and Implementations . . . . . . . . . . . . . . . 17 87 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 17 88 4.4.2. Support in Cellular and Broadband Networks . . . . . 17 89 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 18 90 4.5. Typical Deployment and Traffic Volume Considerations . . 18 91 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 18 92 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 18 93 4.5.3. Wireline Networks with 464XLAT . . . . . . . . . . . 19 94 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 19 95 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 4.8. Optimization for IPv4-only devices/applications . . . . . 20 97 5. Performance Comparison . . . . . . . . . . . . . . . . . . . 21 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 9.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 105 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 A.6. 06 - 00-WG Item . . . . . . . . . . . . . . . . . . . . . 29 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 113 1. Introduction 115 As the deployment of IPv6 becomes more prevalent, it follows that 116 network operators will move to building single-stack IPv6 core and 117 access networks to simplify network planning and operations. 118 However, providing customers with IPv4 services continues to be a 119 requirement for the foreseeable future. To meet this need, the IETF 120 has standardized a number of different IPv4aaS technologies for this 121 [LEN2019] based on differing requirements and deployment scenarios. 123 The number of technologies that have been developed makes it time 124 consuming for a network operator to identify the most appropriate 125 mechanism for their specific deployment. This document provides a 126 comparative analysis of the most commonly used mechanisms to assist 127 operators with this problem. 129 Five different IPv4aaS solutions are considered. The following IPv6 130 transition technologies are covered: 132 1. 464XLAT [RFC6877] 134 2. Dual Stack Lite [RFC6333] 136 3. lw4o6 (Lightweight 4over6) [RFC7596] 138 4. MAP-E [RFC7597] 140 5. MAP-T [RFC7599] 141 We note that [RFC6180] gives guidelines for using IPv6 transition 142 mechanisms during IPv6 deployment addressing a much broader topic, 143 whereas this document focuses on a small part of it. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 2. Overview of the Technologies 155 The following sections introduce the different technologies analyzed 156 in this document, describing some of their most important 157 characteristics. 159 2.1. 464XLAT 161 464XLAT is a single/dual translation model, which uses a customer- 162 side translator (CLAT) located in the customer's device to perform 163 stateless NAT64 translation [RFC7915] (more precisely, stateless 164 NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). 165 IPv4-embedded IPv6 addresses [RFC6052] are used for both source and 166 destination addresses. Commonly, a /96 prefix (either the 167 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 168 as the IPv6 destination for the IPv4-embedded client traffic. 170 In the operator's network, the provider-side translator (PLAT) 171 performs stateful NAT64 [RFC6146] to translate the traffic. The 172 destination IPv4 address is extracted from the IPv4-embedded IPv6 173 packet destination address and the source address is from a pool of 174 public IPv4 addresses. 176 Alternatively, when a dedicated /64 is not available for translation, 177 the CLAT device uses a stateful NAT44 translation before the 178 stateless NAT46 translation. 180 Note that we generally do not see state close to the end-user as 181 equally problematic as state in the middle of the network. 183 In typical deployments, 464XLAT is used together with DNS64 184 [RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client 185 or application communicates with an IPv4-only server, the DNS64 186 server returns the IPv4-embedded IPv6 address of the IPv4-only 187 server. In this case, the IPv6-only client sends out IPv6 packets, 188 thus CLAT functions as an IPv6 router and the PLAT performs a 189 stateful NAT64 for these packets. In this case, there is a single 190 translation. 192 Alternatively, one can say that the DNS64 + stateful NAT64 is used to 193 carry the traffic of the IPv6-only client and the IPv4-only server, 194 and the CLAT is used only for the IPv4 traffic from applications or 195 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 197 Private +----------+ Translated +----------+ _______ 198 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 199 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 200 |Device|<-------| NAT46 |<------------| NAT64 | (________) 201 +------+ +----------+ ^ +----------+ 202 | 203 Operator IPv6 204 network 206 Figure 1: Overview of the 464XLAT architecture 208 Note: in mobile networks, CLAT is commonly implemented in the user's 209 equipment (UE or smartphone). 211 2.2. Dual-Stack Lite 213 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 214 transition mechanisms to be developed. DS-Lite uses a 'Basic 215 Broadband Bridging' (B4) function in the customer's CE router that 216 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 217 service-provider network to a centralized 'Address Family Transition 218 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 219 4in6 traffic and translates the IPv4 payload to public IPv4 source 220 address using a stateful NAPT44 function. 222 +-------------+ 223 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 224 +------+ IPv4 | B4 | tunnel |------+------+ _______ 225 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 226 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 227 +------+ +----------+ ^ |Decap.| 44 | (________) 228 | +------+------+ 229 Operator IPv6 230 network 232 Figure 2: Overview of the DS-Lite architecture 234 2.3. Lightweight 4over6 236 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 237 difference is that the stateful NAPT44 function is relocated from the 238 centralized AFTR to the customer's B4 element (called a lwB4). The 239 AFTR (called a lwAFTR) function therefore only performs A+P routing 240 and 4in6 encapsulation/decapsulation. 242 Routing to the correct client and IPv4 address sharing is achieved 243 using the Address + Port (A+P) model [RFC6346] of provisioning each 244 lwB4 with a unique tuple of IPv4 address unique range of layer-4 245 ports. The client uses these for NAPT44. 247 The lwAFTR implements a binding table, which has a per-client entry 248 linking the customer's source IPv4 address and allocated range of 249 layer-4 ports to their IPv6 tunnel endpoint address. The binding 250 table allows egress traffic from customers to be validated (to 251 prevent spoofing) and ingress traffic to be correctly encapsulated 252 and forwarded. As there needs to be a per-client entry, an lwAFTR 253 implementation needs to be optimized for performing a per-packet 254 lookup on the binding table. 256 Direct communication between two lwB4s is performed by hair-pinning 257 traffic through the lwAFTR. 259 +-------------+ +----------+ 260 Private | lwB4 | IPv4-in-IPv6| Stateless| 261 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 262 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 263 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 264 +------+ | 44 |Decap.| ^ | routing) | (________) 265 +------+------+ | +----------+ 266 Operator IPv6 267 network 269 Figure 3: Overview of the lw4o6 architecture 271 2.4. MAP-E 273 MAP-E uses a stateless algorithm to embed portions of the customer's 274 allocated IPv4 address (or part of an address with A+P routing) into 275 the IPv6 prefix delegated to the client. This allows for large 276 numbers of clients to be provisioned using a single MAP rule (called 277 a MAP domain). The algorithm also allows for direct IPv4 peer-to- 278 peer communication between hosts provisioned with common MAP rules. 280 The CE (Customer-Edge) router typically performs stateful NAPT44 281 [RFC2663] to translate the private IPv4 source addresses and source 282 ports into an address and port range defined by applying the MAP rule 283 applied to the delegated IPv6 prefix. The client address/port 284 allocation size is a design parameter. The CE router then 285 encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it 286 directly to another host in the MAP domain (for peer-to-peer) or to a 287 Border Router (BR) if the IPv4 destination is not covered in one of 288 the CE's MAP rules. 290 The MAP BR is provisioned with the set of MAP rules for the MAP 291 domains it serves. These rules determine how the MAP BR is to 292 decapsulate traffic that it receives from client, validating the 293 source IPv4 address and layer 4 ports assigned, as well as how to 294 calculate the destination IPv6 address for ingress IPv4 traffic. 296 +-------------+ +----------+ 297 Private | MAP CE | IPv4-in-IPv6| Stateless| 298 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 299 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 300 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 301 +------+ | 44 |Decap.| ^ | routing) | (________) 302 +------+------+ | +----------+ 303 Operator IPv6 304 network 306 Figure 4: Overview of the MAP-E architecture 308 2.5. MAP-T 310 MAP-T uses the same mapping algorithm as MAP-E. The major difference 311 is that double stateless translation (NAT46 in the CE and NAT64 in 312 the BR) is used to traverse the ISP's IPv6 single-stack network. 313 MAP-T can also be compared to 464XLAT when there is a double 314 translation. 316 A MAP CE typically performs stateful NAPT44 to translate traffic to a 317 public IPv4 address and port-range calculated by applying the 318 provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) 319 to the delegated IPv6 prefix. The CE then performs stateless 320 translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned 321 with the same BMR as the client, enabling the received IPv6 traffic 322 to be statelessly NAT64 translated back to the public IPv4 source 323 address used by the client. 325 Using translation instead of encapsulation also allows IPv4-only 326 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 327 have IPv4-embedded IPv6 addresses. 329 +-------------+ +----------+ 330 Private | MAP CE | Translated | Stateless| 331 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 332 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 333 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 334 +------+ | 44 |NAT46 | ^ | routing) | (________) 335 +------+------+ | +----------+ 336 Operator IPv6 337 network 339 Figure 5: Overview of the MAP-T architecture 341 3. High-level Architectures and their Consequences 343 3.1. Service Provider Network Traversal 345 For the data-plane, there are two approaches for traversing the IPv6 346 provider network: 348 o 4-6-4 translation 350 o 4-in-6 encapsulation 352 +--------------+---------+---------+-------+-------+-------+ 353 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 354 +--------------+---------+---------+-------+-------+-------+ 355 | 4-6-4 trans. | X | | | | X | 356 | 4-6-4 encap. | | X | X | X | | 357 +--------------+---------+---------+-------+-------+-------+ 359 Table 1: Available Traversal Mechanisms 361 In the scope of this document, all of the encapsulation based 362 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 363 tunneling mechanism which does not require any additional tunnel 364 headers. 366 It should be noted that both of these approaches result in an 367 increase in the size of the packet that needs to be transported 368 across the operator's network when compared to native IPv4. 4-6-4 369 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 370 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 371 overhead (an IPv6 header is prepended to the IPv4 header). 373 The increase in packet size can become a significant problem if there 374 is a link with a smaller MTU in the traffic path. This may result in 375 traffic needing to be fragmented at the ingress point to the IPv6 376 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 377 also result in the need to implement buffering and fragment re- 378 assembly in the BR node. 380 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 381 these mechanisms: It is strongly recommended that the MTU in the 382 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 383 side interface be set so that no fragmentation occurs within the 384 boundary of the IPv6-only domain. 386 3.2. Network Address Translation 388 For the high-level solution of IPv6 service provider network 389 traversal, MAP-T uses double stateless translation. First at the CE 390 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 391 service provider network. 393 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 394 or single translation (stateful NAT64), depending on different 395 factors, such as the use of DNS by the applications and the 396 availability of a DNS64 function (in the host or in the service 397 provider network). For deployment guidelines, please refer to 398 [RFC8683]. 400 The first step for the double translation mechanisms is a stateless 401 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 402 Translation Algorithm) [RFC7915], which does not translate IPv4 403 header options and/or multicast IP/ICMP packets. With encapsulation- 404 based technologies the header is transported intact and multicast can 405 also be carried. 407 Single and double translation results in native IPv6 traffic with a 408 layer-4 next-header. The fields in these headers can be used for 409 functions such as hashing across equal-cost multipaths or ACLs. For 410 encapsulation, there is an IPv6 header followed by an IPv4 header. 411 This results in less entropy for hashing algorithms, and may mean 412 that devices in the traffic path that perform header inspection (e.g. 413 router ACLs or firewalls) require the functionality to look into the 414 payload header. 416 Solutions using double translation can only carry port-aware IP 417 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 418 address sharing (please refer to Section 4.3 for more details). 419 Encapsulation based solutions can carry any other protocols over IP, 420 too. 422 An in-depth analysis of stateful NAT64 can be found in [RFC6889]. 424 3.3. IPv4 Address Sharing 426 As public IPv4 address exhaustion is a common motivation for 427 deploying IPv6, transition technologies need to provide a solution 428 for allowing public IPv4 address sharing. 430 In order to fulfill this requirement, a stateful NAPT function is a 431 necessary function in all of the mechanisms. The major 432 differentiator is where in the architecture this function is located. 434 The solutions compared by this document fall into two categories: 436 o CGN-based approaches (DS-Lite, 464XLAT) 438 o A+P-based approaches (lw4o6, MAP-E, MAP-T) 440 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 441 the NAPT44 function and maintains per-session state for all of the 442 active client's traffic. The customer's device does not require per- 443 session state for NAPT. 445 In the A+P-based model, a device (usually a CE) performs stateful 446 NAPT44 and maintains per-session state only co-located devices, e.g. 447 in the customer's home network. Here, the centralized network 448 function (lwAFTR or BR) only needs to perform stateless 449 encapsulation/decapsulation or NAT64. 451 Issues related to IPv4 address sharing mechanisms are described in 452 [RFC6269] and should also be considered. 454 The address sharing efficiency of the five technologies is 455 significantly different, it is discussed in Section 4.2 457 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 458 sharing, see the details in Section 4.3. However, in that case, 459 there is no advantage in terms of public IPv4 address saving. In the 460 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 462 Conversely, both MAP-E and MAP-T may be configured to provide more 463 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 464 /32) to customers. 466 Dynamic DNS issues in address-sharing contexts and their possible 467 solutions using PCP (Port Control Protocol) are discussed in detail 468 in [RFC7393]. 470 3.4. IPv4 Pool Size Considerations 472 In most networks, it is possible to, using existing data about flows 473 to CDNs/caches or other well-known IPv6-enabled destinations, 474 calculate the percentage of traffic that would turn into IPv6 if it 475 is enabled on that network or part of it. 477 Knowing that, it is possible to calculate the IPv4 pool size required 478 for a given number of subscribers, depending on the IPv4aaS 479 technology being used. 481 Often it is assumed that each user-device (computer, tablet, 482 smartphone) behind a NAT, could simultaneously use about 300 ports. 483 Typically, in the case of a residential subscriber, there will be a 484 maximum of 4 of those devices in use simultaneously, which means a 485 total of 1.200 ports. 487 If for example, 80% of the traffic is expected towards IPv6 488 destinations, only 20% will actually be using IPv4 ports, so in our 489 example, that will mean 240 ports required per subscriber. 491 From the 65.535 ports available per IPv4 address, we could even 492 consider reserving 1.024 ports, in order to allow customers that need 493 EAMT entries for incoming connections to well-known ports, which 494 means 64.511 ports actually available per each IPv4 address. 496 According to this, a /22 (1.024 public IPv4 addresses) will be 497 sufficient for over 275.000 subscribers 498 (1.024x64.511/240=275.246,93). 500 Similarly, a /18 (16.384 public IPv4 addresses) will be sufficient 501 for over 4.403.940 subscribers, and so on. 503 This is a conservative approach, which is valid in the case of 504 464XLAT, because ports are assigned dynamically by the NAT64, so it 505 is not necessary to consider if one user is actually using more or 506 less ports: Average values work well. 508 Further to that, the NAT46 in the CLAT will actually hide the 509 subscriber LANs port usage and only that will be the limiting factor. 510 So even subscribers with higher demands of ports, will not make a big 511 difference. 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 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 563 +-------------------+-----------+-----------+-------+-------+-------+ 564 | DHCPv6 [RFC8415] | | X | X | X | X | 565 | RADIUS [RFC8658] | | [RFC6519] | X | X | X | 566 | TR-069 | * | X | * | X | X | 567 | DNS64 [RFC7050] | X | | | | | 568 | YANG [RFC7950] | [RFC8512] | X | X | X | X | 569 | DHCP4o6 [RFC7341] | | | X | X | | 570 +-------------------+-----------+-----------+-------+-------+-------+ 572 Table 2: Available Provisioning Mechanisms 574 *: Work started at BroadBand Forum (2021). 576 3.6. Support for Multicast 578 The solutions covered in this document are all intended for unicast 579 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 580 multicast traffic over an IPv6 multicast network. This could be 581 deployed in parallel to any of the operator's chosen IPv4aaS 582 mechanism. 584 4. Detailed Analysis 586 4.1. Architectural Differences 588 4.1.1. Basic Comparison 590 The five IPv4aaS technologies can be classified into 2x2=4 categories 591 on the basis of two aspects: 593 o Technology used for service provider network traversal. It can be 594 single/double translation or encapsulation. 596 o Presence or absence of NAPT44 per-flow state in the operator 597 network. 599 +-----------------------+---------+---------+-------+-------+-------+ 600 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 601 +-----------------------+---------+---------+-------+-------+-------+ 602 | 4-6-4 trans. | X | | | | X | 603 | 4-in-4 encap. | | X | X | X | | 604 | Per-flow state in op. | X | X | | | | 605 | network | | | | | | 606 +-----------------------+---------+---------+-------+-------+-------+ 608 Table 3: Available Provisioning Mechanisms 610 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 612 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 613 respectively. This may cause scalability issues for the number of 614 clients or volume of traffic, but does not impose a limitation on the 615 number of ports per user, as they can be allocated dynamically on- 616 demand and the allocation policy can be centrally managed/adjusted. 618 A+P based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in 619 the service provider network. However, this means that the number of 620 ports provided to each user (and hence the effective IPv4 address 621 sharing ratio) must be pre-provisioned to the client. 623 Changing the allocated port ranges with A+P based technologies, 624 requires more planning and is likely to involve re-provisioning both 625 hosts and operator side equipment. It should be noted that due to 626 the per-customer binding table entry used by lw4o6, a single customer 627 can be re-provisioned (e.g., if they request a full IPv4 address) 628 without needing to change parameters for a number of customers as in 629 a MAP domain. 631 It is also worth noting that there is a direct relationship between 632 the efficiency of customer public port-allocations and the 633 corresponding logging overhead that may be necessary to meet data- 634 retention requirements. This is considered in Section 4.7 below. 636 Determining the optimal number of ports for a fixed port set is not 637 an easy task, and may also be impacted by local regulatory law, which 638 may define a maximum number of users per IP address, and consequently 639 a minimum number of ports per user. 641 On the one hand, the "lack of ports" situation may cause serious 642 problems in the operation of certain applications. For example, 643 Miyakawa has demonstrated the consequences of the session number 644 limitation due to port number shortage on the example of Google Maps 645 [MIY2010]. When the limit was 15, several blocks of the map were 646 missing, and the map was unusable. This study also provided several 647 examples for the session numbers of different applications (the 648 highest one was Apple's iTunes: 230-270 ports). 650 The port number consumption of different applications is highly 651 varying and e.g. in the case of web browsing it depends on several 652 factors, including the choice of the web page, the web browser, and 653 sometimes even the operating system [REP2014]. For example, under 654 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 655 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 656 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 658 There may be several users behind a CE router, especially in the 659 broadband case (e.g. Internet is used by different members of a 660 family simultaneously), so sufficient ports must be allocated to 661 avoid impacting user experience. 663 Furthermore, assigning too many ports per CE router will result in 664 waste of public IPv4 addresses, which is a scarce and expensive 665 resource. Clearly this is a big advantage in the case of 464XLAT 666 where they are dynamically managed, so that the number of IPv4 667 addresses for the sharing-pool is smaller while the availability of 668 ports per user don't need to be pre-defined and is not a limitation 669 for them. 671 There is a direct tradeoff between the optimization of client port 672 allocations and the associated logging overhead. Section 4.7 673 discusses this in more depth. 675 We note that common CE router NAT44 implementations utilizing 676 Netfilter, multiplexes active sessions using a 3-tuple (source 677 address, destination address, and destination port). This means that 678 external source ports can be reused for unique internal source and 679 destination address and port sessions. It is also noted, that 680 Netfilter cannot currently make use of multiple source port ranges 681 (i.e. several blocks of ports distributed across the total port space 682 as is common in MAP deployments), this may influence the design when 683 using stateless technologies. 685 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 686 therefore be much more efficient in terms of port allocation and thus 687 public IP address saving. The price is the stateful operation in the 688 service provider network, which allegedly does not scale up well. It 689 should be noticed that in many cases, all those factors may depend on 690 how it is actually implemented. 692 XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX 694 We note that some CGN-type solutions can allocate ports dynamically 695 "on the fly". Depending on configuration, this can result in the 696 same customer being allocated ports from different source addresses. 697 This can cause operational issues for protocols and applications that 698 expect multiple flows to be sourced from the same address. E.g., 699 ECMP hashing, STUN, gaming, content delivery networks. However, it 700 should be noticed that this is the same problem when a network has a 701 NAT44 with multiple public IPv4 addresses, or even when applications 702 in a dual-stack case, behave wrongly if happy eyeballs is flapping 703 the flow address between IPv4 and IPv6. 705 The consequences of IPv4 address sharing [RFC6269] may impact all 706 five technologies. However, when ports are allocated statically, 707 more customers may get ports from the same public IPv4 address, which 708 may results in negative consequences with higher probability, e.g. 709 many applications and service providers (Sony PlayStation Network, 710 OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that 711 they are used for address sharing. 713 Both cases are, again, implementation dependent. 715 We note that although it is not of typical use, one can do 716 deterministic, stateful NAT and reserve a fixed set of ports for each 717 customer, as well. 719 4.3. Support for Public Server Operation 721 Mechanisms that rely on operator side per-flow state do not, by 722 themselves, offer a way for customers to present services on publicly 723 accessible layer-4 ports. 725 Port Control Protocol (PCP) [RFC6877] provides a mechanism for a 726 client to request an external public port from a CGN device. For 727 server operation, it is required with NAT64/464XLAT, and it is 728 supported in some DS-Lite AFTR implementations. 730 A+P based mechanisms distribute a public IPv4 address and restricted 731 range of layer-4 ports to the client. In this case, it is possible 732 for the user to configure their device to offer a publicly accessible 733 server on one of their allocated ports. It should be noted that 734 commonly operators do not assign the Well-Known-Ports to users 735 (unless they are allocating a full IPv4 address), so the user will 736 need to run the service on an allocated port, or configure port 737 translation. 739 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 740 full IPv4 address, allowing exclusive use of all ports, and non-port- 741 based layer 4 protocols. Thus, they may also be used to support 742 server/services operation on their default ports. However, when 743 public IPv4 addresses are assigned to the CE router without address 744 sharing, obviously there is no advantage in terms of IPv4 public 745 addresses saving. 747 It is also possible to configure specific ports mapping in 464XLAT/ 748 NAT64 using EAMT [RFC7757], which means that only those ports are 749 "lost" from the pool of addresses, so there is a higher maximization 750 of the total usage of IPv4/port resources. 752 4.4. Support and Implementations 754 4.4.1. OS Support 756 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 757 (including Android), Windows Mobile, Chrome OS and iOS, but at the 758 time of writing is not available in MacOS. 760 The remaining four solutions are commonly deployed as functions in 761 the CE device only, however in general, except DS-Lite, the vendors 762 support is poor. 764 The OpenWRT Linux based open-source OS designed for CE devices offers 765 a number of different 'opkg' packages as part of the distribution: 767 o '464xlat' enables support for 464XLAT CLAT functionality 769 o 'ds-lite' enables support for DSLite B4 functionality 771 o 'map' enables support for MAP-E and lw4o6 CE functionality 773 o 'map-t' enables support for MAP-T CE functionality 775 For the operator side functionality, some free open-source 776 implementations exist: 778 CLAT, NAT64, EAMT: http://www.jool.mx 780 MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io 781 https://gerrit.fd.io/r/#/admin/projects/ 783 lwAFTR: https://github.com/Igalia/snabb 785 DSLite AFTR: https://www.isc.org/downloads/ 787 4.4.2. Support in Cellular and Broadband Networks 789 Several cellular networks use 464XLAT, whereas we are not aware of 790 any deployment of the four other technologies in cellular networks, 791 as they are not standardised neither implemented in UE devices. 793 In broadband networks, there are some deployments of 464XLAT, MAP-E 794 and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite 795 being the most common, but lw4o6 taking over in the last years. 797 Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of 798 deployment information. 800 4.4.3. Implementation Code Sizes 802 As hint to the relative complexity of the mechanisms, the following 803 code sizes are reported from the OpenWRT implementations of each 804 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 805 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 806 (https://openwrt.org/packages/start). 808 We note that the support for all five technologies requires much less 809 code size than the total sum of the above quantities, because they 810 contain a lot of common functions (data plane is shared among several 811 of them). 813 4.5. Typical Deployment and Traffic Volume Considerations 815 4.5.1. Deployment Possibilities 817 Theoretically, all five IPv4aaS technologies could be used together 818 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 819 the CE router would treat the traffic between an IPv6-only client and 820 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 821 gateway would do a single translation, thus offloading this kind of 822 traffic from the IPv4aaS technology. The cost of this solution would 823 be the need for deploying also DNS64 + stateful NAT64. 825 However, this has not been implemented in clients or actual 826 deployments, so only 464XLAT always uses this optimization and the 827 other four solutions do not use it at all. 829 4.5.2. Cellular Networks with 464XLAT 831 Figures from existing deployments (end of 2018), show that the 832 typical traffic volumes in an IPv6-only cellular network, when 833 464XLAT technology is used together with DNS64, are: 835 o 75% of traffic is IPv6 end-to-end (no translation) 837 o 24% of traffic uses DNS64 + NAT64 (1 translation) 839 o Less than 1% of traffic uses the CLAT in addition to NAT64 (2 840 translations), due to an IPv4 socket and/or IPv4 literal. 842 Without using DNS64, 25% of the traffic would undergo double 843 translation. 845 4.5.3. Wireline Networks with 464XLAT 847 Figures from several existing deployments (end of 2020), mainly with 848 residential customers, show that the typical traffic volumes in an 849 IPv6-only network, when 464XLAT is used with DNS64, are in the 850 following ranges: 852 o 65%-85% of traffic is IPv6 end-to-end (no translation) 854 o 14%-34% of traffic uses DNS64 + NAT64 (1 translation) 856 o Less than 1-2% of traffic uses the CLAT in addition to NAT64 (2 857 translations), due to an IPv4 socket and/or IPv4 literal. 859 Without using DNS64, 16%-35% of the traffic would undergo double 860 translation. 862 4.6. Load Sharing 864 If multiple network-side devices are needed as PLAT/AFTR/BR for 865 capacity, then there is a need for a load sharing mechanism. ECMP 866 (Equal-Cost Multi-Path) load sharing can be used for all 867 technologies, however stateful technologies will be impacted by 868 changes in network topology or device failure. 870 Technologies utilizing DNS64 can also distribute load across PLAT/ 871 AFTR devices, evenly or unevenly, by using different prefixes. 872 Different network specific prefixes can be distributed for 873 subscribers in appropriately sized segments (like split-horizon DNS, 874 also called DNS views). 876 Stateless technologies, due to the lack of per-flow state, can make 877 use of anycast routing for load sharing and resiliency across 878 network-devices, both ingress and egress; flows can take asymmetric 879 paths through the network, i.e., in through one lwAFTR/BR and out via 880 another. 882 Mechanisms with centralized NAPT44 state have a number of challenges 883 specifically related to scaling and resilience. As the total amount 884 of client traffic exceeds the capacity of a single CGN instance, 885 additional nodes are required to handle the load. As each CGN 886 maintains a stateful table of active client sessions, this table may 887 need to be syncronized between CGN instances. This is necessary for 888 two reasons: 890 o To prevent all active customer sessions being dropped in event of 891 a CGN node failure. 893 o To ensure a matching state table entry for an active session in 894 the event of asymmetric routing through different egress and 895 ingress CGN nodes. 897 4.7. Logging 899 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 900 address and port combination will vary over time, therefore, logging 901 is necessary to meet data retention laws. Each entry in the PLAT/ 902 AFTR's generates a logging entry. As discussed in Section 4.2, a 903 client may open hundreds of sessions during common tasks such as web- 904 browsing, each of which needs to be logged so the overall logging 905 burden on the network operator is significant. In some countries, 906 this level of logging is required to comply with data retention 907 legislation. 909 One common optimization available to reduce the logging overhead is 910 the allocation of a block of ports to a client for the duration of 911 their session. This means that logging entry only needs to be made 912 when the client's port block is released, which dramatically reducing 913 the logging overhead. This comes as the cost of less efficient 914 public address sharing as clients need to be allocated a port block 915 of a fixed size regardless of the actual number of ports that they 916 are using. 918 Stateless technologies that pre-allocate the IPv4 addresses and ports 919 only require that copies of the active MAP rules (for MAP-E and MAP- 920 T), or binding-table (for lw4o6) are retained along with timestamp 921 information of when they have been active. Support tools (e.g., 922 those used to serve data retention requests) may need to be updated 923 to be aware of the mechanism in use (e.g., implementing the MAP 924 algorithm so that IPv4 information can be linked to the IPv6 prefix 925 delegated to a client). As stateless technologies do not have a 926 centralized stateful element which customer traffic needs to pass 927 through, so if data retention laws mandate per-session logging, there 928 is no simple way of meeting this requirement with a stateless 929 technology alone. Thus a centralized NAPT44 model may be the only 930 way to meet this requirement. 932 Deterministic CGN [RFC7422] was proposed as a solution to reduce the 933 resource consumption of logging. 935 4.8. Optimization for IPv4-only devices/applications 937 When IPv4-only devices or applications are behind a CE connected with 938 IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, 939 be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 940 E) and will reach the IPv4 address of the destination, even if that 941 service supports dual-stack. This means that the traffic flow will 942 cross thru the AFTR, lwAFTR or BR, depending on the specific 943 transition mechanism being used. 945 Even if those services are directly connected to the operator network 946 (for example, CDNs, caches), or located internally (such as VoIP, 947 etc.), it is not possible to avoid that overhead. 949 However, in the case of those mechanism that use a NAT46 function, in 950 the CE (464XLAT and MAP-T), it is possible to take advantage of 951 optimization functionalities, such as the ones described in 952 [I-D.ietf-v6ops-464xlat-optimization]. 954 Using those optimizations, because the NAT46 has already translated 955 the IPv4-only flow to IPv6, and the services are dual-stack, they can 956 be reached without the need to translate them back to IPv4. 958 5. Performance Comparison 960 We plan to compare the performances of the most prominent free 961 software implementations of the five IPv6 transition technologies 962 using the methodology described in "Benchmarking Methodology for IPv6 963 Transition Technologies" [RFC8219]. 965 The Dual DUT Setup of [RFC8219] makes it possible to use the existing 966 "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] 967 compliant measurement devices, however, this solution has two kinds 968 of limitations: 970 o Dual DUT setup has the drawback that the performances of the CE 971 and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) 972 are measured together. In order to measure the performance of 973 only one of them, we need to ensure that the desired one is the 974 bottleneck. 976 o Measurements procedures for PDV and IPDV measurements are missing 977 from the legacy devices, and the old measurement procedure for 978 Latency has been redefined in [RFC8219]. 980 The Single DUT Setup of [RFC8219] makes it possible to benchmark the 981 selected device separately, but it either requires a special Tester 982 or some trick is need, if we want to use legacy Testers. An example 983 for the latter is our stateless NAT64 measurements testing Througput 984 and Frame Loss Rate using a legacy [RFC5180] compliant commercial 985 tester [LEN2020a] 987 Siitperf, an [RFC8219] compliant DPDK-based software Tester for 988 benchmarking stateless NAT64 gateways has been developed recently and 989 it is available from GitHub [SIITperf] as free software and 990 documented in [LEN2021]. Originally, it literally followed the test 991 frame format of [RFC2544] including "hard wired" source and 992 destination port numbers, and then it has been complemented with the 993 random port feature required by [RFC4814]. The new version is 994 documented in [LEN2020b] 996 o It can be used for benchmarking both the CLAT and PLAT of 464XLAT 997 separately, according to the single DUT setup. (We note that the 998 benchmarking prodedures for stateful NAT64 include the stateless 999 tests, plus a few additional tests, which are not implemented 1000 yet.) 1002 o It can also be used for benchmarking all five IPv4-as-a-Service 1003 technologies according to the Dual DUT setup, because it supports 1004 the usage of IPv4 on its both sides, too. 1006 Another software tester for benchmaring the B4 and AFTR components of 1007 DS-Lite is currently being developed at the Budapest University of 1008 Technology and Economics as a student project. It is planned to be 1009 released as free software later this year. 1011 We plan to start an intesive benchmaking campaign using the resources 1012 of NICT StarBED, Japan. 1014 6. Acknowledgements 1016 The authors would like to thank Ole Troan for his thorough review of 1017 this draft and acknowledge the inputs of Mark Andrews, Edwin 1018 Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore 1019 Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, 1020 Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and TBD ... 1022 7. IANA Considerations 1024 This document does not make any request to IANA. 1026 8. Security Considerations 1028 According to the simplest model, the number of bugs is proportional 1029 to the number of code lines. Please refer to Section 4.4.3 for code 1030 sizes of CE implementations. 1032 For all five technologies, the CE device should contain a DNS proxy. 1033 However, the user may change DNS settings. If it happens and lw4o6, 1034 MAP-E and MAP-T are used with significantly restricted port set, 1035 which is required for an efficient public IPv4 address sharing, the 1036 entropy of the source ports is significantly lowered (e.g. from 16 1037 bits to 10 bits, when 1024 port numbers are assigned to each 1038 subscriber) and thus these technologies are theoretically less 1039 resilient against cache poisoning, see [RFC5452]. However, an 1040 efficient cache poisoning attack requires that the subscriber 1041 operates an own caching DNS server and the attack is performed in the 1042 service provider network. Thus, we consider the chance of the 1043 successful exploitation of this vulnerability as low. 1045 An in-depth security analysis of all five IPv6 transition 1046 technologies and their most prominent free software implementations 1047 according to the methodology defined in [LEN2018] is planned. 1049 As the first step, the theoretical security analysis of 464XLAT was 1050 done in [Azz2020]. 1052 9. References 1054 9.1. Normative References 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, 1058 DOI 10.17487/RFC2119, March 1997, 1059 . 1061 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1062 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1063 December 1998, . 1065 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1066 Network Interconnect Devices", RFC 2544, 1067 DOI 10.17487/RFC2544, March 1999, 1068 . 1070 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1071 Translator (NAT) Terminology and Considerations", 1072 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1073 . 1075 [RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 1076 Factors in Network Device Benchmarking", RFC 4814, 1077 DOI 10.17487/RFC4814, March 2007, 1078 . 1080 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 1081 Dugatkin, "IPv6 Benchmarking Methodology for Network 1082 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 1083 2008, . 1085 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 1086 Resilient against Forged Answers", RFC 5452, 1087 DOI 10.17487/RFC5452, January 2009, 1088 . 1090 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1091 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1092 DOI 10.17487/RFC6052, October 2010, 1093 . 1095 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1096 NAT64: Network Address and Protocol Translation from IPv6 1097 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1098 April 2011, . 1100 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1101 Beijnum, "DNS64: DNS Extensions for Network Address 1102 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1103 DOI 10.17487/RFC6147, April 2011, 1104 . 1106 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1107 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1108 DOI 10.17487/RFC6180, May 2011, 1109 . 1111 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1112 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1113 DOI 10.17487/RFC6269, June 2011, 1114 . 1116 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1117 Stack Lite Broadband Deployments Following IPv4 1118 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1119 . 1121 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1122 the IPv4 Address Shortage", RFC 6346, 1123 DOI 10.17487/RFC6346, August 2011, 1124 . 1126 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 1127 Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 1128 2012, . 1130 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1131 Combination of Stateful and Stateless Translation", 1132 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1133 . 1135 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1136 "Analysis of Stateful 64 Translation", RFC 6889, 1137 DOI 10.17487/RFC6889, April 2013, 1138 . 1140 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1141 the IPv6 Prefix Used for IPv6 Address Synthesis", 1142 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1143 . 1145 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1146 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 1147 RFC 7341, DOI 10.17487/RFC7341, August 2014, 1148 . 1150 [RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, 1151 "Using the Port Control Protocol (PCP) to Update Dynamic 1152 DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, 1153 . 1155 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 1156 and O. Vautrin, "Deterministic Address Mapping to Reduce 1157 Logging in Carrier-Grade NAT Deployments", RFC 7422, 1158 DOI 10.17487/RFC7422, December 2014, 1159 . 1161 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1162 Farrer, "Lightweight 4over6: An Extension to the Dual- 1163 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1164 July 2015, . 1166 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1167 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1168 Port with Encapsulation (MAP-E)", RFC 7597, 1169 DOI 10.17487/RFC7597, July 2015, 1170 . 1172 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1173 and T. Murakami, "Mapping of Address and Port using 1174 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1175 2015, . 1177 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1178 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1179 DOI 10.17487/RFC7757, February 2016, 1180 . 1182 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1183 "IP/ICMP Translation Algorithm", RFC 7915, 1184 DOI 10.17487/RFC7915, June 2016, 1185 . 1187 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1188 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1189 . 1191 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1192 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1193 over an IPv6 Multicast Network", RFC 8114, 1194 DOI 10.17487/RFC8114, March 2017, 1195 . 1197 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1198 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1199 May 2017, . 1201 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 1202 Methodology for IPv6 Transition Technologies", RFC 8219, 1203 DOI 10.17487/RFC8219, August 2017, 1204 . 1206 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1207 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1208 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1209 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1210 . 1212 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1213 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1214 Address Translation (NAT) and Network Prefix Translation 1215 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1216 . 1218 [RFC8658] Jiang, S., Ed., Fu, Y., Ed., Xie, C., Li, T., and M. 1219 Boucadair, Ed., "RADIUS Attributes for Softwire Mechanisms 1220 Based on Address plus Port (A+P)", RFC 8658, 1221 DOI 10.17487/RFC8658, November 2019, 1222 . 1224 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 1225 NAT64/464XLAT in Operator and Enterprise Networks", 1226 RFC 8683, DOI 10.17487/RFC8683, November 2019, 1227 . 1229 9.2. Informative References 1231 [Azz2020] Al-Azzawi, A. and G. Lencse, "Towards the Identification 1232 of the Possible Security Issues of the 464XLAT IPv6 1233 Transition Technology", 43rd International Conference on 1234 Telecommunications and Signal Processing (TSP 2020), 1235 Milan, Italy, 10.1109/TSP49548.2020.9163487, Jul 2020, 1236 . 1239 [I-D.ietf-v6ops-464xlat-optimization] 1240 Martinez, J. and A. D'Egidio, "464XLAT/MAT-T 1241 Optimization", draft-ietf-v6ops-464xlat-optimization-03 1242 (work in progress), July 2020. 1244 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 1245 identification of potential security issues of different 1246 IPv6 transition technologies: Threat analysis of DNS64 and 1247 stateful NAT64", Computers & Security (Elsevier), vol. 1248 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 1249 Aug 2018, . 1252 [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of 1253 IPv6 Transition Technologies: A Subjective Classification 1254 for Security Analysis", IEICE Transactions on 1255 Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: 1256 10.1587/transcom.2018EBR0002, Oct 2019, 1257 . 1260 [LEN2020a] 1261 Lencse, G., "Benchmarking Stateless NAT64 Implementations 1262 with a Standard Tester", Telecommunication Systems, vol. 1263 75, pp. 245-257, DOI: 10.1007/s11235-020-00681-x, Jun 1264 2020, . 1267 [LEN2020b] 1268 Lencse, G., "Adding RFC 4814 Random Port Feature to 1269 Siitperf: Design, Implementation and Performance 1270 Estimation", International Journal of Advances in 1271 Telecommunications, Electrotechnics, Signals and Systems, 1272 vol 9, no 3, pp. 18-26, DOI: 10.11601/ijates.v9i3.291, 1273 2020, . 1276 [LEN2021] Lencse, G., "Design and Implementation of a Software 1277 Tester for Benchmarking Stateless NAT64 Gateways", IEICE 1278 Transactions on Communications, DOI: 1279 10.1587/transcom.2019EBN0010, 2021, 1280 . 1283 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation 1284 schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp. 1285 1078-1084, DOI:10.1587/transcom.E93.B.10, May 2010, 1286 . 1289 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 1290 consumption of the NAT64 IPv6 transition 1291 technology", Proc. 37th Internat. Conf. on 1292 Telecommunications and Signal Processing (TSP 2014), 1293 Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July 1294 2014. 1296 [SIITperf] 1297 Lencse, G., "Siitperf: an RFC 8219 compliant SIIT 1298 (stateless NAT64) tester", November 2019, 1299 . 1301 Appendix A. Change Log 1303 A.1. 01 - 02 1305 o Ian Farrer has joined us as an author. 1307 o Restructuring: the description of the five IPv4aaS technologies 1308 was moved to a separate section. 1310 o More details and figures were added to the description of the five 1311 IPv4aaS technologies. 1313 o Section titled "High-level Architectures and their Consequences" 1314 has been completely rewritten. 1316 o Several additions/clarification throughout Section titled 1317 "Detailed Analysis". 1319 o Section titled "Performance Analysis" was dropped due to lack of 1320 results yet. 1322 o Word based text ported to XML. 1324 o Further text cleanups, added text on state sync and load 1325 balancing. Additional comments inline that should be considered 1326 for future updates. 1328 A.2. 02 - 03 1330 o The suggestions of Mohamed Boucadair are incorporated. 1332 o New considerations regarding possible optimizations. 1334 A.3. 03 - 04 1336 o Section titled "Performance Analysis" was added. It mentions our 1337 new benchmarking tool, siitperf, and highlights our plans. 1339 o Some references were updated or added. 1341 A.4. 04 - 05 1343 o Some references were updated or added. 1345 A.5. 05 - 06 1347 o Some references were updated or added. 1349 A.6. 06 - 00-WG Item 1351 o Stats dated and added for Broadband deployments. 1353 o Other clarifications and references. 1355 o New section: IPv4 Pool Size. 1357 o Typos. 1359 Authors' Addresses 1360 Gabor Lencse 1361 Budapest University of Technology and Economics 1362 Magyar Tudosok korutja 2. 1363 Budapest H-1117 1364 Hungary 1366 Email: lencse@hit.bme.hu 1368 Jordi Palet Martinez 1369 The IPv6 Company 1370 Molino de la Navata, 75 1371 La Navata - Galapagar, Madrid 28420 1372 Spain 1374 Email: jordi.palet@theipv6company.com 1375 URI: http://www.theipv6company.com/ 1377 Lee Howard 1378 Retevia 1379 9940 Main St., Suite 200 1380 Fairfax, Virginia 22031 1381 USA 1383 Email: lee@asgard.org 1385 Richard Patterson 1386 Sky UK 1387 1 Brick Lane 1388 London EQ 6PU 1389 United Kingdom 1391 Email: richard.patterson@sky.uk 1393 Ian Farrer 1394 Deutsche Telekom AG 1395 Landgrabenweg 151 1396 Bonn 53227 1397 Germany 1399 Email: ian.farrer@telekom.de