idnits 2.17.1 draft-ietf-v6ops-rfc7084-bis-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7788]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 11, 2017) is 2512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7550 (Obsoleted by RFC 8415) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations (v6ops) J. Palet Martinez 3 Internet-Draft Consulintel, S.L. 4 Obsoletes: 7084 (if approved) June 11, 2017 5 Intended status: Informational 6 Expires: December 13, 2017 8 Basic Requirements for IPv6 Customer Edge Routers 9 draft-ietf-v6ops-rfc7084-bis-04 11 Abstract 13 This document specifies requirements for an IPv6 Customer Edge (CE) 14 router. Specifically, the current version of this document focuses 15 on the basic provisioning of an IPv6 CE router and the provisioning 16 of IPv6 hosts attached to it and the support of HNCP ([RFC7788]) for 17 automated provisioning of downstream routers. The document also 18 covers several transition technologies, as required in a world where 19 IPv4 addresses are no longer available, so hosts in the customer LANs 20 with IPv4-only or IPv6-only applications or devices, requiring to 21 communicate with IPv4-only services at the Internet, are able to do 22 so. The document obsoletes RFC 7084. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 13, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Current IPv4 End-User Network Architecture . . . . . . . 6 64 4.2. IPv6 End-User Network Architecture . . . . . . . . . . . 7 65 4.2.1. Local Communication . . . . . . . . . . . . . . . . . 9 66 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. General Requirements . . . . . . . . . . . . . . . . . . 9 68 5.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . 10 69 5.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . 14 70 5.4. Transition Technologies Support . . . . . . . . . . . . . 16 71 5.4.1. IPv4 Service Continuity in Customer LANs . . . . . . 16 72 5.4.1.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . 16 73 5.4.1.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . 17 74 5.4.1.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . 18 75 5.4.1.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . 18 76 5.4.1.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . 19 77 5.4.2. Support of IPv6 in IPv4-only WAN access . . . . . . . 19 78 5.4.2.1. 6in4 . . . . . . . . . . . . . . . . . . . . . . 19 79 5.4.2.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . 20 80 5.5. IPv4 Multicast Support . . . . . . . . . . . . . . . . . 22 81 5.6. Security Considerations . . . . . . . . . . . . . . . . . 22 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 84 8. ANNEX A: Code Considerations . . . . . . . . . . . . . . . . 23 85 9. ANNEX B: Changes from RFC7084 . . . . . . . . . . . . . . . . 24 86 10. ANNEX C: Changes from RFC7084-bis-00 . . . . . . . . . . . . 24 87 11. ANNEX D: Changes from RFC7084-bis-01 . . . . . . . . . . . . 25 88 12. ANNEX E: Changes from RFC7084-bis-02 . . . . . . . . . . . . 25 89 13. ANNEX F: Changes from RFC7084-bis-03 . . . . . . . . . . . . 25 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 92 14.2. Informative References . . . . . . . . . . . . . . . . . 31 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 95 1. Introduction 97 This document defines basic IPv6 features for a residential or small- 98 office router, referred to as an "IPv6 CE router", in order to 99 establish an industry baseline for features to be implemented on such 100 a router. 102 These routers typically also support IPv4, at least in the LAN side. 104 This document specifies how an IPv6 CE router automatically 105 provisions its WAN interface, acquires address space for provisioning 106 of its LAN interfaces, and fetches other configuration information 107 from the service provider network. Automatic provisioning of more 108 complex topology than a single router with multiple LAN interfaces 109 may be handled by means of HNCP ([RFC7788]). In some cases, manual 110 provisioning may be acceptable, when intended for a small number of 111 customers. 113 This document doesn't cover the specific details of each possible 114 access technology. For example, if the IPv6 CE is supporting built- 115 in or external 3GPP/LTE interfaces, [RFC7849] is a relevant 116 reference. See [RFC4779] for a discussion of options available for 117 deploying IPv6 in wireline service provider access networks. 119 This document also covers the IP transition technologies required in 120 a world where IPv4 addresses are no longer available, so the service 121 providers need to provision IPv6-only WAN access, while at the same 122 time ensuring that IPv4-only or IPv6-only devices or applications in 123 the customer LANs can still reach IPv4-only devices or applications 124 in Internet, which still don't have IPv6 support. 126 1.1. Requirements Language 128 Take careful note: Unlike other IETF documents, the key words "MUST", 129 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 130 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 131 described in RFC 2119 [RFC2119]. This document uses these keywords 132 not strictly for the purpose of interoperability, but rather for the 133 purpose of establishing industry-common baseline functionality. As 134 such, the document points to several other specifications (preferable 135 in RFC or stable form) to provide additional guidance to implementers 136 regarding any protocol implementation required to produce a 137 successful IPv6 CE router that interoperates successfully with a 138 particular subset of currently deploying and planned common IPv6 139 access networks. 141 2. Terminology 143 End-User Network one or more links attached to the IPv6 CE 144 router that connect IPv6 hosts. 146 IPv6 Customer Edge Router a node intended for home or small-office 147 use that forwards IPv6 packets not 148 explicitly addressed to itself. The IPv6 149 CE router connects the end-user network to 150 a service provider network. In other 151 documents, the IPv6 CE is named as CPE 152 (Customer Premises Equipment or Customer 153 Provided Equipment). In the context of 154 this document, both terminologies are 155 synonymous. 157 IPv6 Host any device implementing an IPv6 stack 158 receiving IPv6 connectivity through the 159 IPv6 CE router. 161 LAN Interface an IPv6 CE router's attachment to a link in 162 the end-user network. Examples are 163 Ethernet (simple or bridged), 802.11 164 wireless, or other LAN technologies. An 165 IPv6 CE router may have one or more 166 network-layer LAN interfaces. 168 Service Provider an entity that provides access to the 169 Internet. In this document, a service 170 provider specifically offers Internet 171 access using IPv6, and it may also offer 172 IPv4 Internet access. The service provider 173 can provide such access over a variety of 174 different transport methods such as FTTH, 175 DSL, cable, wireless, 3GPP/LTE, and others. 177 WAN Interface an IPv6 CE router's attachment to a link 178 used to provide connectivity to the service 179 provider network; example link technologies 180 include Ethernet (simple or bridged), PPP 181 links, Frame Relay, or ATM networks, as 182 well as Internet-layer (or higher-layer) 183 "tunnels", such as tunnels over IPv4 or 184 IPv6 itself. 186 3. Usage Scenarios 188 The IPv6 CE router described in this document is expected to be used 189 typically, in any of the following scenarios: 191 1. Residential/household users. Common usage is any kind of 192 Internet access (web, email, streaming, online gaming, etc.). 194 2. Residential with Small Office/Home Office (SOHO). Same usage as 195 for the first scenario. 197 3. Small Office/Home Office (SOHO). Same usage as for the first 198 scenario. 200 4. Small and Medium Enterprise (SME). Same usage as for the first 201 scenario. 203 5. Residential/household with advanced requirements. Same basic 204 usage as for the first scenario, however there may be 205 requirements for exporting services to the WAN (IP cameras, web, 206 DNS, email, VPN, etc.). 208 6. Small and Medium Enterprise (SME) with advanced requirements. 209 Same basic usage as for the first scenario, however there may be 210 requirements for exporting services to the WAN (IP cameras, web, 211 DNS, email, VPN, etc.). 213 The above list is not intended to be comprehensive of all the 214 possible usage scenarios, just the main ones. In fact, combinations 215 of the above usages are also possible, for example a residential with 216 SOHO and advanced requirements. 218 The mechanisms for exporting IPv6 services are commonly "naturally" 219 available in any IPv6 router, as when using GUA, unless they are 220 blocked by firewall rules, which may require some manual 221 configuration by means of a GUI and/or CLI. 223 However, in the case of IPv4, because the usage of private addresses 224 and NAT, it typically requires some degree of manual configuration 225 such as setting up a DMZ, virtual servers, or port/protocol 226 forwarding. In general, CE routers already provide GUI and/or CLI to 227 manually configure them, or the possibility to setup the CE in bridge 228 mode, so another CE behind it, takes care of that. It is out of the 229 scope of this document the definition of any requirements for that. 231 The main difference for an IPv6 CE router to support one or several 232 of the above indicated scenarios, is related to the packet processing 233 capabilities, performance, even other details such as the number of 234 WAN/LAN interfaces, their maximum speed, memory for keeping tables or 235 tracking connections, etc. So, it is out of the scope of this 236 document to classify them. 238 For example, an SME may have just 10 employees (micro-SME), which 239 commonly will be considered same as a SOHO, but a small SME can have 240 up to 50 employees, or 250 for a medium one. Depending on the IPv6 241 CE router capabilities or even how it is being configured (for 242 instance, using SLAAC or DHCPv6), it may support even a higher number 243 of employees if the traffic in the LANs is low, or switched by 244 another device(s), or the WAN bandwidth requirements are low, etc. 245 The actual bandwidth capabilities of access with technologies such as 246 FTTH, cable and even 3GPP/LTE, allows the support of such usages, and 247 indeed, is a very common situation that access networks and the IPv6 248 CE provided by the service provider are the same for SMEs and 249 residential users. 251 There is also no difference in terms of who actually provides the 252 IPv6 CE router. In most of the cases is the service provider, and in 253 fact is responsible, typically, of provisioning/managing at least the 254 WAN side. However, commonly the user has access to configure the LAN 255 interfaces, firewall, DMZ, and many other aspects. In fact, in many 256 cases, the user must supply, or at least can replace the IPv6 CE 257 router, which makes even more relevant that all the IPv6 CE routers, 258 support the same requirements defined in this document. 260 The IPv6 CE router described in this document is not intended for 261 usage in other scenarios such as bigger Enterprises, Data Centers, 262 Content Providers, etc. So, even if the documented requirements meet 263 their needs, may have additional requirements, which are out of the 264 scope of this document. 266 4. Architecture 268 4.1. Current IPv4 End-User Network Architecture 270 An end-user network will likely support both IPv4 and IPv6. It is 271 not expected that an end user will change their existing network 272 topology with the introduction of IPv6. There are some differences 273 in how IPv6 works and is provisioned; these differences have 274 implications for the network architecture. A typical IPv4 end-user 275 network consists of a "plug and play" router with NAT functionality 276 and a single link behind it, connected to the service provider 277 network. 279 A typical IPv4 NAT deployment by default blocks all incoming 280 connections. Opening of ports is typically allowed using a Universal 281 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 282 other firewall control protocol. 284 Another consequence of using private address space in the end-user 285 network is that it provides stable addressing; that is, it never 286 changes even when you change service providers, and the addresses are 287 always there even when the WAN interface is down or the customer edge 288 router has not yet been provisioned. 290 Many existing routers support dynamic routing (which learns routes 291 from other routers), and advanced end-users can build arbitrary, 292 complex networks using manual configuration of address prefixes 293 combined with a dynamic routing protocol. 295 4.2. IPv6 End-User Network Architecture 297 The end-user network architecture for IPv6 should provide equivalent 298 or better capabilities and functionality than the current IPv4 299 architecture. 301 The end-user network is a stub network, in the sense that is not 302 providing transit to other external networks. However HNCP 303 ([RFC7788]) allows support for automatic provisioning of downstream 304 routers. Figure 1 illustrates the model topology for the end-user 305 network. 307 +-------+-------+ \ 308 | Service | \ 309 | Provider | | Service 310 | Router | | Provider 311 +-------+-------+ | Network 312 | / 313 | Customer / 314 | Internet Connection / 315 | 316 +------+--------+ \ 317 | IPv6 | \ 318 | Customer Edge | \ 319 | Router | / 320 +---+-------+-+-+ / 321 Network A | | Network B | 322 ---+----------------+-+- --+---+-------------+-- | 323 | | | | \ 324 +----+-----+ | +----+-----+ +-----+----+ \ 325 |IPv6 Host | | | IPv6 Host| |IPv6 Host | / 326 | | | | | | | / 327 +----------+ | +----------+ +----------+ / 328 | | 329 +------+--------+ | End-User 330 | IPv6 | | Network(s) 331 | Router | \ 332 +------+--------+ \ 333 Network C | \ 334 ---+-------------+----+- | 335 | | | 336 +----+-----+ +-----+----+ | 337 |IPv6 Host | |IPv6 Host | / 338 | | | | / 339 +----------+ +-----+----+ / 341 Figure 1: An Example of a Typical End-User Network 343 This architecture describes the: 345 o Basic capabilities of an IPv6 CE router 347 o Provisioning of the WAN interface connecting to the service 348 provider 350 o Provisioning of the LAN interfaces 352 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 353 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 354 multicast routing protocol. 356 The IPv6 CE router may be manually configured in an arbitrary 357 topology with a dynamic routing protocol or using HNCP ([RFC7788]). 358 Automatic provisioning and configuration is described for a single 359 IPv6 CE router only. 361 4.2.1. Local Communication 363 Link-local IPv6 addresses are used by hosts communicating on a single 364 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 365 by hosts communicating within the end-user network across multiple 366 links, but without requiring the application to use a globally 367 routable address. The IPv6 CE router defaults to acting as the 368 demarcation point between two networks by providing a ULA boundary, a 369 multicast zone boundary, and ingress and egress traffic filters. 371 At the time of this writing, several host implementations do not 372 handle the case where they have an IPv6 address configured and no 373 IPv6 connectivity, either because the address itself has a limited 374 topological reachability (e.g., ULA) or because the IPv6 CE router is 375 not connected to the IPv6 network on its WAN interface. To support 376 host implementations that do not handle multihoming in a multi-prefix 377 environment [RFC7157], the IPv6 CE router should not, as detailed in 378 the requirements below, advertise itself as a default router on the 379 LAN interface(s) when it does not have IPv6 connectivity on the WAN 380 interface or when it is not provisioned with IPv6 addresses. For 381 local IPv6 communication, the mechanisms specified in [RFC4191] are 382 used. 384 ULA addressing is useful where the IPv6 CE router has multiple LAN 385 interfaces with hosts that need to communicate with each other. If 386 the IPv6 CE router has only a single LAN interface (IPv6 link), then 387 link-local addressing can be used instead. 389 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 390 conform to these recommendations, especially requirements ULA-5 and 391 L-4 below. 393 5. Requirements 395 5.1. General Requirements 397 The IPv6 CE router is responsible for implementing IPv6 routing; that 398 is, the IPv6 CE router must look up the IPv6 destination address in 399 its routing table to decide to which interface it should send the 400 packet. 402 In this role, the IPv6 CE router is responsible for ensuring that 403 traffic using its ULA addressing does not go out the WAN interface 404 and does not originate from the WAN interface. 406 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 407 Requirements specification [RFC6434]. 409 G-2: The IPv6 CE router MUST implement ICMPv6 according to 410 [RFC4443]. In particular, point-to-point links MUST be handled 411 as described in Section 3.1 of [RFC4443]. 413 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 414 its LAN interface(s) and its WAN interface until the router has 415 successfully completed the IPv6 address and the delegated 416 prefix acquisition process. 418 G-4: By default, an IPv6 CE router that has no default router(s) on 419 its WAN interface MUST NOT advertise itself as an IPv6 default 420 router on its LAN interfaces. That is, the "Router Lifetime" 421 field is set to zero in all Router Advertisement messages it 422 originates [RFC4861]. 424 G-5: By default, if the IPv6 CE router is an advertising router and 425 loses its IPv6 default router(s) and/or detects loss of 426 connectivity on the WAN interface, it MUST explicitly 427 invalidate itself as an IPv6 default router on each of its 428 advertising interfaces by immediately transmitting one or more 429 Router Advertisement messages with the "Router Lifetime" field 430 set to zero [RFC4861]. 432 G-6: The IPv6 CE router MUST comply with [RFC7608]. 434 5.2. WAN-Side Configuration 436 The IPv6 CE router will need to support connectivity to one or more 437 access network architectures. This document describes an IPv6 CE 438 router that is not specific to any particular architecture or service 439 provider and that supports all commonly used architectures. 441 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 442 IPv6-supported link layer, and there is no need for a link-layer- 443 specific configuration protocol for IPv6 network-layer configuration 444 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 445 section makes the assumption that the same mechanism will work for 446 any link layer, be it Ethernet, the Data Over Cable Service Interface 447 Specification (DOCSIS), PPP, or others. 449 WAN-side requirements: 451 W-1: When the router is attached to the WAN interface link, it MUST 452 act as an IPv6 host for the purposes of stateless [RFC4862] or 453 stateful [RFC3315] interface address assignment. 455 W-2: The IPv6 CE router MUST generate a link-local address and 456 finish Duplicate Address Detection according to [RFC4862] prior 457 to sending any Router Solicitations on the interface. The 458 source address used in the subsequent Router Solicitation MUST 459 be the link-local address on the WAN interface. 461 W-3: Absent other routing information, the IPv6 CE router MUST use 462 Router Discovery as specified in [RFC4861] to discover a 463 default router(s) and install a default route(s) in its routing 464 table with the discovered router's address as the next hop. 466 W-4: The router MUST act as a requesting router for the purposes of 467 DHCPv6 prefix delegation ([RFC3633]). 469 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 470 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 471 network-interface resets or IPv6 CE router reboots. 473 W-6: The WAN interface of the IPv6 CE router SHOULD support a Port 474 Control Protocol (PCP) client as specified in [RFC6887] for use 475 by applications on the IPv6 CE router. The PCP client SHOULD 476 follow the procedure specified in Section 8.1 of [RFC6887] to 477 discover its PCP server. This document takes no position on 478 whether such functionality is enabled by default or mechanisms 479 by which users would configure the functionality. Handling PCP 480 requests from PCP clients in the LAN side of the IPv6 CE router 481 is out of scope. 483 Link-layer requirements: 485 WLL-1: If the WAN interface supports Ethernet encapsulation, then 486 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 488 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 489 router MUST support IPv6 over PPP [RFC5072]. 491 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 492 stack environment with IPCP and IPV6CP running over one PPP 493 logical channel, the Network Control Protocols (NCPs) MUST be 494 treated as independent of each other and start and terminate 495 independently. 497 Address assignment requirements: 499 WAA-1: The IPv6 CE router MUST support Stateless Address 500 Autoconfiguration (SLAAC) [RFC4862]. 502 WAA-2: The IPv6 CE router MUST follow the recommendations in 503 Section 4 of [RFC5942], and in particular the handling of 504 the L flag in the Router Advertisement Prefix Information 505 option. 507 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 508 behavior. 510 WAA-4: The IPv6 CE router MUST be able to support the following 511 DHCPv6 options: Identity Association for Non-temporary 512 Address (IA_NA), Reconfigure Accept [RFC3315], and 513 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 514 support the DNS Search List (DNSSL) option as specified in 515 [RFC3646]. 517 WAA-5: The IPv6 CE router SHOULD implement the Network Time 518 Protocol (NTP) as specified in [RFC5905] to provide a time 519 reference common to the service provider for other 520 protocols, such as DHCPv6, to use. If the IPv6 CE router 521 implements NTP, it requests the NTP Server DHCPv6 option 522 [RFC5908] and uses the received list of servers as primary 523 time reference, unless explicitly configured otherwise. LAN 524 side support of NTP is out of scope for this document. 526 WAA-6: If the IPv6 CE router receives a Router Advertisement 527 message (described in [RFC4861]) with the M flag set to 1, 528 the IPv6 CE router MUST do DHCPv6 address assignment 529 (request an IA_NA option). 531 WAA-7: If the IPv6 CE router does not acquire a global IPv6 532 address(es) from either SLAAC or DHCPv6, then it MUST create 533 a global IPv6 address(es) from its delegated prefix(es) and 534 configure those on one of its internal virtual network 535 interfaces, unless configured to require a global IPv6 536 address on the WAN interface. 538 WAA-8: The IPv6 CE router MUST support the SOL_MAX_RT option 539 [RFC7083] and request the SOL_MAX_RT option in an Option 540 Request Option (ORO). 542 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 543 (Weak End System) model [RFC1122]. When originating packets 544 from an interface, it will use a source address from another 545 one of its interfaces if the outgoing interface does not 546 have an address of suitable scope. 548 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 549 Time option and associated client behavior as specified in 550 [RFC4242]. 552 Prefix delegation requirements: 554 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 555 requesting router behavior as specified in [RFC3633] 556 (Identity Association for Prefix Delegation (IA_PD) option). 558 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 559 router the size of the prefix it requires. If so, it MUST 560 ask for a prefix large enough to assign one /64 for each of 561 its interfaces, rounded up to the nearest nibble, and SHOULD 562 be configurable to ask for more. 564 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 565 prefix size different from what is given in the hint. If the 566 delegated prefix is too small to address all of its 567 interfaces, the IPv6 CE router SHOULD log a system management 568 error. [RFC6177] covers the recommendations for service 569 providers for prefix allocation sizes. 571 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 572 delegation when either the M or O flags are set to 1 in a 573 received Router Advertisement (RA) message. Behavior of the 574 IPv6 CE router to use DHCPv6 prefix delegation when the IPv6 575 CE router has not received any RA or received an RA with the 576 M and the O bits set to zero is out of scope for this 577 document. 579 WPD-5: Any packet received by the IPv6 CE router with a destination 580 address in the prefix(es) delegated to the IPv6 CE router but 581 not in the set of prefixes assigned by the IPv6 CE router to 582 the LAN must be dropped. In other words, the next hop for 583 the prefix(es) delegated to the IPv6 CE router should be the 584 null destination. This is necessary to prevent forwarding 585 loops when some addresses covered by the aggregate are not 586 reachable [RFC4632]. 588 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 589 Unreachable message in accordance with Section 3.1 of 590 [RFC4443] back to the source of the packet, if the 591 packet is to be dropped due to this rule. 593 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 594 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 595 Advertise/Reply messages, even if the message does not 596 contain any addresses, unless configured to only obtain its 597 WAN IPv6 address via DHCPv6; see [RFC7550]. 599 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 600 routing protocol on its WAN interface. 602 WPD-8: The IPv6 CE router SHOULD support the [RFC6603] Prefix 603 Exclude option. 605 5.3. LAN-Side Configuration 607 The IPv6 CE router distributes configuration information obtained 608 during WAN interface provisioning to IPv6 hosts and assists IPv6 609 hosts in obtaining IPv6 addresses. It also supports connectivity of 610 these devices in the absence of any working WAN interface. 612 An IPv6 CE router is expected to support an IPv6 end-user network and 613 IPv6 hosts that exhibit the following characteristics: 615 1. Link-local addresses may be insufficient for allowing IPv6 616 applications to communicate with each other in the end-user 617 network. The IPv6 CE router will need to enable this 618 communication by providing globally scoped unicast addresses or 619 ULAs [RFC4193], whether or not WAN connectivity exists. 621 2. IPv6 hosts should be capable of using SLAAC and may be capable of 622 using DHCPv6 for acquiring their addresses. 624 3. IPv6 hosts may use DHCPv6 for other configuration information, 625 such as the DNS_SERVERS option for acquiring DNS information. 627 Unless otherwise specified, the following requirements apply to the 628 IPv6 CE router's LAN interfaces only. 630 ULA requirements: 632 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 633 prefix [RFC4193]. 635 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 636 consistently across reboots. 638 ULA-3: The value of the ULA prefix SHOULD be configurable. 640 ULA-4: By default, the IPv6 CE router MUST act as a site border 641 router according to Section 4.3 of [RFC4193] and filter 642 packets with local IPv6 source or destination addresses 643 accordingly. 645 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 646 router with a Router Lifetime greater than zero whenever all 647 of its configured and delegated prefixes are ULA prefixes. 649 LAN requirements: 651 L-1: The IPv6 CE router MUST support router behavior according to 652 Neighbor Discovery for IPv6 [RFC4861]. 654 L-2: The IPv6 CE router MUST assign a separate /64 from its 655 delegated prefix(es) (and ULA prefix if configured to provide 656 ULA addressing) for each of its LAN interfaces. 658 L-3: An IPv6 CE router MUST advertise itself as a router for the 659 delegated prefix(es) (and ULA prefix if configured to provide 660 ULA addressing) using the "Route Information Option" specified 661 in Section 2.3 of [RFC4191]. This advertisement is 662 independent of having or not having IPv6 connectivity on the 663 WAN interface. 665 L-4: An IPv6 CE router MUST NOT advertise itself as a default 666 router with a Router Lifetime [RFC4861] greater than zero if 667 it has no prefixes configured or delegated to it. 669 L-5: The IPv6 CE router MUST make each LAN interface an advertising 670 interface according to [RFC4861]. 672 L-6: In Router Advertisement messages ([RFC4861]), the Prefix 673 Information option's A and L flags MUST be set to 1 by 674 default. 676 L-7: The A and L flags' ([RFC4861]) settings SHOULD be user 677 configurable. 679 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 680 IPv6 address assignment according to [RFC3315] OR a stateless 681 DHCPv6 server according to [RFC3736] on its LAN interfaces. 683 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 684 IA_NA option, it SHOULD set the M flag to zero and the O flag 685 to 1 in its Router Advertisement messages [RFC4861]. 687 L-10: The IPv6 CE router MUST support providing DNS information in 688 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 690 L-11: The IPv6 CE router MUST support providing DNS information in 691 the Router Advertisement Recursive DNS Server (RDNSS) and DNS 692 Search List options. Both options are specified in [RFC6106]. 694 L-12: The IPv6 CE router SHOULD implement a DNS proxy as described 695 in [RFC5625]. 697 L-13: The IPv6 CE router SHOULD make available a subset of DHCPv6 698 options (as listed in Section 5.3 of [RFC3736]) received from 699 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 700 server. 702 L-14: If the delegated prefix changes, i.e., the current prefix is 703 replaced with a new prefix without any overlapping time 704 period, then the IPv6 CE router MUST immediately advertise the 705 old prefix with a Preferred Lifetime of zero and a Valid 706 Lifetime of either a) zero or b) the lower of the current 707 Valid Lifetime and two hours (which must be decremented in 708 real time) in a Router Advertisement message as described in 709 Section 5.5.3, (e) of [RFC4862]. 711 L-15: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 712 message, code 5 (Source address failed ingress/egress policy) 713 for packets forwarded to it that use an address from a prefix 714 that has been invalidated. 716 L-16: The IPv6 CE router SHOULD provide HNCP (Home Networking 717 Control Protocol) services, as specified in [RFC7788]. 719 5.4. Transition Technologies Support 721 Even if the main target of this document is the support of IPv6-only 722 WAN access, for some time, there will be a need to support IPv4-only 723 devices and applications in the customers LANs, in one side of the 724 picture. In the other side, some Service Providers willing to deploy 725 IPv6, may not be able to do so in the first stage, neither as 726 IPv6-only or dual-stack in the WAN. Consequently, transition 727 technologies to resolve both issues should be taken in consideration. 729 5.4.1. IPv4 Service Continuity in Customer LANs 731 5.4.1.1. 464XLAT 733 464XLAT [RFC6877] is a technique to provide IPv4 access service to 734 IPv6-only edge networks without encapsulation. 736 The IPv6 CE router SHOULD support CLAT functionality. If 464XLAT is 737 supported, it MUST be implemented according to [RFC6877]. The 738 following CE Requirements also apply: 740 464XLAT requirements: 742 464XLAT-1: The IPv6 CE router MUST perform IPv4 Network Address 743 Translation (NAT) on IPv4 traffic translated using the 744 CLAT, unless a dedicated /64 prefix has been acquired 745 using DHCPv6-PD [RFC3633]. 747 464XLAT-2: The IPv6 CE router MUST implement [RFC7050] in order to 748 discover the PLAT-side translation IPv4 and IPv6 749 prefix(es)/suffix(es). In environments with PCP support, 750 the IPv6 CE SHOULD follow [RFC7225] to learn the PLAT- 751 side translation IPv4 and IPv6 prefix(es)/suffix(es) used 752 by an upstream PCP-controlled NAT64 device. 754 5.4.1.2. Dual-Stack Lite (DS-Lite) 756 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 757 services and incentives for the deployment of IPv6. It also 758 de-couples IPv6 deployment in the service provider network from the 759 rest of the Internet, making incremental deployment easier. Dual- 760 Stack Lite enables a broadband service provider to share IPv4 761 addresses among customers by combining two well-known technologies: 762 IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is 763 expected that DS-Lite traffic is forwarded over the IPv6 CE router's 764 native IPv6 WAN interface, and not encapsulated in another tunnel. 766 The IPv6 CE router SHOULD implement DS-Lite functionality. If 767 DS-Lite is supported, it MUST be implemented according to [RFC6333]. 768 This document takes no position on simultaneous operation of Dual- 769 Stack Lite and native IPv4. The following IPv6 CE router 770 requirements also apply: 772 DS-Lite requirements: 774 DSLITE-1: The IPv6 CE router MUST support configuration of DS-Lite 775 via the DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE 776 router MAY use other mechanisms to configure DS-Lite 777 parameters. Such mechanisms are outside the scope of this 778 document. 780 DSLITE-2: The IPv6 CE router MUST support the DHCPv6 S46 priority 781 option described in [RFC8026]. 783 DSLITE-3: The IPv6 CE router MUST NOT perform IPv4 Network Address 784 Translation (NAT) on IPv4 traffic encapsulated using DS- 785 Lite. 787 DSLITE-4: If the IPv6 CE router is configured with an IPv4 address 788 on its WAN interface, then the IPv6 CE router SHOULD 789 disable the DS-Lite Basic Bridging BroadBand (B4) element. 791 5.4.1.3. Lightweight 4over6 (lw4o6) 793 Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the 794 NAPT function from the DS-Lite tunnel concentrator to the tunnel 795 client located in the IPv6 CE router, removing the requirement for a 796 CGN function in the tunnel concentrator and reducing the amount of 797 centralized state. 799 The IPv6 CE router SHOULD implement lw4o6 functionality. If DS-Lite 800 is implemented, lw4o6 MUST be supported as well. If lw4o6 is 801 supported, it MUST be implemented according to [RFC7596]. This 802 document takes no position on simultaneous operation of lw4o6 and 803 native IPv4. The following IPv6 CE router Requirements also apply: 805 Lw4o6 requirements: 807 LW4O6-1: The IPv6 CE router MUST support configuration of lw4o6 via 808 the lw4o6 DHCPv6 options [RFC7598]. The IPv6 CE router MAY 809 use other mechanisms to configure lw4o6 parameters. Such 810 mechanisms are outside the scope of this document. 812 LW4O6-2: The IPv6 CE router MUST support the DHCPv6 S46 priority 813 option described in [RFC8026]. 815 LW4O6-3: The IPv6 CE router MUST support the DHCPv4-over-DHCPv6 816 (DHCP 4o6) transport described in [RFC7341]. 818 LW4O6-4: The IPv6 CE router MAY support Dynamic Allocation of Shared 819 IPv4 Addresses as described in [RFC7618]. 821 5.4.1.4. MAP-E 823 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 824 an IPv6 network using IP encapsulation, including a generic mechanism 825 for mapping between IPv6 addresses and IPv4 addresses as well as 826 transport-layer ports. 828 The IPv6 CE router SHOULD support MAP-E functionality. If MAP-E is 829 supported, it MUST be implemented according to [RFC7597]. The 830 following CE Requirements also apply: 832 MAP-E requirements: 834 MAPE-1: The IPv6 CE router MUST support configuration of MAP-E via 835 the MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY 836 use other mechanisms to configure MAP-E parameters. Such 837 mechanisms are outside the scope of this document. 839 MAPE-2: The IPv6 CE router MUST support the DHCPv6 S46 priority 840 option described in [RFC8026]. 842 5.4.1.5. MAP-T 844 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 845 that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as 846 the form of IPv6 domain transport. 848 The IPv6 CE router SHOULD support MAP-T functionality. If MAP-T is 849 supported, it MUST be implemented according to [RFC7599]. The 850 following IPv6 CE Requirements also apply: 852 MAP-T requirements: 854 MAPT-1: The CE router MUST support configuration of MAP-T via the 855 MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use 856 other mechanisms to configure MAP-E parameters. Such 857 mechanisms are outside the scope of this document. 859 MAPT-2: The IPv6 CE router MUST support the DHCPv6 S46 priority 860 option described in [RFC8026]. 862 5.4.2. Support of IPv6 in IPv4-only WAN access 864 5.4.2.1. 6in4 866 6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to 867 manually configure IPv6 support via a service provider's IPv4 network 868 infrastructure. 870 The IPv6 CE router MAY support 6in4 functionality. 6in4 used for a 871 manually configured tunnel requires a subset of the 6rd parameters 872 (delegated prefix and remote IPv4 end-point). The on-wire and 873 forwarding plane is identical for both mechanisms, however 6in4 874 doesn't support mesh traffic and requires manually provisioning. 875 Thus, if the device supports either 6rd or 6in4, it's commonly a 876 minor UI addition to support both. If 6in4 is supported, it MUST be 877 implemented according to [RFC4213]. The following CE Requirements 878 also apply: 880 6in4 requirements: 882 6IN4-1: The IPv6 CE router SHOULD support 6in4 automated 883 configuration by means of the 6rd DHCPv4 Option 212. If the 884 IPv6 CE router has obtained an IPv4 network address through 885 some other means such as PPP, it SHOULD use the DHCPINFORM 886 request message [RFC2131] to request the 6rd DHCPv4 Option. 888 The IPv6 CE router MAY use other mechanisms to configure 889 6in4 parameters. Such mechanisms are outside the scope of 890 this document. 892 6IN4-2: If the IPv6 CE router is capable of automated configuration 893 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 894 support user-entered configuration of 6in4. 896 6IN4-3: If the IPv6 CE router supports configuration mechanisms 897 other than the 6rd DHCPv4 Option 212 (user-entered, TR-069 898 [TR-069], etc.), the IPv6 CE router MUST support 6in4 in 899 "hub and spoke" mode. 6in4 in "hub and spoke" requires all 900 IPv6 traffic to go to the 6rd Border Relay, which in this 901 case is the tunnel-end-point. In effect, this requirement 902 removes the "direct connect to 6rd" route defined in 903 Section 7.1.1 of [RFC5969]. 905 6IN4-4: The IPv6 CE router MUST allow 6in4 and native IPv6 WAN 906 interfaces to be active alone as well as simultaneously in 907 order to support coexistence of the two technologies during 908 an incremental transition period such as a transition from 909 6in4 to native IPv6. 911 6IN4-5: Each packet sent on a 6in4 or native WAN interface MUST be 912 directed such that its source IP address is derived from the 913 delegated prefix associated with the particular interface 914 from which the packet is being sent (Section 4.3 of 915 [RFC3704]). 917 6IN4-6: The IPv6 CE router MUST allow different as well as identical 918 delegated prefixes to be configured via each (6in4 or 919 native) WAN interface. 921 6IN4-7: In the event that forwarding rules produce a tie between 922 6in4 and native IPv6, by default, the IPv6 CE router MUST 923 prefer native IPv6. 925 5.4.2.2. 6rd 927 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 928 advance deployment of IPv6 to end users via a service provider's IPv4 929 network infrastructure. Key aspects include automatic IPv6 prefix 930 delegation to sites, stateless operation, simple provisioning, and 931 service that is equivalent to native IPv6 at the sites that are 932 served by the mechanism. It is expected that such traffic is 933 forwarded over the IPv6 CE router's native IPv4 WAN interface and not 934 encapsulated in another tunnel. 936 The IPv6 CE router MAY support 6rd functionality. If 6rd is 937 supported, it MUST be implemented according to [RFC5969]. The 938 following CE Requirements also apply: 940 6rd requirements: 942 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 943 DHCPv4 Option 212. If the IPv6 CE router has obtained an 944 IPv4 network address through some other means such as PPP, it 945 SHOULD use the DHCPINFORM request message [RFC2131] to 946 request the 6rd DHCPv4 Option. The IPv6 CE router MAY use 947 other mechanisms to configure 6rd parameters. Such 948 mechanisms are outside the scope of this document. 950 6RD-2: If the IPv6 CE router is capable of automated configuration 951 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 952 support user-entered configuration of 6rd. 954 6RD-3: If the IPv6 CE router supports configuration mechanisms other 955 than the 6rd DHCPv4 Option 212 (user-entered, TR-069 956 [TR-069], etc.), the IPv6 CE router MUST support 6rd in "hub 957 and spoke" mode. 6rd in "hub and spoke" requires all IPv6 958 traffic to go to the 6rd Border Relay. In effect, this 959 requirement removes the "direct connect to 6rd" route defined 960 in Section 7.1.1 of [RFC5969]. 962 6RD-4: The IPv6 CE router MUST allow 6rd and native IPv6 WAN 963 interfaces to be active alone as well as simultaneously in 964 order to support coexistence of the two technologies during 965 an incremental transition period such as a transition from 966 6rd to native IPv6. 968 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be 969 directed such that its source IP address is derived from the 970 delegated prefix associated with the particular interface 971 from which the packet is being sent (Section 4.3 of 972 [RFC3704]). 974 6RD-6: The IPv6 CE router MUST allow different as well as identical 975 delegated prefixes to be configured via each (6rd or native) 976 WAN interface. 978 6RD-7: In the event that forwarding rules produce a tie between 6rd 979 and native IPv6, by default, the IPv6 CE router MUST prefer 980 native IPv6. 982 5.5. IPv4 Multicast Support 984 Actual deployments support IPv4 multicast for services such as IPTV. 985 In the transition phase it is expected that multicast services will 986 still be provided using IPv4 to the customer LANs. 988 In order to support the delivery of IPv4 multicast services to IPv4 989 clients over an IPv6 multicast network, the IPv6 CE router SHOULD 990 support [RFC8114] and [RFC8115]. 992 5.6. Security Considerations 994 It is considered a best practice to filter obviously malicious 995 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 996 the IPv6 CE router ought to support basic stateless egress and 997 ingress filters. The IPv6 CE router is also expected to offer 998 mechanisms to filter traffic entering the customer network; however, 999 the method by which vendors implement configurable packet filtering 1000 is beyond the scope of this document. 1002 Security requirements: 1004 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 1005 the IPv6 CE router SHOULD support functionality sufficient for 1006 implementing the set of recommendations in [RFC6092], 1007 Section 4. This document takes no position on whether such 1008 functionality is enabled by default or mechanisms by which 1009 users would configure it. 1011 S-2: The IPv6 CE router SHOULD support ingress filtering in 1012 accordance with BCP 38 [RFC2827]. Note that this requirement 1013 was downgraded from a MUST from RFC 6204 due to the difficulty 1014 of implementation in the IPv6 CE router and the feature's 1015 redundancy with upstream router ingress filtering. 1017 S-3: If the IPv6 CE router firewall is configured to filter incoming 1018 tunneled data, the firewall SHOULD provide the capability to 1019 filter decapsulated packets from a tunnel. 1021 6. Acknowledgements 1023 Thanks to James Woodyatt, Mohamed Boucadair, Masanobu Kawashima, 1024 Mikael Abrahamsson, Barbara Stark, Ole Troan and Brian Carpenter for 1025 their review and comments. 1027 This document is an update of RFC7084, whose original authors were: 1028 Hemant Singh, Wes Beebee, Chris Donley and Barbara Stark. The rest 1029 of the text on this section and the Contributors section, are the 1030 original acknowledgements and Contributors sections of the earlier 1031 version of this document. 1033 Thanks to the following people (in alphabetical order) for their 1034 guidance and feedback: 1036 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 1037 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 1038 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 1039 Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas 1040 Herbst, Ray Hunter, Joel Jaeggli, Kevin Johns, Erik Kline, Stephen 1041 Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, 1042 David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, 1043 Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen, 1044 Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark 1045 Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James 1046 Woodyatt, Carl Wuyts, and Cor Zwart. 1048 This document is based in part on CableLabs' eRouter specification. 1049 The authors wish to acknowledge the additional contributors from the 1050 eRouter team: 1052 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 1053 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 1054 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 1055 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 1056 Torbet, and Greg White. 1058 7. Contributors 1060 The following people have participated as co-authors or provided 1061 substantial contributions to this document: Ralph Droms, Kirk 1062 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 1063 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole 1064 Troan for editorship in the original RFC 6204 document. 1066 8. ANNEX A: Code Considerations 1068 One of the apparent main issues for vendors to include new 1069 functionalities, such as support for new transition mechanisms, is 1070 the lack of space in the flash (or equivalent) memory. However, it 1071 has been confirmed from existing open source implementations 1072 (OpenWRT/LEDE), that adding the support for the new transitions 1073 mechanisms, requires around 10-12 Kbytes (because most of the code is 1074 shared among several transition mechanisms), which typically means 1075 about 0,15% of the existing code size in popular CEs in the market. 1077 It is also clear that the new requirements don't have extra cost in 1078 terms of RAM memory, neither other hardware requirements such as more 1079 powerful CPUs. 1081 The other issue seems to be the cost of developing the code for those 1082 new functionalities. However at the time of writing this document, 1083 it has been confirmed that there are several open source versions of 1084 the required code for supporting the new transition mechanisms, so 1085 the development cost is negligent, and only integration and testing 1086 cost may become a minor issue. 1088 9. ANNEX B: Changes from RFC7084 1090 The -bis version of this document has some minor text edits here and 1091 there. Significant updates are: 1093 1. New section "Usage Scenarios". 1095 2. Added support of HNCP ([RFC7788]) in LAN (L-16). 1097 3. Added support of 464XLAT ([RFC6877]). 1099 4. Added support of lw4o6 ([RFC7596]). 1101 5. Added support of MAP-E ([RFC7597]) and MAP-T ([RFC7599]). 1103 6. As the main scope of this document is the IPv6-only CE (IPv6-only 1104 in the WAN link), the support of 6rd ([RFC5969]) has been changed 1105 to MAY. 6in4 ([RFC4213]) support has been included as well in 1106 case 6rd is supported, as it doesn't require additional code. 1108 7. New section "IPv4 Multicast Support". 1110 8. Added support for DNS proxy [RFC5625] as general LAN requirement. 1112 9. Split of transition in two sub-sections for the sake of clarity. 1114 10. ANNEX C: Changes from RFC7084-bis-00 1116 Section to be removed for WGLC. Significant updates are: 1118 1. LW4O6-5 changed to port-restricted to conform with [RFC7596]. 1120 2. MAPE-3 changed to port-restricted to conform with [RFC7597]. 1122 3. MAPT-3 changed to port-restricted to conform with [RFC7599]. 1124 4. [RFC7341] removed from 464XLAT, DS-LITE, MAP-E and MAP-T 1125 requirements. 1127 5. [RFC5625] removed from 464XLAT, and included as general LAN 1128 requirement. 1130 6. [RFC7618] included as MAY for lw4o6. 1132 7. 6in4 text clarifications. 1134 8. Included non-normative reference to [RFC7849] to clarify that the 1135 details of the connectivity to 3GPP/LTE networks is out of the 1136 scope. 1138 9. Split of transition in two sub-sections for the sake of clarity. 1140 11. ANNEX D: Changes from RFC7084-bis-01 1142 Section to be removed for WGLC. Significant updates are: 1144 1. G-6 added in order to comply with [RFC7608]. 1146 2. LW4O6-5 removed. 1148 3. MAPE-3 removed. 1150 4. MAPT-3 removed. 1152 5. Included non-normative reference to [RFC7849] to clarify that the 1153 details of the connectivity to 3GPP/LTE networks is out of the 1154 scope. 1156 6. Split of transition in two sub-sections for the sake of clarity. 1158 12. ANNEX E: Changes from RFC7084-bis-02 1160 Section to be removed for WGLC. Significant updates are: 1162 1. LW4O6-5 removed, was a mistake due to copy-paste from DS-LITE. 1164 2. Removed citation to individual I-Ds for DHCPv6 options. 1166 13. ANNEX F: Changes from RFC7084-bis-03 1168 Section to be removed for WGLC. Significant updates are: 1170 1. Clarifications on text regarding downstream routers support. 1172 14. References 1174 14.1. Normative References 1176 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1177 Communication Layers", STD 3, RFC 1122, 1178 DOI 10.17487/RFC1122, October 1989, 1179 . 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, 1183 DOI 10.17487/RFC2119, March 1997, 1184 . 1186 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1187 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1188 . 1190 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1191 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1192 . 1194 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1195 Defeating Denial of Service Attacks which employ IP Source 1196 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1197 May 2000, . 1199 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1200 C., and M. Carney, "Dynamic Host Configuration Protocol 1201 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1202 2003, . 1204 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1205 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1206 DOI 10.17487/RFC3633, December 2003, 1207 . 1209 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1210 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1211 DOI 10.17487/RFC3646, December 2003, 1212 . 1214 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1215 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1216 2004, . 1218 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1219 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 1220 April 2004, . 1222 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1223 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1224 November 2005, . 1226 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1227 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1228 . 1230 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1231 for IPv6 Hosts and Routers", RFC 4213, 1232 DOI 10.17487/RFC4213, October 2005, 1233 . 1235 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1236 Time Option for Dynamic Host Configuration Protocol for 1237 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 1238 2005, . 1240 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1241 Control Message Protocol (ICMPv6) for the Internet 1242 Protocol Version 6 (IPv6) Specification", RFC 4443, 1243 DOI 10.17487/RFC4443, March 2006, 1244 . 1246 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1247 "Internet Group Management Protocol (IGMP) / Multicast 1248 Listener Discovery (MLD)-Based Multicast Forwarding 1249 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 1250 August 2006, . 1252 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1253 (CIDR): The Internet Address Assignment and Aggregation 1254 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1255 2006, . 1257 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 1258 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 1259 Access Networks", RFC 4779, DOI 10.17487/RFC4779, January 1260 2007, . 1262 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1263 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1264 DOI 10.17487/RFC4861, September 2007, 1265 . 1267 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1268 Address Autoconfiguration", RFC 4862, 1269 DOI 10.17487/RFC4862, September 2007, 1270 . 1272 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1273 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1274 . 1276 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1277 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1278 . 1280 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1281 "Network Time Protocol Version 4: Protocol and Algorithms 1282 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1283 . 1285 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 1286 Server Option for DHCPv6", RFC 5908, DOI 10.17487/RFC5908, 1287 June 2010, . 1289 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1290 Model: The Relationship between Links and Subnet 1291 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1292 . 1294 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1295 Infrastructures (6rd) -- Protocol Specification", 1296 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1297 . 1299 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1300 Capabilities in Customer Premises Equipment (CPE) for 1301 Providing Residential IPv6 Internet Service", RFC 6092, 1302 DOI 10.17487/RFC6092, January 2011, 1303 . 1305 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1306 "IPv6 Router Advertisement Options for DNS Configuration", 1307 RFC 6106, DOI 10.17487/RFC6106, November 2010, 1308 . 1310 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1311 Assignment to End Sites", BCP 157, RFC 6177, 1312 DOI 10.17487/RFC6177, March 2011, 1313 . 1315 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1316 Stack Lite Broadband Deployments Following IPv4 1317 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1318 . 1320 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1321 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 1322 RFC 6334, DOI 10.17487/RFC6334, August 2011, 1323 . 1325 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1326 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1327 2011, . 1329 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 1330 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 1331 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 1332 . 1334 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1335 Combination of Stateful and Stateless Translation", 1336 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1337 . 1339 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1340 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1341 DOI 10.17487/RFC6887, April 2013, 1342 . 1344 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1345 the IPv6 Prefix Used for IPv6 Address Synthesis", 1346 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1347 . 1349 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 1350 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 1351 2013, . 1353 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1354 Port Control Protocol (PCP)", RFC 7225, 1355 DOI 10.17487/RFC7225, May 2014, 1356 . 1358 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1359 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 1360 RFC 7341, DOI 10.17487/RFC7341, August 2014, 1361 . 1363 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1364 Farrer, "Lightweight 4over6: An Extension to the Dual- 1365 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1366 July 2015, . 1368 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1369 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1370 Port with Encapsulation (MAP-E)", RFC 7597, 1371 DOI 10.17487/RFC7597, July 2015, 1372 . 1374 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 1375 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 1376 Configuration of Softwire Address and Port-Mapped 1377 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 1378 . 1380 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1381 and T. Murakami, "Mapping of Address and Port using 1382 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1383 2015, . 1385 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1386 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1387 DOI 10.17487/RFC7608, July 2015, 1388 . 1390 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 1391 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 1392 RFC 7618, DOI 10.17487/RFC7618, August 2015, 1393 . 1395 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1396 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1397 2016, . 1399 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 1400 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 1401 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 1402 November 2016, . 1404 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1405 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1406 over an IPv6 Multicast Network", RFC 8114, 1407 DOI 10.17487/RFC8114, March 2017, 1408 . 1410 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 1411 Option for IPv4-Embedded Multicast and Unicast IPv6 1412 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 1413 . 1415 14.2. Informative References 1417 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 1418 and D. Wing, "IPv6 Multihoming without Network Address 1419 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 1420 . 1422 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 1423 Recommendations with Multiple Stateful DHCPv6 Options", 1424 RFC 7550, DOI 10.17487/RFC7550, May 2015, 1425 . 1427 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 1428 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 1429 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, 1430 DOI 10.17487/RFC7849, May 2016, 1431 . 1433 [TR-069] Broadband Forum, "CPE WAN Management Protocol", TR-069 1434 Amendment 4, July 2011, 1435 . 1437 [UPnP-IGD] 1438 UPnP Forum, "InternetGatewayDevice:2 Device Template 1439 Version 1.01", December 2010, 1440 . 1442 Author's Address 1444 Jordi Palet Martinez 1445 Consulintel, S.L. 1446 Molino de la Navata, 75 1447 La Navata - Galapagar, Madrid 28420 1448 Spain 1450 EMail: jordi.palet@consulintel.es 1451 URI: http://www.consulintel.es/