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