idnits 2.17.1 draft-ietf-v6ops-transition-ipv4aas-01.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 (May 27, 2018) is 2154 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations (v6ops) J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Intended status: Informational H. M.-H. Liu 5 Expires: November 28, 2018 D-Link Systems, Inc. 6 M. Kawashima 7 NEC Platforms, Ltd. 8 May 27, 2018 10 Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity 11 as-a-Service 12 draft-ietf-v6ops-transition-ipv4aas-01 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 thru the retail market. 20 Specifically, this document extends the "Basic Requirements for IPv6 21 Customer Edge Routers" in order to allow the provisioning of IPv6 22 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) 23 by means of new transition mechanisms. The document only covers 24 transition technologies for delivering IPv4 in IPv6-only access 25 networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required 26 in a world where IPv4 addresses are no longer available, so hosts in 27 the customer LANs with IPv4-only or IPv6-only applications or 28 devices, requiring to communicate with IPv4-only services at the 29 Internet, are still able to do so. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 28, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language - Special Note . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. General Requirements . . . . . . . . . . . . . . . . . . 4 70 3.2. LAN-Side Configuration . . . . . . . . . . . . . . . . . 4 71 3.3. Transition Technologies Support for IPv4 service 72 continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 5 73 3.3.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.3.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 6 75 3.3.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 7 76 3.3.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 9 79 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Differences from RFC7084 . . . . . . . . . . . . . . . . . . 9 81 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 10 86 12. Annex B: End-User Network Architecture . . . . . . . . . . . 12 87 13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 15 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 14.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 This document defines IPv4 service continuity features over an 96 IPv6-only network, for a residential or small-office router, referred 97 to as an "IPv6 Transition CE Router", in order to establish an 98 industry baseline for transition features to be implemented on such a 99 router. 101 These routers are likely to rely upon "Basic Requirements for IPv6 102 Customer Edge Routers" ([RFC7084]), so the scope of this document is 103 to ensure the IPv4 "service continuity" support, in the LAN side and 104 the access to IPv4-only Internet services from an IPv6-only access 105 WAN even from IPv6-only applications or devices in the LAN side. 107 This document covers a set of IP transition techniques required when 108 ISPs have an IPv6-only access network. This is a common situation in 109 a world where IPv4 addresses are no longer available, so the service 110 providers need to provision IPv6-only WAN access. At the same time, 111 they need to ensure that both IPv4-only and IPv6-only devices or 112 applications in the customer networks, can still reach IPv4-only 113 devices and applications in the Internet. 115 This document specifies the IPv4 service continuity mechanisms to be 116 supported by an IPv6 Transition CE Router, and relevant provisioning 117 or configuration information differences from [RFC7084]. 119 This document is not a recommendation for service providers to use 120 any specific transition mechanism. 122 Automatic provisioning of more complex topology than a single router 123 with multiple LAN interfaces may be handled by means of HNCP 124 ([RFC7788]), which is out of the scope of this document. 126 Service providers who specify feature sets for IPv6 Transition CE 127 Router MAY specify a different set of features than those included in 128 this document. Since it is impossible to know prior to sale which 129 transition mechanism a device will need over the lifetime of the 130 device, IPv6 Transition CE Router intended for the retail market MUST 131 support all of them. 133 A complete description of "Usage Scenarios" and "End-User Network 134 Architecture" is provided in Annex A and B, respectively. 136 1.1. Requirements Language - Special Note 138 Unlike other IETF documents, the key words "MUST", "MUST NOT", 139 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 140 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 141 described in RFC 2119 [RFC2119]. This document uses these keywords 142 not strictly for the purpose of interoperability, but rather for the 143 purpose of establishing industry-common baseline functionality. As 144 such, the document points to several other specifications to provide 145 additional guidance to implementers regarding any protocol 146 implementation required to produce a successful IPv6 Transition CE 147 Router that interoperates successfully with a particular subset of 148 currently deploying and planned common IPv6-only access networks. 150 2. Terminology 152 This document uses the same terms as in [RFC7084], with minor 153 clarifications. 155 "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition 156 technologies for delivering IPv4 in IPv6-only access networks. 158 The term "IPv6 transition Customer Edge Router with IPv4aaS" 159 (shortened as "IPv6 Transition CE Router") is defined as an "IPv6 160 Customer Edge Router" that provides features for the delivery of IPv4 161 services over an IPv6-only WAN network including IPv6-IPv4 162 communications. 164 The "WAN Interface" term used across this document, means that can 165 also support link technologies based in Internet-layer (or higher- 166 layers) "tunnels", such as IPv4-in-IPv6 tunnels. 168 3. Requirements 170 The IPv6 Transition CE Router MUST comply with [RFC7084] (Basic 171 Requirements for IPv6 Customer Edge Routers). 173 3.1. General Requirements 175 A new general requirement is added, in order to ensure that the IPv6 176 Transition CE Router respects the IPv6 prefix length as a parameter: 178 G-6 The IPv6 Transition CE Router MUST comply with [RFC7608] (IPv6 179 Prefix Length Recommendation for Forwarding). 181 3.2. LAN-Side Configuration 183 A new LAN requirement is added, which in fact is common in regular 184 IPv6 Transition CE Router, and it is required by most of the 185 transition mechanisms: 187 L-15 The IPv6 Transition CE Router SHOULD implement a DNS proxy as 188 described in [RFC5625] (DNS Proxy Implementation Guidelines). 190 3.3. Transition Technologies Support for IPv4 service continuity (IPv4 191 as-a-Service - IPv4aaS) 193 The main target of this document is the support of IPv6-only WAN 194 access. To enable legacy IPv4 functionality, this document also 195 includes the support of IPv4-only devices and applications in the 196 customers LANs, as well as IPv4-only services on the Internet. Thus, 197 both IPv4-only and the IPv6-only devices inside the IPv6 Transition 198 CE Router are able to reach the IPv4-only services. 200 This document takes no position on simultaneous operation of any 201 transition mechanism and native IPv4. 203 In order to seamlessly provide the IPv4 Service Continuity in 204 Customer LANs, allowing an automated IPv6 transition mechanism 205 provisioning, general transition requirements are added. 207 General transition requirements: 209 TRANS-1: If more than one S46 mechanism is supported, the IPv6 210 Transition CE Router MUST support the DHCPv6 S46 priority 211 option described in [RFC8026] (Unified IPv4-in-IPv6 212 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 213 Prioritization Mechanism). 215 TRANS-2: The IPv6 Transition CE Router MUST verify if the WAN link 216 supports native IPv4. In that case, transition mechanisms 217 SHOULD NOT be automatically enabled for that interface. 219 TRANS-3: If native IPv4 is not available and 464XLAT [RFC6877] is 220 supported, the IPv6 Transition CE Router MUST enable the 221 CLAT (in order to automatically configure 464XLAT 222 [RFC6877]). If 464XLAT [RFC6877] is not supported, and 223 more than one S46 mechanism is supported, following 224 Section 1.4 of [RFC8026], MUST check for a valid match in 225 OPTION_S46_PRIORITY, which will allow configuring any of 226 the other transition mechanisms. 228 The following sections describe the requirements for supporting 229 transition mechanisms. 231 3.3.1. 464XLAT 233 464XLAT [RFC6877] is a technique to provide IPv4 service over an 234 IPv6-only access network without encapsulation. This architecture 235 assumes a NAT64 [RFC6146] (Stateful NAT64: Network Address and 236 Protocol Translation from IPv6 Clients to IPv4 Servers) function 237 deployed at the service provider or a third-party network. 239 The IPv6 Transition CE Router SHOULD support CLAT functionality. If 240 464XLAT is supported, it MUST be implemented according to [RFC6877]. 241 The following IPv6 Transition CE Router requirements also apply: 243 464XLAT requirements: 245 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 246 Address Translation (NAT) on IPv4 traffic translated 247 using the CLAT, unless a dedicated /64 prefix has been 248 acquired using DHCPv6-PD [RFC3633] (IPv6 Prefix Options 249 for DHCPv6). 251 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 252 [RFC6970] (UPnP Internet Gateway Device - Port Control 253 Protocol Interworking Function). 255 464XLAT-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 256 Router MUST also implement [RFC7291] (DHCP Options for 257 the PCP). If no PCP server is configured, the IPv6 258 Transition CE Router MAY verify if the default gateway, 259 or the NAT64 is the PCP server. A plain IPv6 mode is 260 used to send PCP requests to the server. 262 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 263 (Discovery of the IPv6 Prefix Used for IPv6 Address 264 Synthesis) in order to discover the PLAT-side translation 265 IPv4 and IPv6 prefix(es)/suffix(es). The IPv6 Transition 266 CE Router MUST follow [RFC7225] (Discovering NAT64 IPv6 267 Prefixes Using the PCP), in order to learn the PLAT-side 268 translation IPv4 and IPv6 prefix(es)/suffix(es) used by 269 an upstream PCP-controlled NAT64 device. 271 3.3.2. Dual-Stack Lite (DS-Lite) 273 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 274 services and incentives for the deployment of IPv6. It also de- 275 couples IPv6 deployment in the service provider network from the rest 276 of the Internet, making incremental deployment easier. Dual-Stack 277 Lite enables a broadband service provider to share IPv4 addresses 278 among customers by combining two well-known technologies: IP in IP 279 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 280 that DS-Lite traffic is forwarded over the IPv6 Transition CE 281 Router's native IPv6 WAN interface, and not encapsulated in another 282 tunnel. 284 The IPv6 Transition CE Router SHOULD implement DS-Lite [RFC6333] 285 functionality. If DS-Lite is supported, it MUST be implemented 286 according to [RFC6333]. The following IPv6 Transition CE Router 287 requirements also apply: 289 DS-Lite requirements: 291 DSLITE-1: The IPv6 Transition CE Router MUST support configuration 292 of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 293 Option for Dual-Stack Lite). The IPv6 Transition CE 294 Router MAY use other mechanisms to configure DS-Lite 295 parameters. Such mechanisms are outside the scope of this 296 document. 298 DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 299 [RFC6970] (UPnP Internet Gateway Device - Port Control 300 Protocol Interworking Function). 302 DSLITE-3: If PCP ([RFC6887]) is implemented, the IPv6 Transition CE 303 Router SHOULD also implement [RFC7291] (DHCP Options for 304 the PCP). If PCP ([RFC6887]) is implemented and a PCP 305 server is not configured, the IPv6 Transition CE Router 306 MUST assume, by default, that the AFTR is the PCP server. 307 A plain IPv6 mode is used to send PCP requests to the 308 server. 310 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 311 Network Address Translation (NAT) on IPv4 traffic 312 encapsulated using DS-Lite ([RFC6333]). 314 3.3.3. Lightweight 4over6 (lw4o6) 316 Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the 317 NAPT function from the DS-Lite tunnel concentrator to the tunnel 318 client located in the IPv6 Transition CE Router, removing the 319 requirement for a CGN function in the tunnel concentrator and 320 reducing the amount of centralized state. 322 The IPv6 Transition CE Router SHOULD implement lw4o6 functionality. 323 If DS-Lite is implemented, lw4o6 SHOULD be supported as well. If 324 lw4o6 is supported, it MUST be implemented according to [RFC7596]. 325 The following IPv6 Transition CE Router requirements also apply: 327 Lw4o6 requirements: 329 LW4O6-1: The IPv6 Transition CE Router MUST support configuration of 330 lw4o6 via the lw4o6 DHCPv6 options [RFC7598] (DHCPv6 331 Options for Configuration of Softwire Address and Port- 332 Mapped Clients). The IPv6 Transition CE Router MAY use 333 other mechanisms to configure lw4o6 parameters. Such 334 mechanisms are outside the scope of this document. 336 LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over- 337 DHCPv6 (DHCP 4o6) transport described in [RFC7341] (DHCPv4- 338 over-DHCPv6 Transport). 340 LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic 341 Allocation of Shared IPv4 Addresses as described in 342 [RFC7618] (Dynamic Allocation of Shared IPv4 Addresses). 344 3.3.4. MAP-E 346 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 347 an IPv6 network using IP encapsulation, including an algorithmic 348 mechanism for mapping between IPv6 addresses and IPv4 addresses as 349 well as transport-layer ports. 351 The IPv6 Transition CE Router SHOULD support MAP-E functionality. If 352 MAP-E is supported, it MUST be implemented according to [RFC7597]. 353 The following IPv6 Transition CE Router requirements also apply: 355 MAP-E requirements: 357 MAPE-1: The IPv6 Transition CE Router MUST support configuration of 358 MAP-E via the MAP-E DHCPv6 options [RFC7598] (DHCPv6 Options 359 for Configuration of Softwire Address and Port-Mapped 360 Clients). The IPv6 Transition CE Router MAY use other 361 mechanisms to configure MAP-E parameters. Such mechanisms 362 are outside the scope of this document. 364 MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 365 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 366 Allocation of Shared IPv4 Addresses). 368 3.3.5. MAP-T 370 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 371 that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as 372 the form of IPv6 domain transport. 374 The IPv6 Transition CE Router SHOULD support MAP-T functionality. If 375 MAP-T is supported, it MUST be implemented according to [RFC7599]. 376 The following IPv6 Transition CE Router requirements also apply: 378 MAP-T requirements: 380 MAPT-1: The IPv6 Transition CE Router MUST support configuration of 381 MAP-T via the MAP-T DHCPv6 options [RFC7598] (DHCPv6 Options 382 for Configuration of Softwire Address and Port-Mapped 383 Clients). The IPv6 Transition CE Router MAY use other 384 mechanisms to configure MAP-T parameters. Such mechanisms 385 are outside the scope of this document. 387 MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation 388 of Shared IPv4 Addresses as described in [RFC7618] (Dynamic 389 Allocation of Shared IPv4 Addresses). 391 4. IPv4 Multicast Support 393 Actual deployments support IPv4 multicast for services such as IPTV. 394 In the transition phase it is expected that multicast services will 395 still be provided using IPv4 to the customer LANs. 397 If the IPv6 Transition CE Router supports delivery of IPv4 multicast 398 services, then it MUST support [RFC8114] (Delivery of IPv4 Multicast 399 Services to IPv4 Clients over an IPv6 Multicast Network) and 400 [RFC8115] (DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 401 Prefixes). 403 5. UPnP Support 405 UPnP SHOULD be disabled by default on the IPv6 Transition CE Router 406 when using an IPv4aaS transition mechanism. 408 UPnP MAY be enabled when a IPv6 Transition CE Router is configured to 409 use a stateless mechanism that allows unsolicited inbound packets 410 through to the CE, such as MAP or LW4o6, or when configured with an a 411 port set containing all 65535 ports, e.g. with an IPv4 address 412 sharing ratio of 1. 414 If UPnP is enabled on a IPv6 Transition CE Router, the UPnP agent 415 MUST reject any port mapping requests for ports outside of the port 416 set allocated to the IPv6 Transition CE Router. 418 UPnP MAY also be enabled on a IPv6 Transition CE Router configured 419 for IPv4aaS mechanisms that support PCP [RFC6887], if implemented in 420 conjunction with a method to control the external port mapping, such 421 as IGD-PCP IWF [RFC6970]. 423 A IPv6 Transition CE Router that implements a UPnP agent, SHOULD 424 support the Open Connectivity Foundation's IGD:2 specification, 425 including the AddAnyPortMapping() function. 427 6. Differences from RFC7084 429 This document no longer consider the need to support 6rd ([RFC5969]) 430 and includes slightly different requirements for DS-LITE [RFC6333]. 432 7. Code Considerations 434 One of the apparent main issues for vendors to include new 435 functionalities, such as support for new transition mechanisms, is 436 the lack of space in the flash (or equivalent) memory. However, it 437 has been confirmed from existing open source implementations 438 (OpenWRT/LEDE, Linux, others), that adding the support for the new 439 transitions mechanisms, requires around 10-12 Kbytes (because most of 440 the code base is shared among several transition mechanisms already 441 supported by [RFC7084]), as a single data plane is common to all 442 them, which typically means about 0,15% of the existing code size in 443 popular CEs already in the market. 445 It is also clear that the new requirements don't have extra cost in 446 terms of RAM memory, neither other hardware requirements such as more 447 powerful CPUs. 449 The other issue seems to be the cost of developing the code for those 450 new functionalities. However, at the time of writing this document, 451 it has been confirmed that there are several open source versions of 452 the required code for supporting the new transition mechanisms, and 453 even several vendors already have implementations and provide it to 454 ISPs, so the development cost is negligent, and only integration and 455 testing cost may become a minor issue. 457 8. Security Considerations 459 The IPv6 Transition CE Router must comply with the Security 460 Considerations as stated in [RFC7084], as well as those stated by 461 each transition mechanism implemented by the IPv6 Transition CE 462 Router. 464 9. IANA Considerations 466 This document has no actions for IANA. 468 10. Acknowledgements 470 Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian 471 Carpenter, Lee Howard, Richard Patterson, Barbara Stark, Ole Troan, 472 James Woodyatt, and "TBD", for their review and comments in this and 473 previous versions of this document. 475 11. Annex A: Usage Scenarios 477 The situation previously described, where there is ongoing IPv6 478 deployment and lack of IPv4 addresses, is not happening at the same 479 pace at every country, and even within every country, every ISP. For 480 different technical, financial, commercial/marketing and socio- 481 economic reasons, each network is transitioning at their own pace, 482 and nobody has a magic crystal ball, to make a guess. 484 Different studies (for example [IPv6Survey]) also show that this is a 485 changing situation, because in a single country, it may be that not 486 all operators provide IPv6 support, and consumers may switch ISPs and 487 use the same IPv6 Transition CE Router with an ISP that provides 488 IPv4-only and an ISP that provides IPv6 plus IPv4aaS. 490 So, it is clear that, to cover all those evolving situations, a IPv6 491 Transition CE Router is required, at least from the perspective of 492 the transition support, which can accommodate those changes. 494 Moreover, because some services will remain IPv4-only for an 495 undetermined time, and some service providers will remain IPv4-only 496 for an undetermined period of time, IPv4 will be needed for an 497 undetermined period of time. There will be a need for CEs with 498 support "IPv4 as-a-Service" for an undetermined period of time. 500 This document is consequently, based on those premises, in order to 501 ensure the continued transition from networks that today may provide 502 access with dual-stack or IPv6-in-IPv4, as described in [RFC7084], 503 and as an "extension" to it, evolving to an IPv6-only access with 504 IPv4-as-a-Service. 506 Considering that situation and different possible usage cases, the 507 IPv6 Transition CE Router described in this document is expected to 508 be used typically, in the following scenarios: 510 1. Residential/household, Small Office/Home Office (SOHO) and Small/ 511 Medium Enterprise (SME). Common usage is any kind of Internet 512 access (web, email, streaming, online gaming, etc.). 514 2. Residential/household and Small/Medium Enterprise (SME) with 515 advanced requirements. Same basic usage as for the previous 516 case, however there may be requirements for allowing inbound 517 connections (IP cameras, web, DNS, email, VPN, etc.). 519 The above list is not intended to be comprehensive of all the 520 possible usage scenarios, just an overall view. In fact, 521 combinations of the above usages are also possible, as well as 522 situations where the same CE is used at different times in different 523 scenarios or even different services providers that may use a 524 different transition mechanism. 526 The mechanisms for allowing inbound connections are "naturally" 527 available in any IPv6 router, as when using GUA, unless they are 528 blocked by firewall rules, which may require some manual 529 configuration by means of a GUI and/or CLI. 531 However, in the case of IPv4aaS, because the usage of private 532 addresses and NAT and even depending on the specific transition 533 mechanism, it typically requires some degree of more complex manual 534 configuration such as setting up a DMZ, virtual servers, or port/ 535 protocol forwarding. In general, IPv4 CE Routers already provide GUI 536 and/or CLI to manually configure them, or the possibility to setup 537 the CE in bridge mode, so another CE behind it, takes care of that. 538 It is out of the scope of this document the definition of any 539 requirements for that. 541 The main difference for a CE Router to support the above indicated 542 scenarios and number of users, is related to the packet processing 543 capabilities, performance, even other details such as the number of 544 WAN/LAN interfaces, their maximum speed, memory for keeping tables or 545 tracking connections, etc. It is out of the scope of this document 546 to classify them. 548 The actual bandwidth capabilities of access technologies such as 549 FTTH, cable and even 3GPP/LTE, allows the support of such scenarios, 550 and indeed, is a very common situation that access networks and CE 551 Router provided by the service provider are the same for SMEs and 552 residential users. 554 There is also no difference in terms of who actually provides the CE 555 Router. In most of the cases is the service provider, and in fact is 556 responsible, typically, of provisioning/managing at least the WAN 557 side. However, commonly the user has access to configure the LAN 558 interfaces, firewall, DMZ, and many other features. In fact, in many 559 cases, the user must supply or may replace the CE Router; this makes 560 even more relevant that all the CE Routers, support the same 561 requirements defined in this document. 563 The IPv6 Transition CE Router described in this document is not 564 intended for usage in other scenarios such as large Enterprises, Data 565 Centers, Content Providers, etc. So, even if the documented 566 requirements meet their needs, they may have additional requirements, 567 which are out of the scope of this document. 569 12. Annex B: End-User Network Architecture 571 According to the descriptions in the preceding sections, an end-user 572 network will likely support both IPv4 and IPv6. It is not expected 573 that an end user will change their existing network topology with the 574 introduction of IPv6. There are some differences in how IPv6 works 575 and is provisioned; these differences have implications for the 576 network architecture. 578 A typical IPv4 end-user network consists of a "plug and play" router 579 with NAT functionality and a single link upstream, connected to the 580 service provider network. 582 From the perspective of an "IPv4 user" behind an IPv6 transition 583 Customer Edge Router with IPv4aaS, this doesn't change. 585 However, while a typical IPv4 NAT deployment by default blocks all 586 incoming connections and may allow opening of ports using a Universal 587 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 588 other firewall control protocol, in the case of an IPv6-only access 589 and IPv4aaS, that may not be feasible depending on specific 590 transition mechanism details. PCP (Port Control Protocol, [RFC6887]) 591 may be an alternative solution. 593 Another consequence of using IPv4 private address space in the end- 594 user network is that it provides stable addressing; that is, it never 595 changes even when you change service providers, and the addresses are 596 always there even when the WAN interface is down or the customer edge 597 router has not yet been provisioned. In the case of an IPv6-only 598 access, there is no change on that if the transition mechanism keeps 599 running the NAT interface towards the LAN side. 601 More advanced routers support dynamic routing (which learns routes 602 from other routers), and advanced end-users can build arbitrary, 603 complex networks using manual configuration of address prefixes 604 combined with a dynamic routing protocol. Once again, this is true 605 for both, IPv4 and IPv6. 607 In general, the end-user network architecture for IPv6 should provide 608 equivalent or better capabilities and functionality than the current 609 IPv4 architecture. 611 The end-user network is a stub network, in the sense that is not 612 providing transit to other external networks. However, HNCP 613 ([RFC7788]) allows support for automatic provisioning of downstream 614 routers. Figure 1 illustrates the model topology for the end-user 615 network. 617 +---------------+ \ 618 | Service | \ 619 | Provider | | Service 620 | Router | | Provider 621 +-------+-------+ | Network 622 | / 623 | Customer / 624 | Internet Connection / 625 | 626 +------+--------+ \ 627 | IPv6 | \ 628 | Customer Edge | \ 629 | Router | / 630 +---+-------+---+ / 631 Network A | | Network B | 632 ---+----------------+-+- --+---+-------------+-- | 633 | | | | \ 634 +---+------+ | +----+-----+ +-----+----+ \ 635 |IPv6 Host | | | IPv4 Host| |IPv4/IPv6 | / 636 | | | | | | Host | / 637 +----------+ | +----------+ +----------+ / 638 | | 639 +------+--------+ | End-User 640 | IPv6 | | Network(s) 641 | Router | \ 642 +------+--------+ \ 643 Network C | \ 644 ---+-------------+--+--- | 645 | | | 646 +---+------+ +----+-----+ | 647 |IPv6 Host | |IPv6 Host | / 648 | | | | / 649 +----------+ +----------+ / 651 Figure 1: An Example of a Typical End-User Network 653 This architecture describes the: 655 o Basic capabilities of the IPv6 Transition CE Router 657 o Provisioning of the WAN interface connecting to the service 658 provider 660 o Provisioning of the LAN interfaces 662 The IPv6 Transition CE Router may be manually configured in an 663 arbitrary topology with a dynamic routing protocol or using HNCP 664 ([RFC7788]). Automatic provisioning and configuration is described 665 for a single IPv6 Transition CE Router only. 667 13. ANNEX C: Changes from -00 669 Section to be removed for WGLC. Significant updates are: 671 1. ID-Nits: IANA section. 673 2. ID-Nits: RFC7084 reference removed from Abstract. 675 3. This document no longer updates RFC7084. 677 4. UPnP section reworded. 679 5. "CE Router" changed to "IPv6 Transition CE Router". 681 6. Reduced text in Annex A. 683 14. References 685 14.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 693 Host Configuration Protocol (DHCP) version 6", RFC 3633, 694 DOI 10.17487/RFC3633, December 2003, 695 . 697 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 698 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 699 . 701 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 702 Infrastructures (6rd) -- Protocol Specification", 703 RFC 5969, DOI 10.17487/RFC5969, August 2010, 704 . 706 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 707 NAT64: Network Address and Protocol Translation from IPv6 708 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 709 April 2011, . 711 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 712 Stack Lite Broadband Deployments Following IPv4 713 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 714 . 716 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 717 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 718 RFC 6334, DOI 10.17487/RFC6334, August 2011, 719 . 721 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 722 Combination of Stateful and Stateless Translation", 723 RFC 6877, DOI 10.17487/RFC6877, April 2013, 724 . 726 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 727 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 728 DOI 10.17487/RFC6887, April 2013, 729 . 731 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 732 Play (UPnP) Internet Gateway Device - Port Control 733 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 734 DOI 10.17487/RFC6970, July 2013, 735 . 737 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 738 the IPv6 Prefix Used for IPv6 Address Synthesis", 739 RFC 7050, DOI 10.17487/RFC7050, November 2013, 740 . 742 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 743 Requirements for IPv6 Customer Edge Routers", RFC 7084, 744 DOI 10.17487/RFC7084, November 2013, 745 . 747 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 748 Port Control Protocol (PCP)", RFC 7225, 749 DOI 10.17487/RFC7225, May 2014, 750 . 752 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 753 the Port Control Protocol (PCP)", RFC 7291, 754 DOI 10.17487/RFC7291, July 2014, 755 . 757 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 758 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 759 RFC 7341, DOI 10.17487/RFC7341, August 2014, 760 . 762 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 763 Farrer, "Lightweight 4over6: An Extension to the Dual- 764 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 765 July 2015, . 767 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 768 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 769 Port with Encapsulation (MAP-E)", RFC 7597, 770 DOI 10.17487/RFC7597, July 2015, 771 . 773 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 774 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 775 Configuration of Softwire Address and Port-Mapped 776 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 777 . 779 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 780 and T. Murakami, "Mapping of Address and Port using 781 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 782 2015, . 784 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 785 Length Recommendation for Forwarding", BCP 198, RFC 7608, 786 DOI 10.17487/RFC7608, July 2015, 787 . 789 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 790 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 791 RFC 7618, DOI 10.17487/RFC7618, August 2015, 792 . 794 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 795 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 796 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 797 November 2016, . 799 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 800 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 801 over an IPv6 Multicast Network", RFC 8114, 802 DOI 10.17487/RFC8114, March 2017, 803 . 805 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 806 Option for IPv4-Embedded Multicast and Unicast IPv6 807 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 808 . 810 14.2. Informative References 812 [IPv6Survey] 813 Palet Martinez, J., "IPv6 Deployment Survey", January 814 2018, 815 . 818 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 819 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 820 2016, . 822 [UPnP-IGD] 823 UPnP Forum, "InternetGatewayDevice:2 Device Template 824 Version 1.01", December 2010, 825 . 827 Authors' Addresses 829 Jordi Palet Martinez 830 The IPv6 Company 831 Molino de la Navata, 75 832 La Navata - Galapagar, Madrid 28420 833 Spain 835 EMail: jordi.palet@theipv6company.com 836 URI: http://www.theipv6company.com/ 838 Hans M.-H. Liu 839 D-Link Systems, Inc. 840 17595 Mount Herrmann St. 841 Fountain Valley, California 92708 842 US 844 EMail: hans.liu@dlinkcorp.com 845 URI: http://www.dlink.com/ 846 Masanobu Kawashima 847 NEC Platforms, Ltd. 848 800, Shimomata 849 Kakegawa-shi, Shizuoka 436-8501 850 Japan 852 EMail: kawashimam@vx.jp.nec.com 853 URI: https://www.necplatforms.co.jp/en/