idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-05.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 (July 20, 2018) is 2104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-pref64folks-6man-ra-pref64-00 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 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: January 21, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 July 20, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-05 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 January 21, 2019. 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. LAN-Side Configuration . . . . . . . . . . . . . . . . . 4 70 3.2. Transition Technologies Support for IPv4 Service 71 Continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 5 72 3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 7 74 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 8 75 3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 10 78 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. Differences from RFC7084 . . . . . . . . . . . . . . . . . . 10 80 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 12 85 12. Annex B: End-User Network Architecture . . . . . . . . . . . 14 86 13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 16 87 14. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 16 88 15. ANNEX E: Changes from -02 . . . . . . . . . . . . . . . . . . 16 89 16. ANNEX F: Changes from -03 . . . . . . . . . . . . . . . . . . 17 90 17. ANNEX F: Changes from -04 . . . . . . . . . . . . . . . . . . 17 91 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 18.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 rely upon "Basic Requirements for IPv6 Customer Edge 105 Routers" ([RFC7084]), so the scope of this document is to ensure the 106 IPv4 "service continuity" support, in the LAN side and the access to 107 IPv4-only Internet services from an IPv6-only access WAN even from 108 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. LAN-Side Configuration 183 A new LAN requirement is added, which in fact is common in regular 184 IPv6 Transition CE Router, and it is required by most of the 185 transition mechanisms: 187 L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as 188 described in [RFC5625] (DNS Proxy Implementation Guidelines). 190 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4 191 as-a-Service - IPv4aaS) 193 The main target of this document is the support of IPv6-only WAN 194 access. To enable legacy IPv4 functionality, this document also 195 includes the support of IPv4-only devices and applications in the 196 customers LANs, as well as IPv4-only services on the Internet. Thus, 197 both IPv4-only and the IPv6-only devices inside the IPv6 Transition 198 CE Router are able to reach the IPv4-only services. 200 This document takes no position on simultaneous operation of one or 201 several transition mechanism and/or native IPv4. 203 In order to seamlessly provide the IPv4 Service Continuity in 204 Customer LANs, allowing an automated IPv6 transition mechanism 205 provisioning, general transition requirements are defined. 207 General transition requirements: 209 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 210 priority options described in [RFC8026] (Unified IPv4-in- 211 IPv6 Softwire Customer Premises Equipment (CPE): A 212 DHCPv6-Based Prioritization Mechanism). 214 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or 215 API option to manually enable/disable each of the supported 216 transition mechanisms. 218 TRANS-3: The IPv6 Transition CE Router MUST request the relevant 219 configuration options for each supported transition 220 mechanisms, which MUST remain disabled at this step. 222 TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of 223 [RFC8026], MUST check for a valid match in 224 OPTION_S46_PRIORITY, which allows enabling/disabling a 225 transition mechanism. 227 TRANS-5: In order to allow the service provider to disable all the 228 transition mechanisms, the IPv6 Transition CE Router MUST 229 NOT enable any transition mechanisms if no match is found 230 between the priority list and the candidate list. 232 The following sections describe the requirements for supporting each 233 one of the transition mechanisms. 235 3.2.1. 464XLAT 237 464XLAT [RFC6877] is a technique to provide IPv4 service over an 238 IPv6-only access network without encapsulation. This architecture 239 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 240 Protocol Translation from IPv6 Clients to IPv4 Servers) function 241 deployed at the service provider or a third-party network. 243 The IPv6 Transition CE Router SHOULD support CLAT functionality. If 244 464XLAT is supported, it MUST be implemented according to [RFC6877]. 245 The following IPv6 Transition CE Router requirements also apply: 247 464XLAT requirements: 249 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 250 Address Translation (NAT) on IPv4 traffic translated 251 using the CLAT, unless a dedicated /64 prefix has been 252 acquired, either using DHCPv6-PD [RFC3633] (IPv6 Prefix 253 Options for DHCPv6) or by alternative means. 255 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 256 [RFC6970] (UPnP Internet Gateway Device - Port Control 257 Protocol Interworking Function). 259 464XLAT-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 260 Router MUST also implement [RFC7291] (DHCP Options for 261 the PCP). Following ([RFC6887]), if no PCP server is 262 configured, the IPv6 Transition CE Router MAY verify if 263 the default gateway, or the NAT64 is the PCP server. A 264 plain IPv6 mode MUST be used to send PCP requests to the 265 server. 267 464XLAT-4: The IPv6 Transition CE Router MUST implement 268 [I-D.pref64folks-6man-ra-pref64] (Discovering PREF64 in 269 Router Advertisements) and [RFC7050] (Discovery of the 270 IPv6 Prefix Used for IPv6 Address Synthesis) in order to 271 discover the PLAT-side translation IPv4 and IPv6 272 prefix(es)/suffix(es). 274 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 275 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 276 the PCP), in order to learn the PLAT-side translation 277 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 278 PCP-controlled NAT64 device. 280 464XLAT-6: [RFC8115] MUST be implemented and a DHCPv6 Option 281 "OPTION_V6_PREFIX64" ([RFC8115]), with zeroed 282 ASM_mPrefix64 and SSM_mPrefix64, MUST also be considered 283 as a valid NAT64 prefix (uPrefix64). 285 464XLAT-7: The priority for the NAT64 prefix, in case the network 286 provides several choices, MUST be: 1) [RFC7225], 2) 287 [RFC8115], 3) [I-D.pref64folks-6man-ra-pref64] and 4) 288 [RFC7050]. 290 464XLAT-8: 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.2.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.2.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.2.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.2.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 An 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 Lorenzo Colitti, for their review and 519 comments in 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, an 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, CLI and/or API. 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. ANNEX F: Changes from -04 772 Section to be removed for WGLC. Significant updates are: 774 1. Removed G-1. 776 2. Added support for draft-pref64folks-6man-ra-pref64. 778 3. General text clarifications. 780 18. References 782 18.1. Normative References 784 [I-D.pref64folks-6man-ra-pref64] 785 Colitti, L., Kline, E., and J. Linkova, "Discovering 786 PREF64 in Router Advertisements", draft-pref64folks-6man- 787 ra-pref64-00 (work in progress), July 2018. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 795 Host Configuration Protocol (DHCP) version 6", RFC 3633, 796 DOI 10.17487/RFC3633, December 2003, 797 . 799 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 800 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 801 . 803 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 804 Infrastructures (6rd) -- Protocol Specification", 805 RFC 5969, DOI 10.17487/RFC5969, August 2010, 806 . 808 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 809 NAT64: Network Address and Protocol Translation from IPv6 810 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 811 April 2011, . 813 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 814 Beijnum, "DNS64: DNS Extensions for Network Address 815 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 816 DOI 10.17487/RFC6147, April 2011, 817 . 819 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 820 Stack Lite Broadband Deployments Following IPv4 821 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 822 . 824 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 825 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 826 RFC 6334, DOI 10.17487/RFC6334, August 2011, 827 . 829 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 830 Combination of Stateful and Stateless Translation", 831 RFC 6877, DOI 10.17487/RFC6877, April 2013, 832 . 834 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 835 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 836 DOI 10.17487/RFC6887, April 2013, 837 . 839 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 840 Play (UPnP) Internet Gateway Device - Port Control 841 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 842 DOI 10.17487/RFC6970, July 2013, 843 . 845 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 846 the IPv6 Prefix Used for IPv6 Address Synthesis", 847 RFC 7050, DOI 10.17487/RFC7050, November 2013, 848 . 850 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 851 Requirements for IPv6 Customer Edge Routers", RFC 7084, 852 DOI 10.17487/RFC7084, November 2013, 853 . 855 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 856 Port Control Protocol (PCP)", RFC 7225, 857 DOI 10.17487/RFC7225, May 2014, 858 . 860 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 861 the Port Control Protocol (PCP)", RFC 7291, 862 DOI 10.17487/RFC7291, July 2014, 863 . 865 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 866 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 867 RFC 7341, DOI 10.17487/RFC7341, August 2014, 868 . 870 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 871 Farrer, "Lightweight 4over6: An Extension to the Dual- 872 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 873 July 2015, . 875 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 876 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 877 Port with Encapsulation (MAP-E)", RFC 7597, 878 DOI 10.17487/RFC7597, July 2015, 879 . 881 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 882 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 883 Configuration of Softwire Address and Port-Mapped 884 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 885 . 887 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 888 and T. Murakami, "Mapping of Address and Port using 889 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 890 2015, . 892 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 893 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 894 RFC 7618, DOI 10.17487/RFC7618, August 2015, 895 . 897 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 898 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 899 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 900 November 2016, . 902 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 903 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 904 over an IPv6 Multicast Network", RFC 8114, 905 DOI 10.17487/RFC8114, March 2017, 906 . 908 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 909 Option for IPv4-Embedded Multicast and Unicast IPv6 910 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 911 . 913 18.2. Informative References 915 [IPv6Survey] 916 Palet Martinez, J., "IPv6 Deployment Survey", January 917 2018, 918 . 921 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 922 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 923 2016, . 925 [UPnP-IGD] 926 UPnP Forum, "InternetGatewayDevice:2 Device Template 927 Version 1.01", December 2010, 928 . 930 Authors' Addresses 932 Jordi Palet Martinez 933 The IPv6 Company 934 Molino de la Navata, 75 935 La Navata - Galapagar, Madrid 28420 936 Spain 938 Email: jordi.palet@theipv6company.com 939 URI: http://www.theipv6company.com/ 941 Hans M.-H. Liu 942 D-Link Systems, Inc. 943 17595 Mount Herrmann St. 944 Fountain Valley, California 92708 945 US 947 Email: hans.liu@dlinkcorp.com 948 URI: http://www.dlink.com/ 949 Masanobu Kawashima 950 NEC Platforms, Ltd. 951 800, Shimomata 952 Kakegawa-shi, Shizuoka 436-8501 953 Japan 955 Email: kawashimam@vx.jp.nec.com 956 URI: https://www.necplatforms.co.jp/en/