idnits 2.17.00 (12 Aug 2021) /tmp/idnits6170/draft-xie-v6ops-reqirements-multi-domain-ipv6only-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IAB-statement' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC7597' is defined on line 569, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-bess-ipv6-only-pe-design-00 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipv6-deployment-04 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-transition-comparison-02 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group C. Xie 3 Internet-Draft C. Ma 4 Intended status: Informational China Telecom 5 Expires: September 8, 2022 X. Li 6 CERNET Center/Tsinghua University 7 G. Mishra 8 Verizon Inc 9 M. Boucadair 10 Orange 11 March 7, 2022 13 Requirements to Multi-domain IPv6-only Network 14 draft-xie-v6ops-reqirements-multi-domain-ipv6only-01 16 Abstract 18 Dual-stack deployments require both IPv4 and IPv6 transfer 19 capabilities are deployed in parallel. IPv6-only is considered as 20 the ultimate stage where only IPv6 transfer capabilities are used 21 while ensuring global reachability. This document specifies 22 requirements when deploying IPv6-only in multi-domain networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 8, 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. The reason to consider multi-domain factor when implementing 62 IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Requirements from IPv6-native traffic . . . . . . . . . . . . 8 65 7. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Requirements from IPv4 service delivery . . . . . . . . . . . 10 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 12.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 IPv6 capabilities have been widely deployed during the past 10 years 78 and IPv6 traffic is growing faster than IPv4. Document 79 [I-D.ietf-v6ops-ipv6-deployment] provides an overview of IPv6 80 transition deployment status and how the transition to IPv6 is 81 progressing among network operators and enterprises. 83 When most services and networks did not support IPv6, it was 84 straightforward to keep IPv4 function running when IPv6 was 85 introduced in early stages. Which is called IPv4/IPv6 dual- 86 stack[RFC4213]. Many IPv6 deployments rely on this dual-stack 87 approach. However, dual-stack does have a few disadvantages in the 88 long run, like the duplication of the network resources and states, 89 as well as other limitations for network operation. For this reason, 90 when IPv6 usage increases to a certain limit, it would be better to 91 consider IPv6-only. Generally, running an IPv6-only network would 92 reduce operational expenditures and optimize operations as compared 93 to an IPv4/IPv6 dual-stack environment. In 2016, the IAB announced 94 that it " expects that the IETF will stop requiring IPv4 95 compatibility in new or extended protocols. Future IETF protocol 96 work will then optimize for and depend on IPv6."[IAB-statement] 97 In order to extend the service in the case of IPv4 address depletion, 98 operators need to provide IPv6 services and still keep the ability 99 for users to access the global IPv4 Internet. Therefore, IPv4 as a 100 Service (IPv4aaS) is a natural consideration for IPv6-only scheme. 101 Several IPv4 service continuity mechanisms have been designed within 102 IETF during the past twenty 103 years[I-D.ietf-v6ops-transition-comparison]. When these schemes 104 support the hosting of IPv4 service, different types of IPv4 and IPv6 105 conversion technologies are required, for example, 464XLAT[RFC6877] 106 uses stateful NAT64 translation technology, MAP-E[RFC7597]and MAP-T 107 [RFC7599] use stateless NAT64 translation. DS-Lite[RFC6333] adopts 108 AFTR-based 4over6 tunneling technology, while the backbone network 109 adopts GRE tunneling or stateless translation technology, etc. This 110 document specifies the requirements for multi-domain IPv6-only 111 network from the perspective of operators. It does not introduce any 112 new IPv6 transition mechanisms. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119] . 120 3. Terminology 122 The following terms are defined in this draft: 124 o Multi-domain IPv6-only network: An IPv6-only network which 125 consists of multiple ASes belonging to and operated by the same 126 operator. 128 o UE: User Equipment, e.g., mobile phone. 130 o CPE: Customer Premise Edge device. 132 o IXP: Internet Exchange Point. 134 o PE : Provider Edge device. 136 o IPv4-embedded IPv6 packet: IPv6 packet which is generated from 137 IPv4 packet by algorithmically mapping of the source and 138 destination IPv4 addresses to IPv6 addresses. 140 o Border gateway: A PE router which run eBGP routing protocol and 141 peering with the BGP router of external AS. 143 o Conversion point: A function which provides conversion between 144 IPv4 and IPv6 realms. 146 4. The reason to consider multi-domain factor when implementing 147 IPv6-only 149 In general, transition to IPv6-only from dual-stack means some or all 150 the IPv4 protocol instances of dual-stack network will closed 151 gradually, thereby IPv6 will become the main network-layer protocol. 152 When IPv4 is closed at the network layer, the first question is how 153 to make remaining IPv4 services running normally and users' 154 experience does not deteriorate. The deployment of IPv6-only should 155 not be based on the premise of the extinction of all IPv4-only 156 services in short time, it is very possible that some portion of the 157 Internet service will consistently be IPv4-based. In other words, 158 IPv6-only network should carry not only IPv6-capable services, but 159 also IPv4-only services. 161 [RFC5565]describes the IPv4-over-IPv6 scenario, where the network 162 core is IPv6-only and the interconnected IPv4 networks are called 163 IPv4 client networks. The P Routers (Provider Routers) in the core 164 only support IPv6, but the AFBRs support IPv4 on interfaces facing 165 IPv4 client networks and IPv6 on interfaces facing the core. The 166 routing solution defined in [RFC5565] for this scenario is to run 167 IBGP among AFBRs to exchange IPv4 routing information in the core, 168 and the IPv4 packets are forwarded from one IPv4 client network to 169 the other through a softwire using tunneling technology, such as 170 MPLS, LSP, GRE, L2TPv3, etc. 172 [RFC6992] describes a routing scenario where IPv4 packets are 173 transported over an IPv6 network, based on [RFC6145] and [RFC6052], 174 along with a separate OSPFv3 routing table for IPv4-embedded IPv6 175 routes in the IPv6 network. 177 In general, the networks of large-scale operators are composed of 178 multiple autonomous system(AS)es, different ASes may serve different 179 scenarios, such as metro network, backbone network, 4G or 5G mobile 180 core, data center network, and are often managed by different 181 departments or institutions, using different routing and security 182 policies. When introducing the IPv6-only scheme without 183 collaboration between ASes, different ASes adopt the IPv6 transition 184 approach independently, the result is that multiple IPv6-only islands 185 are connected by IPv4 links between domains. As shown in figure 1, 186 there will be more IPv4-IPv6 packet conversion gateways with 187 different functions in the network. Under this circumstance, 188 IPv4-embedded IPv6 packets need to be transformed back to IPv4 189 packets at the egress of one AS, and then back to IPv6 in the next 190 domain, and the number of conversion points will increases along with 191 the increasing of the number of ASes. Excessive IPv4-IPv6 conversion 192 gateways lead to complexity of network and CAPEX increasing. 193 Therefore, there is an urgent need for multi-domain IPv6-only 194 solutions to eliminate unnecessary conversion functions and improve 195 data forwarding efficiency. 197 +---+ +---+ +------+ 198 |UE/|--|PGW| | IPv4 | 199 |CPE| +---+ |Server| 200 +---+ | +------+ 201 | | 202 ----------- ----------- 203 /Mobile Core\ / \ 204 | Network | | IPv4 | 205 | (IPv6-only) | | Internet | 206 \ / \ / 207 ----------- ----------- 208 | | 209 +-----+ +--------+ 210 |PLAT/| |IPv4 BGP| 211 |NAT64| | Router | 212 +-----+ +--------+ 213 | IPv4 link |IPv4 link 214 | ----------- | 215 +---------+ / Backbone \ +---------+ 216 |Stateless|----| Network ----|Stateless| 217 | NAT64 | \(IPv6-only)/ | NAT64 | 218 +---------+ ----------- +---------+ 219 XLAT-1 XLAT-2 220 Figure 1: IPv6-only Independent Deployment in Multi-domain Network 222 5. Scenarios 224 This section describes scenarios where IPv4 packets are transported 225 over a multi-domain IPv6-only network. A typical model of multi- 226 domain IPv6 network is depicted in figure 2. Network 1, belonging to 227 and operated by operator A, runs IPv6 and is composed of multiple 228 inter-connected ASes, i.e., AS1, AS2 and AS3. In addition, network 1 229 provides access to different types of users, including mobile, home 230 broadband and enterprise customers, denoted by UE1, UE2 and UE3 in 231 figure 2. Routers that are outside the backbone but directly 232 attached to it are known as "Customer Edge" (CE) routers. 234 Network 1 is open, it is interworking with the external networks. 235 Operator 2 is one of the neighbor operators of Operator 1, AS4 of 236 operator 2 and AS3 of operator are interconnected through BGP 237 protocol. In order to illustrate "IPv4 As A service" , AS4 is an 238 IPv4-only network, which means that it does not run IPv6 protocol. 240 In addition, cloud services are hosted in data centers and connected 241 across multiple data centers, the edge, and public and private 242 clouds. The data center must be able to communicate across these 243 multiple sites, both on-premises and in the cloud. IPv6-only network 244 need to provide connections for cloud data center. Network 1 245 supports two connections modes of cloud data centers, the first one 246 is between cloud data center and individual users, for instance, the 247 user of CPE1 access the service hosted in DC1, the second one is the 248 connection between cloud data centers, for instance, communications 249 between DC1 and DC2. 251 The edge nodes of the Network 1 are often known as "Provider Edge" 252 (PE) routers. The term "ingress" (or "ingress PE") refers to the 253 router at which a packet enters the network, and the term "egress" 254 (or "egress PE") refers to the router at which it leaves the 255 backbone. Interior nodes are often known as "P routers". The P 256 routers in the core only support IPv6, but the PEs support IPv4 on 257 interfaces facing IPv4 client networks and IPv6 on interfaces facing 258 the core. 260 Network 1 provides transportation services for packets that originate 261 outside the network and whose destinations are outside the network. 262 These packets enter the IPv6 network at one of its "edge routers". 263 They are routed through the network to another edge router, after 264 which they leave the network and continue on their way. 266 ----- ----- 267 / \ / \ 268 | DC1 | | DC2 | 269 \ / \ / 270 ----- ----- 271 ---------|--------------|--------- 272 | | (Operator1) | | 273 | +---+ Network +---+ | 274 | |PE3| |PE4| | (Operator2) 275 | +---+ +---+ | +--+ 276 | / \ / \ | / \ 277 +----+ | +---+ +--+ +--+ +---+ | +---+ + 278 |UE/ |---|PE1| AS1 |R1|-|R2| |PE5|---|BR1| AS4 | 279 |CPE1| | +---+ +--+ +--+ +---+ | +---+ + 280 +----+ | \ / | | | \ / 281 | +--+ | | | +--+ 282 | |R5| | | | 283 | +--+ | AS3 | | 284 | | | | | 285 | +--+ | | | 286 +----+ | |R6| | | | (Operator3) 287 |UE/ | | +--+ | | | +--+ 288 |CPE2|\| / \ | | | / \ 289 +----+ \ +---+ +--+ +--+ +---+ | +---+ + 290 |-|PE2| AS2 |R3|-|R4| |PE6|---|BR2| AS5 | 291 +----+ / +---+ +--+ +--+ +---+ | +---+ + 292 |UE/ |/| \ / \ / | \ / 293 |CPE3| | ---- ----- | +--+ 294 +----+ | | 295 ---------------------------------- 296 Figure 2. Multi-domain IPv6 Network Model 298 In order to illustrate the requirements of IPv6-only network, the 299 following scenarios should be considered, 301 Scenario 1: IPv6 user to IPv4 server, IPv6-only user accesses IPv4 302 services hosted in cloud data centers. 304 Scenario 2: IPv4 user to IPv4 server, IPv4-only user accesses IPv4 305 services hosted in cloud data centers. 307 Scenario 3: IPv6 user to IPv6 server, IPv6-only user accesses IPv6 308 services hosted in cloud data centers. 310 Scenario 4: DC-to-DC, IPv6-only provide communications between VMs 311 hosted cloud data centers, despite they are IPv4, IPv6 or IPv4/IPv6 312 dual-stack. 314 Scenario 5: Transit for neighbor networks, IPv6-only network serves 315 as an interconnection between several segregated IPv4-only network, 316 IPv4 packets are transported over the IPv6 network between IPv4 317 networks. 319 Scenario 6: IPv6-Only eBGP Edge peering in Internet Exchange Point 320 (IXP)[I-D.ietf-bess-ipv6-only-pe-design], this serves to eliminate 321 IPv4 provisioning at the Edge of IXP that are facing IPv4 address 322 depletion at large peering points. 324 Scenario 7, 5G Transport service, SD-WAN, etc. 326 It should be noted that the aforementioned scenarios are only a 327 subset of the scenarios that multi-domain IPv6-only network will 328 support in the future. 330 6. Requirements from IPv6-native traffic 332 Since there is no IPv4-IPv6 transition issue, native-IPv6 traffic can 333 be transported by IPv6-only network naturally, the requirements are 334 not covered by this document. 336 7. Procedure 338 This section firstly gives a very brief overview of the procedures of 339 the IPv4 service delivery over IPv6-only network. 341 When an ingress PE receives an IPv4 packet from a client-facing 342 interface destined to a remote IPv4 network, it looks up the packet's 343 destination IP address. In the scenario of interest, the best match 344 will help to find another PE, the egress PE. Since this is a multi- 345 domain IPv6-only network, the ingress and egress may belong to 346 different ASes, for example the ingress is in AS 1 and egress is in 347 AS 2. The ingress PE must transform the IPv4 packet into IPv6 packet 348 and forward the packet to the egress PE. The egress PE then derives 349 the IPv4 source and destination addresses from the IPv4-embedded IPv6 350 addresses, respectively [RFC6052]and restore the original IPv4 351 packet, and forwards it further according to the IPv4 routing table 352 maintained on the egress. The IPv6 data-path can be shown as below, 353 IPv6 Data Path 354 |<------------------------>| 355 | | (Operator2) 356 | ---- ----- | ---- 357 | / \ / \ | / \ 358 +----+ +---+ +--+ +--+ +---+ | | 359 |UE/ |---|PE1| AS1 |R1|-|R2| AS3 |PE3|---| AS4 | 360 |CPE1| +---+ +--+ +--+ +---+ | | 361 +----+ \ / \ / \ / 362 ---- ----- ---- 364 Figure 3. IPv6 Data Path from Ingress PE to Egress PE 366 Another case that IPv4 packets may have been transformed into IPv6 367 packet in UE/CPE, as done by CLAT of 464XLAT 368 [RFC6877][RFC6877],before they reach the edge of the network. 369 In this case, the ingress PE receives an IPv6 packet from a client- 370 facing interface and looks up the packet's destination IPv6 address. 371 and forward the packet to the egress PE. The egress PE then restore 372 the original IPv4 packet, and forwards it further by looking up its 373 IP destination address. The IPv6 data-path can be shown as below. 375 IPv6 Data Path 376 |<--------------------------------->| 377 | | (Operator2) 378 | ---- ----- | ---- 379 | / \ / \ | / \ 380 +----+ +---+ +--+ +--+ +---+ | | 381 |UE/ |---|PE1| AS1 |R1|-|R2| AS3 |PE3|---| AS4 | 382 |CPE1| +---+ +--+ +--+ +---+ | | 383 +----+ \ / \ / \ / 384 ---- ----- ---- 386 Figure 4. IPv6 Data Path from UE/CPE to Egress PE 388 When PE of IPv6-only network UE/CPE need to implement IPv4-IPv6 389 conversion, a specific IPv6 address range will represent IPv4 systems 390 (IPv4-converted addresses), and the IPv6 systems have addresses 391 (IPv4-translatable addresses or IPv4-embedded IPv6 addresses) that 392 can be algorithmically mapped to a subset of the service provider's 393 IPv4 addresses. Note that IPv4-translatable addresses are a subset 394 of IPv4-converted addresses. In this way, there is no need to 395 concern oneself with translation tables, as the IPv4 and IPv6 396 counterparts are algorithmically related. 398 8. Requirements from IPv4 service delivery 400 In order to support IPv4 service delivery, the following requirements 401 should be met by multi-domain IPv6-only network, 403 Requirement 1: beneficial to wider IPv6 adoption 405 It should largely reduce IPv4 public address consumption and 406 accelerate the deployment of IPv6, rather than prolonging the 407 lifecycle of IPv4 by introducing multiple layers of 44NAT. 409 Requirement 2: IPv4-as-a-Service 411 IPv6 transition mechanisms should provide IPv4 service delivery and 412 there should be no perceived degradation of customer experience when 413 accessing the remaining IPv4 services. 415 Requirement 3: end-to-end 417 End-to-end means, for any given IPv4 traffic flow, there should be no 418 IPv4-IPv6 conversion point in the middle of the IPv6 data path when 419 traversing multi-domain IPv6 network, in other words, IPv4 packet 420 should not appear in the middle of the IPv6 data path, the maximum 421 number of the transition point should be two. In addition, IPv6-only 422 network should support the following two types of IPv6 data path, as 423 mentioned in section 7. 425 -From UE to egress, the packets of IPv4 service can be translated 426 into IPv6 packets within UE or CPE, and there should be no IPv4-IPv6 427 conversion before they reaches the egress of the network. 429 -From the ingress to egress, since the core of the network is 430 IPv6-based, so all IPv4 packets which reaches the edge of the network 431 should be transformed into IPv6 packets by the ingress and forwarded 432 to the egress of the network. The end-to-end requirement also be 433 valid for cloud-to-cloud communications. 435 Requirement 4: support of translation and encapsulation 437 For the data-plane, there are two approaches for traversing the IPv6 438 provider network: 4-6-4 translation and 4-in6 encapsulation, both of 439 them can be supported by IPv6-only network, the core nodes do not 440 distinguish between translation-based IPv6 packet and encapsulation- 441 based IPv6 packet. At the egress, the PE can recover IPv4 packet by 442 reading the next-header field of the packet. It should be noted that 443 translation mode and encapsulation mode have the same IPv4-IPv6 444 address mapping algorithm. 446 Requirement 5: controller independent 448 In order to forward an IPv4 packet to the right egress point, IPv4 449 reachability information must be exchanged in advance between the 450 IPv4 networks over in IPv6-only network. In general, BGP4+ is used 451 to distribute external IPv4 routing information among AFBRs. In the 452 scenarios of interest, the extension of BGP4+ sessions can be used to 453 pass IPv4 routing information. This would require that IPv4-embedded 454 IPv6 routes be flooded throughout the entire IPv6-only network and 455 stored on every router. It does not rely on the deployment of any 456 centralized controller. Note that with this routing solution, the 457 IPv4 and IPv6 header conversion performed in both directions by the 458 PE is stateless. 460 Requirement 6: user stateless at the border gateway 462 Maintaining user status will need great volume of storage and 463 computation power, so it is generally stored or managed at the edge 464 of network and close to the user side. It is unsuitable to store 465 user-related status at the inter-connection point. The border 466 gateway with other networks should be unaware of the user-related 467 information, it only needs to perform stateless translation or 468 encapsulation/decapsulation. 470 Requirement 7: high scalability 472 It should achieve scalability, simplicity and high availability, 473 especially for large-scale SPs. When PE processes IPv4-features at 474 the edge of the network, the quantity of the IPv4-related status 475 should not increase linearly or exponentially along with the quantity 476 of the user or traffic. Considering this, it is better to adopt 477 algorithm-based mapping approach to avoid excessive status storage at 478 the edge. it would also prevent overload of the IPv6 routing table. 480 Requirement 8: SRv6 applicable 482 SRv6 can be supported by inserting SRH in translated IPv6 packet, so 483 the network programming can be realized for IPv4 traffic flow. 485 Requirement 9: incremental deployment 487 It should deploy in an incremental fashion and the overall transition 488 process should be stable and operational. 490 9. Security Considerations 492 There are no other special security considerations. 494 10. IANA Considerations 496 There are no other special IANA considerations. 498 11. Acknowledgement 500 This is under development by a large group of people. Those who have 501 posted to the list during the discussion. 503 12. References 505 12.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 12.2. Informative References 514 [I-D.ietf-bess-ipv6-only-pe-design] 515 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 516 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 517 IPv4-NLRI with IPv6-NH", draft-ietf-bess-ipv6-only-pe- 518 design-00 (work in progress), September 2021. 520 [I-D.ietf-v6ops-ipv6-deployment] 521 Fioccola, G., Volpato, P., Elkins, N., Martinez, J. P., 522 Mishra, G. S., and C. Xie, "IPv6 Deployment Status", 523 draft-ietf-v6ops-ipv6-deployment-04 (work in progress), 524 February 2022. 526 [I-D.ietf-v6ops-transition-comparison] 527 Lencse, G., Martinez, J. P., Howard, L., Patterson, R., 528 and I. Farrer, "Pros and Cons of IPv6 Transition 529 Technologies for IPv4aaS", draft-ietf-v6ops-transition- 530 comparison-02 (work in progress), March 2022. 532 [IAB-statement] 533 "IAB statement", 534 . 536 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 537 for IPv6 Hosts and Routers", RFC 4213, 538 DOI 10.17487/RFC4213, October 2005, 539 . 541 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 542 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 543 . 545 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 546 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 547 DOI 10.17487/RFC6052, October 2010, 548 . 550 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 551 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 552 . 554 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 555 Stack Lite Broadband Deployments Following IPv4 556 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 557 . 559 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 560 Combination of Stateful and Stateless Translation", 561 RFC 6877, DOI 10.17487/RFC6877, April 2013, 562 . 564 [RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for 565 IPv4-Embedded IPv6 Packets", RFC 6992, 566 DOI 10.17487/RFC6992, July 2013, 567 . 569 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 570 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 571 Port with Encapsulation (MAP-E)", RFC 7597, 572 DOI 10.17487/RFC7597, July 2015, 573 . 575 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 576 and T. Murakami, "Mapping of Address and Port using 577 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 578 2015, . 580 Authors' Addresses 582 Chongfeng Xie 583 China Telecom 584 Beiqijia Town, Changping District 585 Beijing, Beijing 102209 586 China 588 Email: xiechf@chinatelecom.cn 590 Chenhao Ma 591 China Telecom 592 Beiqijia Town, Changping District 593 Beijing, Beijing 102209 594 China 596 Email: machh@chinatelecom.cn 598 Xing Li 599 CERNET Center/Tsinghua University 600 Shuangqing Road No.30, Haidian District 601 Beijing, Beijing 100084 602 China 604 Email: xing@cernet.edu.cn 606 Gyan Mishra 607 Verizon Inc 609 Email: gyan.s.mishra@verizon.com 611 Mohamed Boucadair 612 Orange 613 France 615 Email: mohamed.boucadair@orange.com