idnits 2.17.1 draft-lmhp-v6ops-transition-comparison-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The 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 (July 6, 2019) is 1755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6050' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC6147' is defined on line 918, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-nat64-deployment-06 == Outdated reference: A later version (-04) exists of draft-palet-v6ops-464xlat-opt-cdn-caches-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: January 7, 2020 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 July 6, 2019 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-lmhp-v6ops-transition-comparison-03 17 Abstract 19 Several IPv6 transition technologies have been developed to provide 20 customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only 21 access and/or core network. All these technologies have their 22 advantages and disadvantages, and depending on existing topology, 23 skills, strategy and other preferences, one of these technologies may 24 be the most appropriate solution for a network operator. 26 This document examines the five most prominent IPv4aaS technologies 27 considering a number of different aspects to provide network 28 operators with an easy to use reference to assist in selecting the 29 technology that best suits their needs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 9 77 3.4. CE Provisioning Considerations . . . . . . . . . . . . . 10 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 . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.8. Optimization for IPv4-only devices/applications . . . . . 18 95 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 100 8.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 102 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 As the deployment of IPv6 becomes more prevalent, it follows that 109 network operators will move to building single-stack IPv6 core and 110 access networks to simplify network planning and operations. 111 However, providing customers with IPv4 services continues to be a 112 requirement for the foreseeable future. To meet this need, the IETF 113 has standardized a number of different IPv4aaS technologies for this 114 [LEN2017] based on differing requirements and deployment scenarios. 116 The number of technologies that have been developed makes it time 117 consuming for a network operator to identify the most appropriate 118 mechanism for their specific deployment. This document provides a 119 comparative analysis of the most commonly used mechanisms to assist 120 operators with this problem. 122 Five different IPv4aaS solutions are considered. The following IPv6 123 transition technologies are covered: 125 1. 464XLAT [RFC6877] 127 2. Dual Stack Lite [RFC6333] 129 3. lw4o6 (Lightweight 4over6) [RFC7596] 131 4. MAP-E [RFC7597] 133 5. MAP-T [RFC7599] 135 We note that [RFC6180] gives guidelines for using IPv6 transition 136 mechanisms during IPv6 deployment addressing a much broader topic, 137 whereas this document focuses on a small part of it. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2. Overview of the Technologies 149 The following sections introduce the different technologies analyzed 150 in this document, describing some of their most important 151 characteristics. 153 2.1. 464XLAT 155 464XLAT is a single/dual translation model, which uses a customer- 156 side translator (CLAT) located in the customer's device to perform 157 stateless NAT64 translation [RFC7915] (more precisely, stateless 158 NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). 159 IPv4-embedded IPv6 addresses [RFC6052] are used for both source and 160 destination addresses. Commonly, a /96 prefix (either the 161 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 162 as the IPv6 destination for the IPv4-embedded client traffic. 164 In the operator's network, the provider-side translator (PLAT) 165 performs stateful NAT64 [RFC6146] to translate the traffic. The 166 destination IPv4 address is extracted from the IPv4-embedded IPv6 167 packet destination address and the source address is from a pool of 168 public IPv4 addresses. 170 Alternatively, when a dedicated /64 is not available for translation, 171 the CLAT device uses a stateful NAT44 translation before the 172 stateless NAT46 translation. 174 Note that we generally do not see state close to the end-user as 175 equally problematic as state in the middle of the network. 177 In typical deployments, 464XLAT is used together with DNS64, see 178 Section 3.1.2 of [I-D.ietf-v6ops-nat64-deployment]. When an 179 IPv6-only client or application communicates with an IPv4-only 180 server, the DNS64 server returns the IPv4-embedded IPv6 address of 181 the IPv4-only server. In this case, the IPv6-only client sends out 182 IPv6 packets, thus CLAT functions as an IPv6 router and the PLAT 183 performs a stateful NAT64 for these packets. In this case, there is 184 a single translation. 186 Alternatively, one can say that the DNS64 + stateful NAT64 is used to 187 carry the traffic of the IPv6-only client and the IPv4-only server, 188 and the CLAT is used only for the IPv4 traffic from applications or 189 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 191 Private +----------+ Translated +----------+ _______ 192 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 193 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 194 |Device|<-------| NAT46 |<------------| NAT64 | (________) 195 +------+ +----------+ ^ +----------+ 196 | 197 Operator IPv6 198 network 200 Figure 1: Overview of the 464XLAT architecture 202 Note: in mobile networks, CLAT is commonly implemented in the user's 203 equipment (UE or smartphone). 205 2.2. Dual-Stack Lite 207 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 208 transition mechanisms to be developed. DS-Lite uses a 'Basic 209 Broadband Bridging' (B4) function in the customer's CE router that 210 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 211 service-provider network to a centralized 'Address Family Transition 212 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 213 4in6 traffic and translates the IPv4 payload to public IPv4 source 214 address using a stateful NAPT44 function. 216 +-------------+ 217 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 218 +------+ IPv4 | B4 | tunnel |------+------+ _______ 219 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 220 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 221 +------+ +----------+ ^ |Decap.| 44 | (________) 222 | +------+------+ 223 Operator IPv6 224 network 226 Figure 2: Overview of the DS-Lite architecture 228 2.3. Lightweight 4over6 230 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 231 difference is that the stateful NAPT44 function is relocated from the 232 centralized AFTR to the customer's B4 element (called a lwB4). The 233 AFTR (called a lwAFTR) function therefore only performs A+P routing 234 and 4in6 encapsulation/decapsulation. 236 Routing to the correct client and IPv4 address sharing is achieved 237 using the Address + Port (A+P) model [RFC6346] of provisioning each 238 lwB4 with a unique tuple of IPv4 address unique range of layer-4 239 ports. The client uses these for NAPT44. 241 The lwAFTR implements a binding table, which has a per-client entry 242 linking the customer's source IPv4 address and allocated range of 243 layer-4 ports to their IPv6 tunnel endpoint address. The binding 244 table allows egress traffic from customers to be validated (to 245 prevent spoofing) and ingress traffic to be correctly encapsulated 246 and forwarded. As there needs to be a per-client entry, an lwAFTR 247 implementation needs to be optimized for performing a per-packet 248 lookup on the binding table. 250 Direct communication between two lwB4s is performed by hair-pinning 251 traffic through the lwAFTR. 253 +-------------+ +----------+ 254 Private | lwB4 | IPv4-in-IPv6| Stateless| 255 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 256 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 257 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 258 +------+ | 44 |Decap.| ^ | routing) | (________) 259 +------+------+ | +----------+ 260 Operator IPv6 261 network 263 Figure 3: Overview of the lw4o6 architecture 265 2.4. MAP-E 267 MAP-E uses a stateless algorithm to embed portions of the customer's 268 allocated IPv4 address (or part of an address with A+P routing) into 269 the IPv6 prefix delegated to the client. This allows for large 270 numbers of clients to be provisioned using a single MAP rule (called 271 a MAP domain). The algorithm also allows for direct IPv4 peer-to- 272 peer communication between hosts provisioned with common MAP rules. 274 The CE (Customer-Edge) router typically performs stateful NAPT44 275 [RFC2663] to translate the private IPv4 source addresses and source 276 ports into an address and port range defined by applying the MAP rule 277 applied to the delegated IPv6 prefix. The client address/port 278 allocation size is a design parameter. The CE router then 279 encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it 280 directly to another host in the MAP domain (for peer-to-peer) or to a 281 Border Router (BR) if the IPv4 destination is not covered in one of 282 the CE's MAP rules. 284 The MAP BR is provisioned with the set of MAP rules for the MAP 285 domains it serves. These rules determine how the MAP BR is to 286 decapsulate traffic that it receives from client, validating the 287 source IPv4 address and layer 4 ports assigned, as well as how to 288 calculate the destination IPv6 address for ingress IPv4 traffic. 290 +-------------+ +----------+ 291 Private | MAP CE | IPv4-in-IPv6| Stateless| 292 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 293 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 294 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 295 +------+ | 44 |Decap.| ^ | routing) | (________) 296 +------+------+ | +----------+ 297 Operator IPv6 298 network 300 Figure 4: Overview of the MAP-E architecture 302 2.5. MAP-T 304 MAP-T uses the same mapping algorithm as MAP-E. The major difference 305 is that double stateless translation (NAT46 in the CE and NAT64 in 306 the BR) is used to traverse the ISP's IPv6 single-stack network. 307 MAP-T can also be compared to 464XLAT when there is a double 308 translation. 310 A MAP CE typically performs stateful NAPT44 to translate traffic to a 311 public IPv4 address and port-range calculated by applying the 312 provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) 313 to the delegated IPv6 prefix. The CE then performs stateless 314 translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned 315 with the same BMR as the client, enabling the received IPv6 traffic 316 to be statelessly NAT64 translated back to the public IPv4 source 317 address used by the client. 319 Using translation instead of encapsulation also allows IPv4-only 320 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 321 have IPv4-embedded IPv6 addresses. 323 +-------------+ +----------+ 324 Private | MAP CE | Translated | Stateless| 325 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 326 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 327 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 328 +------+ | 44 |NAT46 | ^ | routing) | (________) 329 +------+------+ | +----------+ 330 Operator IPv6 331 network 333 Figure 5: Overview of the MAP-T architecture 335 3. High-level Architectures and their Consequences 337 3.1. Service Provider Network Traversal 339 For the data-plane, there are two approaches for traversing the IPv6 340 provider network: 342 o 4-6-4 translation 344 o 4-in-6 encapsulation 346 +--------------+---------+---------+-------+-------+-------+ 347 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 348 +--------------+---------+---------+-------+-------+-------+ 349 | 4-6-4 trans. | X | | | | X | 350 | 4-6-4 encap. | | X | X | X | | 351 +--------------+---------+---------+-------+-------+-------+ 353 Table 1: Available Traversal Mechanisms 355 In the scope of this document, all of the encapsulation based 356 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 357 tunneling mechanism which does not require any additional tunnel 358 headers. 360 It should be noted that both of these approaches result in an 361 increase in the size of the packet that needs to be transported 362 across the operator's network when compared to native IPv4. 4-6-4 363 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 364 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 365 overhead (an IPv6 header is prepended to the IPv4 header). 367 The increase in packet size can become a significant problem if there 368 is a link with a smaller MTU in the traffic path. This may result in 369 traffic needing to be fragmented at the ingress point to the IPv6 370 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 371 also result in the need to implement buffering and fragment re- 372 assembly in the BR node. 374 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 375 these mechanisms: It is strongly recommended that the MTU in the 376 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 377 side interface be set so that no fragmentation occurs within the 378 boundary of the IPv6-only domain. 380 3.2. Network Address Translation 382 For the high-level solution of IPv6 service provider network 383 traversal, MAP-T uses double stateless translation. First at the CE 384 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 385 service provider network. 387 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 388 or single translation (stateful NAT64), depending on different 389 factors, such as the use of DNS by the applications and the 390 availability of a DNS64 function (in the host or in the service 391 provider network). For deployment guidelines, please refer to 392 [I-D.ietf-v6ops-nat64-deployment]. 394 The first step for the double translation mechanisms is a stateless 395 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 396 Translation Algorithm) [RFC7915], which does not translate IPv4 397 header options and/or multicast IP/ICMP packets. With encapsulation- 398 based technologies the header is transported intact and multicast can 399 also be carried. 401 Single and double translation results in native IPv6 traffic with a 402 layer-4 next-header. The fields in these headers can be used for 403 functions such as hashing across equal-cost multipaths or ACLs. For 404 encapsulation, there is an IPv6 header followed by an IPv4 header. 405 This results in less entropy for hashing algorithms, and may mean 406 that devices in the traffic path that perform header inspection (e.g. 407 router ACLs or firewalls) require the functionality to look into the 408 payload header. 410 Solutions using double translation can only carry port-aware IP 411 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 412 address sharing (please refer to Section 4.3 for more details). 413 Encapsulation based solutions can carry any other protocols over IP, 414 too. 416 An in-depth analysis of stateful NAT64 can be found in [RFC6889]. 418 3.3. IPv4 Address Sharing 420 As public IPv4 address exhaustion is a common motivation for 421 deploying IPv6, transition technologies need to provide a solution 422 for allowing public IPv4 address sharing. 424 In order to fulfill this requirement, a stateful NAPT function is a 425 necessary function in all of the mechanisms. The major 426 differentiator is where in the architecture this function is located. 428 The solutions compared by this document fall into two categories: 430 o CGN-based approaches (DS-Lite, 464XLAT) 432 o A+P-based approaches (lw4o6, MAP-E, MAP-T) 434 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 435 the NAPT44 function and maintains per-session state for all of the 436 active client's traffic. The customer's device does not require per- 437 session state for NAPT. 439 In the A+P-based model, a device (usually a CE) performs stateful 440 NAPT44 and maintains per-session state only co-located devices, e.g. 441 in the customer's home network. Here, the centralized network 442 function (lwAFTR or BR) only needs to perform stateless 443 encapsulation/decapsulation or NAT64. 445 Issues related to IPv4 address sharing mechanisms are described in 446 [RFC6269] and should also be considered. 448 The address sharing efficiency of the five technologies is 449 significantly different, it is discussed in Section 4.2 451 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 452 sharing, see the details in Section 4.3. However, in that case, 453 there is no advantage in terms of public IPv4 address saving. In the 454 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 456 Conversely, both MAP-E and MAP-T may be configured to provide more 457 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 458 /32) to customers. 460 Dynamic DNS issues in address-sharing contexts and their possible 461 solutions using PCP (Port Control Protocol) are discussed in detail 462 in [RFC7393]. 464 3.4. CE Provisioning Considerations 466 All of the technologies require some provisioning of customer 467 devices. The table below shows which methods currently have 468 extensions for provisioning the different mechanisms. 470 +------------------+-----------+---------+-------+-------+-------+ 471 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 472 +------------------+-----------+---------+-------+-------+-------+ 473 | DHCPv6 [RFC8415] | | X | X | X | X | 474 | RADIUS Attr. | | X | X | X | X | 475 | TR-69 | | X | | X | X | 476 | DNS64 [RFC7050] | X | | | | | 477 | YANG [RFC7950] | [RFC8512] | X | X | X | X | 478 | DHCP4o6 | | | X | X | | 479 +------------------+-----------+---------+-------+-------+-------+ 481 Table 2: Available Provisioning Mechanisms 483 3.5. Support for Multicast 485 The solutions covered in this document are all intended for unicast 486 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 487 multicast traffic over an IPv6 multicast network. This could be 488 deployed in parallel to any of the operator's chosen IPv4aaS 489 mechanism. 491 4. Detailed Analysis 493 4.1. Architectural Differences 495 4.1.1. Basic Comparison 497 The five IPv4aaS technologies can be classified into 2x2=4 categories 498 on the basis of two aspects: 500 o Technology used for service provider network traversal. It can be 501 single/double translation or encapsulation. 503 o Presence or absence of NAPT44 per-flow state in the operator 504 network. 506 +-----------------------+---------+---------+-------+-------+-------+ 507 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 508 +-----------------------+---------+---------+-------+-------+-------+ 509 | 4-6-4 trans. | X | | | | X | 510 | 4-in-4 encap. | | X | X | X | | 511 | Per-flow state in op. | X | X | | | | 512 | network | | | | | | 513 +-----------------------+---------+---------+-------+-------+-------+ 515 Table 3: Available Provisioning Mechanisms 517 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 519 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 520 respectively. This may cause scalability issues for the number of 521 clients or volume of traffic, but does not impose a limitation on the 522 number of ports per user, as they can be allocated dynamically on- 523 demand and the allocation policy can be centrally managed/adjusted. 525 A+P based mechanisms (Lw4o6, MAP-E, and MAP-T) avoid using NAPT in 526 the service provider network. However, this means that the number of 527 ports provided to each user (and hence the effective IPv4 address 528 sharing ratio) must be pre-provisioned to the client. 530 Changing the allocated port ranges with A+P based technologies, 531 requires more planning and is likely to involve re-provisioning both 532 hosts and operator side equipment. It should be noted that due to 533 the per-customer binding table entry used by lw4o6, a single customer 534 can be re-provisioned (e.g., if they request a full IPv4 address) 535 without needing to change parameters for a number of customers as in 536 a MAP domain. 538 It is also worth noting that there is a direct relationship between 539 the efficiency of customer public port-allocations and the 540 corresponding logging overhead that may be necessary to meet data- 541 retention requirements. This is considered in Section 4.7 below. 543 Determining the optimal number of ports for a fixed port set is not 544 an easy task, and may also be impacted by local regulatory law, which 545 may define a maximum number of users per IP address, and consequently 546 a minimum number of ports per user. 548 On the one hand, the "lack of ports" situation may cause serious 549 problems in the operation of certain applications. For example, 550 Miyakawa has demonstrated the consequences of the session number 551 limitation due to port number shortage on the example of Google Maps 552 [MIY2010]. When the limit was 15, several blocks of the map were 553 missing, and the map was unusable. This study also provided several 554 examples for the session numbers of different applications (the 555 highest one was Apple's iTunes: 230-270 ports). 557 The port number consumption of different applications is highly 558 varying and e.g. in the case of web browsing it depends on several 559 factors, including the choice of the web page, the web browser, and 560 sometimes even the operating system [REP2014]. For example, under 561 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 562 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 563 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 565 There may be several users behind a CE router, especially in the 566 broadband case (e.g. Internet is used by different members of a 567 family simultaneously), so sufficient ports must be allocated to 568 avoid impacting user experience. 570 Furthermore, assigning too many ports per CE router will result in 571 waste of public IPv4 addresses, which is a scarce and expensive 572 resource. Clearly this is a big advantage in the case of 464XLAT 573 where they are dynamically managed, so that the number of IPv4 574 addresses for the sharing-pool is smaller while the availability of 575 ports per user don't need to be pre-defined and is not a limitation 576 for them. 578 There is a direct tradeoff between the optimization of client port 579 allocations and the associated logging overhead. Section 4.7 580 discusses this in more depth. 582 We note that common CE router NAT44 implementations utilizing 583 Netfilter, multiplexes active sessions using a 3-tuple (source 584 address, destination address, and destination port). This means that 585 external source ports can be reused for unique internal source and 586 destination address and port sessions. It is also noted, that 587 Netfilter cannot currently make use of multiple source port ranges 588 (i.e. several blocks of ports distributed across the total port space 589 as is common in MAP deployments), this may influence the design when 590 using stateless technologies. 592 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 593 therefore be much more efficient in terms of port allocation and thus 594 public IP address saving. The price is the stateful operation in the 595 service provider network, which allegedly does not scale up well. It 596 should be noticed that in many cases, all those factors may depend on 597 how it is actually implemented. 599 XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX 601 We note that some CGN-type solutions can allocate ports dynamically 602 "on the fly". Depending on configuration, this can result in the 603 same customer being allocated ports from different source addresses. 604 This can cause operational issues for protocols and applications that 605 expect multiple flows to be sourced from the same address. E.g., 606 ECMP hashing, STUN, gaming, content delivery networks. However, it 607 should be noticed that this is the same problem when a network has a 608 NAT44 with multiple public IPv4 addresses, or even when applications 609 in a dual-stack case, behave wrongly if happy eyeballs is flapping 610 the flow address between IPv4 and IPv6. 612 The consequences of IPv4 address sharing [RFC6269] may impact all 613 five technologies. However, when ports are allocated statically, 614 more customers may get ports from the same public IPv4 address, which 615 may results in negative consequences with higher probability, e.g. 616 many applications and service providers (Sony PlayStation Network, 617 OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that 618 they are used for address sharing. 620 Both cases are, again, implementation dependent. 622 We note that although it is not of typical use, one can do 623 deterministic, stateful NAT and reserve a fixed set of ports for each 624 customer, as well. 626 4.3. Support for Public Server Operation 628 Mechanisms that rely on operator side per-flow state do not, by 629 themselves, offer a way for customers to present services on publicly 630 accessible layer-4 ports. 632 Port Control Protocol (PCP) [RFC6877] provides a mechanism for a 633 client to request an external public port from a CGN device. For 634 server operation, it is required with NAT64/464XLAT, and it is 635 supported in some DS-Lite AFTR implementations. 637 A+P based mechanisms distribute a public IPv4 address and restricted 638 range of layer-4 ports to the client. In this case, it is possible 639 for the user to configure their device to offer a publicly accessible 640 server on one of their allocated ports. It should be noted that 641 commonly operators do not assign the Well-Known-Ports to users 642 (unless they are allocating a full IPv4 address), so the user will 643 need to run the service on an allocated port, or configure port 644 translation. 646 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 647 full IPv4 address, allowing exclusive use of all ports, and non-port- 648 based layer 4 protocols. Thus, they may also be used to support 649 server/services operation on their default ports. However, when 650 public IPv4 addresses are assigned to the CE router without address 651 sharing, obviously there is no advantage in terms of IPv4 public 652 addresses saving. 654 It is also possible to configure specific ports mapping in 464XLAT/ 655 NAT64 using EAMT [RFC7757], which means that only those ports are 656 "lost" from the pool of addresses, so there is a higher maximization 657 of the total usage of IPv4/port resources. 659 4.4. Support and Implementations 661 4.4.1. OS Support 663 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 664 (including Android), Windows Mobile, Chrome OS and iOS, but at the 665 time of writing is not available in MacOS. 667 The remaining four solutions are commonly deployed as functions in 668 the CE device only, however in general, except DS-Lite, the vendors 669 support is poor. 671 The OpenWRT Linux based open-source OS designed for CE devices offers 672 a number of different 'opkg' packages as part of the distribution: 674 o '464xlat' enables support for 464XLAT CLAT functionality 676 o 'ds-lite' enables support for DSLite B4 functionality 678 o 'map' enables support for MAP-E and lw4o6 CE functionality 680 o 'map-t' enables support for MAP-T CE functionality 682 For the operator side functionality, some free open-source 683 implementations exist: 685 CLAT, NAT64, EAMT: http://www.jool.mx 687 MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io 688 https://gerrit.fd.io/r/#/admin/projects/ 690 lwAFTR: https://github.com/Igalia/snabb 692 DSLite AFTR: https://www.isc.org/downloads/ 694 4.4.2. Support in Cellular and Broadband Networks 696 Several cellular networks use 464XLAT, whereas we are not aware of 697 any deployment of the four other technologies in cellular networks, 698 as they are not implemented in UE devices. 700 In broadband networks, there are some deployments of 464XLAT, MAP-E 701 and MAP-T. lw4o6 and DS-Lite have more deployments, with DS-Lite 702 being the most common, but lw4o6 taking over in the last years. 704 4.4.3. Implementation Code Sizes 706 As hint to the relative complexity of the mechanisms, the following 707 code sizes are reported from the OpenWRT implementations of each 708 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 709 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 710 (https://openwrt.org/packages/start). 712 We note that the support for all five technologies requires much less 713 code size than the total sum of the above quantities, because they 714 contain a lot of common functions (data plane is shared among several 715 of them). 717 4.5. Typical Deployment and Traffic Volume Considerations 719 4.5.1. Deployment Possibilities 721 Theoretically, all five IPv4aaS technologies could be used together 722 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 723 the CE router would treat the traffic between an IPv6-only client and 724 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 725 gateway would do a single translation, thus offloading this kind of 726 traffic from the IPv4aaS technology. The cost of this solution would 727 be the need for deploying also DNS64 + stateful NAT64. 729 However, this has not been implemented in clients or actual 730 deployments, so only 464XLAT always uses this optimization and the 731 other four solutions do not use it at all. 733 4.5.2. Cellular Networks with 464XLAT 735 Actual figures from existing deployments, show that the typical 736 traffic volumes in an IPv6-only cellular network, when 464XLAT 737 technology is used together with DNS64, are: 739 o 75% of traffic is IPv6 end-to-end (no translation) 741 o 24% of traffic uses DNS64 + NAT64 (1 translation) 743 o Less than 1% of traffic uses the CLAT in addition to NAT64 (2 744 translations), due to an IPv4 socket and/or IPv4 literal. 746 Without using DNS64, 25% of the traffic would undergo double 747 translation. 749 4.6. Load Sharing 751 If multiple network-side devices are needed as PLAT/AFTR/BR for 752 capacity, then there is a need for a load sharing mechanism. ECMP 753 (Equal-Cost Multi-Path) load sharing can be used for all 754 technologies, however stateful technologies will be impacted by 755 changes in network topology or device failure. 757 Technologies utilizing DNS64 can also distribute load across PLAT/ 758 AFTR devices, evenly or unevenly, by using different prefixes. 759 Different network specific prefixes can be distributed for 760 subscribers in appropriately sized segments (like split-horizon DNS, 761 also called DNS views). 763 Stateless technologies, due to the lack of per-flow state, can make 764 use of anycast routing for load sharing and resiliency across 765 network-devices, both ingress and egress; flows can take asymmetric 766 paths through the network, i.e., in through one lwAFTR/BR and out via 767 another. 769 Mechanisms with centralized NAPT44 state have a number of challenges 770 specifically related to scaling and resilience. As the total amount 771 of client traffic exceeds the capacity of a single CGN instance, 772 additional nodes are required to handle the load. As each CGN 773 maintains a stateful table of active client sessions, this table may 774 need to be syncronized between CGN instances. This is necessary for 775 two reasons: 777 o To prevent all active customer sessions being dropped in event of 778 a CGN node failure. 780 o To ensure a matching state table entry for an active session in 781 the event of asymmetric routing through different egress and 782 ingress CGN nodes. 784 4.7. Logging 786 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 787 address and port combination will vary over time, therefore, logging 788 is necessary to meet data retention laws. Each entry in the PLAT/ 789 AFTR's generates a logging entry. As discussed in Section 4.2, a 790 client may open hundreds of sessions during common tasks such as web- 791 browsing, each of which needs to be logged so the overall logging 792 burden on the network operator is significant. In some countries, 793 this level of logging is required to comply with data retention 794 legislation. 796 One common optimization available to reduce the logging overhead is 797 the allocation of a block of ports to a client for the duration of 798 their session. This means that logging entry only needs to be made 799 when the client's port block is released, which dramatically reducing 800 the logging overhead. This comes as the cost of less efficient 801 public address sharing as clients need to be allocated a port block 802 of a fixed size regardless of the actual number of ports that they 803 are using. 805 Stateless technologies that pre-allocate the IPv4 addresses and ports 806 only require that copies of the active MAP rules (for MAP-E and MAP- 807 T), or binding-table (for lw4o6) are retained along with timestamp 808 information of when they have been active. Support tools (e.g., 809 those used to serve data retention requests) may need to be updated 810 to be aware of the mechanism in use (e.g., implementing the MAP 811 algorithm so that IPv4 information can be linked to the IPv6 prefix 812 delegated to a client). As stateless technologies do not have a 813 centralized stateful element which customer traffic needs to pass 814 through, so if data retention laws mandate per-session logging, there 815 is no simple way of meeting this requirement with a stateless 816 technology alone. Thus a centralized NAPT44 model may be the only 817 way to meet this requirement. 819 Deterministic CGN [RFC7422] was proposed as a solution to reduce the 820 resource consumption of logging. 822 4.8. Optimization for IPv4-only devices/applications 824 When IPv4-only devices or applications are behind a CE connected with 825 IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, 826 be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 827 E) and will reach the IPv4 address of the destination, even if that 828 service supports dual-stack. This means that the traffic flow will 829 cross thru the AFTR, lwAFTR or BR, depending on the specific 830 transition mechanism being used. 832 Even if those services are directly connected to the operator network 833 (for example, CDNs, caches), or located internally (such as VoIP, 834 etc.), it is not possible to avoid that overhead. 836 However, in the case of those mechanism that use a NAT46 function, in 837 the CE (464XLAT and MAP-T), it is possible to take advantage of 838 optimization functionalities, such as the ones described in 839 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 841 Using those optimizations, because the NAT46 has already translated 842 the IPv4-only flow to IPv6, and the services are dual-stack, they can 843 be reached without the need to translate them back to IPv4. 845 5. Acknowledgements 847 The authors would like to thank Ole Troan for his thorough review of 848 this draft and acknowledge the inputs of Mark Andrews, Edwin 849 Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore 850 Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, 851 Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and TBD ... 853 6. IANA Considerations 855 This document does not make any request to IANA. 857 7. Security Considerations 859 According to the simplest model, the number of bugs is proportional 860 to the number of code lines. Please refer to Section 4.4.3 for code 861 sizes of CE implementations. 863 For all five technologies, the CE device should contain a DNS proxy. 864 However, the user may change DNS settings. If it happens and lw4o6, 865 MAP-E and MAP-T are used with significantly restricted port set, 866 which is required for an efficient public IPv4 address sharing, the 867 entropy of the source ports is significantly lowered (e.g. from 16 868 bits to 10 bits, when 1024 port numbers are assigned to each 869 subscriber) and thus these technologies are theoretically less 870 resilient against cache poisoning, see [RFC5452]. However, an 871 efficient cache poisoning attack requires that the subscriber 872 operates an own caching DNS server and the attack is performed in the 873 service provider network. Thus, we consider the chance of the 874 successful exploitation of this vulnerability as low. 876 An in-depth security analysis of all five IPv6 transition 877 technologies and their most prominent free software implementations 878 according to the methodology defined in [LEN2018] is planned. 880 8. References 882 8.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 890 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 891 December 1998, . 893 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 894 Translator (NAT) Terminology and Considerations", 895 RFC 2663, DOI 10.17487/RFC2663, August 1999, 896 . 898 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 899 Resilient against Forged Answers", RFC 5452, 900 DOI 10.17487/RFC5452, January 2009, 901 . 903 [RFC6050] Drage, K., "A Session Initiation Protocol (SIP) Extension 904 for the Identification of Services", RFC 6050, 905 DOI 10.17487/RFC6050, November 2010, 906 . 908 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 909 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 910 DOI 10.17487/RFC6052, October 2010, 911 . 913 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 914 NAT64: Network Address and Protocol Translation from IPv6 915 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 916 April 2011, . 918 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 919 Beijnum, "DNS64: DNS Extensions for Network Address 920 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 921 DOI 10.17487/RFC6147, April 2011, 922 . 924 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 925 Transition Mechanisms during IPv6 Deployment", RFC 6180, 926 DOI 10.17487/RFC6180, May 2011, 927 . 929 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 930 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 931 DOI 10.17487/RFC6269, June 2011, 932 . 934 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 935 Stack Lite Broadband Deployments Following IPv4 936 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 937 . 939 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 940 the IPv4 Address Shortage", RFC 6346, 941 DOI 10.17487/RFC6346, August 2011, 942 . 944 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 945 Combination of Stateful and Stateless Translation", 946 RFC 6877, DOI 10.17487/RFC6877, April 2013, 947 . 949 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 950 "Analysis of Stateful 64 Translation", RFC 6889, 951 DOI 10.17487/RFC6889, April 2013, 952 . 954 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 955 the IPv6 Prefix Used for IPv6 Address Synthesis", 956 RFC 7050, DOI 10.17487/RFC7050, November 2013, 957 . 959 [RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, 960 "Using the Port Control Protocol (PCP) to Update Dynamic 961 DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, 962 . 964 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 965 and O. Vautrin, "Deterministic Address Mapping to Reduce 966 Logging in Carrier-Grade NAT Deployments", RFC 7422, 967 DOI 10.17487/RFC7422, December 2014, 968 . 970 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 971 Farrer, "Lightweight 4over6: An Extension to the Dual- 972 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 973 July 2015, . 975 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 976 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 977 Port with Encapsulation (MAP-E)", RFC 7597, 978 DOI 10.17487/RFC7597, July 2015, 979 . 981 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 982 and T. Murakami, "Mapping of Address and Port using 983 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 984 2015, . 986 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 987 Mappings for Stateless IP/ICMP Translation", RFC 7757, 988 DOI 10.17487/RFC7757, February 2016, 989 . 991 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 992 "IP/ICMP Translation Algorithm", RFC 7915, 993 DOI 10.17487/RFC7915, June 2016, 994 . 996 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 997 RFC 7950, DOI 10.17487/RFC7950, August 2016, 998 . 1000 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1001 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1002 over an IPv6 Multicast Network", RFC 8114, 1003 DOI 10.17487/RFC8114, March 2017, 1004 . 1006 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1007 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1008 May 2017, . 1010 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1011 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1012 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1013 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1014 . 1016 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1017 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1018 Address Translation (NAT) and Network Prefix Translation 1019 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1020 . 1022 8.2. Informative References 1024 [I-D.ietf-v6ops-nat64-deployment] 1025 Palet, J., "Additional NAT64/464XLAT Deployment Guidelines 1026 in Operator and Enterprise Networks", draft-ietf-v6ops- 1027 nat64-deployment-06 (work in progress), May 2019. 1029 [I-D.palet-v6ops-464xlat-opt-cdn-caches] 1030 Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- 1031 palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress), 1032 June 2019. 1034 [LEN2017] Lencse, G. and Y. Kadobayashi, "Survey of IPv6 Transition 1035 Technologies for Security Analysis", IEICE Communications 1036 Society Internet Architecture Workshop, Tokyo, Japan, 1037 IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24, Aug 1038 2017, . 1041 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 1042 identification of potential security issues of different 1043 IPv6 transition technologies: Threat analysis of DNS64 and 1044 stateful NAT64", Computers & Security (Elsevier), vol. 1045 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 1046 Aug 2018, . 1049 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", 1050 IEICE Trans. Commun., vol.E93-B, no.5, pp. 1078-1084, 1051 DOI:10.1587/transcom.E93.B.10, May 2010, 1052 . 1055 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 1056 consumption of the NAT64 IPv6 transition technology", 1057 Proc. 37th Internat. Conf. on Telecommunications and 1058 Signal Processing (TSP 2014), Berlin, Germany, DOI: 1059 10.1109/TSP.2015.7296411, July 2014. 1061 Appendix A. Change Log 1063 A.1. 01 - 02 1065 o Ian Farrer has joined us as an author. 1067 o Restructuring: the description of the five IPv4aaS technologies 1068 was moved to a separate section. 1070 o More details and figures were added to the description of the five 1071 IPv4aaS technologies. 1073 o Section titled "High-level Architectures and their Consequences" 1074 has been completely rewritten. 1076 o Several additions/clarification throughout Section titled 1077 "Detailed Analysis". 1079 o Section titled "Performance Analysis" was dropped due to lack of 1080 results yet. 1082 o Word based text ported to XML. 1084 o Further text cleanups, added text on state sync and load 1085 balancing. Additional comments inline that should be considered 1086 for future updates. 1088 A.2. 02 - 03 1090 o The suggestions of Mohamed Boucadair are incorporated. 1092 o New considerations regarding possible optimizations. 1094 Authors' Addresses 1096 Gabor Lencse 1097 Budapest University of Technology and Economics 1098 Magyar Tudosok korutja 2. 1099 Budapest H-1117 1100 Hungary 1102 Email: lencse@hit.bme.hu 1104 Jordi Palet Martinez 1105 The IPv6 Company 1106 Molino de la Navata, 75 1107 La Navata - Galapagar, Madrid 28420 1108 Spain 1110 Email: jordi.palet@theipv6company.com 1111 URI: http://www.theipv6company.com/ 1113 Lee Howard 1114 Retevia 1115 9940 Main St., Suite 200 1116 Fairfax, Virginia 22031 1117 USA 1119 Email: lee@asgard.org 1120 Richard Patterson 1121 Sky UK 1122 1 Brick Lane 1123 London EQ 6PU 1124 United Kingdom 1126 Email: richard.patterson@sky.uk 1128 Ian Farrer 1129 Deutsche Telekom AG 1130 Landgrabenweg 151 1131 Bonn 53227 1132 Germany 1134 Email: ian.farrer@telekom.de