idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-13.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 (January 10, 2019) is 1926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: July 14, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 January 10, 2019 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-13 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 by vendors who sell through the retail market. 20 Specifically, this document extends the "Basic Requirements for IPv6 21 Customer Edge Routers" (RFC7084) in order to allow the provisioning 22 of IPv6 transition services for the support of "IPv4 as-a-Service" 23 (IPv4aaS) by means of new transition mechanisms. The document only 24 covers transition technologies for delivering IPv4 in IPv6-only 25 access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This 26 is necessary because there aren't sufficient IPv4 addresses available 27 for every possible customer/device. However, devices or applications 28 in the customer LANs (Local Area Networks) may be IPv4-only or 29 IPv6-only and still need to communicate with IPv4-only services at 30 the Internet. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 14, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language - Special Note . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 6 71 3.2. Transition Technologies Support for IPv4 Service 72 Continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 6 73 3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 9 75 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 10 76 3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11 79 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Comparison to RFC7084 . . . . . . . . . . . . . . . . . . . . 12 81 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 14 86 12. Annex B: End-User Network Architecture . . . . . . . . . . . 15 87 13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 18 88 14. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 18 89 15. ANNEX E: Changes from -02 . . . . . . . . . . . . . . . . . . 18 90 16. ANNEX F: Changes from -03 . . . . . . . . . . . . . . . . . . 19 91 17. ANNEX G: Changes from -04 . . . . . . . . . . . . . . . . . . 19 92 18. ANNEX H: Changes from -05 . . . . . . . . . . . . . . . . . . 19 93 19. ANNEX I: Changes from -06 . . . . . . . . . . . . . . . . . . 19 94 20. ANNEX J: Changes from -07 . . . . . . . . . . . . . . . . . . 19 95 21. ANNEX K: Changes from -08, -09 and -10 . . . . . . . . . . . 20 96 22. ANNEX L: Changes from -11 and -12 . . . . . . . . . . . . . . 20 97 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 23.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 23.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Introduction 104 This document defines IPv4 service continuity features over an 105 IPv6-only network, for a residential or small-office router, referred 106 to as an "IPv6 Transition CE Router", in order to establish an 107 industry baseline for transition features to be implemented on such a 108 router. 110 These routers rely upon "Basic Requirements for IPv6 Customer Edge 111 Routers" [RFC7084]. The scope of this document is to ensure the IPv4 112 "service continuity" support, for devices in the LAN side. This 113 ensures that remote IPv4-only services continue to be accessible, 114 from an IPv6-only Internet Service Provider access network (typically 115 referred as WAN - Wide Area Network, even if in some cases it may be 116 metropolitan, regional, etc.), from both, IPv4-only and IPv6-only 117 applications or devices in the LAN side. 119 +------------+ +------------+ \ 120 | IPv4-only | | IPv4/IPv6 | \ 121 | Remote | | Remote | | 122 | Host | | Host | | Internet 123 +--------+---+ +---+--------+ | 124 | | / 125 | | / 126 +-+-----------+-+ \ 127 | Service | \ 128 | Provider | \ 129 | Router | | Service 130 +-------+-------+ | Provider 131 | IPv6-only | Network 132 | Customer / 133 | Internet Connection / 134 | / 135 +------+--------+ \ 136 | IPv6 | \ 137 | Customer Edge | \ 138 | Router | | 139 +---+-------+---+ | 140 LAN A | | LAN B | End-User 141 -+----------------+- -+-----+-------------+- | Network(s) 142 | | | | 143 +---+------+ +----+-----+ +-----+----+ | 144 | IPv6-only| | IPv4-only| |IPv4/IPv6 | / 145 | Host | | Host | | Host | / 146 +----------+ +----------+ +----------+ / 148 Figure 1: Simplified Typical IPv6-only Access Network 150 This document covers a set of IP transition techniques required when 151 ISPs (Internet Service Providers) have, or want to have, an IPv6-only 152 access network. This is a common situation when sufficient IPv4 153 addresses are no longer available for every possible customer and 154 device, causing IPv4 addresses to become prohibitively expensive. 155 This, in turn, may result in service providers provisioning IPv6-only 156 WAN access. At the same time, they need to ensure that both 157 IPv4-only and IPv6-only devices or applications in the customer 158 networks can still reach IPv4-only devices and applications in the 159 Internet. 161 This document specifies the IPv4 service continuity mechanisms to be 162 supported by an IPv6 Transition CE Router, and relevant provisioning 163 or configuration information differences from [RFC7084]. 165 This document is not a recommendation for service providers to use 166 any specific transition mechanism. 168 Automatic provisioning of more complex topology than a single router 169 with multiple LAN interfaces may be handled by means of HNCP 170 [RFC7788] (Home Networking Control Protocol), which is out of the 171 scope of this document. 173 Since it is impossible to know prior to sale which transition 174 mechanism a device will need over its lifetime, an IPv6 Transition CE 175 Router intended for the retail market MUST support all the IPv4aaS 176 transition mechanisms supported by this document. Service providers 177 who specify feature sets for the IPv6 Transition CE Router, may 178 define a different set of features than those included in this 179 document, for example supporting only some of the transition 180 mechanisms enumerated in this document. 182 A complete description of "Usage Scenarios" and "End-User Network 183 Architecture" is provided in Annexes A and B, respectively, which 184 together with [RFC7084], will facilitate the reader to have a clearer 185 understanding of this document. 187 1.1. Requirements Language - Special Note 189 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document, are not used as described in [RFC2119]. When these words 192 aren't capitalized, they have their normal English meaning, as per 193 [RFC8174]. This document uses these keywords not strictly for the 194 purpose of interoperability, but rather for the purpose of 195 establishing industry-common baseline functionality. As such, the 196 document points to several other specifications to provide additional 197 guidance to implementers regarding any protocol implementation 198 required to produce a successful IPv6 Transition CE Router that 199 interoperates successfully with a particular subset of currently 200 deploying and planned common IPv6-only access networks. 202 Additionally, the keyword "DEFAULT" is to be interpreted in this 203 document as pertaining to a configuration as applied by a vendor, 204 prior to the administrator changing it for its initial activation. 206 2. Terminology 208 This document uses the same terms as in [RFC7084], with minor 209 clarifications. 211 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 212 technologies for delivering IPv4 in IPv6-only connectivity. 214 The term "IPv6 transition Customer Edge Router with IPv4aaS" 215 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 216 Customer Edge Router" that provides features for the delivery of IPv4 217 services over an IPv6-only WAN network, including IPv6-IPv4 218 communications. 220 The "WAN Interface" term used across this document, defines an IPv6 221 Transition CE Router attachment to an IPv6-only link used to provide 222 connectivity to a service provider network, including link Internet- 223 layer (or higher layers) "tunnels", such as IPv4-in-IPv6 tunnels. 225 3. Requirements 227 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 228 Requirements for IPv6 Customer Edge Routers) and this document adds 229 new requirements, as described in the following sub-sections. 231 3.1. LAN-Side Configuration 233 A new LAN requirement is added, which in fact is common in regular 234 IPv6 Transition CE Routers, and it is required by most of the 235 transition mechanisms: 237 L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as 238 described in [RFC5625] (DNS Proxy Implementation Guidelines). 240 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4 241 as-a-Service - IPv4aaS) 243 The main target of this document is the support of IPv6-only WAN 244 access. To enable legacy IPv4 functionality, this document also 245 includes the support of IPv4-only devices and applications in the 246 customers LANs, as well as IPv4-only services on the Internet. Thus, 247 both IPv4-only and the IPv6-only devices in the customer-side LANs of 248 the IPv6 Transition CE Router are able to reach the IPv4-only 249 services. 251 Note that this document is only configuring the IPv4aaS in the IPv6 252 Transition CE Router itself, and not forwarding such information to 253 devices attached to the LANs, so the WAN configuration, availability 254 of native IPv4 or IPv4aaS, is transparent for them. 256 This document takes no position on simultaneous operation of one or 257 several transition mechanisms and/or native IPv4. 259 In order to seamlessly provide IPv4 service continuity in the 260 customer LANs, and allow an automated IPv6 transition mechanism 261 provisioning, the following general transition requirements are 262 defined. 264 General transition requirements: 266 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 267 priority options described in [RFC8026] (Unified IPv4-in- 268 IPv6 Softwire Customer Premises Equipment (CPE): A 269 DHCPv6-Based Prioritization Mechanism). 271 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or 272 API option to manually enable/disable each of the supported 273 transition mechanisms. 275 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN 276 subnet, the IPv6 Transition CE Router MUST allow 277 appropriate subnetting and configuring the address space 278 (which may depend on each transition mechanism) among the 279 several interfaces. In some transition mechanisms, this 280 may require differentiating mappings/translations per 281 interfaces. 283 In order to allow the service provider to disable all the transition 284 mechanisms and/or choose the most convenient one, the IPv6 Transition 285 CE Router MUST follow the following configuration steps: 287 CONFIG-1: Request the relevant configuration options for each 288 supported transition mechanisms, which MUST remain 289 disabled at this step. 291 CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid 292 match in OPTION_S46_PRIORITY, which allows enabling/ 293 disabling a transition mechanism. 295 CONFIG-3: Keep disabled all the transition mechanisms if no match is 296 found between the priority list and the candidate list. 298 The following sections describe the requirements for supporting each 299 one of the transition mechanisms. An IPv6 Transition CE Router 300 intended for the retail market MUST support all of them. 302 3.2.1. 464XLAT 304 464XLAT [RFC6877] is a technique to provide IPv4 service over an 305 IPv6-only access network without encapsulation. This architecture 306 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 307 Protocol Translation from IPv6 Clients to IPv4 Servers) function 308 deployed at the service provider or a third-party network. 310 The IPv6 Transition CE Router MUST support CLAT functionality 311 [RFC6877] if intended for the retail market. If 464XLAT is 312 supported, it MUST be implemented according to [RFC6877]. The 313 following IPv6 Transition CE Router requirements also apply: 315 464XLAT requirements: 317 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 318 Address Translation (NAT) on IPv4 traffic translated 319 using the CLAT, unless a dedicated /64 prefix has been 320 acquired, either using DHCPv6-PD [RFC8415] (IPv6 Prefix 321 Options for DHCPv6) or by alternative means. 323 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 324 [RFC6970] (UPnP Internet Gateway Device - Port Control 325 Protocol Interworking Function). 327 464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 328 Router MUST also implement [RFC7291] (DHCP Options for 329 the PCP). Following [RFC6887], if no PCP server is 330 configured, the IPv6 Transition CE Router MAY verify if 331 the default gateway, or the NAT64 is the PCP server. 332 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is 333 used) MUST be used to send PCP requests to the server. 335 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 336 (Discovery of the IPv6 Prefix Used for IPv6 Address 337 Synthesis) in order to discover the PLAT-side translation 338 IPv4 and IPv6 prefix(es)/suffix(es). 340 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 341 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 342 the PCP), in order to learn the PLAT-side translation 343 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 344 PCP-controlled NAT64 device. 346 464XLAT-6: [RFC8115] MUST be implemented and a DHCPv6 Option 347 "OPTION_V6_PREFIX64" [RFC8115], with zeroed ASM_mPrefix64 348 and SSM_mPrefix64, MUST also be considered as a valid 349 NAT64 prefix (uPrefix64). 351 464XLAT-7: The priority for the NAT64 prefix, in case the network 352 provides several choices, MUST be: 1) [RFC7225], 2) 353 [RFC8115], and 3) [RFC7050]. 355 464XLAT-8: If a DHCPv6 Option "OPTION_V6_PREFIX64" [RFC8115], with 356 zeroed ASM_mPrefix64 and SSM_mPrefix64 provides a NAT64 357 prefix, or one or more NAT64 prefixes are learnt by means 358 of either [RFC7050] or [RFC7225], then 464XLAT MUST be 359 included in the candidate list of possible S46 mechanism 360 (Section 1.4.1 of [RFC8026]). 362 The NAT64 prefix could be discovered by means of [RFC7050] only in 363 the case the service provider uses DNS64 [RFC6147]. If DNS64 364 [RFC6147] is not used, or not trusted, as the DNS configuration at 365 the CE (or hosts behind the CE) may be modified by the customer, then 366 the service provider may opt to configure the NAT64 prefix either by 367 means of [RFC7225] or [RFC8115], which also can be used if the 368 service provider uses DNS64 [RFC6147]. 370 3.2.2. Dual-Stack Lite (DS-Lite) 372 Dual-Stack Lite [RFC6333] enables continued support for IPv4 373 services. Dual-Stack Lite enables a broadband service provider to 374 share IPv4 addresses among customers by combining two well-known 375 technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation 376 (NAT). It is expected that DS-Lite traffic is forwarded over the 377 IPv6 Transition CE Router's native IPv6 WAN interface, and not 378 encapsulated in another tunnel. 380 The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality 381 [RFC6333] if intended for the retail market. If DS-Lite is 382 supported, it MUST be implemented according to [RFC6333]. The 383 following IPv6 Transition CE Router requirements also apply: 385 DS-Lite requirements: 387 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 388 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 389 Option for Dual-Stack Lite). The IPv6 Transition CE 390 Router MAY use other mechanisms to configure DS-Lite 391 parameters. Such mechanisms are outside the scope of this 392 document. 394 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 395 [RFC6970] (UPnP Internet Gateway Device - Port Control 396 Protocol Interworking Function). 398 DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 399 Router SHOULD implement [RFC7291] (DHCP Options for the 400 PCP). If PCP [RFC6887] is implemented and a PCP server is 401 not configured, the IPv6 Transition CE Router MUST assume, 402 by DEFAULT, that the AFTR is the PCP server. Plain IPv6 403 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be 404 used to send PCP requests to the server. 406 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 407 Network Address Translation (NAT) on IPv4 traffic 408 encapsulated using DS-Lite [RFC6333]. 410 3.2.3. Lightweight 4over6 (lw4o6) 412 lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the 413 NAPT function from the DS-Lite tunnel concentrator to the tunnel 414 client located in the IPv6 Transition CE Router, removing the 415 requirement for a CGN (Carrier Grade NAT, AFTR - Address Family 416 Transition Router) function in the tunnel concentrator and reducing 417 the amount of centralized state. 419 The IPv6 Transition CE Router MUST implement lwB4 functionality 420 [RFC7596] if intended for the retail market. If DS-Lite is 421 implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is 422 supported, it MUST be implemented according to [RFC7596]. The 423 following IPv6 Transition CE Router requirements also apply: 425 lw4o6 requirements: 427 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 428 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 429 Options for Configuration of Softwire Address and Port- 430 Mapped Clients). The IPv6 Transition CE Router MAY use 431 other mechanisms to configure lw4o6 parameters. Such 432 mechanisms are outside the scope of this document. 434 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 435 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 436 over-DHCPv6 Transport). 438 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 439 Allocation of Shared IPv4 Addresses as described in 440 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 442 3.2.4. MAP-E 444 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 445 an IPv6 network using IP encapsulation, including an algorithmic 446 mechanism for mapping between IPv6 and IPv4 addresses. 448 The IPv6 Transition CE Router MUST support MAP-E CE functionality 449 [RFC7597] if intended for the retail market. If MAP-E is supported, 450 it MUST be implemented according to [RFC7597]. The following IPv6 451 Transition CE Router requirements also apply: 453 MAP-E requirements: 455 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 456 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 457 for Configuration of Softwire Address and Port-Mapped 458 Clients). The IPv6 Transition CE Router MAY use other 459 mechanisms to configure MAP-E parameters. Such mechanisms 460 are outside the scope of this document. 462 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 463 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 464 Allocation of Shared IPv4 Addresses). 466 3.2.5. MAP-T 468 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 469 that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as 470 the form of IPv6 domain transport. 472 The IPv6 Transition CE Router MUST support MAP-T CE functionality 473 [RFC7599] if intended for the retail market. If MAP-T is supported, 474 it MUST be implemented according to [RFC7599]. The following IPv6 475 Transition CE Router requirements also apply: 477 MAP-T requirements: 479 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 480 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 481 for Configuration of Softwire Address and Port-Mapped 482 Clients). The IPv6 Transition CE Router MAY use other 483 mechanisms to configure MAP-T parameters. Such mechanisms 484 are outside the scope of this document. 486 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 487 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 488 Allocation of Shared IPv4 Addresses). 490 4. IPv4 Multicast Support 492 Existing IPv4 deployments support IPv4 multicast for services such as 493 IPTV. In the transition phase, it is expected that multicast 494 services will still be provided using IPv4 to the customer LANs. 496 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 497 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 498 Services to IPv4 Clients over an IPv6 Multicast Network) and 499 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 500 Prefixes). 502 5. UPnP Support 504 If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a 505 CE router, but cannot be associated with an IPv4 interface 506 established by an IPv4aaS mechanism or cannot determine which ports 507 are available, an AddPortMapping() or AddAnyPortMapping() action MUST 508 be rejected with error code 729 "ConflictWithOtherMechanisms". Port 509 availability could be determined through PCP or access to a 510 configured port set (if the IPv4aaS mechanism limits the available 511 ports). 513 An AddPortMapping() request for a port that is not available MUST 514 result in "ConflictInMappingEntry". 516 An AddAnyPortMapping() request for a port that is not available 517 SHOULD result in a successful mapping with an alternative 518 "NewReservedPort" value from within the configured port set range, or 519 as assigned by PCP as per [RFC6970], Section 5.6.1. 521 Note that IGD:1 and its WANIPConnection:1 service have been 522 deprecated by OCF (Open Connectivity Foundation). 524 6. Comparison to RFC7084 526 This document doesn't include support for 6rd [RFC5969], because it 527 is an IPv6-in-IPv4 tunneling. 529 Regarding DS-LITE [RFC6333], this document includes slightly 530 different requirements, related to the support of PCP [RFC6887], IGD- 531 PCP IWF [RFC6970] and the prioritization of the transition 532 mechanisms, including dual-stack. 534 7. Code Considerations 536 One of the apparent main issues for vendors to include new 537 functionalities, such as support for new transition mechanisms, is 538 the lack of space in the flash (or equivalent) memory. However, it 539 has been confirmed from existing open source implementations 540 (OpenWRT/LEDE, Linux, VPP, others), that adding the support for the 541 new transitions mechanisms, requires around 10-12 Kbytes, because 542 most of the code base is shared among several transition mechanisms, 543 which are already supported by [RFC7084]. A single data plane is 544 common to all them, which typically means, in popular CEs already in 545 the market [OpenWRT], about 0,15% of the existing code size. 547 In general, the new requirements don't have extra cost in terms of 548 RAM memory, nor other hardware requirements such as more powerful 549 CPUs, if compared to the cost of NAT44 code, so existing hardware 550 should support all them with minimal impact. 552 The other issue seems to be the cost of developing the code for those 553 new functionalities. However, at the time of writing this document, 554 it has been confirmed that there are several open source versions of 555 the required code for supporting all the new transition mechanisms, 556 and several vendors already have implementations and provide it to 557 ISPs, so the development cost is negligible, and only integration and 558 testing cost may become an issue. 560 Finally, in some cases, operators supporting several transition 561 mechanisms may need to consider training costs for staff in all those 562 techniques for their operation and management, even if this is not 563 directly caused by supporting this document, but because the business 564 decisions behind that. 566 8. Security Considerations 568 The IPv6 Transition CE Router must comply with the Security 569 Considerations as stated in [RFC7084], as well as those stated by 570 each transition mechanism implemented by the IPv6 Transition CE 571 Router. 573 As described in [RFC8026] and [RFC8415] Security Consideration 574 sections, there are generic DHCP security issues, which in the case 575 of this document means that malicious nodes may alter the priority of 576 the transition mechanisms. 578 Access network architecture for securing DHCP within the access 579 network is out of scope of this document. Securing DHCP in the LAN 580 is also not in scope. DHCP packets MUST NOT be forwarded between LAN 581 and WAN interfaces of an IPv6 Transition CE router. 583 9. IANA Considerations 585 IANA is requested, by means of this document, to update the "Option 586 Codes permitted in the S46 Priority Option" registry available at 587 https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 588 parameters.xhtml#option-codes-s46-priority-option, with the following 589 entry. 591 +-------------+--------------------+-----------+ 592 | Option Code | S46 Mechanism | Reference | 593 +-------------+--------------------+-----------+ 594 | 113 | 464XLAT | [thisdoc] | 595 +-------------+--------------------+-----------+ 597 Table 1: DHCPv6 Option Code for 464XLAT 599 10. Acknowledgements 601 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 602 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 603 Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, 604 for their review and comments in this and/or previous versions of 605 this document, as well as to the Last Call reviewers by the Ops-dir 606 (Dan Romascanu), Sec-dir (Christian Huitema), Rtg-dir (Daniele 607 Ceccarelli), Tsv-art (Martin Stiemerling) and Gen-art (Matthew 608 Miller). 610 11. Annex A: Usage Scenarios 612 The situation previously described, where there is ongoing IPv6 613 deployment and lack of IPv4 addresses, is not happening at the same 614 pace in every country, and even within every country, every ISP. For 615 different technical, financial, commercial/marketing and socio- 616 economic reasons, each network is transitioning at their own pace; 617 the global transition timings cannot be estimated. 619 Different studies (for example [IPv6Survey]) also show that the IPv6 620 deployment is a changing situation. In a single country, not all 621 operators will necessarily provide IPv6 support. Consumers may also 622 switch ISPs, and use the same IPv6 Transition CE Router with either 623 an ISP that provides IPv4-only or an ISP that provides IPv6 with 624 IPv4aaS. 626 So, to cover all those evolving situations, an IPv6 Transition CE 627 Router is required, at least from the perspective of the transition 628 support. 630 Moreover, because some services will remain IPv4-only for an 631 undetermined time, and some service providers will remain IPv4-only 632 for an undetermined period of time, IPv4 will be needed for an 633 undetermined period of time. There will be a need for CEs with 634 support "IPv4 as-a-Service" for an undetermined period of time. 636 This document, based on those premises, ensures that the IPv6 637 Transition CE Router allows the continued transition from networks 638 that today may provide access with dual-stack or IPv6-in-IPv4, as 639 described in [RFC7084], and as an "extension" to it, evolve to an 640 IPv6-only access with IPv4-as-a-Service. 642 Considering that situation and different possible usage cases, the 643 IPv6 Transition CE Router described in this document is expected to 644 be used typically, in residential/household, Small Office/Home Office 645 (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind 646 of Internet access (web, email, streaming, online gaming, etc.) and 647 even more advanced requirements including inbound connections (IP 648 cameras, web, DNS, email, VPN, etc.). 650 The above is not intended to be comprehensive list of all the 651 possible usage cases, just an overall view. In fact, combinations of 652 the above usages are also possible, as well as situations where the 653 same CE is used at different times in different scenarios or even 654 different services providers that may use a different transition 655 mechanism. 657 The mechanisms for allowing inbound connections are "naturally" 658 available in any IPv6 router, when using GUA (IPv6 Global Unicast 659 Addresses), unless they are blocked by firewall rules, which may 660 require some manual configuration by means of a GUI, CLI and/or API. 662 However, in the case of IPv4aaS, because the usage of private 663 addresses and NAT and even depending on the specific transition 664 mechanism, inbound connections typically require some degree of more 665 complex manual configuration such as setting up a DMZ, virtual 666 servers, or port/protocol forwarding. In general, IPv4 CE Routers 667 already provide a GUI and/or a CLI to manually configure them, or the 668 possibility to setup the CE in bridge mode, so another CE behind it 669 takes care of that. The requirements for that support are out of the 670 scope of this document. 672 It is not relevant who provides the IPv6 Transition CE Router. In 673 most of the cases is the service provider, and in fact is 674 responsible, typically, of provisioning/managing at least the WAN 675 side. Commonly, the user has access to configure the LAN interfaces, 676 firewall, DMZ, and many other features. However, in many cases, the 677 user must supply or may replace the IPv6 Transition CE Router. This 678 underscores the importance of the IPv6 Transition CE Routers 679 supporting the same requirements defined in this document. 681 The IPv6 Transition CE Router described in this document is not 682 intended for usage in other scenarios such as large Enterprises, Data 683 Centers, Content Providers, etc. So even if the documented 684 requirements meet their needs, they may have additional requirements, 685 which are out of the scope of this document. 687 12. Annex B: End-User Network Architecture 689 According to the descriptions in the preceding sections, an end-user 690 network will likely support both IPv4 and IPv6. It is not expected 691 that an end-user will change their existing network topology with the 692 introduction of IPv6. There are some differences in how IPv6 works 693 and is provisioned; these differences have implications for the 694 network architecture. 696 A typical IPv4 end-user network consists of a "plug and play" router 697 with NAT functionality and a single link upstream, connected to the 698 service provider network. 700 From the perspective of an "IPv4 user" behind an IPv6 transition 701 Customer Edge Router with IPv4aaS, this doesn't change. 703 However, while a typical IPv4 NAT deployment by default blocks all 704 incoming connections and may allow opening of ports using a Universal 705 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 706 other firewall control protocol, in the case of an IPv6-only access 707 and IPv4aaS, that may not be feasible depending on specific 708 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 709 may be an alternative solution. 711 Another consequence of using IPv4 private address space in the end- 712 user network is that it provides stable addressing; that is, it 713 doesn't change, even when you change service providers, and the 714 addresses are always usable even when the WAN interface is down or 715 the customer edge router has not yet been provisioned. In the case 716 of an IPv6-only access, private IPv4 addresses are also available if 717 the IPv4aaS transition mechanism keeps running the NAT interface 718 towards the LAN side when the WAN interface is down. 720 More advanced routers support dynamic routing (which learns routes 721 from other routers), and advanced end-users can build arbitrary, 722 complex networks using manual configuration of address prefixes 723 combined with a dynamic routing protocol. Once again, this is true 724 for both, IPv4 and IPv6. 726 In general, the end-user network architecture for IPv6 should provide 727 equivalent or better capabilities and functionality than the current 728 IPv4 architecture. 730 The end-user network is a stub network, in the sense that is not 731 providing transit to other external networks. However, HNCP 732 [RFC7788] allows support for automatic provisioning of downstream 733 routers. Figure 1 illustrates the model topology for the end-user 734 network. 736 +---------------+ \ 737 | Service | \ 738 | Provider | \ 739 | Router | | Service 740 +-------+-------+ | Provider 741 | IPv6-only | Network 742 | Customer / 743 | Internet Connection / 744 | / 745 +------+--------+ \ 746 | IPv6 | \ 747 | Customer Edge | \ 748 | Router | | 749 +---+-------+---+ | 750 Network A | | Network B | 751 -+----------------+-+- -+---+-------------+- | 752 | | | | | 753 +---+------+ | +----+-----+ +-----+----+ | 754 | IPv6 | | | IPv4 | |IPv4/IPv6 | | 755 | Host | | | Host | | Host | | 756 +----------+ | +----------+ +----------+ | End-User 757 | | Network(s) 758 +------+--------+ | 759 | IPv6 | | 760 | Router | | 761 +------+--------+ | 762 Network C | | 763 -+-------------+--+- | 764 | | | 765 +---+------+ +----+-----+ | 766 | IPv6 | | IPv6 | / 767 | Host | | Host | / 768 +----------+ +----------+ / 770 Figure 2: An Example of a Typical End-User Network 772 This architecture describes the: 774 o Basic capabilities of the IPv6 Transition CE Router 776 o Provisioning of the WAN interface connecting to the service 777 provider 779 o Provisioning of the LAN interfaces 781 The IPv6 Transition CE Router may be manually configured in an 782 arbitrary topology with a dynamic routing protocol or using HNCP 783 [RFC7788]. Automatic provisioning and configuration is described for 784 a single IPv6 Transition CE Router only. 786 13. ANNEX C: Changes from -00 788 Section to be removed by RFC Editor. Significant updates are: 790 1. ID-Nits: IANA section. 792 2. ID-Nits: RFC7084 reference removed from Abstract. 794 3. This document no longer updates RFC7084. 796 4. UPnP section reworded. 798 5. "CE Router" changed to "IPv6 Transition CE Router". 800 6. Reduced text in Annex A. 802 14. ANNEX D: Changes from -01 804 Section to be removed by RFC Editor. Significant updates are: 806 1. TRANS requirements reworked in order to increase operator control 807 and allow gradual transitioning from dual-stack to IPv6-only on 808 specific customers. 810 2. New TRANS requirement so all the supported transition mechanisms 811 are disabled by default, in order to facilitate the operator 812 management. 814 3. New TRANS requirement in order to allow turning on/off each 815 transition mechanism by the user. 817 4. Clarification on how to obtain multiple /64 for 464XLAT. 819 5. S46 priority update to RFC8026 for including 464XLAT and related 820 changes in several sections. 822 15. ANNEX E: Changes from -02 824 Section to be removed by RFC Editor. Significant updates are: 826 1. RFC8026 update removed, not needed with new approach. 828 2. TRANS and 464XLAT requirements reworded in order to match new 829 approach to allow operator control on each/all the transition 830 mechanisms. 832 3. Added text in 464XLAT to clarify the usage. 834 16. ANNEX F: Changes from -03 836 Section to be removed by RFC Editor. Significant updates are: 838 1. Several editorial changes across the document, specially TRANS 839 requirements. 841 2. DNS proxy MUST instead of SHOULD. 843 17. ANNEX G: Changes from -04 845 Section to be removed by RFC Editor. Significant updates are: 847 1. Removed G-1. 849 2. Added support for draft-pref64folks-6man-ra-pref64. 851 3. General text clarifications. 853 18. ANNEX H: Changes from -05 855 Section to be removed by RFC Editor. Significant updates are: 857 1. Reworded and shorter UPnP section and new informative reference. 859 2. New general transition requirement in case multiple public IPv4 860 prefixes are provided, so to run multiple instances according to 861 each specific transition mechanism. 863 3. General text clarifications. 865 19. ANNEX I: Changes from -06 867 Section to be removed by RFC Editor. Significant updates are: 869 1. Removed reference and text related to pref64folks-6man-ra-pref64. 871 2. General text clarifications. 873 20. ANNEX J: Changes from -07 875 Section to be removed by RFC Editor. Significant updates are: 877 1. Added text to UPnP section. 879 21. ANNEX K: Changes from -08, -09 and -10 881 Section to be removed by RFC Editor. Significant updates are: 883 1. Editorial edits. 885 22. ANNEX L: Changes from -11 and -12 887 Section to be removed by RFC Editor. Significant updates are: 889 1. Changes related to suggestions by Ops-dir, Sec-dir, Rtg-dir, Tsv- 890 art and Gen-art, as well as comments from IESG review. 892 23. References 894 23.1. Normative References 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, 898 DOI 10.17487/RFC2119, March 1997, 899 . 901 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 902 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 903 . 905 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 906 Infrastructures (6rd) -- Protocol Specification", 907 RFC 5969, DOI 10.17487/RFC5969, August 2010, 908 . 910 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 911 NAT64: Network Address and Protocol Translation from IPv6 912 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 913 April 2011, . 915 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 916 Beijnum, "DNS64: DNS Extensions for Network Address 917 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 918 DOI 10.17487/RFC6147, April 2011, 919 . 921 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 922 Stack Lite Broadband Deployments Following IPv4 923 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 924 . 926 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 927 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 928 RFC 6334, DOI 10.17487/RFC6334, August 2011, 929 . 931 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 932 Combination of Stateful and Stateless Translation", 933 RFC 6877, DOI 10.17487/RFC6877, April 2013, 934 . 936 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 937 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 938 DOI 10.17487/RFC6887, April 2013, 939 . 941 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 942 Play (UPnP) Internet Gateway Device - Port Control 943 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 944 DOI 10.17487/RFC6970, July 2013, 945 . 947 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 948 the IPv6 Prefix Used for IPv6 Address Synthesis", 949 RFC 7050, DOI 10.17487/RFC7050, November 2013, 950 . 952 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 953 Requirements for IPv6 Customer Edge Routers", RFC 7084, 954 DOI 10.17487/RFC7084, November 2013, 955 . 957 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 958 Port Control Protocol (PCP)", RFC 7225, 959 DOI 10.17487/RFC7225, May 2014, 960 . 962 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 963 the Port Control Protocol (PCP)", RFC 7291, 964 DOI 10.17487/RFC7291, July 2014, 965 . 967 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 968 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 969 RFC 7341, DOI 10.17487/RFC7341, August 2014, 970 . 972 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 973 Farrer, "Lightweight 4over6: An Extension to the Dual- 974 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 975 July 2015, . 977 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 978 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 979 Port with Encapsulation (MAP-E)", RFC 7597, 980 DOI 10.17487/RFC7597, July 2015, 981 . 983 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 984 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 985 Configuration of Softwire Address and Port-Mapped 986 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 987 . 989 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 990 and T. Murakami, "Mapping of Address and Port using 991 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 992 2015, . 994 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 995 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 996 RFC 7618, DOI 10.17487/RFC7618, August 2015, 997 . 999 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 1000 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 1001 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 1002 November 2016, . 1004 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1005 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1006 over an IPv6 Multicast Network", RFC 8114, 1007 DOI 10.17487/RFC8114, March 2017, 1008 . 1010 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 1011 Option for IPv4-Embedded Multicast and Unicast IPv6 1012 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 1013 . 1015 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1016 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1017 May 2017, . 1019 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1020 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1021 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1022 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1023 . 1025 23.2. Informative References 1027 [IPv6Survey] 1028 Palet Martinez, J., "IPv6 Deployment Survey", January 1029 2018, 1030 . 1033 [OpenWRT] OpenWRT, "OpenWRT Packages", January 2018, 1034 . 1036 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1037 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1038 2016, . 1040 [UPnP-IGD] 1041 UPnP Forum, "InternetGatewayDevice:2 Device Template 1042 Version 1.01", December 2010, 1043 . 1045 [UPnP-WANIPC] 1046 UPnP Forum, "WANIPConnection:2 Service", December 2010, 1047 . 1050 Authors' Addresses 1052 Jordi Palet Martinez 1053 The IPv6 Company 1054 Molino de la Navata, 75 1055 La Navata - Galapagar, Madrid 28420 1056 Spain 1058 Email: jordi.palet@theipv6company.com 1059 URI: http://www.theipv6company.com/ 1060 Hans M.-H. Liu 1061 D-Link Systems, Inc. 1062 17595 Mount Herrmann St. 1063 Fountain Valley, California 92708 1064 US 1066 Email: hans.liu@dlinkcorp.com 1067 URI: http://www.dlink.com/ 1069 Masanobu Kawashima 1070 NEC Platforms, Ltd. 1071 800, Shimomata 1072 Kakegawa-shi, Shizuoka 436-8501 1073 Japan 1075 Email: kawashimam@vx.jp.nec.com 1076 URI: https://www.necplatforms.co.jp/en/