idnits 2.17.1 draft-lmhp-v6ops-transition-comparison-06.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 (Jan 9, 2021) is 1200 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 Internet Engineering Task Force G. Lencse 3 Internet-Draft BUTE 4 Intended status: Informational J. Palet Martinez 5 Expires: July 13, 2021 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 Jan 9, 2021 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-lmhp-v6ops-transition-comparison-06 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 July 13, 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 . . . . . . . . . . . . . . . . . . . 5 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. CE Provisioning Considerations . . . . . . . . . . . . . 11 78 3.5. Support for Multicast . . . . . . . . . . . . . . . . . . 11 79 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. Architectural Differences . . . . . . . . . . . . . . . . 11 81 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 11 82 4.2. Tradeoff between Port Number Efficiency and Stateless 83 Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 84 4.3. Support for Public Server Operation . . . . . . . . . . . 14 85 4.4. Support and Implementations . . . . . . . . . . . . . . . 15 86 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 15 87 4.4.2. Support in Cellular and Broadband Networks . . . . . 16 88 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 16 89 4.5. Typical Deployment and Traffic Volume Considerations . . 16 90 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 16 91 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 16 92 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 17 93 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 4.8. Optimization for IPv4-only devices/applications . . . . . 18 95 5. Performance Comparison . . . . . . . . . . . . . . . . . . . 19 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 9.2. Informative References . . . . . . . . . . . . . . . . . 24 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 103 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 As the deployment of IPv6 becomes more prevalent, it follows that 113 network operators will move to building single-stack IPv6 core and 114 access networks to simplify network planning and operations. 115 However, providing customers with IPv4 services continues to be a 116 requirement for the foreseeable future. To meet this need, the IETF 117 has standardized a number of different IPv4aaS technologies for this 118 [LEN2019] based on differing requirements and deployment scenarios. 120 The number of technologies that have been developed makes it time 121 consuming for a network operator to identify the most appropriate 122 mechanism for their specific deployment. This document provides a 123 comparative analysis of the most commonly used mechanisms to assist 124 operators with this problem. 126 Five different IPv4aaS solutions are considered. The following IPv6 127 transition technologies are covered: 129 1. 464XLAT [RFC6877] 131 2. Dual Stack Lite [RFC6333] 133 3. lw4o6 (Lightweight 4over6) [RFC7596] 135 4. MAP-E [RFC7597] 137 5. MAP-T [RFC7599] 139 We note that [RFC6180] gives guidelines for using IPv6 transition 140 mechanisms during IPv6 deployment addressing a much broader topic, 141 whereas this document focuses on a small part of it. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. Overview of the Technologies 153 The following sections introduce the different technologies analyzed 154 in this document, describing some of their most important 155 characteristics. 157 2.1. 464XLAT 159 464XLAT is a single/dual translation model, which uses a customer- 160 side translator (CLAT) located in the customer's device to perform 161 stateless NAT64 translation [RFC7915] (more precisely, stateless 162 NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). 163 IPv4-embedded IPv6 addresses [RFC6052] are used for both source and 164 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 Note that we generally do not see state close to the end-user as 179 equally problematic as state in the middle of the network. 181 In typical deployments, 464XLAT is used together with DNS64 182 [RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client 183 or application communicates with an IPv4-only server, the DNS64 184 server returns the IPv4-embedded IPv6 address of the IPv4-only 185 server. In this case, the IPv6-only client sends out IPv6 packets, 186 thus CLAT functions as an IPv6 router and the PLAT performs a 187 stateful NAT64 for these packets. In this case, there is a single 188 translation. 190 Alternatively, one can say that the DNS64 + stateful NAT64 is used to 191 carry the traffic of the IPv6-only client and the IPv4-only server, 192 and the CLAT is used only for the IPv4 traffic from applications or 193 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 195 Private +----------+ Translated +----------+ _______ 196 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 197 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 198 |Device|<-------| NAT46 |<------------| NAT64 | (________) 199 +------+ +----------+ ^ +----------+ 200 | 201 Operator IPv6 202 network 204 Figure 1: Overview of the 464XLAT architecture 206 Note: in mobile networks, CLAT is commonly implemented in the user's 207 equipment (UE or smartphone). 209 2.2. Dual-Stack Lite 211 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 212 transition mechanisms to be developed. DS-Lite uses a 'Basic 213 Broadband Bridging' (B4) function in the customer's CE router that 214 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 215 service-provider network to a centralized 'Address Family Transition 216 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 217 4in6 traffic and translates the IPv4 payload to public IPv4 source 218 address using a stateful NAPT44 function. 220 +-------------+ 221 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 222 +------+ IPv4 | B4 | tunnel |------+------+ _______ 223 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 224 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 225 +------+ +----------+ ^ |Decap.| 44 | (________) 226 | +------+------+ 227 Operator IPv6 228 network 230 Figure 2: Overview of the DS-Lite architecture 232 2.3. Lightweight 4over6 234 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 235 difference is that the stateful NAPT44 function is relocated from the 236 centralized AFTR to the customer's B4 element (called a lwB4). The 237 AFTR (called a lwAFTR) function therefore only performs A+P routing 238 and 4in6 encapsulation/decapsulation. 240 Routing to the correct client and IPv4 address sharing is achieved 241 using the Address + Port (A+P) model [RFC6346] of provisioning each 242 lwB4 with a unique tuple of IPv4 address unique range of layer-4 243 ports. The client uses these for NAPT44. 245 The lwAFTR implements a binding table, which has a per-client entry 246 linking the customer's source IPv4 address and allocated range of 247 layer-4 ports to their IPv6 tunnel endpoint address. The binding 248 table allows egress traffic from customers to be validated (to 249 prevent spoofing) and ingress traffic to be correctly encapsulated 250 and forwarded. As there needs to be a per-client entry, an lwAFTR 251 implementation needs to be optimized for performing a per-packet 252 lookup on the binding table. 254 Direct communication between two lwB4s is performed by hair-pinning 255 traffic through the lwAFTR. 257 +-------------+ +----------+ 258 Private | lwB4 | IPv4-in-IPv6| Stateless| 259 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 260 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 261 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 262 +------+ | 44 |Decap.| ^ | routing) | (________) 263 +------+------+ | +----------+ 264 Operator IPv6 265 network 267 Figure 3: Overview of the lw4o6 architecture 269 2.4. MAP-E 271 MAP-E uses a stateless algorithm to embed portions of the customer's 272 allocated IPv4 address (or part of an address with A+P routing) into 273 the IPv6 prefix delegated to the client. This allows for large 274 numbers of clients to be provisioned using a single MAP rule (called 275 a MAP domain). The algorithm also allows for direct IPv4 peer-to- 276 peer communication between hosts provisioned with common MAP rules. 278 The CE (Customer-Edge) router typically performs stateful NAPT44 279 [RFC2663] to translate the private IPv4 source addresses and source 280 ports into an address and port range defined by applying the MAP rule 281 applied to the delegated IPv6 prefix. The client address/port 282 allocation size is a design parameter. The CE router then 283 encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it 284 directly to another host in the MAP domain (for peer-to-peer) or to a 285 Border Router (BR) if the IPv4 destination is not covered in one of 286 the CE's MAP rules. 288 The MAP BR is provisioned with the set of MAP rules for the MAP 289 domains it serves. These rules determine how the MAP BR is to 290 decapsulate traffic that it receives from client, validating the 291 source IPv4 address and layer 4 ports assigned, as well as how to 292 calculate the destination IPv6 address for ingress IPv4 traffic. 294 +-------------+ +----------+ 295 Private | MAP CE | IPv4-in-IPv6| Stateless| 296 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 297 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 298 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 299 +------+ | 44 |Decap.| ^ | routing) | (________) 300 +------+------+ | +----------+ 301 Operator IPv6 302 network 304 Figure 4: Overview of the MAP-E architecture 306 2.5. MAP-T 308 MAP-T uses the same mapping algorithm as MAP-E. The major difference 309 is that double stateless translation (NAT46 in the CE and NAT64 in 310 the BR) is used to traverse the ISP's IPv6 single-stack network. 311 MAP-T can also be compared to 464XLAT when there is a double 312 translation. 314 A MAP CE typically performs stateful NAPT44 to translate traffic to a 315 public IPv4 address and port-range calculated by applying the 316 provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) 317 to the delegated IPv6 prefix. The CE then performs stateless 318 translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned 319 with the same BMR as the client, enabling the received IPv6 traffic 320 to be statelessly NAT64 translated back to the public IPv4 source 321 address used by the client. 323 Using translation instead of encapsulation also allows IPv4-only 324 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 325 have IPv4-embedded IPv6 addresses. 327 +-------------+ +----------+ 328 Private | MAP CE | Translated | Stateless| 329 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 330 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 331 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 332 +------+ | 44 |NAT46 | ^ | routing) | (________) 333 +------+------+ | +----------+ 334 Operator IPv6 335 network 337 Figure 5: Overview of the MAP-T architecture 339 3. High-level Architectures and their Consequences 341 3.1. Service Provider Network Traversal 343 For the data-plane, there are two approaches for traversing the IPv6 344 provider network: 346 o 4-6-4 translation 348 o 4-in-6 encapsulation 350 +--------------+---------+---------+-------+-------+-------+ 351 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 352 +--------------+---------+---------+-------+-------+-------+ 353 | 4-6-4 trans. | X | | | | X | 354 | 4-6-4 encap. | | X | X | X | | 355 +--------------+---------+---------+-------+-------+-------+ 357 Table 1: Available Traversal Mechanisms 359 In the scope of this document, all of the encapsulation based 360 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 361 tunneling mechanism which does not require any additional tunnel 362 headers. 364 It should be noted that both of these approaches result in an 365 increase in the size of the packet that needs to be transported 366 across the operator's network when compared to native IPv4. 4-6-4 367 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 368 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 369 overhead (an IPv6 header is prepended to the IPv4 header). 371 The increase in packet size can become a significant problem if there 372 is a link with a smaller MTU in the traffic path. This may result in 373 traffic needing to be fragmented at the ingress point to the IPv6 374 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 375 also result in the need to implement buffering and fragment re- 376 assembly in the BR node. 378 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 379 these mechanisms: It is strongly recommended that the MTU in the 380 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 381 side interface be set so that no fragmentation occurs within the 382 boundary of the IPv6-only domain. 384 3.2. Network Address Translation 386 For the high-level solution of IPv6 service provider network 387 traversal, MAP-T uses double stateless translation. First at the CE 388 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 389 service provider network. 391 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 392 or single translation (stateful NAT64), depending on different 393 factors, such as the use of DNS by the applications and the 394 availability of a DNS64 function (in the host or in the service 395 provider network). For deployment guidelines, please refer to 396 [RFC8683]. 398 The first step for the double translation mechanisms is a stateless 399 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 400 Translation Algorithm) [RFC7915], which does not translate IPv4 401 header options and/or multicast IP/ICMP packets. With encapsulation- 402 based technologies the header is transported intact and multicast can 403 also be carried. 405 Single and double translation results in native IPv6 traffic with a 406 layer-4 next-header. The fields in these headers can be used for 407 functions such as hashing across equal-cost multipaths or ACLs. For 408 encapsulation, there is an IPv6 header followed by an IPv4 header. 409 This results in less entropy for hashing algorithms, and may mean 410 that devices in the traffic path that perform header inspection (e.g. 411 router ACLs or firewalls) require the functionality to look into the 412 payload header. 414 Solutions using double translation can only carry port-aware IP 415 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 416 address sharing (please refer to Section 4.3 for more details). 417 Encapsulation based solutions can carry any other protocols over IP, 418 too. 420 An in-depth analysis of stateful NAT64 can be found in [RFC6889]. 422 3.3. IPv4 Address Sharing 424 As public IPv4 address exhaustion is a common motivation for 425 deploying IPv6, transition technologies need to provide a solution 426 for allowing public IPv4 address sharing. 428 In order to fulfill this requirement, a stateful NAPT function is a 429 necessary function in all of the mechanisms. The major 430 differentiator is where in the architecture this function is located. 432 The solutions compared by this document fall into two categories: 434 o CGN-based approaches (DS-Lite, 464XLAT) 436 o A+P-based approaches (lw4o6, MAP-E, MAP-T) 438 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 439 the NAPT44 function and maintains per-session state for all of the 440 active client's traffic. The customer's device does not require per- 441 session state for NAPT. 443 In the A+P-based model, a device (usually a CE) performs stateful 444 NAPT44 and maintains per-session state only co-located devices, e.g. 445 in the customer's home network. Here, the centralized network 446 function (lwAFTR or BR) only needs to perform stateless 447 encapsulation/decapsulation or NAT64. 449 Issues related to IPv4 address sharing mechanisms are described in 450 [RFC6269] and should also be considered. 452 The address sharing efficiency of the five technologies is 453 significantly different, it is discussed in Section 4.2 455 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 456 sharing, see the details in Section 4.3. However, in that case, 457 there is no advantage in terms of public IPv4 address saving. In the 458 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 460 Conversely, both MAP-E and MAP-T may be configured to provide more 461 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 462 /32) to customers. 464 Dynamic DNS issues in address-sharing contexts and their possible 465 solutions using PCP (Port Control Protocol) are discussed in detail 466 in [RFC7393]. 468 3.4. CE Provisioning Considerations 470 All of the technologies require some provisioning of customer 471 devices. The table below shows which methods currently have 472 extensions for provisioning the different mechanisms. 474 +------------------+-----------+---------+-------+-------+-------+ 475 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 476 +------------------+-----------+---------+-------+-------+-------+ 477 | DHCPv6 [RFC8415] | | X | X | X | X | 478 | RADIUS Attr. | | X | X | X | X | 479 | TR-69 | | X | | X | X | 480 | DNS64 [RFC7050] | X | | | | | 481 | YANG [RFC7950] | [RFC8512] | X | X | X | X | 482 | DHCP4o6 | | | X | X | | 483 +------------------+-----------+---------+-------+-------+-------+ 485 Table 2: Available Provisioning Mechanisms 487 3.5. Support for Multicast 489 The solutions covered in this document are all intended for unicast 490 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 491 multicast traffic over an IPv6 multicast network. This could be 492 deployed in parallel to any of the operator's chosen IPv4aaS 493 mechanism. 495 4. Detailed Analysis 497 4.1. Architectural Differences 499 4.1.1. Basic Comparison 501 The five IPv4aaS technologies can be classified into 2x2=4 categories 502 on the basis of two aspects: 504 o Technology used for service provider network traversal. It can be 505 single/double translation or encapsulation. 507 o Presence or absence of NAPT44 per-flow state in the operator 508 network. 510 +-----------------------+---------+---------+-------+-------+-------+ 511 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 512 +-----------------------+---------+---------+-------+-------+-------+ 513 | 4-6-4 trans. | X | | | | X | 514 | 4-in-4 encap. | | X | X | X | | 515 | Per-flow state in op. | X | X | | | | 516 | network | | | | | | 517 +-----------------------+---------+---------+-------+-------+-------+ 519 Table 3: Available Provisioning Mechanisms 521 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 523 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 524 respectively. This may cause scalability issues for the number of 525 clients or volume of traffic, but does not impose a limitation on the 526 number of ports per user, as they can be allocated dynamically on- 527 demand and the allocation policy can be centrally managed/adjusted. 529 A+P based mechanisms (Lw4o6, MAP-E, and MAP-T) avoid using NAPT in 530 the service provider network. However, this means that the number of 531 ports provided to each user (and hence the effective IPv4 address 532 sharing ratio) must be pre-provisioned to the client. 534 Changing the allocated port ranges with A+P based technologies, 535 requires more planning and is likely to involve re-provisioning both 536 hosts and operator side equipment. It should be noted that due to 537 the per-customer binding table entry used by lw4o6, a single customer 538 can be re-provisioned (e.g., if they request a full IPv4 address) 539 without needing to change parameters for a number of customers as in 540 a MAP domain. 542 It is also worth noting that there is a direct relationship between 543 the efficiency of customer public port-allocations and the 544 corresponding logging overhead that may be necessary to meet data- 545 retention requirements. This is considered in Section 4.7 below. 547 Determining the optimal number of ports for a fixed port set is not 548 an easy task, and may also be impacted by local regulatory law, which 549 may define a maximum number of users per IP address, and consequently 550 a minimum number of ports per user. 552 On the one hand, the "lack of ports" situation may cause serious 553 problems in the operation of certain applications. For example, 554 Miyakawa has demonstrated the consequences of the session number 555 limitation due to port number shortage on the example of Google Maps 556 [MIY2010]. When the limit was 15, several blocks of the map were 557 missing, and the map was unusable. This study also provided several 558 examples for the session numbers of different applications (the 559 highest one was Apple's iTunes: 230-270 ports). 561 The port number consumption of different applications is highly 562 varying and e.g. in the case of web browsing it depends on several 563 factors, including the choice of the web page, the web browser, and 564 sometimes even the operating system [REP2014]. For example, under 565 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 566 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 567 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 569 There may be several users behind a CE router, especially in the 570 broadband case (e.g. Internet is used by different members of a 571 family simultaneously), so sufficient ports must be allocated to 572 avoid impacting user experience. 574 Furthermore, assigning too many ports per CE router will result in 575 waste of public IPv4 addresses, which is a scarce and expensive 576 resource. Clearly this is a big advantage in the case of 464XLAT 577 where they are dynamically managed, so that the number of IPv4 578 addresses for the sharing-pool is smaller while the availability of 579 ports per user don't need to be pre-defined and is not a limitation 580 for them. 582 There is a direct tradeoff between the optimization of client port 583 allocations and the associated logging overhead. Section 4.7 584 discusses this in more depth. 586 We note that common CE router NAT44 implementations utilizing 587 Netfilter, multiplexes active sessions using a 3-tuple (source 588 address, destination address, and destination port). This means that 589 external source ports can be reused for unique internal source and 590 destination address and port sessions. It is also noted, that 591 Netfilter cannot currently make use of multiple source port ranges 592 (i.e. several blocks of ports distributed across the total port space 593 as is common in MAP deployments), this may influence the design when 594 using stateless technologies. 596 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 597 therefore be much more efficient in terms of port allocation and thus 598 public IP address saving. The price is the stateful operation in the 599 service provider network, which allegedly does not scale up well. It 600 should be noticed that in many cases, all those factors may depend on 601 how it is actually implemented. 603 XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX 604 We note that some CGN-type solutions can allocate ports dynamically 605 "on the fly". Depending on configuration, this can result in the 606 same customer being allocated ports from different source addresses. 607 This can cause operational issues for protocols and applications that 608 expect multiple flows to be sourced from the same address. E.g., 609 ECMP hashing, STUN, gaming, content delivery networks. However, it 610 should be noticed that this is the same problem when a network has a 611 NAT44 with multiple public IPv4 addresses, or even when applications 612 in a dual-stack case, behave wrongly if happy eyeballs is flapping 613 the flow address between IPv4 and IPv6. 615 The consequences of IPv4 address sharing [RFC6269] may impact all 616 five technologies. However, when ports are allocated statically, 617 more customers may get ports from the same public IPv4 address, which 618 may results in negative consequences with higher probability, e.g. 619 many applications and service providers (Sony PlayStation Network, 620 OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that 621 they are used for address sharing. 623 Both cases are, again, implementation dependent. 625 We note that although it is not of typical use, one can do 626 deterministic, stateful NAT and reserve a fixed set of ports for each 627 customer, as well. 629 4.3. Support for Public Server Operation 631 Mechanisms that rely on operator side per-flow state do not, by 632 themselves, offer a way for customers to present services on publicly 633 accessible layer-4 ports. 635 Port Control Protocol (PCP) [RFC6877] provides a mechanism for a 636 client to request an external public port from a CGN device. For 637 server operation, it is required with NAT64/464XLAT, and it is 638 supported in some DS-Lite AFTR implementations. 640 A+P based mechanisms distribute a public IPv4 address and restricted 641 range of layer-4 ports to the client. In this case, it is possible 642 for the user to configure their device to offer a publicly accessible 643 server on one of their allocated ports. It should be noted that 644 commonly operators do not assign the Well-Known-Ports to users 645 (unless they are allocating a full IPv4 address), so the user will 646 need to run the service on an allocated port, or configure port 647 translation. 649 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 650 full IPv4 address, allowing exclusive use of all ports, and non-port- 651 based layer 4 protocols. Thus, they may also be used to support 652 server/services operation on their default ports. However, when 653 public IPv4 addresses are assigned to the CE router without address 654 sharing, obviously there is no advantage in terms of IPv4 public 655 addresses saving. 657 It is also possible to configure specific ports mapping in 464XLAT/ 658 NAT64 using EAMT [RFC7757], which means that only those ports are 659 "lost" from the pool of addresses, so there is a higher maximization 660 of the total usage of IPv4/port resources. 662 4.4. Support and Implementations 664 4.4.1. OS Support 666 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 667 (including Android), Windows Mobile, Chrome OS and iOS, but at the 668 time of writing is not available in MacOS. 670 The remaining four solutions are commonly deployed as functions in 671 the CE device only, however in general, except DS-Lite, the vendors 672 support is poor. 674 The OpenWRT Linux based open-source OS designed for CE devices offers 675 a number of different 'opkg' packages as part of the distribution: 677 o '464xlat' enables support for 464XLAT CLAT functionality 679 o 'ds-lite' enables support for DSLite B4 functionality 681 o 'map' enables support for MAP-E and lw4o6 CE functionality 683 o 'map-t' enables support for MAP-T CE functionality 685 For the operator side functionality, some free open-source 686 implementations exist: 688 CLAT, NAT64, EAMT: http://www.jool.mx 690 MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io 691 https://gerrit.fd.io/r/#/admin/projects/ 693 lwAFTR: https://github.com/Igalia/snabb 695 DSLite AFTR: https://www.isc.org/downloads/ 697 4.4.2. Support in Cellular and Broadband Networks 699 Several cellular networks use 464XLAT, whereas we are not aware of 700 any deployment of the four other technologies in cellular networks, 701 as they are not implemented in UE devices. 703 In broadband networks, there are some deployments of 464XLAT, MAP-E 704 and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite 705 being the most common, but lw4o6 taking over in the last years. 707 Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of 708 deployment information. 710 4.4.3. Implementation Code Sizes 712 As hint to the relative complexity of the mechanisms, the following 713 code sizes are reported from the OpenWRT implementations of each 714 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 715 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 716 (https://openwrt.org/packages/start). 718 We note that the support for all five technologies requires much less 719 code size than the total sum of the above quantities, because they 720 contain a lot of common functions (data plane is shared among several 721 of them). 723 4.5. Typical Deployment and Traffic Volume Considerations 725 4.5.1. Deployment Possibilities 727 Theoretically, all five IPv4aaS technologies could be used together 728 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 729 the CE router would treat the traffic between an IPv6-only client and 730 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 731 gateway would do a single translation, thus offloading this kind of 732 traffic from the IPv4aaS technology. The cost of this solution would 733 be the need for deploying also DNS64 + stateful NAT64. 735 However, this has not been implemented in clients or actual 736 deployments, so only 464XLAT always uses this optimization and the 737 other four solutions do not use it at all. 739 4.5.2. Cellular Networks with 464XLAT 741 Actual figures from existing deployments, show that the typical 742 traffic volumes in an IPv6-only cellular network, when 464XLAT 743 technology is used together with DNS64, are: 745 o 75% of traffic is IPv6 end-to-end (no translation) 747 o 24% of traffic uses DNS64 + NAT64 (1 translation) 749 o Less than 1% of traffic uses the CLAT in addition to NAT64 (2 750 translations), due to an IPv4 socket and/or IPv4 literal. 752 Without using DNS64, 25% of the traffic would undergo double 753 translation. 755 4.6. Load Sharing 757 If multiple network-side devices are needed as PLAT/AFTR/BR for 758 capacity, then there is a need for a load sharing mechanism. ECMP 759 (Equal-Cost Multi-Path) load sharing can be used for all 760 technologies, however stateful technologies will be impacted by 761 changes in network topology or device failure. 763 Technologies utilizing DNS64 can also distribute load across PLAT/ 764 AFTR devices, evenly or unevenly, by using different prefixes. 765 Different network specific prefixes can be distributed for 766 subscribers in appropriately sized segments (like split-horizon DNS, 767 also called DNS views). 769 Stateless technologies, due to the lack of per-flow state, can make 770 use of anycast routing for load sharing and resiliency across 771 network-devices, both ingress and egress; flows can take asymmetric 772 paths through the network, i.e., in through one lwAFTR/BR and out via 773 another. 775 Mechanisms with centralized NAPT44 state have a number of challenges 776 specifically related to scaling and resilience. As the total amount 777 of client traffic exceeds the capacity of a single CGN instance, 778 additional nodes are required to handle the load. As each CGN 779 maintains a stateful table of active client sessions, this table may 780 need to be syncronized between CGN instances. This is necessary for 781 two reasons: 783 o To prevent all active customer sessions being dropped in event of 784 a CGN node failure. 786 o To ensure a matching state table entry for an active session in 787 the event of asymmetric routing through different egress and 788 ingress CGN nodes. 790 4.7. Logging 792 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 793 address and port combination will vary over time, therefore, logging 794 is necessary to meet data retention laws. Each entry in the PLAT/ 795 AFTR's generates a logging entry. As discussed in Section 4.2, a 796 client may open hundreds of sessions during common tasks such as web- 797 browsing, each of which needs to be logged so the overall logging 798 burden on the network operator is significant. In some countries, 799 this level of logging is required to comply with data retention 800 legislation. 802 One common optimization available to reduce the logging overhead is 803 the allocation of a block of ports to a client for the duration of 804 their session. This means that logging entry only needs to be made 805 when the client's port block is released, which dramatically reducing 806 the logging overhead. This comes as the cost of less efficient 807 public address sharing as clients need to be allocated a port block 808 of a fixed size regardless of the actual number of ports that they 809 are using. 811 Stateless technologies that pre-allocate the IPv4 addresses and ports 812 only require that copies of the active MAP rules (for MAP-E and MAP- 813 T), or binding-table (for lw4o6) are retained along with timestamp 814 information of when they have been active. Support tools (e.g., 815 those used to serve data retention requests) may need to be updated 816 to be aware of the mechanism in use (e.g., implementing the MAP 817 algorithm so that IPv4 information can be linked to the IPv6 prefix 818 delegated to a client). As stateless technologies do not have a 819 centralized stateful element which customer traffic needs to pass 820 through, so if data retention laws mandate per-session logging, there 821 is no simple way of meeting this requirement with a stateless 822 technology alone. Thus a centralized NAPT44 model may be the only 823 way to meet this requirement. 825 Deterministic CGN [RFC7422] was proposed as a solution to reduce the 826 resource consumption of logging. 828 4.8. Optimization for IPv4-only devices/applications 830 When IPv4-only devices or applications are behind a CE connected with 831 IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, 832 be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 833 E) and will reach the IPv4 address of the destination, even if that 834 service supports dual-stack. This means that the traffic flow will 835 cross thru the AFTR, lwAFTR or BR, depending on the specific 836 transition mechanism being used. 838 Even if those services are directly connected to the operator network 839 (for example, CDNs, caches), or located internally (such as VoIP, 840 etc.), it is not possible to avoid that overhead. 842 However, in the case of those mechanism that use a NAT46 function, in 843 the CE (464XLAT and MAP-T), it is possible to take advantage of 844 optimization functionalities, such as the ones described in 845 [I-D.ietf-v6ops-464xlat-optimization]. 847 Using those optimizations, because the NAT46 has already translated 848 the IPv4-only flow to IPv6, and the services are dual-stack, they can 849 be reached without the need to translate them back to IPv4. 851 5. Performance Comparison 853 We plan to compare the performances of the most prominent free 854 software implementations of the five IPv6 transition technologies 855 using the methodology described in "Benchmarking Methodology for IPv6 856 Transition Technologies" [RFC8219]. 858 The Dual DUT Setup of [RFC8219] makes it possible to use the existing 859 "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] 860 compliant measurement devices, however, this solution has two kinds 861 of limitations: 863 o Dual DUT setup has the drawback that the performances of the CE 864 and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) 865 are measured together. In order to measure the performance of 866 only one of them, we need to ensure that the desired one is the 867 bottleneck. 869 o Measurements procedures for PDV and IPDV measurements are missing 870 from the legacy devices, and the old measurement procedure for 871 Latency has been redefined in [RFC8219]. 873 The Single DUT Setup of [RFC8219] makes it possible to benchmark the 874 selected device separately, but it either requires a special Tester 875 or some trick is need, if we want to use legacy Testers. An example 876 for the latter is our stateless NAT64 measurements testing Througput 877 and Frame Loss Rate using a legacy [RFC5180] compliant commercial 878 tester [LEN2020a] 880 Siitperf, an [RFC8219] compliant DPDK-based software Tester for 881 benchmarking stateless NAT64 gateways has been developed recently and 882 it is available from GitHub [SIITperf] as free software and 883 documented in [LEN2021]. Originally, it literally followed the test 884 frame format of [RFC2544] including "hard wired" source and 885 destination port numbers, and then it has been complemented with the 886 random port feature required by [RFC4814]. The new version is 887 documented in [LEN2020b] 889 o It can be used for benchmarking both the CLAT and PLAT of 464XLAT 890 separately, according to the single DUT setup. (We note that the 891 benchmarking prodedures for stateful NAT64 include the stateless 892 tests, plus a few additional tests, which are not implemented 893 yet.) 895 o It can also be used for benchmarking all five IPv4-as-a-Service 896 technologies according to the Dual DUT setup, because it supports 897 the usage of IPv4 on its both sides, too. 899 Another software tester for benchmaring the B4 and AFTR components of 900 DS-Lite is currently being developed at the Budapest University of 901 Technology and Economics as a student project. It is planned to be 902 released as free software later this year. 904 We plan to start an intesive benchmaking campaign using the resources 905 of NICT StarBED, Japan. 907 6. Acknowledgements 909 The authors would like to thank Ole Troan for his thorough review of 910 this draft and acknowledge the inputs of Mark Andrews, Edwin 911 Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore 912 Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, 913 Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and TBD ... 915 7. IANA Considerations 917 This document does not make any request to IANA. 919 8. Security Considerations 921 According to the simplest model, the number of bugs is proportional 922 to the number of code lines. Please refer to Section 4.4.3 for code 923 sizes of CE implementations. 925 For all five technologies, the CE device should contain a DNS proxy. 926 However, the user may change DNS settings. If it happens and lw4o6, 927 MAP-E and MAP-T are used with significantly restricted port set, 928 which is required for an efficient public IPv4 address sharing, the 929 entropy of the source ports is significantly lowered (e.g. from 16 930 bits to 10 bits, when 1024 port numbers are assigned to each 931 subscriber) and thus these technologies are theoretically less 932 resilient against cache poisoning, see [RFC5452]. However, an 933 efficient cache poisoning attack requires that the subscriber 934 operates an own caching DNS server and the attack is performed in the 935 service provider network. Thus, we consider the chance of the 936 successful exploitation of this vulnerability as low. 938 An in-depth security analysis of all five IPv6 transition 939 technologies and their most prominent free software implementations 940 according to the methodology defined in [LEN2018] is planned. 942 As the first step, the theoretical security analysis of 464XLAT was 943 done in [Azz2020]. 945 9. References 947 9.1. Normative References 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, 951 DOI 10.17487/RFC2119, March 1997, 952 . 954 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 955 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 956 December 1998, . 958 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 959 Network Interconnect Devices", RFC 2544, 960 DOI 10.17487/RFC2544, March 1999, 961 . 963 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 964 Translator (NAT) Terminology and Considerations", 965 RFC 2663, DOI 10.17487/RFC2663, August 1999, 966 . 968 [RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 969 Factors in Network Device Benchmarking", RFC 4814, 970 DOI 10.17487/RFC4814, March 2007, 971 . 973 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 974 Dugatkin, "IPv6 Benchmarking Methodology for Network 975 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 976 2008, . 978 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 979 Resilient against Forged Answers", RFC 5452, 980 DOI 10.17487/RFC5452, January 2009, 981 . 983 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 984 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 985 DOI 10.17487/RFC6052, October 2010, 986 . 988 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 989 NAT64: Network Address and Protocol Translation from IPv6 990 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 991 April 2011, . 993 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 994 Beijnum, "DNS64: DNS Extensions for Network Address 995 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 996 DOI 10.17487/RFC6147, April 2011, 997 . 999 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1000 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1001 DOI 10.17487/RFC6180, May 2011, 1002 . 1004 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1005 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1006 DOI 10.17487/RFC6269, June 2011, 1007 . 1009 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1010 Stack Lite Broadband Deployments Following IPv4 1011 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1012 . 1014 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1015 the IPv4 Address Shortage", RFC 6346, 1016 DOI 10.17487/RFC6346, August 2011, 1017 . 1019 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1020 Combination of Stateful and Stateless Translation", 1021 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1022 . 1024 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1025 "Analysis of Stateful 64 Translation", RFC 6889, 1026 DOI 10.17487/RFC6889, April 2013, 1027 . 1029 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1030 the IPv6 Prefix Used for IPv6 Address Synthesis", 1031 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1032 . 1034 [RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, 1035 "Using the Port Control Protocol (PCP) to Update Dynamic 1036 DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, 1037 . 1039 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 1040 and O. Vautrin, "Deterministic Address Mapping to Reduce 1041 Logging in Carrier-Grade NAT Deployments", RFC 7422, 1042 DOI 10.17487/RFC7422, December 2014, 1043 . 1045 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1046 Farrer, "Lightweight 4over6: An Extension to the Dual- 1047 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1048 July 2015, . 1050 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1051 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1052 Port with Encapsulation (MAP-E)", RFC 7597, 1053 DOI 10.17487/RFC7597, July 2015, 1054 . 1056 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1057 and T. Murakami, "Mapping of Address and Port using 1058 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1059 2015, . 1061 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1062 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1063 DOI 10.17487/RFC7757, February 2016, 1064 . 1066 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1067 "IP/ICMP Translation Algorithm", RFC 7915, 1068 DOI 10.17487/RFC7915, June 2016, 1069 . 1071 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1072 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1073 . 1075 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1076 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1077 over an IPv6 Multicast Network", RFC 8114, 1078 DOI 10.17487/RFC8114, March 2017, 1079 . 1081 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1082 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1083 May 2017, . 1085 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 1086 Methodology for IPv6 Transition Technologies", RFC 8219, 1087 DOI 10.17487/RFC8219, August 2017, 1088 . 1090 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1091 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1092 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1093 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1094 . 1096 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1097 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1098 Address Translation (NAT) and Network Prefix Translation 1099 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1100 . 1102 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 1103 NAT64/464XLAT in Operator and Enterprise Networks", 1104 RFC 8683, DOI 10.17487/RFC8683, November 2019, 1105 . 1107 9.2. Informative References 1109 [Azz2020] Al-Azzawi, A. and G. Lencse, "Towards the Identification 1110 of the Possible Security Issues of the 464XLAT IPv6 1111 Transition Technology", 43rd International Conference on 1112 Telecommunications and Signal Processing (TSP 2020), 1113 Milan, Italy, 10.1109/TSP49548.2020.9163487, Jul 2020, 1114 . 1117 [I-D.ietf-v6ops-464xlat-optimization] 1118 Martinez, J. and A. D'Egidio, "464XLAT/MAT-T 1119 Optimization", draft-ietf-v6ops-464xlat-optimization-03 1120 (work in progress), July 2020. 1122 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 1123 identification of potential security issues of different 1124 IPv6 transition technologies: Threat analysis of DNS64 and 1125 stateful NAT64", Computers & Security (Elsevier), vol. 1126 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 1127 Aug 2018, . 1130 [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of 1131 IPv6 Transition Technologies: A Subjective Classification 1132 for Security Analysis", IEICE Transactions on 1133 Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: 1134 10.1587/transcom.2018EBR0002, Oct 2019, 1135 . 1138 [LEN2020a] 1139 Lencse, G., "Benchmarking Stateless NAT64 Implementations 1140 with a Standard Tester", Telecommunication Systems, vol. 1141 75, pp. 245-257, DOI: 10.1007/s11235-020-00681-x, Jun 1142 2020, . 1145 [LEN2020b] 1146 Lencse, G., "Adding RFC 4814 Random Port Feature to 1147 Siitperf: Design, Implementation and Performance 1148 Estimation", International Journal of Advances in 1149 Telecommunications, Electrotechnics, Signals and Systems, 1150 vol 9, no 3, pp. 18-26, DOI: 10.11601/ijates.v9i3.291, 1151 2020, . 1154 [LEN2021] Lencse, G., "Design and Implementation of a Software 1155 Tester for Benchmarking Stateless NAT64 Gateways", IEICE 1156 Transactions on Communications, DOI: 1157 10.1587/transcom.2019EBN0010, 2021, 1158 . 1161 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation 1162 schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp. 1163 1078-1084, DOI:10.1587/transcom.E93.B.10, May 2010, 1164 . 1167 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 1168 consumption of the NAT64 IPv6 transition 1169 technology", Proc. 37th Internat. Conf. on 1170 Telecommunications and Signal Processing (TSP 2014), 1171 Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July 1172 2014. 1174 [SIITperf] 1175 Lencse, G., "Siitperf: an RFC 8219 compliant SIIT 1176 (stateless NAT64) tester", November 2019, 1177 . 1179 Appendix A. Change Log 1181 A.1. 01 - 02 1183 o Ian Farrer has joined us as an author. 1185 o Restructuring: the description of the five IPv4aaS technologies 1186 was moved to a separate section. 1188 o More details and figures were added to the description of the five 1189 IPv4aaS technologies. 1191 o Section titled "High-level Architectures and their Consequences" 1192 has been completely rewritten. 1194 o Several additions/clarification throughout Section titled 1195 "Detailed Analysis". 1197 o Section titled "Performance Analysis" was dropped due to lack of 1198 results yet. 1200 o Word based text ported to XML. 1202 o Further text cleanups, added text on state sync and load 1203 balancing. Additional comments inline that should be considered 1204 for future updates. 1206 A.2. 02 - 03 1208 o The suggestions of Mohamed Boucadair are incorporated. 1210 o New considerations regarding possible optimizations. 1212 A.3. 03 - 04 1214 o Section titled "Performance Analysis" was added. It mentions our 1215 new benchmarking tool, siitperf, and highlights our plans. 1217 o Some references were updated or added. 1219 A.4. 04 - 05 1221 o Some references were updated or added. 1223 A.5. 05 - 06 1225 o Some references were updated or added. 1227 Authors' Addresses 1229 Gabor Lencse 1230 Budapest University of Technology and Economics 1231 Magyar Tudosok korutja 2. 1232 Budapest H-1117 1233 Hungary 1235 Email: lencse@hit.bme.hu 1237 Jordi Palet Martinez 1238 The IPv6 Company 1239 Molino de la Navata, 75 1240 La Navata - Galapagar, Madrid 28420 1241 Spain 1243 Email: jordi.palet@theipv6company.com 1244 URI: http://www.theipv6company.com/ 1246 Lee Howard 1247 Retevia 1248 9940 Main St., Suite 200 1249 Fairfax, Virginia 22031 1250 USA 1252 Email: lee@asgard.org 1253 Richard Patterson 1254 Sky UK 1255 1 Brick Lane 1256 London EQ 6PU 1257 United Kingdom 1259 Email: richard.patterson@sky.uk 1261 Ian Farrer 1262 Deutsche Telekom AG 1263 Landgrabenweg 151 1264 Bonn 53227 1265 Germany 1267 Email: ian.farrer@telekom.de