idnits 2.17.00 (12 Aug 2021) /tmp/idnits51218/draft-ietf-v6ops-transition-ipv4aas-15.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 28, 2019) is 1202 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: August 1, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 January 28, 2019 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-15 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 August 1, 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) . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 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, -13 and -14 . . . . . . . . . 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, 286 unless a NAT64 prefix has been configured, in which case, 287 464XLAT MUST be enabled. 289 Because 464XLAT has not DHCPv6 configuration options, it can't be 290 included, at the time being, in the OPTION_S46_PRIORITY. In the 291 future, an update of [RFC8026] or a NAT64 DHCPv6 configuration 292 option, may enable it. Meanwhile, if an operator provides 464XLAT, 293 it needs to ensure that OPTION_S46_PRIORITY is not sent for any other 294 transition mechanism to the relevant customers. 296 The following sections describe the requirements for supporting each 297 one of the transition mechanisms. An IPv6 Transition CE Router 298 intended for the retail market MUST support all of them. 300 3.2.1. 464XLAT 302 464XLAT [RFC6877] is a technique to provide IPv4 service over an 303 IPv6-only access network without encapsulation. This architecture 304 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 305 Protocol Translation from IPv6 Clients to IPv4 Servers) function 306 deployed at the service provider or a third-party network. 308 The IPv6 Transition CE Router MUST support CLAT functionality 309 [RFC6877] if intended for the retail market. If 464XLAT is 310 supported, it MUST be implemented according to [RFC6877]. The 311 following IPv6 Transition CE Router requirements also apply: 313 464XLAT requirements: 315 464XLAT-1: Unless a dedicated /64 prefix has been acquired, either 316 using DHCPv6-PD [RFC8415] (IPv6 Prefix Options for 317 DHCPv6) or by alternative means, the IPv6 Transition CE 318 Router MUST perform IPv4 Network Address Translation 319 (NAT) on IPv4 traffic translated using the CLAT. 321 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 322 [RFC6970] (UPnP Internet Gateway Device - Port Control 323 Protocol Interworking Function). 325 464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 326 Router MUST also implement [RFC7291] (DHCP Options for 327 the PCP). Following [RFC6887], if no PCP server is 328 configured, the IPv6 Transition CE Router MAY verify if 329 the default gateway, or the NAT64 is the PCP server. The 330 IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., 331 no IPv4-in-IPv6 encapsulation is used) to send PCP 332 requests to the server. 334 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 335 (Discovery of the IPv6 Prefix Used for IPv6 Address 336 Synthesis) in order to discover the PLAT-side translation 337 IPv4 and IPv6 prefix(es)/suffix(es). 339 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 340 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 341 the PCP), in order to learn the PLAT-side translation 342 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 343 PCP-controlled NAT64 device. 345 464XLAT-6: The priority for the NAT64 prefix, in case the network 346 provides several choices, MUST be: 1) [RFC7225], 2) 347 [RFC7050]. 349 The NAT64 prefix could be discovered by means of [RFC7050] only in 350 the case the service provider uses DNS64 [RFC6147]. It may be the 351 case that the service provider does not use or does not trust DNS64 352 [RFC6147] because the DNS configuration at the CE (or hosts behind 353 the CE) can be modified by the customer. In that case, the service 354 provider may opt to configure the NAT64 prefix by means of [RFC7225]. 355 This can also be used if the service provider uses DNS64 [RFC6147]. 357 3.2.2. Dual-Stack Lite (DS-Lite) 359 Dual-Stack Lite [RFC6333] enables continued support for IPv4 360 services. Dual-Stack Lite enables a broadband service provider to 361 share IPv4 addresses among customers by combining two well-known 362 technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation 363 (NAT). It is expected that DS-Lite traffic is forwarded over the 364 IPv6 Transition CE Router's native IPv6 WAN interface, and not 365 encapsulated in another tunnel. 367 The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality 368 [RFC6333] if intended for the retail market. If DS-Lite is 369 supported, it MUST be implemented according to [RFC6333]. The 370 following IPv6 Transition CE Router requirements also apply: 372 DS-Lite requirements: 374 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 375 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 376 Option for Dual-Stack Lite). The IPv6 Transition CE 377 Router MAY use other mechanisms to configure DS-Lite 378 parameters. Such mechanisms are outside the scope of this 379 document. 381 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 382 [RFC6970] (UPnP Internet Gateway Device - Port Control 383 Protocol Interworking Function). 385 DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 386 Router SHOULD implement [RFC7291] (DHCP Options for the 387 PCP). If PCP [RFC6887] is implemented and a PCP server is 388 not configured, the IPv6 Transition CE Router MUST assume, 389 by default, that the AFTR is the PCP server. The IPv6 390 Transition CE Router MUST use plain IPv6 mode (i.e., no 391 IPv4-in-IPv6 encapsulation is used) to send PCP requests 392 to the server. The term "default" above is to be 393 interpreted as pertaining to a configuration as applied by 394 a vendor, prior to the administrator changing it for its 395 initial activation. 397 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 398 Network Address Translation (NAT) on IPv4 traffic 399 encapsulated using DS-Lite [RFC6333]. 401 3.2.3. Lightweight 4over6 (lw4o6) 403 lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the 404 NAPT function from the DS-Lite tunnel concentrator to the tunnel 405 client located in the IPv6 Transition CE Router, removing the 406 requirement for a CGN (Carrier Grade NAT, AFTR - Address Family 407 Transition Router) function in the tunnel concentrator and reducing 408 the amount of centralized state. 410 The IPv6 Transition CE Router MUST implement lwB4 functionality 411 [RFC7596] if intended for the retail market. If DS-Lite is 412 implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is 413 supported, it MUST be implemented according to [RFC7596]. The 414 following IPv6 Transition CE Router requirements also apply: 416 lw4o6 requirements: 418 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 419 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 420 Options for Configuration of Softwire Address and Port- 421 Mapped Clients). The IPv6 Transition CE Router MAY use 422 other mechanisms to configure lw4o6 parameters. Such 423 mechanisms are outside the scope of this document. 425 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 426 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 427 over-DHCPv6 Transport). 429 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 430 Allocation of Shared IPv4 Addresses as described in 431 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 433 3.2.4. MAP-E 435 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 436 an IPv6 network using IP encapsulation, including an algorithmic 437 mechanism for mapping between IPv6 and IPv4 addresses. 439 The IPv6 Transition CE Router MUST support MAP-E CE functionality 440 [RFC7597] if intended for the retail market. If MAP-E is supported, 441 it MUST be implemented according to [RFC7597]. The following IPv6 442 Transition CE Router requirements also apply: 444 MAP-E requirements: 446 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 447 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 448 for Configuration of Softwire Address and Port-Mapped 449 Clients). The IPv6 Transition CE Router MAY use other 450 mechanisms to configure MAP-E parameters. Such mechanisms 451 are outside the scope of this document. 453 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 454 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 455 Allocation of Shared IPv4 Addresses). 457 3.2.5. MAP-T 459 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 460 that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as 461 the form of IPv6 domain transport. 463 The IPv6 Transition CE Router MUST support MAP-T CE functionality 464 [RFC7599] if intended for the retail market. If MAP-T is supported, 465 it MUST be implemented according to [RFC7599]. The following IPv6 466 Transition CE Router requirements also apply: 468 MAP-T requirements: 470 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 471 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 472 for Configuration of Softwire Address and Port-Mapped 473 Clients). The IPv6 Transition CE Router MAY use other 474 mechanisms to configure MAP-T parameters. Such mechanisms 475 are outside the scope of this document. 477 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 478 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 479 Allocation of Shared IPv4 Addresses). 481 4. IPv4 Multicast Support 483 Existing IPv4 deployments support IPv4 multicast for services such as 484 IPTV. In the transition phase, it is expected that multicast 485 services will still be provided using IPv4 to the customer LANs. 487 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 488 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 489 Services to IPv4 Clients over an IPv6 Multicast Network) and 490 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 491 Prefixes). 493 5. UPnP Support 495 If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a 496 CE router, but cannot be associated with an IPv4 interface 497 established by an IPv4aaS mechanism or cannot determine which ports 498 are available, an AddPortMapping() or AddAnyPortMapping() action MUST 499 be rejected with error code 729 "ConflictWithOtherMechanisms". Port 500 availability could be determined through PCP or access to a 501 configured port set (if the IPv4aaS mechanism limits the available 502 ports). 504 An AddPortMapping() request for a port that is not available MUST 505 result in "ConflictInMappingEntry". 507 An AddAnyPortMapping() request for a port that is not available 508 SHOULD result in a successful mapping with an alternative 509 "NewReservedPort" value from within the configured port set range, or 510 as assigned by PCP as per [RFC6970], Section 5.6.1. 512 Note that IGD:1 and its WANIPConnection:1 service have been 513 deprecated by OCF (Open Connectivity Foundation). 515 6. Comparison to RFC7084 517 This document doesn't include support for 6rd [RFC5969], because it 518 is an IPv6-in-IPv4 tunneling. 520 Regarding DS-LITE [RFC6333], this document includes slightly 521 different requirements, related to the support of PCP [RFC6887], IGD- 522 PCP IWF [RFC6970] and the prioritization of the transition 523 mechanisms, including dual-stack. 525 7. Code Considerations 527 At the time of this writing, one of the apparent main issues for 528 vendors to include new functionalities, such as support for new 529 transition mechanisms, is the lack of space in the flash (or 530 equivalent) memory. However, it has been confirmed from existing 531 open source implementations (OpenWRT/LEDE, Linux, VPP, others), that 532 adding the support for the new transition mechanisms, requires around 533 10-12 Kbytes, because most of the code base is shared among several 534 transition mechanisms, which are already supported by [RFC7084]. A 535 single data plane is common to all them, which typically means, in 536 popular CEs already in the market [OpenWRT], the new required code is 537 only about 0.15% of the total existing code size. 539 In general, the new requirements don't have extra cost in terms of 540 RAM memory, nor other hardware requirements such as more powerful 541 CPUs, if compared to the cost of NAT44 code, so existing hardware 542 should be able to support all them with minimal impact. 544 The other issue seems to be the cost of developing the code for those 545 new functionalities. However, at the time of writing this document, 546 it has been confirmed that there are several open source versions of 547 the required code for supporting all the new transition mechanisms, 548 and several vendors already have implementations and provide it to 549 ISPs, so the development cost is negligible, and only integration and 550 testing cost may become an issue. 552 Finally, in some cases, operators supporting several transition 553 mechanisms may need to consider training costs for staff in all the 554 techniques for their operation and management, even if this is not 555 directly caused by supporting this document, but because the business 556 decisions behind that. 558 8. Security Considerations 560 The IPv6 Transition CE Router must comply with the Security 561 Considerations as stated in [RFC7084], as well as those stated by 562 each transition mechanism implemented by the IPv6 Transition CE 563 Router. 565 As described in [RFC8026] and [RFC8415] Security Consideration 566 sections, there are generic DHCP security issues, which in the case 567 of this document means that malicious nodes may alter the priority of 568 the transition mechanisms. 570 Access network architecture for securing DHCP within the access 571 network is out of scope of this document. Securing DHCP in the LAN 572 is also not in scope. DHCP packets MUST NOT be forwarded between LAN 573 and WAN interfaces of an IPv6 Transition CE router. 575 9. IANA Considerations 577 This document does not have any new specific IANA considerations. 579 10. Acknowledgements 581 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 582 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 583 Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, 584 for their review and comments in this and/or previous versions of 585 this document, as well as to the Last Call reviewers by the Ops-dir 586 (Dan Romascanu), Sec-dir (Christian Huitema), Rtg-dir (Daniele 587 Ceccarelli), Tsv-art (Martin Stiemerling), Gen-art (Matthew Miller) 588 and IESG (Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben 589 Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach). 591 11. Annex A: Usage Scenarios 593 The situation previously described, where there is ongoing IPv6 594 deployment and lack of IPv4 addresses, is not happening at the same 595 pace in every country, and even within every country, for every ISP. 596 For different technical, financial, commercial/marketing and socio- 597 economic reasons, each network is transitioning at their own pace; 598 the global transition timings cannot be reliably estimated. 600 Different studies (for example [IPv6Survey]) also show that the IPv6 601 deployment is a changing situation. In a single country, not all 602 operators will necessarily provide IPv6 support. Consumers may also 603 switch ISPs, and use the same IPv6 Transition CE Router with either 604 an ISP that provides IPv4-only or an ISP that provides IPv6 with 605 IPv4aaS. 607 So, to cover all those evolving situations, an IPv6 Transition CE 608 Router is required, at least from the perspective of the transition 609 support. 611 Moreover, because some services will remain IPv4-only for an 612 undetermined time, and some service providers will remain IPv4-only 613 for an undetermined period of time, IPv4 will be needed for an 614 undetermined period of time. There will be a need for CEs with 615 support "IPv4 as-a-Service" for an undetermined period of time. 617 This document, based on those premises, ensures that the IPv6 618 Transition CE Router allows the continued transition from networks 619 that today may provide access with dual-stack or IPv6-in-IPv4, as 620 described in [RFC7084], and as an "extension" to it, evolve to an 621 IPv6-only access with IPv4-as-a-Service. 623 Considering that situation and different possible usage cases, the 624 IPv6 Transition CE Router described in this document is expected to 625 be used typically, in residential/household, Small Office/Home Office 626 (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind 627 of Internet access (web, email, streaming, online gaming, etc.) and 628 even more advanced requirements including inbound connections (IP 629 cameras, web, DNS, email, VPN, etc.). 631 The above is not intended to be a comprehensive list of all the 632 possible usage cases, just an overall view. In fact, combinations of 633 the above usages are also possible, as well as situations where the 634 same CE is used at different times in different scenarios or even 635 different with services providers that may use a different transition 636 mechanism. 638 The mechanisms for allowing inbound connections are "naturally" 639 available in any IPv6 router when using GUA (IPv6 Global Unicast 640 Addresses), unless they are blocked by firewall rules, which may 641 require some manual configuration. 643 However, in the case of IPv4aaS, because the usage of private 644 addresses and NAT and even depending on the specific transition 645 mechanism, inbound connections typically require some degree of more 646 complex manual configuration such as setting up a DMZ, virtual 647 servers, or port/protocol forwarding. In general, IPv4 CE Routers 648 already provide a GUI, CLI or API to manually configure them, or the 649 possibility to setup the CE in bridge mode, so another CE behind it 650 takes care of that. The requirements for that support are out of the 651 scope of this document. 653 It is not relevant who provides the IPv6 Transition CE Router. In 654 most of the cases it is the service provider, and in fact they are 655 responsible, typically, of provisioning/managing at least the WAN 656 side. Commonly, the user has access to configure the LAN interfaces, 657 firewall, DMZ, and many other features. However, in many cases, the 658 user must supply or may replace the IPv6 Transition CE Router. This 659 underscores the importance of the IPv6 Transition CE Routers 660 fulfilling the same requirements defined in this document. 662 The IPv6 Transition CE Router described in this document is not 663 intended for usage in other scenarios such as large Enterprises, Data 664 Centers, Content Providers, etc. So even if the documented 665 requirements meet their needs, they may have additional requirements, 666 which are out of the scope of this document. 668 12. Annex B: End-User Network Architecture 670 According to the descriptions in the preceding sections, an end-user 671 network will likely support both IPv4 and IPv6. It is not expected 672 that an end-user will change their existing network topology with the 673 introduction of IPv6. There are some differences in how IPv6 works 674 and is provisioned; these differences have implications for the 675 network architecture. 677 A typical IPv4 end-user network consists of a "plug and play" router 678 with NAT functionality and a single link upstream, connected to the 679 service provider network. 681 From the perspective of an "IPv4 user" behind an IPv6 transition 682 Customer Edge Router with IPv4aaS, this doesn't change. 684 However, while a typical IPv4 NAT deployment by default blocks all 685 incoming connections and may allow opening of ports using a Universal 686 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 687 other firewall control protocol, in the case of an IPv6-only access 688 and IPv4aaS, that may not be feasible depending on specific 689 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 690 may be an alternative solution. 692 Another consequence of using IPv4 private address space in the end- 693 user network is that it provides stable addressing; that is, it 694 doesn't change, even when you change service providers, and the 695 addresses are always usable even when the WAN interface is down or 696 the customer edge router has not yet been provisioned. In the case 697 of an IPv6-only access, private IPv4 addresses are also available if 698 the IPv4aaS transition mechanism keeps running the NAT interface 699 towards the LAN side when the WAN interface is down. 701 More advanced routers support dynamic routing (which learns routes 702 from other routers), and advanced end-users can build arbitrary, 703 complex networks using manual configuration of address prefixes 704 combined with a dynamic routing protocol. Once again, this is true 705 for both IPv4 and IPv6. 707 In general, the end-user network architecture for IPv6 should provide 708 equivalent or better capabilities and functionality than the current 709 IPv4 architecture. 711 The end-user network is a stub network, in the sense that is not 712 providing transit to other external networks. However, HNCP 713 [RFC7788] allows support for automatic provisioning of downstream 714 routers. Figure 2 illustrates the model topology for the end-user 715 network. 717 +---------------+ \ 718 | Service | \ 719 | Provider | \ 720 | Router | | Service 721 +-------+-------+ | Provider 722 | IPv6-only | Network 723 | Customer / 724 | Internet Connection / 725 | / 726 +------+--------+ \ 727 | IPv6 | \ 728 | Customer Edge | \ 729 | Router | | 730 +---+-------+---+ | 731 Network A | | Network B | 732 -+----------------+-+- -+---+-------------+- | 733 | | | | | 734 +---+------+ | +----+-----+ +-----+----+ | 735 | IPv6 | | | IPv4 | |IPv4/IPv6 | | 736 | Host | | | Host | | Host | | 737 +----------+ | +----------+ +----------+ | End-User 738 | | Network(s) 739 +------+--------+ | 740 | IPv6 | | 741 | Router | | 742 +------+--------+ | 743 Network C | | 744 -+-------------+--+- | 745 | | | 746 +---+------+ +----+-----+ | 747 | IPv6 | | IPv6 | / 748 | Host | | Host | / 749 +----------+ +----------+ / 751 Figure 2: An Example of a Typical End-User Network 753 This architecture describes the: 755 o Basic capabilities of the IPv6 Transition CE Router 757 o Provisioning of the WAN interface connecting to the service 758 provider 760 o Provisioning of the LAN interfaces 762 The IPv6 Transition CE Router may be manually configured in an 763 arbitrary topology with a dynamic routing protocol or using HNCP 764 [RFC7788]. Automatic provisioning and configuration is described for 765 a single IPv6 Transition CE Router only. 767 13. ANNEX C: Changes from -00 769 Section to be removed by RFC Editor. Significant updates are: 771 1. ID-Nits: IANA section. 773 2. ID-Nits: RFC7084 reference removed from Abstract. 775 3. This document no longer updates RFC7084. 777 4. UPnP section reworded. 779 5. "CE Router" changed to "IPv6 Transition CE Router". 781 6. Reduced text in Annex A. 783 14. ANNEX D: Changes from -01 785 Section to be removed by RFC Editor. Significant updates are: 787 1. TRANS requirements reworked in order to increase operator control 788 and allow gradual transitioning from dual-stack to IPv6-only on 789 specific customers. 791 2. New TRANS requirement so all the supported transition mechanisms 792 are disabled by default, in order to facilitate the operator 793 management. 795 3. New TRANS requirement in order to allow turning on/off each 796 transition mechanism by the user. 798 4. Clarification on how to obtain multiple /64 for 464XLAT. 800 5. S46 priority update to RFC8026 for including 464XLAT and related 801 changes in several sections. 803 15. ANNEX E: Changes from -02 805 Section to be removed by RFC Editor. Significant updates are: 807 1. RFC8026 update removed, not needed with new approach. 809 2. TRANS and 464XLAT requirements reworded in order to match new 810 approach to allow operator control on each/all the transition 811 mechanisms. 813 3. Added text in 464XLAT to clarify the usage. 815 16. ANNEX F: Changes from -03 817 Section to be removed by RFC Editor. Significant updates are: 819 1. Several editorial changes across the document, specially TRANS 820 requirements. 822 2. DNS proxy MUST instead of SHOULD. 824 17. ANNEX G: Changes from -04 826 Section to be removed by RFC Editor. Significant updates are: 828 1. Removed G-1. 830 2. Added support for draft-pref64folks-6man-ra-pref64. 832 3. General text clarifications. 834 18. ANNEX H: Changes from -05 836 Section to be removed by RFC Editor. Significant updates are: 838 1. Reworded and shorter UPnP section and new informative reference. 840 2. New general transition requirement in case multiple public IPv4 841 prefixes are provided, so to run multiple instances according to 842 each specific transition mechanism. 844 3. General text clarifications. 846 19. ANNEX I: Changes from -06 848 Section to be removed by RFC Editor. Significant updates are: 850 1. Removed reference and text related to pref64folks-6man-ra-pref64. 852 2. General text clarifications. 854 20. ANNEX J: Changes from -07 856 Section to be removed by RFC Editor. Significant updates are: 858 1. Added text to UPnP section. 860 21. ANNEX K: Changes from -08, -09 and -10 862 Section to be removed by RFC Editor. Significant updates are: 864 1. Editorial edits. 866 22. ANNEX L: Changes from -11, -12, -13 and -14 868 Section to be removed by RFC Editor. Significant updates are: 870 1. Changes related to suggestions by Ops-dir, Sec-dir, Rtg-dir, Tsv- 871 art and Gen-art, as well as comments from IESG review. 873 2. IANA section removed as a consequence of the removal of the 874 inclusion of 464XLAT in the RFC8026 priority mechanism. 876 23. References 878 23.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 886 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 887 . 889 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 890 Infrastructures (6rd) -- Protocol Specification", 891 RFC 5969, DOI 10.17487/RFC5969, August 2010, 892 . 894 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 895 NAT64: Network Address and Protocol Translation from IPv6 896 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 897 April 2011, . 899 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 900 Beijnum, "DNS64: DNS Extensions for Network Address 901 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 902 DOI 10.17487/RFC6147, April 2011, 903 . 905 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 906 Stack Lite Broadband Deployments Following IPv4 907 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 908 . 910 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 911 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 912 RFC 6334, DOI 10.17487/RFC6334, August 2011, 913 . 915 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 916 Combination of Stateful and Stateless Translation", 917 RFC 6877, DOI 10.17487/RFC6877, April 2013, 918 . 920 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 921 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 922 DOI 10.17487/RFC6887, April 2013, 923 . 925 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 926 Play (UPnP) Internet Gateway Device - Port Control 927 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 928 DOI 10.17487/RFC6970, July 2013, 929 . 931 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 932 the IPv6 Prefix Used for IPv6 Address Synthesis", 933 RFC 7050, DOI 10.17487/RFC7050, November 2013, 934 . 936 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 937 Requirements for IPv6 Customer Edge Routers", RFC 7084, 938 DOI 10.17487/RFC7084, November 2013, 939 . 941 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 942 Port Control Protocol (PCP)", RFC 7225, 943 DOI 10.17487/RFC7225, May 2014, 944 . 946 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 947 the Port Control Protocol (PCP)", RFC 7291, 948 DOI 10.17487/RFC7291, July 2014, 949 . 951 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 952 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 953 RFC 7341, DOI 10.17487/RFC7341, August 2014, 954 . 956 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 957 Farrer, "Lightweight 4over6: An Extension to the Dual- 958 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 959 July 2015, . 961 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 962 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 963 Port with Encapsulation (MAP-E)", RFC 7597, 964 DOI 10.17487/RFC7597, July 2015, 965 . 967 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 968 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 969 Configuration of Softwire Address and Port-Mapped 970 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 971 . 973 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 974 and T. Murakami, "Mapping of Address and Port using 975 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 976 2015, . 978 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 979 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 980 RFC 7618, DOI 10.17487/RFC7618, August 2015, 981 . 983 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 984 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 985 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 986 November 2016, . 988 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 989 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 990 over an IPv6 Multicast Network", RFC 8114, 991 DOI 10.17487/RFC8114, March 2017, 992 . 994 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 995 Option for IPv4-Embedded Multicast and Unicast IPv6 996 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 997 . 999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1001 May 2017, . 1003 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1004 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1005 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1006 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1007 . 1009 23.2. Informative References 1011 [IPv6Survey] 1012 Palet Martinez, J., "IPv6 Deployment Survey", January 1013 2018, 1014 . 1017 [OpenWRT] OpenWRT, "OpenWRT Packages", January 2018, 1018 . 1020 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1021 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1022 2016, . 1024 [UPnP-IGD] 1025 UPnP Forum, "InternetGatewayDevice:2 Device Template 1026 Version 1.01", December 2010, 1027 . 1029 [UPnP-WANIPC] 1030 UPnP Forum, "WANIPConnection:2 Service", December 2010, 1031 . 1034 Authors' Addresses 1036 Jordi Palet Martinez 1037 The IPv6 Company 1038 Molino de la Navata, 75 1039 La Navata - Galapagar, Madrid 28420 1040 Spain 1042 Email: jordi.palet@theipv6company.com 1043 URI: http://www.theipv6company.com/ 1044 Hans M.-H. Liu 1045 D-Link Systems, Inc. 1046 17595 Mount Herrmann St. 1047 Fountain Valley, California 92708 1048 US 1050 Email: hans.liu@dlinkcorp.com 1051 URI: http://www.dlink.com/ 1053 Masanobu Kawashima 1054 NEC Platforms, Ltd. 1055 800, Shimomata 1056 Kakegawa-shi, Shizuoka 436-8501 1057 Japan 1059 Email: kawashimam@vx.jp.nec.com 1060 URI: https://www.necplatforms.co.jp/en/