idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-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 : ---------------------------------------------------------------------------- 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 15, 2018) is 2141 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 Intended status: Informational H. M.-H. Liu 5 Expires: December 17, 2018 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 June 15, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-03 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 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 December 17, 2018. 48 Copyright Notice 50 Copyright (c) 2018 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 - Special Note . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. General Requirements . . . . . . . . . . . . . . . . . . 4 70 3.2. LAN-Side Configuration . . . . . . . . . . . . . . . . . 4 71 3.3. Transition Technologies Support for IPv4 service 72 continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 5 73 3.3.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 7 75 3.3.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 8 76 3.3.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 9 79 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6. Differences from RFC7084 . . . . . . . . . . . . . . . . . . 10 81 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 11 86 12. Annex B: End-User Network Architecture . . . . . . . . . . . 13 87 13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 16 88 14. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 16 89 15. ANNEX E: Changes from -02 . . . . . . . . . . . . . . . . . . 16 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 16.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 16.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 This document defines IPv4 service continuity features over an 98 IPv6-only network, for a residential or small-office router, referred 99 to as an "IPv6 Transition CE Router", in order to establish an 100 industry baseline for transition features to be implemented on such a 101 router. 103 These routers are likely to rely upon "Basic Requirements for IPv6 104 Customer Edge Routers" ([RFC7084]), so the scope of this document is 105 to ensure the IPv4 "service continuity" support, in the LAN side and 106 the access to IPv4-only Internet services from an IPv6-only access 107 WAN even from IPv6-only applications or devices in the LAN side. 109 This document covers a set of IP transition techniques required when 110 ISPs have an IPv6-only access network. This is a common situation in 111 a world where IPv4 addresses are no longer available, so the service 112 providers need to provision IPv6-only WAN access. At the same time, 113 they need to ensure that both IPv4-only and IPv6-only devices or 114 applications in the customer networks, can still reach IPv4-only 115 devices and applications in the Internet. 117 This document specifies the IPv4 service continuity mechanisms to be 118 supported by an IPv6 Transition CE Router, and relevant provisioning 119 or configuration information differences from [RFC7084]. 121 This document is not a recommendation for service providers to use 122 any specific transition mechanism. 124 Automatic provisioning of more complex topology than a single router 125 with multiple LAN interfaces may be handled by means of HNCP 126 ([RFC7788]), which is out of the scope of this document. 128 Service providers who specify feature sets for IPv6 Transition CE 129 Router MAY specify a different set of features than those included in 130 this document. Since it is impossible to know prior to sale which 131 transition mechanism a device will need over the lifetime of the 132 device, IPv6 Transition CE Router intended for the retail market MUST 133 support all of them. 135 A complete description of "Usage Scenarios" and "End-User Network 136 Architecture" is provided in Annex A and B, respectively. 138 1.1. Requirements Language - Special Note 140 Unlike other IETF documents, the key words "MUST", "MUST NOT", 141 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 142 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 143 described in RFC 2119 [RFC2119]. This document uses these keywords 144 not strictly for the purpose of interoperability, but rather for the 145 purpose of establishing industry-common baseline functionality. As 146 such, the document points to several other specifications to provide 147 additional guidance to implementers regarding any protocol 148 implementation required to produce a successful IPv6 Transition CE 149 Router that interoperates successfully with a particular subset of 150 currently deploying and planned common IPv6-only access networks. 152 2. Terminology 154 This document uses the same terms as in [RFC7084], with minor 155 clarifications. 157 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 158 technologies for delivering IPv4 in IPv6-only access networks. 160 The term "IPv6 transition Customer Edge Router with IPv4aaS" 161 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 162 Customer Edge Router" that provides features for the delivery of IPv4 163 services over an IPv6-only WAN network including IPv6-IPv4 164 communications. 166 The "WAN Interface" term used across this document, means that can 167 also support link technologies based in Internet-layer (or higher- 168 layers) "tunnels", such as IPv4-in-IPv6 tunnels. 170 3. Requirements 172 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 173 Requirements for IPv6 Customer Edge Routers). 175 3.1. General Requirements 177 A new general requirement is added, in order to ensure that the IPv6 178 Transition CE Router respects the IPv6 prefix length as a parameter: 180 G-6 The IPv6 Transition CE Router MUST comply with [RFC7608] (IPv6 181 Prefix Length Recommendation for Forwarding). 183 3.2. LAN-Side Configuration 185 A new LAN requirement is added, which in fact is common in regular 186 IPv6 Transition CE Router, and it is required by most of the 187 transition mechanisms: 189 L-15 The IPv6 Transition CE Router SHOULD implement a DNS proxy as 190 described in [RFC5625] (DNS Proxy Implementation Guidelines). 192 3.3. Transition Technologies Support for IPv4 service continuity (IPv4 193 as-a-Service - IPv4aaS) 195 The main target of this document is the support of IPv6-only WAN 196 access. To enable legacy IPv4 functionality, this document also 197 includes the support of IPv4-only devices and applications in the 198 customers LANs, as well as IPv4-only services on the Internet. Thus, 199 both IPv4-only and the IPv6-only devices inside the IPv6 Transition 200 CE Router are able to reach the IPv4-only services. 202 This document takes no position on simultaneous operation of any 203 transition mechanism and native IPv4. 205 In order to seamlessly provide the IPv4 Service Continuity in 206 Customer LANs, allowing an automated IPv6 transition mechanism 207 provisioning, general transition requirements are added. 209 General transition requirements: 211 TRANS-1: All the supported transition mechanisms MUST be disabled by 212 default configuration of the IPv6 Transition CE Router. 214 TRANS-2: The IPv6 Transition CE Router MUST have a GUI and/or CLI 215 option to manually enable/disable each of the supported 216 transition mechanisms. 218 TRANS-3: The IPv6 Transition CE Router MUST support the DHCPv6 S46 219 priority options described in [RFC8026] (Unified IPv4-in- 220 IPv6 Softwire Customer Premises Equipment (CPE): A 221 DHCPv6-Based Prioritization Mechanism). 223 TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of 224 [RFC8026], MUST check for a valid match in 225 OPTION_S46_PRIORITY, which will allow enabling/configuring 226 a transition mechanism. 228 TRANS-5: In order to allow the service provider to disable all the 229 transition mechanisms, the IPv6 Transition CE Router MUST 230 NOT enable any transition mechanisms if no match is found 231 between the priority list and the candidate list. 233 The following sections describe the requirements for supporting each 234 one of the transition mechanisms. 236 3.3.1. 464XLAT 238 464XLAT [RFC6877] is a technique to provide IPv4 service over an 239 IPv6-only access network without encapsulation. This architecture 240 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 241 Protocol Translation from IPv6 Clients to IPv4 Servers) function 242 deployed at the service provider or a third-party network. 244 The IPv6 Transition CE Router SHOULD support CLAT functionality. If 245 464XLAT is supported, it MUST be implemented according to [RFC6877]. 246 The following IPv6 Transition CE Router requirements also apply: 248 464XLAT requirements: 250 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 251 Address Translation (NAT) on IPv4 traffic translated 252 using the CLAT, unless a dedicated /64 prefix has been 253 acquired, either using DHCPv6-PD [RFC3633] (IPv6 Prefix 254 Options for DHCPv6) or by alternative means. 256 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 257 [RFC6970] (UPnP Internet Gateway Device - Port Control 258 Protocol Interworking Function). 260 464XLAT-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 261 Router MUST also implement [RFC7291] (DHCP Options for 262 the PCP). If no PCP server is configured, the IPv6 263 Transition CE Router MAY verify if the default gateway, 264 or the NAT64 is the PCP server. A plain IPv6 mode is 265 used to send PCP requests to the server. 267 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 268 (Discovery of the IPv6 Prefix Used for IPv6 Address 269 Synthesis) in order to discover the PLAT-side translation 270 IPv4 and IPv6 prefix(es)/suffix(es). 272 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 273 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 274 the PCP), in order to learn the PLAT-side translation 275 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 276 PCP-controlled NAT64 device. 278 464XLAT-6: A DHCPv6 Option "OPTION_V6_PREFIX64" ([RFC8115]), with 279 zeroed ASM_mPrefix64 and SSM_mPrefix64, MUST also be 280 considered as a valid NAT64 prefix (uPrefix64). 282 464XLAT-7: If a DHCPv6 Option "OPTION_V6_PREFIX64" ([RFC8115]), with 283 zeroed ASM_mPrefix64 and SSM_mPrefix64 provides a NAT64 284 prefix, or one or more NAT64 prefixes are learnt by means 285 of either [RFC7050] or [RFC7225], then 464XLAT MUST be 286 included in the candidate list of possible S46 mechanism 287 (Section 1.4.1 of [RFC8026]). 289 The NAT64 prefix could be discovered by means of [RFC7050] only in 290 the case the service provider uses DNS64 ([RFC6147]). If DNS64 291 ([RFC6147]) is not used, or not trusted, as the DNS configuration at 292 the CE (or hosts behind the CE) may be modified by the customer, then 293 the service provider may opt to configure the NAT64 prefix either by 294 means of [RFC7225] or [RFC8115], which also can be used if the 295 service provider uses DNS64 ([RFC6147]). 297 3.3.2. Dual-Stack Lite (DS-Lite) 299 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 300 services and incentives for the deployment of IPv6. It also de- 301 couples IPv6 deployment in the service provider network from the rest 302 of the Internet, making incremental deployment easier. Dual-Stack 303 Lite enables a broadband service provider to share IPv4 addresses 304 among customers by combining two well-known technologies: IP in IP 305 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 306 that DS-Lite traffic is forwarded over the IPv6 Transition CE 307 Router's native IPv6 WAN interface, and not encapsulated in another 308 tunnel. 310 The IPv6 Transition CE Router SHOULD implement DS-Lite [RFC6333] 311 functionality. If DS-Lite is supported, it MUST be implemented 312 according to [RFC6333]. The following IPv6 Transition CE Router 313 requirements also apply: 315 DS-Lite requirements: 317 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 318 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 319 Option for Dual-Stack Lite). The IPv6 Transition CE 320 Router MAY use other mechanisms to configure DS-Lite 321 parameters. Such mechanisms are outside the scope of this 322 document. 324 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 325 [RFC6970] (UPnP Internet Gateway Device - Port Control 326 Protocol Interworking Function). 328 DSLITE-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 329 Router SHOULD also implement [RFC7291] (DHCP Options for 330 the PCP). If PCP ([RFC6887]) is implemented and a PCP 331 server is not configured, the IPv6 Transition CE Router 332 MUST assume, by default, that the AFTR is the PCP server. 333 A plain IPv6 mode is used to send PCP requests to the 334 server. 336 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 337 Network Address Translation (NAT) on IPv4 traffic 338 encapsulated using DS-Lite ([RFC6333]). 340 3.3.3. Lightweight 4over6 (lw4o6) 342 lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the 343 NAPT function from the DS-Lite tunnel concentrator to the tunnel 344 client located in the IPv6 Transition CE Router, removing the 345 requirement for a CGN function in the tunnel concentrator and 346 reducing the amount of centralized state. 348 The IPv6 Transition CE Router SHOULD implement lw4o6 functionality. 349 If DS-Lite is implemented, lw4o6 SHOULD be supported as well. If 350 lw4o6 is supported, it MUST be implemented according to [RFC7596]. 351 The following IPv6 Transition CE Router requirements also apply: 353 lw4o6 requirements: 355 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 356 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 357 Options for Configuration of Softwire Address and Port- 358 Mapped Clients). The IPv6 Transition CE Router MAY use 359 other mechanisms to configure lw4o6 parameters. Such 360 mechanisms are outside the scope of this document. 362 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 363 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 364 over-DHCPv6 Transport). 366 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 367 Allocation of Shared IPv4 Addresses as described in 368 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 370 3.3.4. MAP-E 372 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 373 an IPv6 network using IP encapsulation, including an algorithmic 374 mechanism for mapping between IPv6 addresses and IPv4 addresses as 375 well as transport-layer ports. 377 The IPv6 Transition CE Router SHOULD support MAP-E functionality. If 378 MAP-E is supported, it MUST be implemented according to [RFC7597]. 379 The following IPv6 Transition CE Router requirements also apply: 381 MAP-E requirements: 383 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 384 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 385 for Configuration of Softwire Address and Port-Mapped 386 Clients). The IPv6 Transition CE Router MAY use other 387 mechanisms to configure MAP-E parameters. Such mechanisms 388 are outside the scope of this document. 390 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 391 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 392 Allocation of Shared IPv4 Addresses). 394 3.3.5. MAP-T 396 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 397 that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as 398 the form of IPv6 domain transport. 400 The IPv6 Transition CE Router SHOULD support MAP-T functionality. If 401 MAP-T is supported, it MUST be implemented according to [RFC7599]. 402 The following IPv6 Transition CE Router requirements also apply: 404 MAP-T requirements: 406 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 407 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 408 for Configuration of Softwire Address and Port-Mapped 409 Clients). The IPv6 Transition CE Router MAY use other 410 mechanisms to configure MAP-T parameters. Such mechanisms 411 are outside the scope of this document. 413 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 414 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 415 Allocation of Shared IPv4 Addresses). 417 4. IPv4 Multicast Support 419 Actual deployments support IPv4 multicast for services such as IPTV. 420 In the transition phase it is expected that multicast services will 421 still be provided using IPv4 to the customer LANs. 423 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 424 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 425 Services to IPv4 Clients over an IPv6 Multicast Network) and 426 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 427 Prefixes). 429 5. UPnP Support 431 UPnP SHOULD be disabled by default on the IPv6 Transition CE Router 432 when using an IPv4aaS transition mechanism. 434 UPnP MAY be enabled when a IPv6 Transition CE Router is configured to 435 use a stateless mechanism that allows unsolicited inbound packets 436 through to the CE, such as MAP or lw4o6, or when configured with 4 a 437 port set containing all 65535 ports, e.g. with an IPv4 address 438 sharing ratio of 1. 440 If UPnP is enabled on a IPv6 Transition CE Router, the UPnP agent 441 MUST reject any port mapping requests for ports outside of the port 442 set allocated to the IPv6 Transition CE Router. 444 UPnP MAY also be enabled on a IPv6 Transition CE Router configured 445 for IPv4aaS mechanisms that support PCP [RFC6887], if implemented in 446 conjunction with a method to control the external port mapping, such 447 as IGD-PCP IWF [RFC6970]. 449 A IPv6 Transition CE Router that implements a UPnP agent, SHOULD 450 support the Open Connectivity Foundation's IGD:2 specification, 451 including the AddAnyPortMapping() function. 453 6. Differences from RFC7084 455 This document no longer consider the need to support 6rd ([RFC5969]) 456 and includes slightly different requirements for DS-LITE [RFC6333]. 458 7. Code Considerations 460 One of the apparent main issues for vendors to include new 461 functionalities, such as support for new transition mechanisms, is 462 the lack of space in the flash (or equivalent) memory. However, it 463 has been confirmed from existing open source implementations 464 (OpenWRT/LEDE, Linux, others), that adding the support for the new 465 transitions mechanisms, requires around 10-12 Kbytes (because most of 466 the code base is shared among several transition mechanisms already 467 supported by [RFC7084]), as a single data plane is common to all 468 them, which typically means about 0,15% of the existing code size in 469 popular CEs already in the market. 471 It is also clear that the new requirements don't have extra cost in 472 terms of RAM memory, neither other hardware requirements such as more 473 powerful CPUs. 475 The other issue seems to be the cost of developing the code for those 476 new functionalities. However, at the time of writing this document, 477 it has been confirmed that there are several open source versions of 478 the required code for supporting the new transition mechanisms, and 479 even several vendors already have implementations and provide it to 480 ISPs, so the development cost is negligent, and only integration and 481 testing cost may become a minor issue. 483 8. Security Considerations 485 The IPv6 Transition CE Router must comply with the Security 486 Considerations as stated in [RFC7084], as well as those stated by 487 each transition mechanism implemented by the IPv6 Transition CE 488 Router. 490 9. IANA Considerations 492 IANA is instructed, by means of this document, to create a new Option 493 Code for 464XLAT in the registry "Option Codes permitted in the S46 494 Priority Option", with a referente to this document, as follows. 496 +-------------+--------------------+-----------+ 497 | Option Code | S46 Mechanism | Reference | 498 +-------------+--------------------+-----------+ 499 | 113 | 464XLAT | [thisdoc] | 500 +-------------+--------------------+-----------+ 502 Table 1: DHCPv6 Option Code for 464XLAT 504 10. Acknowledgements 506 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 507 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 508 Ole Troan, James Woodyatt and ..., for their review and comments in 509 this and/or previous versions of this document. 511 11. Annex A: Usage Scenarios 513 The situation previously described, where there is ongoing IPv6 514 deployment and lack of IPv4 addresses, is not happening at the same 515 pace at every country, and even within every country, every ISP. For 516 different technical, financial, commercial/marketing and socio- 517 economic reasons, each network is transitioning at their own pace, 518 and nobody has a magic crystal ball, to make a guess. 520 Different studies (for example [IPv6Survey]) also show that this is a 521 changing situation, because in a single country, it may be that not 522 all operators provide IPv6 support, and consumers may switch ISPs and 523 use the same IPv6 Transition CE Router with an ISP that provides 524 IPv4-only and an ISP that provides IPv6 plus IPv4aaS. 526 So, it is clear that, to cover all those evolving situations, a IPv6 527 Transition CE Router is required, at least from the perspective of 528 the transition support, which can accommodate those changes. 530 Moreover, because some services will remain IPv4-only for an 531 undetermined time, and some service providers will remain IPv4-only 532 for an undetermined period of time, IPv4 will be needed for an 533 undetermined period of time. There will be a need for CEs with 534 support "IPv4 as-a-Service" for an undetermined period of time. 536 This document is consequently, based on those premises, in order to 537 ensure the continued transition from networks that today may provide 538 access with dual-stack or IPv6-in-IPv4, as described in [RFC7084], 539 and as an "extension" to it, evolving to an IPv6-only access with 540 IPv4-as-a-Service. 542 Considering that situation and different possible usage cases, the 543 IPv6 Transition CE Router described in this document is expected to 544 be used typically, in the following scenarios: 546 1. Residential/household, Small Office/Home Office (SOHO) and Small/ 547 Medium Enterprise (SME). Common usage is any kind of Internet 548 access (web, email, streaming, online gaming, etc.). 550 2. Residential/household and Small/Medium Enterprise (SME) with 551 advanced requirements. Same basic usage as for the previous 552 case, however there may be requirements for allowing inbound 553 connections (IP cameras, web, DNS, email, VPN, etc.). 555 The above list is not intended to be comprehensive of all the 556 possible usage scenarios, just an overall view. In fact, 557 combinations of the above usages are also possible, as well as 558 situations where the same CE is used at different times in different 559 scenarios or even different services providers that may use a 560 different transition mechanism. 562 The mechanisms for allowing inbound connections are "naturally" 563 available in any IPv6 router, as when using GUA, unless they are 564 blocked by firewall rules, which may require some manual 565 configuration by means of a GUI and/or CLI. 567 However, in the case of IPv4aaS, because the usage of private 568 addresses and NAT and even depending on the specific transition 569 mechanism, it typically requires some degree of more complex manual 570 configuration such as setting up a DMZ, virtual servers, or port/ 571 protocol forwarding. In general, IPv4 CE Routers already provide GUI 572 and/or CLI to manually configure them, or the possibility to setup 573 the CE in bridge mode, so another CE behind it, takes care of that. 575 It is out of the scope of this document the definition of any 576 requirements for that. 578 The main difference for a CE Router to support the above indicated 579 scenarios and number of users, is related to the packet processing 580 capabilities, performance, even other details such as the number of 581 WAN/LAN interfaces, their maximum speed, memory for keeping tables or 582 tracking connections, etc. It is out of the scope of this document 583 to classify them. 585 The actual bandwidth capabilities of access technologies such as 586 FTTH, cable and even 3GPP/LTE, allows the support of such scenarios, 587 and indeed, is a very common situation that access networks and CE 588 Router provided by the service provider are the same for SMEs and 589 residential users. 591 There is also no difference in terms of who actually provides the CE 592 Router. In most of the cases is the service provider, and in fact is 593 responsible, typically, of provisioning/managing at least the WAN 594 side. However, commonly the user has access to configure the LAN 595 interfaces, firewall, DMZ, and many other features. In fact, in many 596 cases, the user must supply or may replace the CE Router; this makes 597 even more relevant that all the CE Routers, support the same 598 requirements defined in this document. 600 The IPv6 Transition CE Router described in this document is not 601 intended for usage in other scenarios such as large Enterprises, Data 602 Centers, Content Providers, etc. So, even if the documented 603 requirements meet their needs, they may have additional requirements, 604 which are out of the scope of this document. 606 12. Annex B: End-User Network Architecture 608 According to the descriptions in the preceding sections, an end-user 609 network will likely support both IPv4 and IPv6. It is not expected 610 that an end user will change their existing network topology with the 611 introduction of IPv6. There are some differences in how IPv6 works 612 and is provisioned; these differences have implications for the 613 network architecture. 615 A typical IPv4 end-user network consists of a "plug and play" router 616 with NAT functionality and a single link upstream, connected to the 617 service provider network. 619 From the perspective of an "IPv4 user" behind an IPv6 transition 620 Customer Edge Router with IPv4aaS, this doesn't change. 622 However, while a typical IPv4 NAT deployment by default blocks all 623 incoming connections and may allow opening of ports using a Universal 624 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 625 other firewall control protocol, in the case of an IPv6-only access 626 and IPv4aaS, that may not be feasible depending on specific 627 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 628 may be an alternative solution. 630 Another consequence of using IPv4 private address space in the end- 631 user network is that it provides stable addressing; that is, it never 632 changes even when you change service providers, and the addresses are 633 always there even when the WAN interface is down or the customer edge 634 router has not yet been provisioned. In the case of an IPv6-only 635 access, there is no change on that if the transition mechanism keeps 636 running the NAT interface towards the LAN side. 638 More advanced routers support dynamic routing (which learns routes 639 from other routers), and advanced end-users can build arbitrary, 640 complex networks using manual configuration of address prefixes 641 combined with a dynamic routing protocol. Once again, this is true 642 for both, IPv4 and IPv6. 644 In general, the end-user network architecture for IPv6 should provide 645 equivalent or better capabilities and functionality than the current 646 IPv4 architecture. 648 The end-user network is a stub network, in the sense that is not 649 providing transit to other external networks. However, HNCP 650 ([RFC7788]) allows support for automatic provisioning of downstream 651 routers. Figure 1 illustrates the model topology for the end-user 652 network. 654 +---------------+ \ 655 | Service | \ 656 | Provider | | Service 657 | Router | | Provider 658 +-------+-------+ | Network 659 | / 660 | Customer / 661 | Internet Connection / 662 | 663 +------+--------+ \ 664 | IPv6 | \ 665 | Customer Edge | \ 666 | Router | / 667 +---+-------+---+ / 668 Network A | | Network B | 669 ---+----------------+-+- --+---+-------------+-- | 670 | | | | \ 671 +---+------+ | +----+-----+ +-----+----+ \ 672 |IPv6 Host | | | IPv4 Host| |IPv4/IPv6 | / 673 | | | | | | Host | / 674 +----------+ | +----------+ +----------+ / 675 | | 676 +------+--------+ | End-User 677 | IPv6 | | Network(s) 678 | Router | \ 679 +------+--------+ \ 680 Network C | \ 681 ---+-------------+--+--- | 682 | | | 683 +---+------+ +----+-----+ | 684 |IPv6 Host | |IPv6 Host | / 685 | | | | / 686 +----------+ +----------+ / 688 Figure 1: An Example of a Typical End-User Network 690 This architecture describes the: 692 o Basic capabilities of the IPv6 Transition CE Router 694 o Provisioning of the WAN interface connecting to the service 695 provider 697 o Provisioning of the LAN interfaces 699 The IPv6 Transition CE Router may be manually configured in an 700 arbitrary topology with a dynamic routing protocol or using HNCP 701 ([RFC7788]). Automatic provisioning and configuration is described 702 for a single IPv6 Transition CE Router only. 704 13. ANNEX C: Changes from -00 706 Section to be removed for WGLC. Significant updates are: 708 1. ID-Nits: IANA section. 710 2. ID-Nits: RFC7084 reference removed from Abstract. 712 3. This document no longer updates RFC7084. 714 4. UPnP section reworded. 716 5. "CE Router" changed to "IPv6 Transition CE Router". 718 6. Reduced text in Annex A. 720 14. ANNEX D: Changes from -01 722 Section to be removed for WGLC. Significant updates are: 724 1. TRANS requirements reworked in order to increase operator control 725 and allow gradual transitioning from dual-stack to IPv6-only on 726 specific customers. 728 2. New TRANS requirement so all the supported transition mechanisms 729 are disabled by default, in order to facilitate the operator 730 management. 732 3. New TRANS requirement in order to allow turning on/off each 733 transition mechanism by the user. 735 4. Clarification on how to obtain multiple /64 for 464XLAT. 737 5. S46 priority update to RFC8026 for including 464XLAT and related 738 changes in several sections. 740 15. ANNEX E: Changes from -02 742 Section to be removed for WGLC. Significant updates are: 744 1. RFC8026 update removed, not needed with new approach. 746 2. TRANS and 464XLAT requirements reworded in order to match new 747 approach to allow operator control on each/all the transition 748 mechanisms. 750 3. Added text in 464XLAT to clarify the usage. 752 16. References 754 16.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, 758 DOI 10.17487/RFC2119, March 1997, 759 . 761 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 762 Host Configuration Protocol (DHCP) version 6", RFC 3633, 763 DOI 10.17487/RFC3633, December 2003, 764 . 766 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 767 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 768 . 770 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 771 Infrastructures (6rd) -- Protocol Specification", 772 RFC 5969, DOI 10.17487/RFC5969, August 2010, 773 . 775 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 776 NAT64: Network Address and Protocol Translation from IPv6 777 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 778 April 2011, . 780 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 781 Beijnum, "DNS64: DNS Extensions for Network Address 782 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 783 DOI 10.17487/RFC6147, April 2011, 784 . 786 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 787 Stack Lite Broadband Deployments Following IPv4 788 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 789 . 791 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 792 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 793 RFC 6334, DOI 10.17487/RFC6334, August 2011, 794 . 796 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 797 Combination of Stateful and Stateless Translation", 798 RFC 6877, DOI 10.17487/RFC6877, April 2013, 799 . 801 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 802 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 803 DOI 10.17487/RFC6887, April 2013, 804 . 806 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 807 Play (UPnP) Internet Gateway Device - Port Control 808 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 809 DOI 10.17487/RFC6970, July 2013, 810 . 812 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 813 the IPv6 Prefix Used for IPv6 Address Synthesis", 814 RFC 7050, DOI 10.17487/RFC7050, November 2013, 815 . 817 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 818 Requirements for IPv6 Customer Edge Routers", RFC 7084, 819 DOI 10.17487/RFC7084, November 2013, 820 . 822 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 823 Port Control Protocol (PCP)", RFC 7225, 824 DOI 10.17487/RFC7225, May 2014, 825 . 827 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 828 the Port Control Protocol (PCP)", RFC 7291, 829 DOI 10.17487/RFC7291, July 2014, 830 . 832 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 833 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 834 RFC 7341, DOI 10.17487/RFC7341, August 2014, 835 . 837 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 838 Farrer, "Lightweight 4over6: An Extension to the Dual- 839 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 840 July 2015, . 842 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 843 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 844 Port with Encapsulation (MAP-E)", RFC 7597, 845 DOI 10.17487/RFC7597, July 2015, 846 . 848 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 849 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 850 Configuration of Softwire Address and Port-Mapped 851 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 852 . 854 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 855 and T. Murakami, "Mapping of Address and Port using 856 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 857 2015, . 859 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 860 Length Recommendation for Forwarding", BCP 198, RFC 7608, 861 DOI 10.17487/RFC7608, July 2015, 862 . 864 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 865 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 866 RFC 7618, DOI 10.17487/RFC7618, August 2015, 867 . 869 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 870 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 871 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 872 November 2016, . 874 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 875 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 876 over an IPv6 Multicast Network", RFC 8114, 877 DOI 10.17487/RFC8114, March 2017, 878 . 880 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 881 Option for IPv4-Embedded Multicast and Unicast IPv6 882 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 883 . 885 16.2. Informative References 887 [IPv6Survey] 888 Palet Martinez, J., "IPv6 Deployment Survey", January 889 2018, 890 . 893 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 894 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 895 2016, . 897 [UPnP-IGD] 898 UPnP Forum, "InternetGatewayDevice:2 Device Template 899 Version 1.01", December 2010, 900 . 902 Authors' Addresses 904 Jordi Palet Martinez 905 The IPv6 Company 906 Molino de la Navata, 75 907 La Navata - Galapagar, Madrid 28420 908 Spain 910 Email: jordi.palet@theipv6company.com 911 URI: http://www.theipv6company.com/ 913 Hans M.-H. Liu 914 D-Link Systems, Inc. 915 17595 Mount Herrmann St. 916 Fountain Valley, California 92708 917 US 919 Email: hans.liu@dlinkcorp.com 920 URI: http://www.dlink.com/ 922 Masanobu Kawashima 923 NEC Platforms, Ltd. 924 800, Shimomata 925 Kakegawa-shi, Shizuoka 436-8501 926 Japan 928 Email: kawashimam@vx.jp.nec.com 929 URI: https://www.necplatforms.co.jp/en/