idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-14.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 14, 2019) is 1928 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 18, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 January 14, 2019 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-14 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 18, 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 . . . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . . 8 75 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9 76 3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11 79 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Comparison to RFC7084 . . . . . . . . . . . . . . . . . . . . 12 81 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 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, -12 and -13 . . . . . . . . . . . 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 (ISP) access network from 115 both, IPv4-only and IPv6-only applications and devices in the LAN 116 side. These ISP access networks are typically referred to as Wide 117 Area Networks (WANs), even if in some cases they may be metropolitan 118 or regional. Figure 1 presents a simplified view of this 119 architecture. 121 +------------+ +------------+ \ 122 | IPv4-only | | IPv4/IPv6 | \ 123 | Remote | | Remote | | 124 | Host | | Host | | Internet 125 +--------+---+ +---+--------+ | 126 | | / 127 | | / 128 +-+-----------+-+ \ 129 | Service | \ 130 | Provider | \ 131 | Router | | Service 132 +-------+-------+ | Provider 133 | IPv6-only | Network 134 | Customer / 135 | Internet Connection / 136 | / 137 +------+--------+ \ 138 | IPv6 | \ 139 | Customer Edge | \ 140 | Router | | 141 +---+-------+---+ | 142 LAN A | | LAN B | End-User 143 -+----------------+- -+-----+-------------+- | Network(s) 144 | | | | 145 +---+------+ +----+-----+ +-----+----+ | 146 | IPv6-only| | IPv4-only| |IPv4/IPv6 | / 147 | Host | | Host | | Host | / 148 +----------+ +----------+ +----------+ / 150 Figure 1: Simplified Typical IPv6-only Access Network 152 This document covers a set of IP transition techniques required when 153 ISPs have, or want to have, an IPv6-only access network. This is a 154 common situation when sufficient IPv4 addresses are no longer 155 available for every possible customer and device, causing IPv4 156 addresses to become prohibitively expensive. This, in turn, may 157 result in service providers provisioning IPv6-only WAN access. At 158 the same time, they need to ensure that both IPv4-only and IPv6-only 159 devices and applications in the customer networks can still reach 160 IPv4-only devices and applications in the Internet. 162 This document specifies the IPv4 service continuity mechanisms to be 163 supported by an IPv6 Transition CE Router, and relevant provisioning 164 or configuration information differences from [RFC7084]. 166 This document is not a recommendation for service providers to use 167 any specific transition mechanism. 169 Automatic provisioning of more complex topology than a single router 170 with multiple LAN interfaces may be handled by means of HNCP 171 [RFC7788] (Home Networking Control Protocol), which is out of the 172 scope of this document. 174 Since it is impossible to know prior to sale which transition 175 mechanism a device will need over its lifetime, an IPv6 Transition CE 176 Router intended for the retail market MUST support all the IPv4aaS 177 transition mechanisms listed in this document. Service providers who 178 specify feature sets for the IPv6 Transition CE Router, may define a 179 different set of features than those included in this document, for 180 example supporting only some of the transition mechanisms enumerated 181 in this document. 183 A complete description of "Usage Scenarios" and "End-User Network 184 Architecture" is provided in Annexes A and B, respectively, which 185 together with [RFC7084], will facilitate the reader to have a clearer 186 understanding of this document. 188 1.1. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in 193 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 2. Terminology 198 This document uses the same terms as in [RFC7084], with minor 199 clarifications. 201 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 202 technologies for delivering IPv4 in IPv6-only connectivity. 204 The term "IPv6 transition Customer Edge Router with IPv4aaS" 205 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 206 Customer Edge Router" that provides features for the delivery of IPv4 207 services over an IPv6-only WAN network, including IPv6-IPv4 208 communications. 210 The "WAN Interface" term used across this document, defines an IPv6 211 Transition CE Router attachment to an IPv6-only link used to provide 212 connectivity to a service provider network, including link Internet- 213 layer (or higher layers) "tunnels", such as IPv4-in-IPv6 tunnels. 215 3. Requirements 217 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 218 Requirements for IPv6 Customer Edge Routers) and this document adds 219 new requirements, as described in the following sub-sections. 221 3.1. LAN-Side Configuration 223 A new LAN requirement is added, which in fact is common in regular 224 IPv6 Transition CE Routers, and it is required by most of the 225 transition mechanisms: 227 L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as 228 described in [RFC5625] (DNS Proxy Implementation Guidelines). 230 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4 231 as-a-Service - IPv4aaS) 233 The main target of this document is the support of IPv6-only WAN 234 access. To enable legacy IPv4 functionality, this document also 235 includes the support of IPv4-only devices and applications in the 236 customers LANs, as well as IPv4-only services on the Internet. Thus, 237 both IPv4-only and the IPv6-only devices in the customer-side LANs of 238 the IPv6 Transition CE Router are able to reach the IPv4-only 239 services. 241 Note that this document is only configuring the IPv4aaS in the IPv6 242 Transition CE Router itself, and not forwarding such information to 243 devices attached to the LANs, so the WAN configuration, availability 244 of native IPv4 or IPv4aaS, is transparent for them. 246 This document takes no position on simultaneous operation of one or 247 several transition mechanisms and/or native IPv4. 249 In order to seamlessly provide IPv4 service continuity in the 250 customer LANs, and allow automated IPv6 transition mechanism 251 provisioning, the following general transition requirements are 252 defined. 254 General transition requirements: 256 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 257 priority options described in [RFC8026] (Unified IPv4-in- 258 IPv6 Softwire Customer Premises Equipment (CPE): A 259 DHCPv6-Based Prioritization Mechanism). 261 TRANS-2: The IPv6 Transition CE Router MUST have a GUI and either a 262 CLI or API (or both) to manually enable/disable each of the 263 supported transition mechanisms. 265 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN 266 subnet, the IPv6 Transition CE Router MUST allow 267 appropriate subnetting and configuration of the address 268 space among the several interfaces. In some transition 269 mechanisms, this may require differentiating mappings/ 270 translations on a per-interface basis. 272 In order to allow the service provider to disable all the transition 273 mechanisms and/or choose the most convenient one, the IPv6 Transition 274 CE Router MUST follow the following configuration steps: 276 CONFIG-1: Request the relevant configuration options for each 277 supported transition mechanisms, which MUST remain 278 disabled at this step. 280 CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid 281 match in OPTION_S46_PRIORITY, which allows enabling/ 282 disabling a transition mechanism. 284 CONFIG-3: Keep disabled all the transition mechanisms if no match is 285 found between the priority list and the candidate list. 287 The following sections describe the requirements for supporting each 288 one of the transition mechanisms. An IPv6 Transition CE Router 289 intended for the retail market MUST support all of them. 291 3.2.1. 464XLAT 293 464XLAT [RFC6877] is a technique to provide IPv4 service over an 294 IPv6-only access network without encapsulation. This architecture 295 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 296 Protocol Translation from IPv6 Clients to IPv4 Servers) function 297 deployed at the service provider or a third-party network. 299 The IPv6 Transition CE Router MUST support CLAT functionality 300 [RFC6877] if intended for the retail market. If 464XLAT is 301 supported, it MUST be implemented according to [RFC6877]. The 302 following IPv6 Transition CE Router requirements also apply: 304 464XLAT requirements: 306 464XLAT-1: Unless a dedicated /64 prefix has been acquired, either 307 using DHCPv6-PD [RFC8415] (IPv6 Prefix Options for 308 DHCPv6) or by alternative means, the IPv6 Transition CE 309 Router MUST perform IPv4 Network Address Translation 310 (NAT) on IPv4 traffic translated using the CLAT. 312 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 313 [RFC6970] (UPnP Internet Gateway Device - Port Control 314 Protocol Interworking Function). 316 464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 317 Router MUST also implement [RFC7291] (DHCP Options for 318 the PCP). Following [RFC6887], if no PCP server is 319 configured, the IPv6 Transition CE Router MAY verify if 320 the default gateway, or the NAT64 is the PCP server. The 321 IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., 322 no IPv4-in-IPv6 encapsulation is used) to send PCP 323 requests to the server. 325 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 326 (Discovery of the IPv6 Prefix Used for IPv6 Address 327 Synthesis) in order to discover the PLAT-side translation 328 IPv4 and IPv6 prefix(es)/suffix(es). 330 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 331 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 332 the PCP), in order to learn the PLAT-side translation 333 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 334 PCP-controlled NAT64 device. 336 464XLAT-6: The priority for the NAT64 prefix, in case the network 337 provides several choices, MUST be: 1) [RFC7225], 2) 338 [RFC7050]. 340 464XLAT-7: If one or more NAT64 prefixes are learnt by means of 341 either [RFC7225] or [RFC7050], then 464XLAT MUST be 342 included in the candidate list of possible S46 mechanism 343 (Section 1.4.1 of [RFC8026]). 345 The NAT64 prefix could be discovered by means of [RFC7050] only in 346 the case the service provider uses DNS64 [RFC6147]. It may be the 347 case that the service provider does not use or does not trust DNS64 348 [RFC6147] because the DNS configuration at the CE (or hosts behind 349 the CE) can be modified by the customer. In that case, the service 350 provider may opt to configure the NAT64 prefix by means of [RFC7225]. 351 This can also be used if the service provider uses DNS64 [RFC6147]. 353 3.2.2. Dual-Stack Lite (DS-Lite) 355 Dual-Stack Lite [RFC6333] enables continued support for IPv4 356 services. Dual-Stack Lite enables a broadband service provider to 357 share IPv4 addresses among customers by combining two well-known 358 technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation 359 (NAT). It is expected that DS-Lite traffic is forwarded over the 360 IPv6 Transition CE Router's native IPv6 WAN interface, and not 361 encapsulated in another tunnel. 363 The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality 364 [RFC6333] if intended for the retail market. If DS-Lite is 365 supported, it MUST be implemented according to [RFC6333]. The 366 following IPv6 Transition CE Router requirements also apply: 368 DS-Lite requirements: 370 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 371 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 372 Option for Dual-Stack Lite). The IPv6 Transition CE 373 Router MAY use other mechanisms to configure DS-Lite 374 parameters. Such mechanisms are outside the scope of this 375 document. 377 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 378 [RFC6970] (UPnP Internet Gateway Device - Port Control 379 Protocol Interworking Function). 381 DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 382 Router SHOULD implement [RFC7291] (DHCP Options for the 383 PCP). If PCP [RFC6887] is implemented and a PCP server is 384 not configured, the IPv6 Transition CE Router MUST assume, 385 by default, that the AFTR is the PCP server. The IPv6 386 Transition CE Router MUST use plain IPv6 mode (i.e., no 387 IPv4-in-IPv6 encapsulation is used) to send PCP requests 388 to the server. The term "default" above is to be 389 interpreted as pertaining to a configuration as applied by 390 a vendor, prior to the administrator changing it for its 391 initial activation. 393 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 394 Network Address Translation (NAT) on IPv4 traffic 395 encapsulated using DS-Lite [RFC6333]. 397 3.2.3. Lightweight 4over6 (lw4o6) 399 lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the 400 NAPT function from the DS-Lite tunnel concentrator to the tunnel 401 client located in the IPv6 Transition CE Router, removing the 402 requirement for a CGN (Carrier Grade NAT, AFTR - Address Family 403 Transition Router) function in the tunnel concentrator and reducing 404 the amount of centralized state. 406 The IPv6 Transition CE Router MUST implement lwB4 functionality 407 [RFC7596] if intended for the retail market. If DS-Lite is 408 implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is 409 supported, it MUST be implemented according to [RFC7596]. The 410 following IPv6 Transition CE Router requirements also apply: 412 lw4o6 requirements: 414 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 415 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 416 Options for Configuration of Softwire Address and Port- 417 Mapped Clients). The IPv6 Transition CE Router MAY use 418 other mechanisms to configure lw4o6 parameters. Such 419 mechanisms are outside the scope of this document. 421 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 422 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 423 over-DHCPv6 Transport). 425 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 426 Allocation of Shared IPv4 Addresses as described in 427 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 429 3.2.4. MAP-E 431 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 432 an IPv6 network using IP encapsulation, including an algorithmic 433 mechanism for mapping between IPv6 and IPv4 addresses. 435 The IPv6 Transition CE Router MUST support MAP-E CE functionality 436 [RFC7597] if intended for the retail market. If MAP-E is supported, 437 it MUST be implemented according to [RFC7597]. The following IPv6 438 Transition CE Router requirements also apply: 440 MAP-E requirements: 442 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 443 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 444 for Configuration of Softwire Address and Port-Mapped 445 Clients). The IPv6 Transition CE Router MAY use other 446 mechanisms to configure MAP-E parameters. Such mechanisms 447 are outside the scope of this document. 449 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 450 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 451 Allocation of Shared IPv4 Addresses). 453 3.2.5. MAP-T 455 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 456 that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as 457 the form of IPv6 domain transport. 459 The IPv6 Transition CE Router MUST support MAP-T CE functionality 460 [RFC7599] if intended for the retail market. If MAP-T is supported, 461 it MUST be implemented according to [RFC7599]. The following IPv6 462 Transition CE Router requirements also apply: 464 MAP-T requirements: 466 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 467 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 468 for Configuration of Softwire Address and Port-Mapped 469 Clients). The IPv6 Transition CE Router MAY use other 470 mechanisms to configure MAP-T parameters. Such mechanisms 471 are outside the scope of this document. 473 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 474 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 475 Allocation of Shared IPv4 Addresses). 477 4. IPv4 Multicast Support 479 Existing IPv4 deployments support IPv4 multicast for services such as 480 IPTV. In the transition phase, it is expected that multicast 481 services will still be provided using IPv4 to the customer LANs. 483 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 484 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 485 Services to IPv4 Clients over an IPv6 Multicast Network) and 486 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 487 Prefixes). 489 5. UPnP Support 491 If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a 492 CE router, but cannot be associated with an IPv4 interface 493 established by an IPv4aaS mechanism or cannot determine which ports 494 are available, an AddPortMapping() or AddAnyPortMapping() action MUST 495 be rejected with error code 729 "ConflictWithOtherMechanisms". Port 496 availability could be determined through PCP or access to a 497 configured port set (if the IPv4aaS mechanism limits the available 498 ports). 500 An AddPortMapping() request for a port that is not available MUST 501 result in "ConflictInMappingEntry". 503 An AddAnyPortMapping() request for a port that is not available 504 SHOULD result in a successful mapping with an alternative 505 "NewReservedPort" value from within the configured port set range, or 506 as assigned by PCP as per [RFC6970], Section 5.6.1. 508 Note that IGD:1 and its WANIPConnection:1 service have been 509 deprecated by OCF (Open Connectivity Foundation). 511 6. Comparison to RFC7084 513 This document doesn't include support for 6rd [RFC5969], because it 514 is an IPv6-in-IPv4 tunneling. 516 Regarding DS-LITE [RFC6333], this document includes slightly 517 different requirements, related to the support of PCP [RFC6887], IGD- 518 PCP IWF [RFC6970] and the prioritization of the transition 519 mechanisms, including dual-stack. 521 7. Code Considerations 523 At the time of this writing, one of the apparent main issues for 524 vendors to include new functionalities, such as support for new 525 transition mechanisms, is the lack of space in the flash (or 526 equivalent) memory. However, it has been confirmed from existing 527 open source implementations (OpenWRT/LEDE, Linux, VPP, others), that 528 adding the support for the new transitions mechanisms, requires 529 around 10-12 Kbytes, because most of the code base is shared among 530 several transition mechanisms, which are already supported by 531 [RFC7084]. A single data plane is common to all them, which 532 typically means, in popular CEs already in the market [OpenWRT], the 533 new required code is only about 0.15% of the total existing code 534 size. 536 In general, the new requirements don't have extra cost in terms of 537 RAM memory, nor other hardware requirements such as more powerful 538 CPUs, if compared to the cost of NAT44 code, so existing hardware 539 should be able to support all them with minimal impact. 541 The other issue seems to be the cost of developing the code for those 542 new functionalities. However, at the time of writing this document, 543 it has been confirmed that there are several open source versions of 544 the required code for supporting all the new transition mechanisms, 545 and several vendors already have implementations and provide it to 546 ISPs, so the development cost is negligible, and only integration and 547 testing cost may become an issue. 549 Finally, in some cases, operators supporting several transition 550 mechanisms may need to consider training costs for staff in all the 551 techniques for their operation and management, even if this is not 552 directly caused by supporting this document, but because the business 553 decisions behind that. 555 8. Security Considerations 557 The IPv6 Transition CE Router must comply with the Security 558 Considerations as stated in [RFC7084], as well as those stated by 559 each transition mechanism implemented by the IPv6 Transition CE 560 Router. 562 As described in [RFC8026] and [RFC8415] Security Consideration 563 sections, there are generic DHCP security issues, which in the case 564 of this document means that malicious nodes may alter the priority of 565 the transition mechanisms. 567 Access network architecture for securing DHCP within the access 568 network is out of scope of this document. Securing DHCP in the LAN 569 is also not in scope. DHCP packets MUST NOT be forwarded between LAN 570 and WAN interfaces of an IPv6 Transition CE router. 572 9. IANA Considerations 574 IANA is requested, by means of this document, to update the "Option 575 Codes permitted in the S46 Priority Option" registry available at 576 https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 577 parameters.xhtml#option-codes-s46-priority-option, with the following 578 entry. 580 +-------------+--------------------+-----------+ 581 | Option Code | S46 Mechanism | Reference | 582 +-------------+--------------------+-----------+ 583 | 113 | 464XLAT | [thisdoc] | 584 +-------------+--------------------+-----------+ 586 Table 1: DHCPv6 Option Code for 464XLAT 588 10. Acknowledgements 590 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 591 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 592 Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, 593 for their review and comments in this and/or previous versions of 594 this document, as well as to the Last Call reviewers by the Ops-dir 595 (Dan Romascanu), Sec-dir (Christian Huitema), Rtg-dir (Daniele 596 Ceccarelli), Tsv-art (Martin Stiemerling), Gen-art (Matthew Miller) 597 and IESG (Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben 598 Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach). 600 11. Annex A: Usage Scenarios 602 The situation previously described, where there is ongoing IPv6 603 deployment and lack of IPv4 addresses, is not happening at the same 604 pace in every country, and even within every country, for every ISP. 605 For different technical, financial, commercial/marketing and socio- 606 economic reasons, each network is transitioning at their own pace; 607 the global transition timings cannot be reliably estimated. 609 Different studies (for example [IPv6Survey]) also show that the IPv6 610 deployment is a changing situation. In a single country, not all 611 operators will necessarily provide IPv6 support. Consumers may also 612 switch ISPs, and use the same IPv6 Transition CE Router with either 613 an ISP that provides IPv4-only or an ISP that provides IPv6 with 614 IPv4aaS. 616 So, to cover all those evolving situations, an IPv6 Transition CE 617 Router is required, at least from the perspective of the transition 618 support. 620 Moreover, because some services will remain IPv4-only for an 621 undetermined time, and some service providers will remain IPv4-only 622 for an undetermined period of time, IPv4 will be needed for an 623 undetermined period of time. There will be a need for CEs with 624 support "IPv4 as-a-Service" for an undetermined period of time. 626 This document, based on those premises, ensures that the IPv6 627 Transition CE Router allows the continued transition from networks 628 that today may provide access with dual-stack or IPv6-in-IPv4, as 629 described in [RFC7084], and as an "extension" to it, evolve to an 630 IPv6-only access with IPv4-as-a-Service. 632 Considering that situation and different possible usage cases, the 633 IPv6 Transition CE Router described in this document is expected to 634 be used typically, in residential/household, Small Office/Home Office 635 (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind 636 of Internet access (web, email, streaming, online gaming, etc.) and 637 even more advanced requirements including inbound connections (IP 638 cameras, web, DNS, email, VPN, etc.). 640 The above is not intended to be a comprehensive list of all the 641 possible usage cases, just an overall view. In fact, combinations of 642 the above usages are also possible, as well as situations where the 643 same CE is used at different times in different scenarios or even 644 different with services providers that may use a different transition 645 mechanism. 647 The mechanisms for allowing inbound connections are "naturally" 648 available in any IPv6 router when using GUA (IPv6 Global Unicast 649 Addresses), unless they are blocked by firewall rules, which may 650 require some manual configuration. 652 However, in the case of IPv4aaS, because the usage of private 653 addresses and NAT and even depending on the specific transition 654 mechanism, inbound connections typically require some degree of more 655 complex manual configuration such as setting up a DMZ, virtual 656 servers, or port/protocol forwarding. In general, IPv4 CE Routers 657 already provide a GUI, CLI or API to manually configure them, or the 658 possibility to setup the CE in bridge mode, so another CE behind it 659 takes care of that. The requirements for that support are out of the 660 scope of this document. 662 It is not relevant who provides the IPv6 Transition CE Router. In 663 most of the cases it is the service provider, and in fact they are 664 responsible, typically, of provisioning/managing at least the WAN 665 side. Commonly, the user has access to configure the LAN interfaces, 666 firewall, DMZ, and many other features. However, in many cases, the 667 user must supply or may replace the IPv6 Transition CE Router. This 668 underscores the importance of the IPv6 Transition CE Routers 669 fulfilling the same requirements defined in this document. 671 The IPv6 Transition CE Router described in this document is not 672 intended for usage in other scenarios such as large Enterprises, Data 673 Centers, Content Providers, etc. So even if the documented 674 requirements meet their needs, they may have additional requirements, 675 which are out of the scope of this document. 677 12. Annex B: End-User Network Architecture 679 According to the descriptions in the preceding sections, an end-user 680 network will likely support both IPv4 and IPv6. It is not expected 681 that an end-user will change their existing network topology with the 682 introduction of IPv6. There are some differences in how IPv6 works 683 and is provisioned; these differences have implications for the 684 network architecture. 686 A typical IPv4 end-user network consists of a "plug and play" router 687 with NAT functionality and a single link upstream, connected to the 688 service provider network. 690 From the perspective of an "IPv4 user" behind an IPv6 transition 691 Customer Edge Router with IPv4aaS, this doesn't change. 693 However, while a typical IPv4 NAT deployment by default blocks all 694 incoming connections and may allow opening of ports using a Universal 695 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 696 other firewall control protocol, in the case of an IPv6-only access 697 and IPv4aaS, that may not be feasible depending on specific 698 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 699 may be an alternative solution. 701 Another consequence of using IPv4 private address space in the end- 702 user network is that it provides stable addressing; that is, it 703 doesn't change, even when you change service providers, and the 704 addresses are always usable even when the WAN interface is down or 705 the customer edge router has not yet been provisioned. In the case 706 of an IPv6-only access, private IPv4 addresses are also available if 707 the IPv4aaS transition mechanism keeps running the NAT interface 708 towards the LAN side when the WAN interface is down. 710 More advanced routers support dynamic routing (which learns routes 711 from other routers), and advanced end-users can build arbitrary, 712 complex networks using manual configuration of address prefixes 713 combined with a dynamic routing protocol. Once again, this is true 714 for both IPv4 and IPv6. 716 In general, the end-user network architecture for IPv6 should provide 717 equivalent or better capabilities and functionality than the current 718 IPv4 architecture. 720 The end-user network is a stub network, in the sense that is not 721 providing transit to other external networks. However, HNCP 722 [RFC7788] allows support for automatic provisioning of downstream 723 routers. Figure 2 illustrates the model topology for the end-user 724 network. 726 +---------------+ \ 727 | Service | \ 728 | Provider | \ 729 | Router | | Service 730 +-------+-------+ | Provider 731 | IPv6-only | Network 732 | Customer / 733 | Internet Connection / 734 | / 735 +------+--------+ \ 736 | IPv6 | \ 737 | Customer Edge | \ 738 | Router | | 739 +---+-------+---+ | 740 Network A | | Network B | 741 -+----------------+-+- -+---+-------------+- | 742 | | | | | 743 +---+------+ | +----+-----+ +-----+----+ | 744 | IPv6 | | | IPv4 | |IPv4/IPv6 | | 745 | Host | | | Host | | Host | | 746 +----------+ | +----------+ +----------+ | End-User 747 | | Network(s) 748 +------+--------+ | 749 | IPv6 | | 750 | Router | | 751 +------+--------+ | 752 Network C | | 753 -+-------------+--+- | 754 | | | 755 +---+------+ +----+-----+ | 756 | IPv6 | | IPv6 | / 757 | Host | | Host | / 758 +----------+ +----------+ / 760 Figure 2: An Example of a Typical End-User Network 762 This architecture describes the: 764 o Basic capabilities of the IPv6 Transition CE Router 766 o Provisioning of the WAN interface connecting to the service 767 provider 769 o Provisioning of the LAN interfaces 771 The IPv6 Transition CE Router may be manually configured in an 772 arbitrary topology with a dynamic routing protocol or using HNCP 773 [RFC7788]. Automatic provisioning and configuration is described for 774 a single IPv6 Transition CE Router only. 776 13. ANNEX C: Changes from -00 778 Section to be removed by RFC Editor. Significant updates are: 780 1. ID-Nits: IANA section. 782 2. ID-Nits: RFC7084 reference removed from Abstract. 784 3. This document no longer updates RFC7084. 786 4. UPnP section reworded. 788 5. "CE Router" changed to "IPv6 Transition CE Router". 790 6. Reduced text in Annex A. 792 14. ANNEX D: Changes from -01 794 Section to be removed by RFC Editor. Significant updates are: 796 1. TRANS requirements reworked in order to increase operator control 797 and allow gradual transitioning from dual-stack to IPv6-only on 798 specific customers. 800 2. New TRANS requirement so all the supported transition mechanisms 801 are disabled by default, in order to facilitate the operator 802 management. 804 3. New TRANS requirement in order to allow turning on/off each 805 transition mechanism by the user. 807 4. Clarification on how to obtain multiple /64 for 464XLAT. 809 5. S46 priority update to RFC8026 for including 464XLAT and related 810 changes in several sections. 812 15. ANNEX E: Changes from -02 814 Section to be removed by RFC Editor. Significant updates are: 816 1. RFC8026 update removed, not needed with new approach. 818 2. TRANS and 464XLAT requirements reworded in order to match new 819 approach to allow operator control on each/all the transition 820 mechanisms. 822 3. Added text in 464XLAT to clarify the usage. 824 16. ANNEX F: Changes from -03 826 Section to be removed by RFC Editor. Significant updates are: 828 1. Several editorial changes across the document, specially TRANS 829 requirements. 831 2. DNS proxy MUST instead of SHOULD. 833 17. ANNEX G: Changes from -04 835 Section to be removed by RFC Editor. Significant updates are: 837 1. Removed G-1. 839 2. Added support for draft-pref64folks-6man-ra-pref64. 841 3. General text clarifications. 843 18. ANNEX H: Changes from -05 845 Section to be removed by RFC Editor. Significant updates are: 847 1. Reworded and shorter UPnP section and new informative reference. 849 2. New general transition requirement in case multiple public IPv4 850 prefixes are provided, so to run multiple instances according to 851 each specific transition mechanism. 853 3. General text clarifications. 855 19. ANNEX I: Changes from -06 857 Section to be removed by RFC Editor. Significant updates are: 859 1. Removed reference and text related to pref64folks-6man-ra-pref64. 861 2. General text clarifications. 863 20. ANNEX J: Changes from -07 865 Section to be removed by RFC Editor. Significant updates are: 867 1. Added text to UPnP section. 869 21. ANNEX K: Changes from -08, -09 and -10 871 Section to be removed by RFC Editor. Significant updates are: 873 1. Editorial edits. 875 22. ANNEX L: Changes from -11, -12 and -13 877 Section to be removed by RFC Editor. Significant updates are: 879 1. Changes related to suggestions by Ops-dir, Sec-dir, Rtg-dir, Tsv- 880 art and Gen-art, as well as comments from IESG review. 882 23. References 884 23.1. Normative References 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, 888 DOI 10.17487/RFC2119, March 1997, 889 . 891 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 892 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 893 . 895 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 896 Infrastructures (6rd) -- Protocol Specification", 897 RFC 5969, DOI 10.17487/RFC5969, August 2010, 898 . 900 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 901 NAT64: Network Address and Protocol Translation from IPv6 902 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 903 April 2011, . 905 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 906 Beijnum, "DNS64: DNS Extensions for Network Address 907 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 908 DOI 10.17487/RFC6147, April 2011, 909 . 911 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 912 Stack Lite Broadband Deployments Following IPv4 913 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 914 . 916 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 917 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 918 RFC 6334, DOI 10.17487/RFC6334, August 2011, 919 . 921 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 922 Combination of Stateful and Stateless Translation", 923 RFC 6877, DOI 10.17487/RFC6877, April 2013, 924 . 926 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 927 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 928 DOI 10.17487/RFC6887, April 2013, 929 . 931 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 932 Play (UPnP) Internet Gateway Device - Port Control 933 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 934 DOI 10.17487/RFC6970, July 2013, 935 . 937 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 938 the IPv6 Prefix Used for IPv6 Address Synthesis", 939 RFC 7050, DOI 10.17487/RFC7050, November 2013, 940 . 942 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 943 Requirements for IPv6 Customer Edge Routers", RFC 7084, 944 DOI 10.17487/RFC7084, November 2013, 945 . 947 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 948 Port Control Protocol (PCP)", RFC 7225, 949 DOI 10.17487/RFC7225, May 2014, 950 . 952 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 953 the Port Control Protocol (PCP)", RFC 7291, 954 DOI 10.17487/RFC7291, July 2014, 955 . 957 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 958 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 959 RFC 7341, DOI 10.17487/RFC7341, August 2014, 960 . 962 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 963 Farrer, "Lightweight 4over6: An Extension to the Dual- 964 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 965 July 2015, . 967 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 968 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 969 Port with Encapsulation (MAP-E)", RFC 7597, 970 DOI 10.17487/RFC7597, July 2015, 971 . 973 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 974 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 975 Configuration of Softwire Address and Port-Mapped 976 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 977 . 979 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 980 and T. Murakami, "Mapping of Address and Port using 981 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 982 2015, . 984 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 985 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 986 RFC 7618, DOI 10.17487/RFC7618, August 2015, 987 . 989 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 990 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 991 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 992 November 2016, . 994 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 995 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 996 over an IPv6 Multicast Network", RFC 8114, 997 DOI 10.17487/RFC8114, March 2017, 998 . 1000 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 1001 Option for IPv4-Embedded Multicast and Unicast IPv6 1002 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 1003 . 1005 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1006 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1007 May 2017, . 1009 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1010 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1011 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1012 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1013 . 1015 23.2. Informative References 1017 [IPv6Survey] 1018 Palet Martinez, J., "IPv6 Deployment Survey", January 1019 2018, 1020 . 1023 [OpenWRT] OpenWRT, "OpenWRT Packages", January 2018, 1024 . 1026 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1027 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1028 2016, . 1030 [UPnP-IGD] 1031 UPnP Forum, "InternetGatewayDevice:2 Device Template 1032 Version 1.01", December 2010, 1033 . 1035 [UPnP-WANIPC] 1036 UPnP Forum, "WANIPConnection:2 Service", December 2010, 1037 . 1040 Authors' Addresses 1042 Jordi Palet Martinez 1043 The IPv6 Company 1044 Molino de la Navata, 75 1045 La Navata - Galapagar, Madrid 28420 1046 Spain 1048 Email: jordi.palet@theipv6company.com 1049 URI: http://www.theipv6company.com/ 1050 Hans M.-H. Liu 1051 D-Link Systems, Inc. 1052 17595 Mount Herrmann St. 1053 Fountain Valley, California 92708 1054 US 1056 Email: hans.liu@dlinkcorp.com 1057 URI: http://www.dlink.com/ 1059 Masanobu Kawashima 1060 NEC Platforms, Ltd. 1061 800, Shimomata 1062 Kakegawa-shi, Shizuoka 436-8501 1063 Japan 1065 Email: kawashimam@vx.jp.nec.com 1066 URI: https://www.necplatforms.co.jp/en/