idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-10.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 (October 16, 2018) is 2018 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: April 19, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 October 16, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-10 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 through 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). This is 26 required in a world where sufficient IPv4 addresses are no longer 27 available for every possible customer/device. However, devices or 28 applications in the customer LANs may be IPv4-only or IPv6-only and 29 still need to communicate with IPv4-only services at the Internet. 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 April 19, 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 . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 5 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. Comparison to RFC7084 . . . . . . . . . . . . . . . . . . . . 11 80 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 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 G: Changes from -04 . . . . . . . . . . . . . . . . . . 17 91 18. ANNEX H: Changes from -05 . . . . . . . . . . . . . . . . . . 17 92 19. ANNEX I: Changes from -06 . . . . . . . . . . . . . . . . . . 17 93 20. ANNEX J: Changes from -07 . . . . . . . . . . . . . . . . . . 17 94 21. ANNEX K: Changes from -08 . . . . . . . . . . . . . . . . . . 18 95 22. ANNEX K: Changes from -09 . . . . . . . . . . . . . . . . . . 18 96 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 23.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 23.2. Informative References . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 This document defines IPv4 service continuity features over an 104 IPv6-only network, for a residential or small-office router, referred 105 to as an "IPv6 Transition CE Router", in order to establish an 106 industry baseline for transition features to be implemented on such a 107 router. 109 These routers rely upon "Basic Requirements for IPv6 Customer Edge 110 Routers" ([RFC7084]), so the scope of this document is to ensure the 111 IPv4 "service continuity" support, in the LAN side and the access to 112 IPv4-only Internet services from an IPv6-only access WAN even from 113 IPv6-only applications or devices in the LAN side. 115 This document covers a set of IP transition techniques required when 116 ISPs have, or want to have, an IPv6-only access network. This is a 117 common situation in a world where sufficient public IPv4 addresses 118 are no longer available for every possible customer and device, and 119 become prohibitive expense, so the service providers need to 120 provision IPv6-only WAN access. At the same time, they need to 121 ensure that both IPv4-only and IPv6-only devices or applications in 122 the customer networks can still reach IPv4-only devices and 123 applications in the Internet. 125 This document specifies the IPv4 service continuity mechanisms to be 126 supported by an IPv6 Transition CE Router, and relevant provisioning 127 or configuration information differences from [RFC7084]. 129 This document is not a recommendation for service providers to use 130 any specific transition mechanism. 132 Automatic provisioning of more complex topology than a single router 133 with multiple LAN interfaces may be handled by means of HNCP 134 ([RFC7788]), which is out of the scope of this document. 136 Service providers who specify feature sets for IPv6 Transition CE 137 Router may specify a different set of features than those included in 138 this document. Since it is impossible to know prior to sale which 139 transition mechanism a device will need over the lifetime of the 140 device, IPv6 Transition CE Router intended for the retail market MUST 141 support all the IPv4aaS transition mechanism supported by this 142 document. 144 A complete description of "Usage Scenarios" and "End-User Network 145 Architecture" is provided in Annexes A and B, respectively. 147 1.1. Requirements Language - Special Note 149 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document, are not used as described in RFC 2119 [RFC2119]. This 152 document uses these keywords not strictly for the purpose of 153 interoperability, but rather for the purpose of establishing 154 industry-common baseline functionality. As such, the document points 155 to several other specifications to provide additional guidance to 156 implementers regarding any protocol implementation required to 157 produce a successful IPv6 Transition CE Router that interoperates 158 successfully with a particular subset of currently deploying and 159 planned common IPv6-only access networks. 161 Additionally, the keyword "DEFAULT" is to be interpreted in this 162 document as pertaining to a configuration as applied by a vendor, 163 prior to the administrator changing it for its initial activation. 165 2. Terminology 167 This document uses the same terms as in [RFC7084], with minor 168 clarifications. 170 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 171 technologies for delivering IPv4 in IPv6-only connectivity. 173 The term "IPv6 transition Customer Edge Router with IPv4aaS" 174 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 175 Customer Edge Router" that provides features for the delivery of IPv4 176 services over an IPv6-only WAN network, including IPv6-IPv4 177 communications. 179 The "WAN Interface" term used across this document, defines an IPv6 180 Transition CE Router attachment to an IPv6-only link used to provide 181 connectivity to a service provider network, including link Internet- 182 layer (or higher layers) "tunnels", such as IPv4-in-IPv6 tunnels. 184 3. Requirements 186 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 187 Requirements for IPv6 Customer Edge Routers) and this document add 188 new requirements, as described in the following sub-sections. 190 3.1. LAN-Side Configuration 192 A new LAN requirement is added, which in fact is common in regular 193 IPv6 Transition CE Router, and it is required by most of the 194 transition mechanisms: 196 L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as 197 described in [RFC5625] (DNS Proxy Implementation Guidelines). 199 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4 200 as-a-Service - IPv4aaS) 202 The main target of this document is the support of IPv6-only WAN 203 access. To enable legacy IPv4 functionality, this document also 204 includes the support of IPv4-only devices and applications in the 205 customers LANs, as well as IPv4-only services on the Internet. Thus, 206 both IPv4-only and the IPv6-only devices in the customer-side LANs of 207 the IPv6 Transition CE Router are able to reach the IPv4-only 208 services. 210 This document takes no position on simultaneous operation of one or 211 several transition mechanisms and/or native IPv4. 213 In order to seamlessly provide the IPv4 Service Continuity in 214 Customer LANs, allowing an automated IPv6 transition mechanism 215 provisioning, general transition requirements are defined. 217 General transition requirements: 219 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 220 priority options described in [RFC8026] (Unified IPv4-in- 221 IPv6 Softwire Customer Premises Equipment (CPE): A 222 DHCPv6-Based Prioritization Mechanism). 224 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or 225 API option to manually enable/disable each of the supported 226 transition mechanisms. 228 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN 229 subnet, the IPv6 Transition CE Router MUST allow 230 appropriate subnetting and configuring the address space 231 (which may depend on each transition mechanism) among the 232 several interfaces. In some transition mechanisms, this 233 may require differentiating mappings/translations per 234 interfaces. 236 In order to allow the service provider to disable all the transition 237 mechanisms and/or choose the most convenient one, the IPv6 Transition 238 CE Router MUST follow the following configuration steps: 240 CONFIG-1: Request the relevant configuration options for each 241 supported transition mechanisms, which MUST remain 242 disabled at this step. 244 CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid 245 match in OPTION_S46_PRIORITY, which allows enabling/ 246 disabling a transition mechanism. 248 CONFIG-3: Keep disabled all the transition mechanisms if no match is 249 found between the priority list and the candidate list. 251 The following sections describe the requirements for supporting each 252 one of the transition mechanisms. An IPv6 Transition CE Router 253 intended for the retail market MUST support all of them. 255 3.2.1. 464XLAT 257 464XLAT [RFC6877] is a technique to provide IPv4 service over an 258 IPv6-only access network without encapsulation. This architecture 259 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 260 Protocol Translation from IPv6 Clients to IPv4 Servers) function 261 deployed at the service provider or a third-party network. 263 The IPv6 Transition CE Router SHOULD support CLAT functionality. If 264 464XLAT is supported, it MUST be implemented according to [RFC6877]. 265 The following IPv6 Transition CE Router requirements also apply: 267 464XLAT requirements: 269 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 270 Address Translation (NAT) on IPv4 traffic translated 271 using the CLAT, unless a dedicated /64 prefix has been 272 acquired, either using DHCPv6-PD [RFC3633] (IPv6 Prefix 273 Options for DHCPv6) or by alternative means. 275 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 276 [RFC6970] (UPnP Internet Gateway Device - Port Control 277 Protocol Interworking Function). 279 464XLAT-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 280 Router MUST also implement [RFC7291] (DHCP Options for 281 the PCP). Following ([RFC6887]), if no PCP server is 282 configured, the IPv6 Transition CE Router MAY verify if 283 the default gateway, or the NAT64 is the PCP server. 284 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is 285 used) MUST be used to send PCP requests to the server. 287 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 288 (Discovery of the IPv6 Prefix Used for IPv6 Address 289 Synthesis) in order to discover the PLAT-side translation 290 IPv4 and IPv6 prefix(es)/suffix(es). 292 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 293 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 294 the PCP), in order to learn the PLAT-side translation 295 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 296 PCP-controlled NAT64 device. 298 464XLAT-6: [RFC8115] MUST be implemented and a DHCPv6 Option 299 "OPTION_V6_PREFIX64" ([RFC8115]), with zeroed 300 ASM_mPrefix64 and SSM_mPrefix64, MUST also be considered 301 as a valid NAT64 prefix (uPrefix64). 303 464XLAT-7: The priority for the NAT64 prefix, in case the network 304 provides several choices, MUST be: 1) [RFC7225], 2) 305 [RFC8115], and 3) [RFC7050]. 307 464XLAT-8: If a DHCPv6 Option "OPTION_V6_PREFIX64" ([RFC8115]), with 308 zeroed ASM_mPrefix64 and SSM_mPrefix64 provides a NAT64 309 prefix, or one or more NAT64 prefixes are learnt by means 310 of either [RFC7050] or [RFC7225], then 464XLAT MUST be 311 included in the candidate list of possible S46 mechanism 312 (Section 1.4.1 of [RFC8026]). 314 The NAT64 prefix could be discovered by means of [RFC7050] only in 315 the case the service provider uses DNS64 ([RFC6147]). If DNS64 316 ([RFC6147]) is not used, or not trusted, as the DNS configuration at 317 the CE (or hosts behind the CE) may be modified by the customer, then 318 the service provider may opt to configure the NAT64 prefix either by 319 means of [RFC7225] or [RFC8115], which also can be used if the 320 service provider uses DNS64 ([RFC6147]). 322 3.2.2. Dual-Stack Lite (DS-Lite) 324 Dual-Stack Lite [RFC6333] enables continued support for IPv4 325 services. Dual-Stack Lite enables a broadband service provider to 326 share IPv4 addresses among customers by combining two well-known 327 technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation 328 (NAT). It is expected that DS-Lite traffic is forwarded over the 329 IPv6 Transition CE Router's native IPv6 WAN interface, and not 330 encapsulated in another tunnel. 332 The IPv6 Transition CE Router SHOULD implement DS-Lite B4 333 functionality [RFC6333]. If DS-Lite is supported, it MUST be 334 implemented according to [RFC6333]. The following IPv6 Transition CE 335 Router requirements also apply: 337 DS-Lite requirements: 339 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 340 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 341 Option for Dual-Stack Lite). The IPv6 Transition CE 342 Router MAY use other mechanisms to configure DS-Lite 343 parameters. Such mechanisms are outside the scope of this 344 document. 346 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 347 [RFC6970] (UPnP Internet Gateway Device - Port Control 348 Protocol Interworking Function). 350 DSLITE-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 351 Router SHOULD implement [RFC7291] (DHCP Options for the 352 PCP). If PCP ([RFC6887]) is implemented and a PCP server 353 is not configured, the IPv6 Transition CE Router MUST 354 assume, by DEFAULT, that the AFTR is the PCP server. 355 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is 356 used) MUST be used to send PCP requests to the server. 358 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 359 Network Address Translation (NAT) on IPv4 traffic 360 encapsulated using DS-Lite ([RFC6333]). 362 3.2.3. Lightweight 4over6 (lw4o6) 364 lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the 365 NAPT function from the DS-Lite tunnel concentrator to the tunnel 366 client located in the IPv6 Transition CE Router, removing the 367 requirement for a CGN function in the tunnel concentrator and 368 reducing the amount of centralized state. 370 The IPv6 Transition CE Router SHOULD implement lwB4 functionality 371 [RFC7596]. If DS-Lite is implemented, lw4o6 SHOULD be implemented as 372 well. If lw4o6 is supported, it MUST be implemented according to 373 [RFC7596]. The following IPv6 Transition CE Router requirements also 374 apply: 376 lw4o6 requirements: 378 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 379 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 380 Options for Configuration of Softwire Address and Port- 381 Mapped Clients). The IPv6 Transition CE Router MAY use 382 other mechanisms to configure lw4o6 parameters. Such 383 mechanisms are outside the scope of this document. 385 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 386 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 387 over-DHCPv6 Transport). 389 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 390 Allocation of Shared IPv4 Addresses as described in 391 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 393 3.2.4. MAP-E 395 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 396 an IPv6 network using IP encapsulation, including an algorithmic 397 mechanism for mapping between IPv6 and IPv4 addresses. 399 The IPv6 Transition CE Router SHOULD support MAP-E CE functionality 400 [RFC7597]. If MAP-E is supported, it MUST be implemented according 401 to [RFC7597]. The following IPv6 Transition CE Router requirements 402 also apply: 404 MAP-E requirements: 406 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 407 MAP-E via the MAP-E 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-E parameters. Such mechanisms 411 are outside the scope of this document. 413 MAPE-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 3.2.5. MAP-T 419 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 420 that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as 421 the form of IPv6 domain transport. 423 The IPv6 Transition CE Router SHOULD support MAP-T CE functionality 424 [RFC7599]. If MAP-T is supported, it MUST be implemented according 425 to [RFC7599]. The following IPv6 Transition CE Router requirements 426 also apply: 428 MAP-T requirements: 430 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 431 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 432 for Configuration of Softwire Address and Port-Mapped 433 Clients). The IPv6 Transition CE Router MAY use other 434 mechanisms to configure MAP-T parameters. Such mechanisms 435 are outside the scope of this document. 437 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 438 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 439 Allocation of Shared IPv4 Addresses). 441 4. IPv4 Multicast Support 443 Existing IPv4 deployments support IPv4 multicast for services such as 444 IPTV. In the transition phase, it is expected that multicast 445 services will still be provided using IPv4 to the customer LANs. 447 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 448 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 449 Services to IPv4 Clients over an IPv6 Multicast Network) and 450 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 451 Prefixes). 453 5. UPnP Support 455 If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a 456 CE router, but cannot be associated with an IPv4 interface 457 established by an IPv4aaS mechanism or cannot determine which ports 458 are available, an AddPortMapping() or AddAnyPortMapping() action MUST 459 be rejected with error code 729 "ConflictWithOtherMechanisms". Port 460 availability could be determined through PCP or access to a 461 configured port set (if the IPv4aaS mechanism limits the available 462 ports). 464 An AddPortMapping() request for a port that is not available MUST 465 result in "ConflictInMappingEntry". 467 An AddAnyPortMapping() request for a port that is not available 468 SHOULD result in a successful mapping with an alternative 469 "NewReservedPort" value from within the configured port set range, or 470 as assigned by PCP as per [RFC6970], Section 5.6.1. 472 Note that IGD:1 and its WANIPConnection:1 service have been 473 deprecated by OCF. 475 6. Comparison to RFC7084 477 This document doesn't include support for 6rd ([RFC5969]), because as 478 in an IPv6-in-IPv4 tunneling. 480 Regarding DS-LITE [RFC6333], this document includes slightly 481 different requirements, because the PCP ([RFC6887]) support and the 482 prioritization of the transition mechanisms, including dual-stack. 484 7. Code Considerations 486 One of the apparent main issues for vendors to include new 487 functionalities, such as support for new transition mechanisms, is 488 the lack of space in the flash (or equivalent) memory. However, it 489 has been confirmed from existing open source implementations 490 (OpenWRT/LEDE, Linux, others), that adding the support for the new 491 transitions mechanisms, requires around 10-12 Kbytes (because most of 492 the code base is shared among several transition mechanisms already 493 supported by [RFC7084]), as a single data plane is common to all 494 them, which typically means about 0,15% of the existing code size in 495 popular CEs already in the market [OpenWRT]. 497 In general, the new requirements don't have extra cost in terms of 498 RAM memory, neither other hardware requirements such as more powerful 499 CPUs, if compared to the cost of NAT44 code so, existing hardware 500 supports them with minimal impact. 502 The other issue seems to be the cost of developing the code for those 503 new functionalities. However, at the time of writing this document, 504 it has been confirmed that there are several open source versions of 505 the required code for supporting all the new transition mechanisms, 506 and even several vendors already have implementations and provide it 507 to ISPs, so the development cost is negligible, and only integration 508 and testing cost may become a minor issue. 510 8. Security Considerations 512 The IPv6 Transition CE Router must comply with the Security 513 Considerations as stated in [RFC7084], as well as those stated by 514 each transition mechanism implemented by the IPv6 Transition CE 515 Router. 517 9. IANA Considerations 519 IANA is requested, by means of this document, to update the "Option 520 Codes permitted in the S46 Priority Option" registry available at 521 https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 522 parameters.xhtml#option-codes-s46-priority-option, with the following 523 entry. 525 +-------------+--------------------+-----------+ 526 | Option Code | S46 Mechanism | Reference | 527 +-------------+--------------------+-----------+ 528 | 113 | 464XLAT | [thisdoc] | 529 +-------------+--------------------+-----------+ 531 Table 1: DHCPv6 Option Code for 464XLAT 533 10. Acknowledgements 535 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 536 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 537 Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, 538 for their review and comments in this and/or previous versions of 539 this document. 541 11. Annex A: Usage Scenarios 543 The situation previously described, where there is ongoing IPv6 544 deployment and lack of IPv4 addresses, is not happening at the same 545 pace in every country, and even within every country, every ISP. For 546 different technical, financial, commercial/marketing and socio- 547 economic reasons, each network is transitioning at their own pace, 548 and nobody has a magic crystal ball to make a guess of the global 549 transition timings. 551 Different studies (for example [IPv6Survey]) also show that the IPv6 552 deployment is a changing situation. In a single country, it may 553 happen that not all operators provide IPv6 support, and consumers may 554 switch ISPs and use the same IPv6 Transition CE Router with an ISP 555 that provides IPv4-only and an ISP that provides IPv6 with IPv4aaS. 557 So, it is clear that, to cover all those evolving situations, an IPv6 558 Transition CE Router is required, at least from the perspective of 559 the transition support, which can accommodate those changes. 561 Moreover, because some services will remain IPv4-only for an 562 undetermined time, and some service providers will remain IPv4-only 563 for an undetermined period of time, IPv4 will be needed for an 564 undetermined period of time. There will be a need for CEs with 565 support "IPv4 as-a-Service" for an undetermined period of time. 567 This document, based on those premises, ensures that the IPv6 568 Transition CE Router allows the continued transition from networks 569 that today may provide access with dual-stack or IPv6-in-IPv4, as 570 described in [RFC7084], and as an "extension" to it, evolve to an 571 IPv6-only access with IPv4-as-a-Service. 573 Considering that situation and different possible usage cases, the 574 IPv6 Transition CE Router described in this document is expected to 575 be used typically, in residential/household, Small Office/Home Office 576 (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind 577 of Internet access (web, email, streaming, online gaming, etc.) and 578 even more advanced requirements including inbound connections (IP 579 cameras, web, DNS, email, VPN, etc.). 581 The above is not intended to be comprehensive list of all the 582 possible usage cases, just an overall view. In fact, combinations of 583 the above usages are also possible, as well as situations where the 584 same CE is used at different times in different scenarios or even 585 different services providers that may use a different transition 586 mechanism. 588 The mechanisms for allowing inbound connections are "naturally" 589 available in any IPv6 router, when using GUA (IPv6 Global Unicast 590 Addresses), unless they are blocked by firewall rules, which may 591 require some manual configuration by means of a GUI, CLI and/or API. 593 However, in the case of IPv4aaS, because the usage of private 594 addresses and NAT and even depending on the specific transition 595 mechanism, inbound connections typically require some degree of more 596 complex manual configuration such as setting up a DMZ, virtual 597 servers, or port/protocol forwarding. In general, IPv4 CE Routers 598 already provide a GUI and/or a CLI to manually configure them, or the 599 possibility to setup the CE in bridge mode, so another CE behind it, 600 takes care of that. The requirements for that support are out of the 601 scope of this document. 603 It is not relevant who provides the IPv6 Transition CE Router. In 604 most of the cases is the service provider, and in fact is 605 responsible, typically, of provisioning/managing at least the WAN 606 side. However, commonly the user has access to configure the LAN 607 interfaces, firewall, DMZ, and many other features. However, in 608 fact, in many cases, the user must supply or may replace the IPv6 609 Transition CE Router. This makes even more relevant that all the 610 IPv6 Transition CE Routers support the same requirements defined in 611 this document. 613 The IPv6 Transition CE Router described in this document is not 614 intended for usage in other scenarios such as large Enterprises, Data 615 Centers, Content Providers, etc. So even if the documented 616 requirements meet their needs, they may have additional requirements, 617 which are out of the scope of this document. 619 12. Annex B: End-User Network Architecture 621 According to the descriptions in the preceding sections, an end-user 622 network will likely support both IPv4 and IPv6. It is not expected 623 that an end user will change their existing network topology with the 624 introduction of IPv6. There are some differences in how IPv6 works 625 and is provisioned; these differences have implications for the 626 network architecture. 628 A typical IPv4 end-user network consists of a "plug and play" router 629 with NAT functionality and a single link upstream, connected to the 630 service provider network. 632 From the perspective of an "IPv4 user" behind an IPv6 transition 633 Customer Edge Router with IPv4aaS, this doesn't change. 635 However, while a typical IPv4 NAT deployment by default blocks all 636 incoming connections and may allow opening of ports using a Universal 637 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 638 other firewall control protocol, in the case of an IPv6-only access 639 and IPv4aaS, that may not be feasible depending on specific 640 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 641 may be an alternative solution. 643 Another consequence of using IPv4 private address space in the end- 644 user network is that it provides stable addressing; that is, it 645 doesn't change, even when you change service providers, and the 646 addresses are always usable even when the WAN interface is down or 647 the customer edge router has not yet been provisioned. In the case 648 of an IPv6-only access, private IPv4 addresses are also available if 649 the IPv4aaS transition mechanism keeps running the NAT interface 650 towards the LAN side when the WAN interface is down. 652 More advanced routers support dynamic routing (which learns routes 653 from other routers), and advanced end-users can build arbitrary, 654 complex networks using manual configuration of address prefixes 655 combined with a dynamic routing protocol. Once again, this is true 656 for both, IPv4 and IPv6. 658 In general, the end-user network architecture for IPv6 should provide 659 equivalent or better capabilities and functionality than the current 660 IPv4 architecture. 662 The end-user network is a stub network, in the sense that is not 663 providing transit to other external networks. However, HNCP 664 ([RFC7788]) allows support for automatic provisioning of downstream 665 routers. Figure 1 illustrates the model topology for the end-user 666 network. 668 +---------------+ \ 669 | Service | \ 670 | Provider | | Service 671 | Router | | Provider 672 +-------+-------+ | Network 673 | / 674 | Customer / 675 | Internet Connection / 676 | 677 +------+--------+ \ 678 | IPv6 | \ 679 | Customer Edge | \ 680 | Router | / 681 +---+-------+---+ / 682 Network A | | Network B | 683 ---+----------------+-+- --+---+-------------+-- | 684 | | | | \ 685 +---+------+ | +----+-----+ +-----+----+ \ 686 |IPv6 Host | | | IPv4 Host| |IPv4/IPv6 | / 687 | | | | | | Host | / 688 +----------+ | +----------+ +----------+ / 689 | | 690 +------+--------+ | End-User 691 | IPv6 | | Network(s) 692 | Router | \ 693 +------+--------+ \ 694 Network C | \ 695 ---+-------------+--+--- | 696 | | | 697 +---+------+ +----+-----+ | 698 |IPv6 Host | |IPv6 Host | / 699 | | | | / 700 +----------+ +----------+ / 702 Figure 1: An Example of a Typical End-User Network 704 This architecture describes the: 706 o Basic capabilities of the IPv6 Transition CE Router 708 o Provisioning of the WAN interface connecting to the service 709 provider 711 o Provisioning of the LAN interfaces 713 The IPv6 Transition CE Router may be manually configured in an 714 arbitrary topology with a dynamic routing protocol or using HNCP 715 ([RFC7788]). Automatic provisioning and configuration is described 716 for a single IPv6 Transition CE Router only. 718 13. ANNEX C: Changes from -00 720 Section to be removed for WGLC. Significant updates are: 722 1. ID-Nits: IANA section. 724 2. ID-Nits: RFC7084 reference removed from Abstract. 726 3. This document no longer updates RFC7084. 728 4. UPnP section reworded. 730 5. "CE Router" changed to "IPv6 Transition CE Router". 732 6. Reduced text in Annex A. 734 14. ANNEX D: Changes from -01 736 Section to be removed for WGLC. Significant updates are: 738 1. TRANS requirements reworked in order to increase operator control 739 and allow gradual transitioning from dual-stack to IPv6-only on 740 specific customers. 742 2. New TRANS requirement so all the supported transition mechanisms 743 are disabled by default, in order to facilitate the operator 744 management. 746 3. New TRANS requirement in order to allow turning on/off each 747 transition mechanism by the user. 749 4. Clarification on how to obtain multiple /64 for 464XLAT. 751 5. S46 priority update to RFC8026 for including 464XLAT and related 752 changes in several sections. 754 15. ANNEX E: Changes from -02 756 Section to be removed for WGLC. Significant updates are: 758 1. RFC8026 update removed, not needed with new approach. 760 2. TRANS and 464XLAT requirements reworded in order to match new 761 approach to allow operator control on each/all the transition 762 mechanisms. 764 3. Added text in 464XLAT to clarify the usage. 766 16. ANNEX F: Changes from -03 768 Section to be removed for WGLC. Significant updates are: 770 1. Several editorial changes across the document, specially TRANS 771 requirements. 773 2. DNS proxy MUST instead of SHOULD. 775 17. ANNEX G: Changes from -04 777 Section to be removed for WGLC. Significant updates are: 779 1. Removed G-1. 781 2. Added support for draft-pref64folks-6man-ra-pref64. 783 3. General text clarifications. 785 18. ANNEX H: Changes from -05 787 Section to be removed for WGLC. Significant updates are: 789 1. Reworded and shorter UPnP section and new informative reference. 791 2. New general transition requirement in case multiple public IPv4 792 prefixes are provided, so to run multiple instances according to 793 each specific transition mechanism. 795 3. General text clarifications. 797 19. ANNEX I: Changes from -06 799 Section to be removed for WGLC. Significant updates are: 801 1. Removed reference and text related to pref64folks-6man-ra-pref64. 803 2. General text clarifications. 805 20. ANNEX J: Changes from -07 807 Section to be removed for WGLC. Significant updates are: 809 1. Added text to UPnP section. 811 21. ANNEX K: Changes from -08 813 Section to be removed for WGLC. Significant updates are: 815 1. Editorial edits. 817 22. ANNEX K: Changes from -09 819 Section to be removed for WGLC. Significant updates are: 821 1. Minor editorial edit. 823 23. References 825 23.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 833 Host Configuration Protocol (DHCP) version 6", RFC 3633, 834 DOI 10.17487/RFC3633, December 2003, 835 . 837 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 838 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 839 . 841 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 842 Infrastructures (6rd) -- Protocol Specification", 843 RFC 5969, DOI 10.17487/RFC5969, August 2010, 844 . 846 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 847 NAT64: Network Address and Protocol Translation from IPv6 848 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 849 April 2011, . 851 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 852 Beijnum, "DNS64: DNS Extensions for Network Address 853 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 854 DOI 10.17487/RFC6147, April 2011, 855 . 857 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 858 Stack Lite Broadband Deployments Following IPv4 859 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 860 . 862 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 863 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 864 RFC 6334, DOI 10.17487/RFC6334, August 2011, 865 . 867 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 868 Combination of Stateful and Stateless Translation", 869 RFC 6877, DOI 10.17487/RFC6877, April 2013, 870 . 872 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 873 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 874 DOI 10.17487/RFC6887, April 2013, 875 . 877 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 878 Play (UPnP) Internet Gateway Device - Port Control 879 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 880 DOI 10.17487/RFC6970, July 2013, 881 . 883 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 884 the IPv6 Prefix Used for IPv6 Address Synthesis", 885 RFC 7050, DOI 10.17487/RFC7050, November 2013, 886 . 888 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 889 Requirements for IPv6 Customer Edge Routers", RFC 7084, 890 DOI 10.17487/RFC7084, November 2013, 891 . 893 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 894 Port Control Protocol (PCP)", RFC 7225, 895 DOI 10.17487/RFC7225, May 2014, 896 . 898 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 899 the Port Control Protocol (PCP)", RFC 7291, 900 DOI 10.17487/RFC7291, July 2014, 901 . 903 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 904 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 905 RFC 7341, DOI 10.17487/RFC7341, August 2014, 906 . 908 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 909 Farrer, "Lightweight 4over6: An Extension to the Dual- 910 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 911 July 2015, . 913 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 914 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 915 Port with Encapsulation (MAP-E)", RFC 7597, 916 DOI 10.17487/RFC7597, July 2015, 917 . 919 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 920 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 921 Configuration of Softwire Address and Port-Mapped 922 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 923 . 925 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 926 and T. Murakami, "Mapping of Address and Port using 927 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 928 2015, . 930 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 931 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 932 RFC 7618, DOI 10.17487/RFC7618, August 2015, 933 . 935 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 936 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 937 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 938 November 2016, . 940 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 941 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 942 over an IPv6 Multicast Network", RFC 8114, 943 DOI 10.17487/RFC8114, March 2017, 944 . 946 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 947 Option for IPv4-Embedded Multicast and Unicast IPv6 948 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 949 . 951 23.2. Informative References 953 [IPv6Survey] 954 Palet Martinez, J., "IPv6 Deployment Survey", January 955 2018, 956 . 959 [OpenWRT] OpenWRT, "OpenWRT Packages", January 2018, 960 . 962 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 963 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 964 2016, . 966 [UPnP-IGD] 967 UPnP Forum, "InternetGatewayDevice:2 Device Template 968 Version 1.01", December 2010, 969 . 971 [UPnP-WANIPC] 972 UPnP Forum, "WANIPConnection:2 Service", December 2010, 973 . 976 Authors' Addresses 978 Jordi Palet Martinez 979 The IPv6 Company 980 Molino de la Navata, 75 981 La Navata - Galapagar, Madrid 28420 982 Spain 984 Email: jordi.palet@theipv6company.com 985 URI: http://www.theipv6company.com/ 987 Hans M.-H. Liu 988 D-Link Systems, Inc. 989 17595 Mount Herrmann St. 990 Fountain Valley, California 92708 991 US 993 Email: hans.liu@dlinkcorp.com 994 URI: http://www.dlink.com/ 995 Masanobu Kawashima 996 NEC Platforms, Ltd. 997 800, Shimomata 998 Kakegawa-shi, Shizuoka 436-8501 999 Japan 1001 Email: kawashimam@vx.jp.nec.com 1002 URI: https://www.necplatforms.co.jp/en/