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