idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 27, 2018) is 1918 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: June 30, 2019 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 December 27, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-12 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 June 30, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language - Special Note . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 6 71 3.2. Transition Technologies Support for IPv4 Service 72 Continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 6 73 3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 9 75 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 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], so the scope of this document is to ensure the 112 IPv4 "service continuity" support, in the LAN side, ensuring that 113 remote IPv4-only services are accessible, from an IPv6-only Internet 114 Service Provider access network (typically referred as WAN - Wide 115 Area Network, even in some cases it may be metropolitan, regional, 116 etc.) even from IPv6-only applications or devices in the LAN side. 118 +------------+ +------------+ \ 119 | IPv4-only | | IPv4/IPv6 | \ 120 | Remote | | Remote | | 121 | Host | | Host | | Internet 122 +--------+---+ +---+--------+ | 123 | | / 124 | | / 125 +-+-----------+-+ \ 126 | Service | \ 127 | Provider | \ 128 | Router | | Service 129 +-------+-------+ | Provider 130 | IPv6-only | Network 131 | Customer / 132 | Internet Connection / 133 | / 134 +------+--------+ \ 135 | IPv6 | \ 136 | Customer Edge | \ 137 | Router | | 138 +---+-------+---+ | 139 LAN A | | LAN B | End-User 140 -+----------------+- -+-----+-------------+- | Network(s) 141 | | | | 142 +---+------+ +----+-----+ +-----+----+ | 143 | IPv6-only| | IPv4-only| |IPv4/IPv6 | / 144 | Host | | Host | | Host | / 145 +----------+ +----------+ +----------+ / 147 Figure 1: Simplified Typical IPv6-only Access Network 149 This document covers a set of IP transition techniques required when 150 ISPs (Internet Service Providers) have, or want to have, an IPv6-only 151 access network. This is a common situation when sufficient IPv4 152 addresses are no longer available for every possible customer and 153 device, causing IPv4 addresses to become prohibitive expense. This, 154 in turn, may result in service providers provisioning IPv6-only WAN 155 access. At the same time, they need to ensure that both IPv4-only 156 and IPv6-only devices or applications in the customer networks can 157 still reach IPv4-only devices and applications in the Internet. 159 This document specifies the IPv4 service continuity mechanisms to be 160 supported by an IPv6 Transition CE Router, and relevant provisioning 161 or configuration information differences from [RFC7084]. 163 This document is not a recommendation for service providers to use 164 any specific transition mechanism. 166 Automatic provisioning of more complex topology than a single router 167 with multiple LAN interfaces may be handled by means of HNCP 168 [RFC7788] (Home Networking Control Protocol), which is out of the 169 scope of this document. 171 Since it is impossible to know prior to sale which transition 172 mechanism a device will need over its lifetime, IPv6 Transition CE 173 Router intended for the retail market MUST support all the IPv4aaS 174 transition mechanisms supported by this document. Service providers 175 who specify feature sets for IPv6 Transition CE Router may specify a 176 different set of features than those included in this document, for 177 example supporting only some of the transition mechanisms enumerated 178 in this document. 180 A complete description of "Usage Scenarios" and "End-User Network 181 Architecture" is provided in Annexes A and B, respectively, which 182 together with [RFC7084], will facilitate the reader to have a clearer 183 understanding of this document. 185 1.1. Requirements Language - Special Note 187 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document, are not used as described in RFC 2119 [RFC2119]. This 190 document uses these keywords not strictly for the purpose of 191 interoperability, but rather for the purpose of establishing 192 industry-common baseline functionality. As such, the document points 193 to several other specifications to provide additional guidance to 194 implementers regarding any protocol implementation required to 195 produce a successful IPv6 Transition CE Router that interoperates 196 successfully with a particular subset of currently deploying and 197 planned common IPv6-only access networks. 199 Additionally, the keyword "DEFAULT" is to be interpreted in this 200 document as pertaining to a configuration as applied by a vendor, 201 prior to the administrator changing it for its initial activation. 203 2. Terminology 205 This document uses the same terms as in [RFC7084], with minor 206 clarifications. 208 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 209 technologies for delivering IPv4 in IPv6-only connectivity. 211 The term "IPv6 transition Customer Edge Router with IPv4aaS" 212 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 213 Customer Edge Router" that provides features for the delivery of IPv4 214 services over an IPv6-only WAN network, including IPv6-IPv4 215 communications. 217 The "WAN Interface" term used across this document, defines an IPv6 218 Transition CE Router attachment to an IPv6-only link used to provide 219 connectivity to a service provider network, including link Internet- 220 layer (or higher layers) "tunnels", such as IPv4-in-IPv6 tunnels. 222 3. Requirements 224 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 225 Requirements for IPv6 Customer Edge Routers) and this document adds 226 new requirements, as described in the following sub-sections. 228 3.1. LAN-Side Configuration 230 A new LAN requirement is added, which in fact is common in regular 231 IPv6 Transition CE Router, and it is required by most of the 232 transition mechanisms: 234 L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as 235 described in [RFC5625] (DNS Proxy Implementation Guidelines). 237 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4 238 as-a-Service - IPv4aaS) 240 The main target of this document is the support of IPv6-only WAN 241 access. To enable legacy IPv4 functionality, this document also 242 includes the support of IPv4-only devices and applications in the 243 customers LANs, as well as IPv4-only services on the Internet. Thus, 244 both IPv4-only and the IPv6-only devices in the customer-side LANs of 245 the IPv6 Transition CE Router are able to reach the IPv4-only 246 services. 248 This document takes no position on simultaneous operation of one or 249 several transition mechanisms and/or native IPv4. 251 In order to seamlessly provide the IPv4 Service Continuity in 252 Customer LANs, allowing an automated IPv6 transition mechanism 253 provisioning, general transition requirements are defined. 255 General transition requirements: 257 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 258 priority options described in [RFC8026] (Unified IPv4-in- 259 IPv6 Softwire Customer Premises Equipment (CPE): A 260 DHCPv6-Based Prioritization Mechanism). 262 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or 263 API option to manually enable/disable each of the supported 264 transition mechanisms. 266 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN 267 subnet, the IPv6 Transition CE Router MUST allow 268 appropriate subnetting and configuring the address space 269 (which may depend on each transition mechanism) among the 270 several interfaces. In some transition mechanisms, this 271 may require differentiating mappings/translations per 272 interfaces. 274 In order to allow the service provider to disable all the transition 275 mechanisms and/or choose the most convenient one, the IPv6 Transition 276 CE Router MUST follow the following configuration steps: 278 CONFIG-1: Request the relevant configuration options for each 279 supported transition mechanisms, which MUST remain 280 disabled at this step. 282 CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid 283 match in OPTION_S46_PRIORITY, which allows enabling/ 284 disabling a transition mechanism. 286 CONFIG-3: Keep disabled all the transition mechanisms if no match is 287 found between the priority list and the candidate list. 289 The following sections describe the requirements for supporting each 290 one of the transition mechanisms. An IPv6 Transition CE Router 291 intended for the retail market MUST support all of them. 293 3.2.1. 464XLAT 295 464XLAT [RFC6877] is a technique to provide IPv4 service over an 296 IPv6-only access network without encapsulation. This architecture 297 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 298 Protocol Translation from IPv6 Clients to IPv4 Servers) function 299 deployed at the service provider or a third-party network. 301 The IPv6 Transition CE Router MUST support CLAT functionality 302 [RFC6877] if intended for the retail market. If 464XLAT is 303 supported, it MUST be implemented according to [RFC6877]. The 304 following IPv6 Transition CE Router requirements also apply: 306 464XLAT requirements: 308 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 309 Address Translation (NAT) on IPv4 traffic translated 310 using the CLAT, unless a dedicated /64 prefix has been 311 acquired, either using DHCPv6-PD [RFC8415] (IPv6 Prefix 312 Options for DHCPv6) or by alternative means. 314 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 315 [RFC6970] (UPnP Internet Gateway Device - Port Control 316 Protocol Interworking Function). 318 464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 319 Router MUST also implement [RFC7291] (DHCP Options for 320 the PCP). Following [RFC6887], if no PCP server is 321 configured, the IPv6 Transition CE Router MAY verify if 322 the default gateway, or the NAT64 is the PCP server. 323 Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is 324 used) MUST be used to send PCP requests to the server. 326 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 327 (Discovery of the IPv6 Prefix Used for IPv6 Address 328 Synthesis) in order to discover the PLAT-side translation 329 IPv4 and IPv6 prefix(es)/suffix(es). 331 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 332 follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using 333 the PCP), in order to learn the PLAT-side translation 334 IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream 335 PCP-controlled NAT64 device. 337 464XLAT-6: [RFC8115] MUST be implemented and a DHCPv6 Option 338 "OPTION_V6_PREFIX64" [RFC8115], with zeroed ASM_mPrefix64 339 and SSM_mPrefix64, MUST also be considered as a valid 340 NAT64 prefix (uPrefix64). 342 464XLAT-7: The priority for the NAT64 prefix, in case the network 343 provides several choices, MUST be: 1) [RFC7225], 2) 344 [RFC8115], and 3) [RFC7050]. 346 464XLAT-8: If a DHCPv6 Option "OPTION_V6_PREFIX64" [RFC8115], with 347 zeroed ASM_mPrefix64 and SSM_mPrefix64 provides a NAT64 348 prefix, or one or more NAT64 prefixes are learnt by means 349 of either [RFC7050] or [RFC7225], then 464XLAT MUST be 350 included in the candidate list of possible S46 mechanism 351 (Section 1.4.1 of [RFC8026]). 353 The NAT64 prefix could be discovered by means of [RFC7050] only in 354 the case the service provider uses DNS64 [RFC6147]. If DNS64 355 [RFC6147] is not used, or not trusted, as the DNS configuration at 356 the CE (or hosts behind the CE) may be modified by the customer, then 357 the service provider may opt to configure the NAT64 prefix either by 358 means of [RFC7225] or [RFC8115], which also can be used if the 359 service provider uses DNS64 [RFC6147]. 361 3.2.2. Dual-Stack Lite (DS-Lite) 363 Dual-Stack Lite [RFC6333] enables continued support for IPv4 364 services. Dual-Stack Lite enables a broadband service provider to 365 share IPv4 addresses among customers by combining two well-known 366 technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation 367 (NAT). It is expected that DS-Lite traffic is forwarded over the 368 IPv6 Transition CE Router's native IPv6 WAN interface, and not 369 encapsulated in another tunnel. 371 The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality 372 [RFC6333] if intended for the retail market. If DS-Lite is 373 supported, it MUST be implemented according to [RFC6333]. The 374 following IPv6 Transition CE Router requirements also apply: 376 DS-Lite requirements: 378 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 379 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 380 Option for Dual-Stack Lite). The IPv6 Transition CE 381 Router MAY use other mechanisms to configure DS-Lite 382 parameters. Such mechanisms are outside the scope of this 383 document. 385 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 386 [RFC6970] (UPnP Internet Gateway Device - Port Control 387 Protocol Interworking Function). 389 DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 390 Router SHOULD implement [RFC7291] (DHCP Options for the 391 PCP). If PCP [RFC6887] is implemented and a PCP server is 392 not configured, the IPv6 Transition CE Router MUST assume, 393 by DEFAULT, that the AFTR is the PCP server. Plain IPv6 394 mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be 395 used to send PCP requests to the server. 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. 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 One of the apparent main issues for vendors to include new 528 functionalities, such as support for new transition mechanisms, is 529 the lack of space in the flash (or equivalent) memory. However, it 530 has been confirmed from existing open source implementations 531 (OpenWRT/LEDE, Linux, others), that adding the support for the new 532 transitions mechanisms, requires around 10-12 Kbytes (because most of 533 the code base is shared among several transition mechanisms already 534 supported by [RFC7084]), as a single data plane is common to all 535 them, which typically means about 0,15% of the existing code size in 536 popular CEs already in the market [OpenWRT]. 538 In general, the new requirements don't have extra cost in terms of 539 RAM memory, neither other hardware requirements such as more powerful 540 CPUs, if compared to the cost of NAT44 code so, existing hardware 541 supports them with minimal impact. 543 The other issue seems to be the cost of developing the code for those 544 new functionalities. However, at the time of writing this document, 545 it has been confirmed that there are several open source versions of 546 the required code for supporting all the new transition mechanisms, 547 and several vendors already have implementations and provide it to 548 ISPs, so the development cost is negligible, and only integration and 549 testing cost may become a minor issue. 551 Finally, in some cases, operators supporting several transition 552 mechanisms may need to consider training costs for staff in all those 553 techniques for their operation and management, even if this is not 554 directly caused by supporting this document, but because the business 555 decisions behind that. 557 8. Security Considerations 559 The IPv6 Transition CE Router must comply with the Security 560 Considerations as stated in [RFC7084], as well as those stated by 561 each transition mechanism implemented by the IPv6 Transition CE 562 Router. 564 As described in [RFC8026] and [RFC8026] Security Consideration 565 sections, there are generic DHCP security issues, which in the case 566 of this document means that malicious nodes may alter the priority of 567 the transition mechanisms. 569 9. IANA Considerations 571 IANA is requested, by means of this document, to update the "Option 572 Codes permitted in the S46 Priority Option" registry available at 573 https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 574 parameters.xhtml#option-codes-s46-priority-option, with the following 575 entry. 577 +-------------+--------------------+-----------+ 578 | Option Code | S46 Mechanism | Reference | 579 +-------------+--------------------+-----------+ 580 | 113 | 464XLAT | [thisdoc] | 581 +-------------+--------------------+-----------+ 583 Table 1: DHCPv6 Option Code for 464XLAT 585 10. Acknowledgements 587 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 588 Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, 589 Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, 590 for their review and comments in this and/or previous versions of 591 this document, as well as to the Last Call reviewers by the Opsdir 592 (Dan Romascanu), Secdir (Christian Huitema), Rtgdir (Daniele 593 Ceccarelli) and Tsvdir (Martin Stiemerling). 595 11. Annex A: Usage Scenarios 597 The situation previously described, where there is ongoing IPv6 598 deployment and lack of IPv4 addresses, is not happening at the same 599 pace in every country, and even within every country, every ISP. For 600 different technical, financial, commercial/marketing and socio- 601 economic reasons, each network is transitioning at their own pace; 602 the global transition timings cannot be estimated. 604 Different studies (for example [IPv6Survey]) also show that the IPv6 605 deployment is a changing situation. In a single country, not all 606 operators will necessarily provide IPv6 support. Consumers may also 607 switch ISPs, and use the same IPv6 Transition CE Router with either 608 an ISP that provides IPv4-only or an ISP that provides IPv6 with 609 IPv4aaS. 611 So, to cover all those evolving situations, an IPv6 Transition CE 612 Router is required, at least from the perspective of the transition 613 support. 615 Moreover, because some services will remain IPv4-only for an 616 undetermined time, and some service providers will remain IPv4-only 617 for an undetermined period of time, IPv4 will be needed for an 618 undetermined period of time. There will be a need for CEs with 619 support "IPv4 as-a-Service" for an undetermined period of time. 621 This document, based on those premises, ensures that the IPv6 622 Transition CE Router allows the continued transition from networks 623 that today may provide access with dual-stack or IPv6-in-IPv4, as 624 described in [RFC7084], and as an "extension" to it, evolve to an 625 IPv6-only access with IPv4-as-a-Service. 627 Considering that situation and different possible usage cases, the 628 IPv6 Transition CE Router described in this document is expected to 629 be used typically, in residential/household, Small Office/Home Office 630 (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind 631 of Internet access (web, email, streaming, online gaming, etc.) and 632 even more advanced requirements including inbound connections (IP 633 cameras, web, DNS, email, VPN, etc.). 635 The above is not intended to be comprehensive list of all the 636 possible usage cases, just an overall view. In fact, combinations of 637 the above usages are also possible, as well as situations where the 638 same CE is used at different times in different scenarios or even 639 different services providers that may use a different transition 640 mechanism. 642 The mechanisms for allowing inbound connections are "naturally" 643 available in any IPv6 router, when using GUA (IPv6 Global Unicast 644 Addresses), unless they are blocked by firewall rules, which may 645 require some manual configuration by means of a GUI, CLI and/or API. 647 However, in the case of IPv4aaS, because the usage of private 648 addresses and NAT and even depending on the specific transition 649 mechanism, inbound connections typically require some degree of more 650 complex manual configuration such as setting up a DMZ, virtual 651 servers, or port/protocol forwarding. In general, IPv4 CE Routers 652 already provide a GUI and/or a CLI to manually configure them, or the 653 possibility to setup the CE in bridge mode, so another CE behind it, 654 takes care of that. The requirements for that support are out of the 655 scope of this document. 657 It is not relevant who provides the IPv6 Transition CE Router. In 658 most of the cases is the service provider, and in fact is 659 responsible, typically, of provisioning/managing at least the WAN 660 side. Commonly, the user has access to configure the LAN interfaces, 661 firewall, DMZ, and many other features. However, in many cases, the 662 user must supply or may replace the IPv6 Transition CE Router. This 663 underscores the importance of the IPv6 Transition CE Routers 664 supporting the same requirements defined in this document. 666 The IPv6 Transition CE Router described in this document is not 667 intended for usage in other scenarios such as large Enterprises, Data 668 Centers, Content Providers, etc. So even if the documented 669 requirements meet their needs, they may have additional requirements, 670 which are out of the scope of this document. 672 12. Annex B: End-User Network Architecture 674 According to the descriptions in the preceding sections, an end-user 675 network will likely support both IPv4 and IPv6. It is not expected 676 that an end user will change their existing network topology with the 677 introduction of IPv6. There are some differences in how IPv6 works 678 and is provisioned; these differences have implications for the 679 network architecture. 681 A typical IPv4 end-user network consists of a "plug and play" router 682 with NAT functionality and a single link upstream, connected to the 683 service provider network. 685 From the perspective of an "IPv4 user" behind an IPv6 transition 686 Customer Edge Router with IPv4aaS, this doesn't change. 688 However, while a typical IPv4 NAT deployment by default blocks all 689 incoming connections and may allow opening of ports using a Universal 690 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 691 other firewall control protocol, in the case of an IPv6-only access 692 and IPv4aaS, that may not be feasible depending on specific 693 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 694 may be an alternative solution. 696 Another consequence of using IPv4 private address space in the end- 697 user network is that it provides stable addressing; that is, it 698 doesn't change, even when you change service providers, and the 699 addresses are always usable even when the WAN interface is down or 700 the customer edge router has not yet been provisioned. In the case 701 of an IPv6-only access, private IPv4 addresses are also available if 702 the IPv4aaS transition mechanism keeps running the NAT interface 703 towards the LAN side when the WAN interface is down. 705 More advanced routers support dynamic routing (which learns routes 706 from other routers), and advanced end-users can build arbitrary, 707 complex networks using manual configuration of address prefixes 708 combined with a dynamic routing protocol. Once again, this is true 709 for both, IPv4 and IPv6. 711 In general, the end-user network architecture for IPv6 should provide 712 equivalent or better capabilities and functionality than the current 713 IPv4 architecture. 715 The end-user network is a stub network, in the sense that is not 716 providing transit to other external networks. However, HNCP 717 [RFC7788] allows support for automatic provisioning of downstream 718 routers. Figure 1 illustrates the model topology for the end-user 719 network. 721 +---------------+ \ 722 | Service | \ 723 | Provider | \ 724 | Router | | Service 725 +-------+-------+ | Provider 726 | IPv6-only | Network 727 | Customer / 728 | Internet Connection / 729 | / 730 +------+--------+ \ 731 | IPv6 | \ 732 | Customer Edge | \ 733 | Router | | 734 +---+-------+---+ | 735 Network A | | Network B | 736 -+----------------+-+- -+---+-------------+- | 737 | | | | | 738 +---+------+ | +----+-----+ +-----+----+ | 739 | IPv6 | | | IPv4 | |IPv4/IPv6 | | 740 | Host | | | Host | | Host | | 741 +----------+ | +----------+ +----------+ | End-User 742 | | Network(s) 743 +------+--------+ | 744 | IPv6 | | 745 | Router | | 746 +------+--------+ | 747 Network C | | 748 -+-------------+--+- | 749 | | | 750 +---+------+ +----+-----+ | 751 | IPv6 | | IPv6 | / 752 | Host | | Host | / 753 +----------+ +----------+ / 755 Figure 2: An Example of a Typical End-User Network 757 This architecture describes the: 759 o Basic capabilities of the IPv6 Transition CE Router 761 o Provisioning of the WAN interface connecting to the service 762 provider 764 o Provisioning of the LAN interfaces 766 The IPv6 Transition CE Router may be manually configured in an 767 arbitrary topology with a dynamic routing protocol or using HNCP 768 [RFC7788]. Automatic provisioning and configuration is described for 769 a single IPv6 Transition CE Router only. 771 13. ANNEX C: Changes from -00 773 Section to be removed by RFC Editor. Significant updates are: 775 1. ID-Nits: IANA section. 777 2. ID-Nits: RFC7084 reference removed from Abstract. 779 3. This document no longer updates RFC7084. 781 4. UPnP section reworded. 783 5. "CE Router" changed to "IPv6 Transition CE Router". 785 6. Reduced text in Annex A. 787 14. ANNEX D: Changes from -01 789 Section to be removed by RFC Editor. Significant updates are: 791 1. TRANS requirements reworked in order to increase operator control 792 and allow gradual transitioning from dual-stack to IPv6-only on 793 specific customers. 795 2. New TRANS requirement so all the supported transition mechanisms 796 are disabled by default, in order to facilitate the operator 797 management. 799 3. New TRANS requirement in order to allow turning on/off each 800 transition mechanism by the user. 802 4. Clarification on how to obtain multiple /64 for 464XLAT. 804 5. S46 priority update to RFC8026 for including 464XLAT and related 805 changes in several sections. 807 15. ANNEX E: Changes from -02 809 Section to be removed by RFC Editor. Significant updates are: 811 1. RFC8026 update removed, not needed with new approach. 813 2. TRANS and 464XLAT requirements reworded in order to match new 814 approach to allow operator control on each/all the transition 815 mechanisms. 817 3. Added text in 464XLAT to clarify the usage. 819 16. ANNEX F: Changes from -03 821 Section to be removed by RFC Editor. Significant updates are: 823 1. Several editorial changes across the document, specially TRANS 824 requirements. 826 2. DNS proxy MUST instead of SHOULD. 828 17. ANNEX G: Changes from -04 830 Section to be removed by RFC Editor. Significant updates are: 832 1. Removed G-1. 834 2. Added support for draft-pref64folks-6man-ra-pref64. 836 3. General text clarifications. 838 18. ANNEX H: Changes from -05 840 Section to be removed by RFC Editor. Significant updates are: 842 1. Reworded and shorter UPnP section and new informative reference. 844 2. New general transition requirement in case multiple public IPv4 845 prefixes are provided, so to run multiple instances according to 846 each specific transition mechanism. 848 3. General text clarifications. 850 19. ANNEX I: Changes from -06 852 Section to be removed by RFC Editor. Significant updates are: 854 1. Removed reference and text related to pref64folks-6man-ra-pref64. 856 2. General text clarifications. 858 20. ANNEX J: Changes from -07 860 Section to be removed by RFC Editor. Significant updates are: 862 1. Added text to UPnP section. 864 21. ANNEX K: Changes from -08, -09 and -10 866 Section to be removed by RFC Editor. Significant updates are: 868 1. Editorial edits. 870 22. ANNEX L: Changes from -11 872 Section to be removed by RFC Editor. Significant updates are: 874 1. Changes related to suggestions by Opsdir, Secdir, Rtgdir and 875 Tsvdir. 877 23. References 879 23.1. Normative References 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, 883 DOI 10.17487/RFC2119, March 1997, 884 . 886 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 887 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 888 . 890 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 891 Infrastructures (6rd) -- Protocol Specification", 892 RFC 5969, DOI 10.17487/RFC5969, August 2010, 893 . 895 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 896 NAT64: Network Address and Protocol Translation from IPv6 897 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 898 April 2011, . 900 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 901 Beijnum, "DNS64: DNS Extensions for Network Address 902 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 903 DOI 10.17487/RFC6147, April 2011, 904 . 906 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 907 Stack Lite Broadband Deployments Following IPv4 908 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 909 . 911 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 912 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 913 RFC 6334, DOI 10.17487/RFC6334, August 2011, 914 . 916 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 917 Combination of Stateful and Stateless Translation", 918 RFC 6877, DOI 10.17487/RFC6877, April 2013, 919 . 921 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 922 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 923 DOI 10.17487/RFC6887, April 2013, 924 . 926 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 927 Play (UPnP) Internet Gateway Device - Port Control 928 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 929 DOI 10.17487/RFC6970, July 2013, 930 . 932 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 933 the IPv6 Prefix Used for IPv6 Address Synthesis", 934 RFC 7050, DOI 10.17487/RFC7050, November 2013, 935 . 937 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 938 Requirements for IPv6 Customer Edge Routers", RFC 7084, 939 DOI 10.17487/RFC7084, November 2013, 940 . 942 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 943 Port Control Protocol (PCP)", RFC 7225, 944 DOI 10.17487/RFC7225, May 2014, 945 . 947 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 948 the Port Control Protocol (PCP)", RFC 7291, 949 DOI 10.17487/RFC7291, July 2014, 950 . 952 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 953 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 954 RFC 7341, DOI 10.17487/RFC7341, August 2014, 955 . 957 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 958 Farrer, "Lightweight 4over6: An Extension to the Dual- 959 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 960 July 2015, . 962 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 963 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 964 Port with Encapsulation (MAP-E)", RFC 7597, 965 DOI 10.17487/RFC7597, July 2015, 966 . 968 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 969 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 970 Configuration of Softwire Address and Port-Mapped 971 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 972 . 974 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 975 and T. Murakami, "Mapping of Address and Port using 976 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 977 2015, . 979 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 980 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 981 RFC 7618, DOI 10.17487/RFC7618, August 2015, 982 . 984 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 985 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 986 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 987 November 2016, . 989 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 990 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 991 over an IPv6 Multicast Network", RFC 8114, 992 DOI 10.17487/RFC8114, March 2017, 993 . 995 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 996 Option for IPv4-Embedded Multicast and Unicast IPv6 997 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 998 . 1000 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1001 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1002 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1003 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1004 . 1006 23.2. Informative References 1008 [IPv6Survey] 1009 Palet Martinez, J., "IPv6 Deployment Survey", January 1010 2018, 1011 . 1014 [OpenWRT] OpenWRT, "OpenWRT Packages", January 2018, 1015 . 1017 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1018 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1019 2016, . 1021 [UPnP-IGD] 1022 UPnP Forum, "InternetGatewayDevice:2 Device Template 1023 Version 1.01", December 2010, 1024 . 1026 [UPnP-WANIPC] 1027 UPnP Forum, "WANIPConnection:2 Service", December 2010, 1028 . 1031 Authors' Addresses 1033 Jordi Palet Martinez 1034 The IPv6 Company 1035 Molino de la Navata, 75 1036 La Navata - Galapagar, Madrid 28420 1037 Spain 1039 Email: jordi.palet@theipv6company.com 1040 URI: http://www.theipv6company.com/ 1042 Hans M.-H. Liu 1043 D-Link Systems, Inc. 1044 17595 Mount Herrmann St. 1045 Fountain Valley, California 92708 1046 US 1048 Email: hans.liu@dlinkcorp.com 1049 URI: http://www.dlink.com/ 1050 Masanobu Kawashima 1051 NEC Platforms, Ltd. 1052 800, Shimomata 1053 Kakegawa-shi, Shizuoka 436-8501 1054 Japan 1056 Email: kawashimam@vx.jp.nec.com 1057 URI: https://www.necplatforms.co.jp/en/