idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-02.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 13, 2018) is 2116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations (v6ops) J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Updates: 8026 (if approved) H. M.-H. Liu 5 Intended status: Informational D-Link Systems, Inc. 6 Expires: December 15, 2018 M. Kawashima 7 NEC Platforms, Ltd. 8 June 13, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-02 14 Abstract 16 This document specifies the IPv4 service continuity requirements for 17 an IPv6 Customer Edge (CE) router, either provided by the service 18 provider or thru the retail market. 20 Specifically, this document extends the "Basic Requirements for IPv6 21 Customer Edge Routers" in order to allow the provisioning of IPv6 22 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) 23 by means of new transition mechanisms. The document only covers 24 transition technologies for delivering IPv4 in IPv6-only access 25 networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required 26 in a world where IPv4 addresses are no longer available, so hosts in 27 the customer LANs with IPv4-only or IPv6-only applications or 28 devices, requiring to communicate with IPv4-only services at the 29 Internet, are still able to do so. 31 In order to be able to prioritize, in a uniform way, among all the 32 transition mechanisms, and to enable the service provider to enable/ 33 disable them, this document updates RFC8026. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 15, 2018. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language - Special Note . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. General Requirements . . . . . . . . . . . . . . . . . . 4 73 3.2. LAN-Side Configuration . . . . . . . . . . . . . . . . . 4 74 3.3. Transition Technologies Support for IPv4 service 75 continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 5 76 3.3.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.3.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 6 78 3.3.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 7 79 3.3.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 9 82 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6. Differences from RFC7084 . . . . . . . . . . . . . . . . . . 10 84 7. Update of RFC8026 . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Code Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 89 12. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 11 90 13. Annex B: End-User Network Architecture . . . . . . . . . . . 13 91 14. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 16 92 15. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 16 93 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 16.2. Informative References . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 This document defines IPv4 service continuity features over an 101 IPv6-only network, for a residential or small-office router, referred 102 to as an "IPv6 Transition CE Router", in order to establish an 103 industry baseline for transition features to be implemented on such a 104 router. 106 These routers are likely to rely upon "Basic Requirements for IPv6 107 Customer Edge Routers" ([RFC7084]), so the scope of this document is 108 to ensure the IPv4 "service continuity" support, in the LAN side and 109 the access to IPv4-only Internet services from an IPv6-only access 110 WAN even from IPv6-only applications or devices in the LAN side. 112 This document covers a set of IP transition techniques required when 113 ISPs have an IPv6-only access network. This is a common situation in 114 a world where IPv4 addresses are no longer available, so the service 115 providers need to provision IPv6-only WAN access. At the same time, 116 they need to ensure that both IPv4-only and IPv6-only devices or 117 applications in the customer networks, can still reach IPv4-only 118 devices and applications in the Internet. 120 This document specifies the IPv4 service continuity mechanisms to be 121 supported by an IPv6 Transition CE Router, and relevant provisioning 122 or configuration information differences from [RFC7084]. 124 This document is not a recommendation for service providers to use 125 any specific transition mechanism. 127 Automatic provisioning of more complex topology than a single router 128 with multiple LAN interfaces may be handled by means of HNCP 129 ([RFC7788]), which is out of the scope of this document. 131 Service providers who specify feature sets for IPv6 Transition CE 132 Router MAY specify a different set of features than those included in 133 this document. Since it is impossible to know prior to sale which 134 transition mechanism a device will need over the lifetime of the 135 device, IPv6 Transition CE Router intended for the retail market MUST 136 support all of them. 138 A complete description of "Usage Scenarios" and "End-User Network 139 Architecture" is provided in Annex A and B, respectively. 141 1.1. Requirements Language - Special Note 143 Unlike other IETF documents, the key words "MUST", "MUST NOT", 144 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 145 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 146 described in RFC 2119 [RFC2119]. This document uses these keywords 147 not strictly for the purpose of interoperability, but rather for the 148 purpose of establishing industry-common baseline functionality. As 149 such, the document points to several other specifications to provide 150 additional guidance to implementers regarding any protocol 151 implementation required to produce a successful IPv6 Transition CE 152 Router that interoperates successfully with a particular subset of 153 currently deploying and planned common IPv6-only access networks. 155 2. Terminology 157 This document uses the same terms as in [RFC7084], with minor 158 clarifications. 160 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 161 technologies for delivering IPv4 in IPv6-only access networks. 163 The term "IPv6 transition Customer Edge Router with IPv4aaS" 164 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 165 Customer Edge Router" that provides features for the delivery of IPv4 166 services over an IPv6-only WAN network including IPv6-IPv4 167 communications. 169 The "WAN Interface" term used across this document, means that can 170 also support link technologies based in Internet-layer (or higher- 171 layers) "tunnels", such as IPv4-in-IPv6 tunnels. 173 3. Requirements 175 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 176 Requirements for IPv6 Customer Edge Routers). 178 3.1. General Requirements 180 A new general requirement is added, in order to ensure that the IPv6 181 Transition CE Router respects the IPv6 prefix length as a parameter: 183 G-6 The IPv6 Transition CE Router MUST comply with [RFC7608] (IPv6 184 Prefix Length Recommendation for Forwarding). 186 3.2. LAN-Side Configuration 188 A new LAN requirement is added, which in fact is common in regular 189 IPv6 Transition CE Router, and it is required by most of the 190 transition mechanisms: 192 L-15 The IPv6 Transition CE Router SHOULD implement a DNS proxy as 193 described in [RFC5625] (DNS Proxy Implementation Guidelines). 195 3.3. Transition Technologies Support for IPv4 service continuity (IPv4 196 as-a-Service - IPv4aaS) 198 The main target of this document is the support of IPv6-only WAN 199 access. To enable legacy IPv4 functionality, this document also 200 includes the support of IPv4-only devices and applications in the 201 customers LANs, as well as IPv4-only services on the Internet. Thus, 202 both IPv4-only and the IPv6-only devices inside the IPv6 Transition 203 CE Router are able to reach the IPv4-only services. 205 This document takes no position on simultaneous operation of any 206 transition mechanism and native IPv4. 208 In order to seamlessly provide the IPv4 Service Continuity in 209 Customer LANs, allowing an automated IPv6 transition mechanism 210 provisioning, general transition requirements are added. 212 General transition requirements: 214 TRANS-1: All the supported transition mechanisms MUST be disabled by 215 default configuration of the IPv6 Transition CE Router. 217 TRANS-2: The IPv6 Transition CE Router MUST have a GUI and/or CLI 218 option to manually enable/disable each of the supported 219 transition mechanisms. 221 TRANS-3: The IPv6 Transition CE Router MUST support the DHCPv6 S46 222 priority options described in [RFC8026] (Unified IPv4-in- 223 IPv6 Softwire Customer Premises Equipment (CPE): A 224 DHCPv6-Based Prioritization Mechanism). 226 TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of 227 [RFC8026], MUST check for a valid match in 228 OPTION_S46_PRIORITY, which will allow configuring a 229 transition mechanisms. If 464XLAT [RFC6877] is supported, 230 it MUST be included in the candidate list of possible S46 231 mechanism, if one or more NAT64 prefixes are learnt by 232 means of either [RFC7050] or [RFC7225]. 234 TRANS-5: In order to allow the service provider to disable all the 235 transition mechanisms, the IPv6 Transition CE Router MUST 236 NOT enable any transition mechanisms if no match is found 237 between the priority list and the candidate list. 239 The following sections describe the requirements for supporting each 240 one of the transition mechanisms. 242 3.3.1. 464XLAT 244 464XLAT [RFC6877] is a technique to provide IPv4 service over an 245 IPv6-only access network without encapsulation. This architecture 246 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 247 Protocol Translation from IPv6 Clients to IPv4 Servers) function 248 deployed at the service provider or a third-party network. 250 The IPv6 Transition CE Router SHOULD support CLAT functionality. If 251 464XLAT is supported, it MUST be implemented according to [RFC6877]. 252 The following IPv6 Transition CE Router requirements also apply: 254 464XLAT requirements: 256 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 257 Address Translation (NAT) on IPv4 traffic translated 258 using the CLAT, unless a dedicated /64 prefix has been 259 acquired, either using DHCPv6-PD [RFC3633] (IPv6 Prefix 260 Options for DHCPv6) or by alternative means. 262 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 263 [RFC6970] (UPnP Internet Gateway Device - Port Control 264 Protocol Interworking Function). 266 464XLAT-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 267 Router MUST also implement [RFC7291] (DHCP Options for 268 the PCP). If no PCP server is configured, the IPv6 269 Transition CE Router MAY verify if the default gateway, 270 or the NAT64 is the PCP server. A plain IPv6 mode is 271 used to send PCP requests to the server. 273 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 274 (Discovery of the IPv6 Prefix Used for IPv6 Address 275 Synthesis) in order to discover the PLAT-side translation 276 IPv4 and IPv6 prefix(es)/suffix(es). The IPv6 Transition 277 CE Router MUST follow [RFC7225] (Discovering NAT64 IPv6 278 Prefixes Using the PCP), in order to learn the PLAT-side 279 translation IPv4 and IPv6 prefix(es)/suffix(es) used by 280 an upstream PCP-controlled NAT64 device. 282 3.3.2. Dual-Stack Lite (DS-Lite) 284 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 285 services and incentives for the deployment of IPv6. It also de- 286 couples IPv6 deployment in the service provider network from the rest 287 of the Internet, making incremental deployment easier. Dual-Stack 288 Lite enables a broadband service provider to share IPv4 addresses 289 among customers by combining two well-known technologies: IP in IP 290 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 291 that DS-Lite traffic is forwarded over the IPv6 Transition CE 292 Router's native IPv6 WAN interface, and not encapsulated in another 293 tunnel. 295 The IPv6 Transition CE Router SHOULD implement DS-Lite [RFC6333] 296 functionality. If DS-Lite is supported, it MUST be implemented 297 according to [RFC6333]. The following IPv6 Transition CE Router 298 requirements also apply: 300 DS-Lite requirements: 302 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 303 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 304 Option for Dual-Stack Lite). The IPv6 Transition CE 305 Router MAY use other mechanisms to configure DS-Lite 306 parameters. Such mechanisms are outside the scope of this 307 document. 309 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 310 [RFC6970] (UPnP Internet Gateway Device - Port Control 311 Protocol Interworking Function). 313 DSLITE-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 314 Router SHOULD also implement [RFC7291] (DHCP Options for 315 the PCP). If PCP ([RFC6887]) is implemented and a PCP 316 server is not configured, the IPv6 Transition CE Router 317 MUST assume, by default, that the AFTR is the PCP server. 318 A plain IPv6 mode is used to send PCP requests to the 319 server. 321 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 322 Network Address Translation (NAT) on IPv4 traffic 323 encapsulated using DS-Lite ([RFC6333]). 325 3.3.3. Lightweight 4over6 (lw4o6) 327 Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the 328 NAPT function from the DS-Lite tunnel concentrator to the tunnel 329 client located in the IPv6 Transition CE Router, removing the 330 requirement for a CGN function in the tunnel concentrator and 331 reducing the amount of centralized state. 333 The IPv6 Transition CE Router SHOULD implement lw4o6 functionality. 334 If DS-Lite is implemented, lw4o6 SHOULD be supported as well. If 335 lw4o6 is supported, it MUST be implemented according to [RFC7596]. 336 The following IPv6 Transition CE Router requirements also apply: 338 Lw4o6 requirements: 340 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 341 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 342 Options for Configuration of Softwire Address and Port- 343 Mapped Clients). The IPv6 Transition CE Router MAY use 344 other mechanisms to configure lw4o6 parameters. Such 345 mechanisms are outside the scope of this document. 347 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 348 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 349 over-DHCPv6 Transport). 351 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 352 Allocation of Shared IPv4 Addresses as described in 353 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 355 3.3.4. MAP-E 357 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 358 an IPv6 network using IP encapsulation, including an algorithmic 359 mechanism for mapping between IPv6 addresses and IPv4 addresses as 360 well as transport-layer ports. 362 The IPv6 Transition CE Router SHOULD support MAP-E functionality. If 363 MAP-E is supported, it MUST be implemented according to [RFC7597]. 364 The following IPv6 Transition CE Router requirements also apply: 366 MAP-E requirements: 368 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 369 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 370 for Configuration of Softwire Address and Port-Mapped 371 Clients). The IPv6 Transition CE Router MAY use other 372 mechanisms to configure MAP-E parameters. Such mechanisms 373 are outside the scope of this document. 375 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 376 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 377 Allocation of Shared IPv4 Addresses). 379 3.3.5. MAP-T 381 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 382 that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as 383 the form of IPv6 domain transport. 385 The IPv6 Transition CE Router SHOULD support MAP-T functionality. If 386 MAP-T is supported, it MUST be implemented according to [RFC7599]. 387 The following IPv6 Transition CE Router requirements also apply: 389 MAP-T requirements: 391 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 392 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 393 for Configuration of Softwire Address and Port-Mapped 394 Clients). The IPv6 Transition CE Router MAY use other 395 mechanisms to configure MAP-T parameters. Such mechanisms 396 are outside the scope of this document. 398 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 399 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 400 Allocation of Shared IPv4 Addresses). 402 4. IPv4 Multicast Support 404 Actual deployments support IPv4 multicast for services such as IPTV. 405 In the transition phase it is expected that multicast services will 406 still be provided using IPv4 to the customer LANs. 408 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 409 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 410 Services to IPv4 Clients over an IPv6 Multicast Network) and 411 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 412 Prefixes). 414 5. UPnP Support 416 UPnP SHOULD be disabled by default on the IPv6 Transition CE Router 417 when using an IPv4aaS transition mechanism. 419 UPnP MAY be enabled when a IPv6 Transition CE Router is configured to 420 use a stateless mechanism that allows unsolicited inbound packets 421 through to the CE, such as MAP or lw4o6, or when configured with 4 a 422 port set containing all 65535 ports, e.g. with an IPv4 address 423 sharing ratio of 1. 425 If UPnP is enabled on a IPv6 Transition CE Router, the UPnP agent 426 MUST reject any port mapping requests for ports outside of the port 427 set allocated to the IPv6 Transition CE Router. 429 UPnP MAY also be enabled on a IPv6 Transition CE Router configured 430 for IPv4aaS mechanisms that support PCP [RFC6887], if implemented in 431 conjunction with a method to control the external port mapping, such 432 as IGD-PCP IWF [RFC6970]. 434 A IPv6 Transition CE Router that implements a UPnP agent, SHOULD 435 support the Open Connectivity Foundation's IGD:2 specification, 436 including the AddAnyPortMapping() function. 438 6. Differences from RFC7084 440 This document no longer consider the need to support 6rd ([RFC5969]) 441 and includes slightly different requirements for DS-LITE [RFC6333]. 443 7. Update of RFC8026 445 [RFC8026] (Unified IPv4-in-IPv6 Softwire CPE: A DHCPv6-Based 446 Prioritization Mechanism) specifies a DHCPv6 option in order to 447 priorize among different transition mechanism, all them covered by 448 this document, with the exception of 464XLAT [RFC6877]. 450 This document updates [RFC8026] in order to specify a new option code 451 for 464XLAT [RFC6877], so the IPv6 Transition CE Router can use that 452 as a simple mechanism for detecting if the CLAT need to be enabled/ 453 disabled and what priority 464XLAT has versus other transition 454 mechanism included in the S46 Priority Option. 456 In addition to that, as 464XLAT [RFC6877] doesn't have an specific 457 DHCPv6 message for configuration options, this document changes the 458 behaviour of Section 1.4.1 of [RFC8026], so 464XLAT is included in 459 the candidate list of possible S46 mechanism, if one or more NAT64 460 prefixes are learnt by means of either [RFC7050] or [RFC7225]. 462 8. Code Considerations 464 One of the apparent main issues for vendors to include new 465 functionalities, such as support for new transition mechanisms, is 466 the lack of space in the flash (or equivalent) memory. However, it 467 has been confirmed from existing open source implementations 468 (OpenWRT/LEDE, Linux, others), that adding the support for the new 469 transitions mechanisms, requires around 10-12 Kbytes (because most of 470 the code base is shared among several transition mechanisms already 471 supported by [RFC7084]), as a single data plane is common to all 472 them, which typically means about 0,15% of the existing code size in 473 popular CEs already in the market. 475 It is also clear that the new requirements don't have extra cost in 476 terms of RAM memory, neither other hardware requirements such as more 477 powerful CPUs. 479 The other issue seems to be the cost of developing the code for those 480 new functionalities. However, at the time of writing this document, 481 it has been confirmed that there are several open source versions of 482 the required code for supporting the new transition mechanisms, and 483 even several vendors already have implementations and provide it to 484 ISPs, so the development cost is negligent, and only integration and 485 testing cost may become a minor issue. 487 9. Security Considerations 489 The IPv6 Transition CE Router must comply with the Security 490 Considerations as stated in [RFC7084], as well as those stated by 491 each transition mechanism implemented by the IPv6 Transition CE 492 Router. 494 10. IANA Considerations 496 IANA is instructed, by means of this document, to create a new Option 497 Code for 464XLAT in the registry "Option Codes permitted in the S46 498 Priority Option" as follows. 500 +-------------+--------------------+-----------+ 501 | Option Code | S46 Mechanism | Reference | 502 +-------------+--------------------+-----------+ 503 | 46 | 464XLAT | [RFC6877] | 504 +-------------+--------------------+-----------+ 506 Table 1: DHCPv6 Option Code for 464XLAT 508 11. Acknowledgements 510 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 511 Carpenter, Lee Howard, Richard Patterson, Barbara Stark, Ole Troan, 512 James Woodyatt, and "TBD", for their review and comments in this and 513 previous versions of this document. 515 12. Annex A: Usage Scenarios 517 The situation previously described, where there is ongoing IPv6 518 deployment and lack of IPv4 addresses, is not happening at the same 519 pace at every country, and even within every country, every ISP. For 520 different technical, financial, commercial/marketing and socio- 521 economic reasons, each network is transitioning at their own pace, 522 and nobody has a magic crystal ball, to make a guess. 524 Different studies (for example [IPv6Survey]) also show that this is a 525 changing situation, because in a single country, it may be that not 526 all operators provide IPv6 support, and consumers may switch ISPs and 527 use the same IPv6 Transition CE Router with an ISP that provides 528 IPv4-only and an ISP that provides IPv6 plus IPv4aaS. 530 So, it is clear that, to cover all those evolving situations, a IPv6 531 Transition CE Router is required, at least from the perspective of 532 the transition support, which can accommodate those changes. 534 Moreover, because some services will remain IPv4-only for an 535 undetermined time, and some service providers will remain IPv4-only 536 for an undetermined period of time, IPv4 will be needed for an 537 undetermined period of time. There will be a need for CEs with 538 support "IPv4 as-a-Service" for an undetermined period of time. 540 This document is consequently, based on those premises, in order to 541 ensure the continued transition from networks that today may provide 542 access with dual-stack or IPv6-in-IPv4, as described in [RFC7084], 543 and as an "extension" to it, evolving to an IPv6-only access with 544 IPv4-as-a-Service. 546 Considering that situation and different possible usage cases, the 547 IPv6 Transition CE Router described in this document is expected to 548 be used typically, in the following scenarios: 550 1. Residential/household, Small Office/Home Office (SOHO) and Small/ 551 Medium Enterprise (SME). Common usage is any kind of Internet 552 access (web, email, streaming, online gaming, etc.). 554 2. Residential/household and Small/Medium Enterprise (SME) with 555 advanced requirements. Same basic usage as for the previous 556 case, however there may be requirements for allowing inbound 557 connections (IP cameras, web, DNS, email, VPN, etc.). 559 The above list is not intended to be comprehensive of all the 560 possible usage scenarios, just an overall view. In fact, 561 combinations of the above usages are also possible, as well as 562 situations where the same CE is used at different times in different 563 scenarios or even different services providers that may use a 564 different transition mechanism. 566 The mechanisms for allowing inbound connections are "naturally" 567 available in any IPv6 router, as when using GUA, unless they are 568 blocked by firewall rules, which may require some manual 569 configuration by means of a GUI and/or CLI. 571 However, in the case of IPv4aaS, because the usage of private 572 addresses and NAT and even depending on the specific transition 573 mechanism, it typically requires some degree of more complex manual 574 configuration such as setting up a DMZ, virtual servers, or port/ 575 protocol forwarding. In general, IPv4 CE Routers already provide GUI 576 and/or CLI to manually configure them, or the possibility to setup 577 the CE in bridge mode, so another CE behind it, takes care of that. 579 It is out of the scope of this document the definition of any 580 requirements for that. 582 The main difference for a CE Router to support the above indicated 583 scenarios and number of users, is related to the packet processing 584 capabilities, performance, even other details such as the number of 585 WAN/LAN interfaces, their maximum speed, memory for keeping tables or 586 tracking connections, etc. It is out of the scope of this document 587 to classify them. 589 The actual bandwidth capabilities of access technologies such as 590 FTTH, cable and even 3GPP/LTE, allows the support of such scenarios, 591 and indeed, is a very common situation that access networks and CE 592 Router provided by the service provider are the same for SMEs and 593 residential users. 595 There is also no difference in terms of who actually provides the CE 596 Router. In most of the cases is the service provider, and in fact is 597 responsible, typically, of provisioning/managing at least the WAN 598 side. However, commonly the user has access to configure the LAN 599 interfaces, firewall, DMZ, and many other features. In fact, in many 600 cases, the user must supply or may replace the CE Router; this makes 601 even more relevant that all the CE Routers, support the same 602 requirements defined in this document. 604 The IPv6 Transition CE Router described in this document is not 605 intended for usage in other scenarios such as large Enterprises, Data 606 Centers, Content Providers, etc. So, even if the documented 607 requirements meet their needs, they may have additional requirements, 608 which are out of the scope of this document. 610 13. Annex B: End-User Network Architecture 612 According to the descriptions in the preceding sections, an end-user 613 network will likely support both IPv4 and IPv6. It is not expected 614 that an end user will change their existing network topology with the 615 introduction of IPv6. There are some differences in how IPv6 works 616 and is provisioned; these differences have implications for the 617 network architecture. 619 A typical IPv4 end-user network consists of a "plug and play" router 620 with NAT functionality and a single link upstream, connected to the 621 service provider network. 623 From the perspective of an "IPv4 user" behind an IPv6 transition 624 Customer Edge Router with IPv4aaS, this doesn't change. 626 However, while a typical IPv4 NAT deployment by default blocks all 627 incoming connections and may allow opening of ports using a Universal 628 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 629 other firewall control protocol, in the case of an IPv6-only access 630 and IPv4aaS, that may not be feasible depending on specific 631 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 632 may be an alternative solution. 634 Another consequence of using IPv4 private address space in the end- 635 user network is that it provides stable addressing; that is, it never 636 changes even when you change service providers, and the addresses are 637 always there even when the WAN interface is down or the customer edge 638 router has not yet been provisioned. In the case of an IPv6-only 639 access, there is no change on that if the transition mechanism keeps 640 running the NAT interface towards the LAN side. 642 More advanced routers support dynamic routing (which learns routes 643 from other routers), and advanced end-users can build arbitrary, 644 complex networks using manual configuration of address prefixes 645 combined with a dynamic routing protocol. Once again, this is true 646 for both, IPv4 and IPv6. 648 In general, the end-user network architecture for IPv6 should provide 649 equivalent or better capabilities and functionality than the current 650 IPv4 architecture. 652 The end-user network is a stub network, in the sense that is not 653 providing transit to other external networks. However, HNCP 654 ([RFC7788]) allows support for automatic provisioning of downstream 655 routers. Figure 1 illustrates the model topology for the end-user 656 network. 658 +---------------+ \ 659 | Service | \ 660 | Provider | | Service 661 | Router | | Provider 662 +-------+-------+ | Network 663 | / 664 | Customer / 665 | Internet Connection / 666 | 667 +------+--------+ \ 668 | IPv6 | \ 669 | Customer Edge | \ 670 | Router | / 671 +---+-------+---+ / 672 Network A | | Network B | 673 ---+----------------+-+- --+---+-------------+-- | 674 | | | | \ 675 +---+------+ | +----+-----+ +-----+----+ \ 676 |IPv6 Host | | | IPv4 Host| |IPv4/IPv6 | / 677 | | | | | | Host | / 678 +----------+ | +----------+ +----------+ / 679 | | 680 +------+--------+ | End-User 681 | IPv6 | | Network(s) 682 | Router | \ 683 +------+--------+ \ 684 Network C | \ 685 ---+-------------+--+--- | 686 | | | 687 +---+------+ +----+-----+ | 688 |IPv6 Host | |IPv6 Host | / 689 | | | | / 690 +----------+ +----------+ / 692 Figure 1: An Example of a Typical End-User Network 694 This architecture describes the: 696 o Basic capabilities of the IPv6 Transition CE Router 698 o Provisioning of the WAN interface connecting to the service 699 provider 701 o Provisioning of the LAN interfaces 703 The IPv6 Transition CE Router may be manually configured in an 704 arbitrary topology with a dynamic routing protocol or using HNCP 705 ([RFC7788]). Automatic provisioning and configuration is described 706 for a single IPv6 Transition CE Router only. 708 14. ANNEX C: Changes from -00 710 Section to be removed for WGLC. Significant updates are: 712 1. ID-Nits: IANA section. 714 2. ID-Nits: RFC7084 reference removed from Abstract. 716 3. This document no longer updates RFC7084. 718 4. UPnP section reworded. 720 5. "CE Router" changed to "IPv6 Transition CE Router". 722 6. Reduced text in Annex A. 724 15. ANNEX D: Changes from -01 726 Section to be removed for WGLC. Significant updates are: 728 1. TRANS requirements reworked in order to increase operator control 729 and allow gradual transitioning from dual-stack to IPv6-only on 730 specific customers. 732 2. New TRANS requirement so all the supported transition mechanisms 733 are disabled by default, in order to facilitate the operator 734 management. 736 3. New TRANS requirement in order to allow turning on/off each 737 transition mechanism by the user. 739 4. Clarification on how to obtain multiple /64 for 464XLAT. 741 5. S46 priority update to RFC8026 for including 464XLAT and related 742 changes in several sections. 744 16. References 746 16.1. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 754 Host Configuration Protocol (DHCP) version 6", RFC 3633, 755 DOI 10.17487/RFC3633, December 2003, 756 . 758 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 759 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 760 . 762 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 763 Infrastructures (6rd) -- Protocol Specification", 764 RFC 5969, DOI 10.17487/RFC5969, August 2010, 765 . 767 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 768 NAT64: Network Address and Protocol Translation from IPv6 769 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 770 April 2011, . 772 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 773 Stack Lite Broadband Deployments Following IPv4 774 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 775 . 777 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 778 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 779 RFC 6334, DOI 10.17487/RFC6334, August 2011, 780 . 782 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 783 Combination of Stateful and Stateless Translation", 784 RFC 6877, DOI 10.17487/RFC6877, April 2013, 785 . 787 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 788 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 789 DOI 10.17487/RFC6887, April 2013, 790 . 792 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 793 Play (UPnP) Internet Gateway Device - Port Control 794 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 795 DOI 10.17487/RFC6970, July 2013, 796 . 798 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 799 the IPv6 Prefix Used for IPv6 Address Synthesis", 800 RFC 7050, DOI 10.17487/RFC7050, November 2013, 801 . 803 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 804 Requirements for IPv6 Customer Edge Routers", RFC 7084, 805 DOI 10.17487/RFC7084, November 2013, 806 . 808 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 809 Port Control Protocol (PCP)", RFC 7225, 810 DOI 10.17487/RFC7225, May 2014, 811 . 813 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 814 the Port Control Protocol (PCP)", RFC 7291, 815 DOI 10.17487/RFC7291, July 2014, 816 . 818 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 819 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 820 RFC 7341, DOI 10.17487/RFC7341, August 2014, 821 . 823 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 824 Farrer, "Lightweight 4over6: An Extension to the Dual- 825 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 826 July 2015, . 828 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 829 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 830 Port with Encapsulation (MAP-E)", RFC 7597, 831 DOI 10.17487/RFC7597, July 2015, 832 . 834 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 835 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 836 Configuration of Softwire Address and Port-Mapped 837 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 838 . 840 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 841 and T. Murakami, "Mapping of Address and Port using 842 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 843 2015, . 845 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 846 Length Recommendation for Forwarding", BCP 198, RFC 7608, 847 DOI 10.17487/RFC7608, July 2015, 848 . 850 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 851 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 852 RFC 7618, DOI 10.17487/RFC7618, August 2015, 853 . 855 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 856 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 857 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 858 November 2016, . 860 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 861 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 862 over an IPv6 Multicast Network", RFC 8114, 863 DOI 10.17487/RFC8114, March 2017, 864 . 866 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 867 Option for IPv4-Embedded Multicast and Unicast IPv6 868 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 869 . 871 16.2. Informative References 873 [IPv6Survey] 874 Palet Martinez, J., "IPv6 Deployment Survey", January 875 2018, 876 . 879 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 880 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 881 2016, . 883 [UPnP-IGD] 884 UPnP Forum, "InternetGatewayDevice:2 Device Template 885 Version 1.01", December 2010, 886 . 888 Authors' Addresses 889 Jordi Palet Martinez 890 The IPv6 Company 891 Molino de la Navata, 75 892 La Navata - Galapagar, Madrid 28420 893 Spain 895 Email: jordi.palet@theipv6company.com 896 URI: http://www.theipv6company.com/ 898 Hans M.-H. Liu 899 D-Link Systems, Inc. 900 17595 Mount Herrmann St. 901 Fountain Valley, California 92708 902 US 904 Email: hans.liu@dlinkcorp.com 905 URI: http://www.dlink.com/ 907 Masanobu Kawashima 908 NEC Platforms, Ltd. 909 800, Shimomata 910 Kakegawa-shi, Shizuoka 436-8501 911 Japan 913 Email: kawashimam@vx.jp.nec.com 914 URI: https://www.necplatforms.co.jp/en/