idnits 2.17.1 draft-ietf-v6ops-rfc7084-bis-00.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.) 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 (April 5, 2017) is 2549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6144' is defined on line 1316, but no explicit reference was found in the text ** 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: 8 errors (**), 0 flaws (~~), 3 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) April 5, 2017 5 Intended status: Informational 6 Expires: October 7, 2017 8 Basic Requirements for IPv6 Customer Edge Routers 9 draft-ietf-v6ops-rfc7084-bis-00 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. The document also covers several 17 transition technologies, as required in a world where IPv4 addresses 18 are no longer available, so hosts in the customer LANs with IPv4-only 19 or IPv6-only applications or devices, requiring to communicate with 20 IPv4-only services at the Internet, are able to do so. The document 21 obsoletes RFC 7084. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 7, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Current IPv4 End-User Network Architecture . . . . . . . 6 63 4.2. IPv6 End-User Network Architecture . . . . . . . . . . . 6 64 4.2.1. Local Communication . . . . . . . . . . . . . . . . . 8 65 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. General Requirements . . . . . . . . . . . . . . . . . . 8 67 5.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . 9 68 5.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . 13 69 5.4. Transition Technologies Support . . . . . . . . . . . . . 15 70 5.4.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 15 71 5.4.2. 6in4 . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.4.3. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.4.4. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 18 74 5.4.5. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 19 75 5.4.6. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.4.7. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 20 77 5.5. IPv4 Multicast Support . . . . . . . . . . . . . . . . . 20 78 5.6. Security Considerations . . . . . . . . . . . . . . . . . 21 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 81 8. ANNEX A: Code Considerations . . . . . . . . . . . . . . . . 22 82 9. ANNEX B: Changes from RFC7084 . . . . . . . . . . . . . . . . 23 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 85 10.2. Informative References . . . . . . . . . . . . . . . . . 28 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 88 1. Introduction 90 This document defines basic IPv6 features for a residential or small- 91 office router, referred to as an "IPv6 CE router", in order to 92 establish an industry baseline for features to be implemented on such 93 a router. 95 These routers typically also support IPv4, at least in the LAN side. 97 This document specifies how an IPv6 CE router automatically 98 provisions its WAN interface, acquires address space for provisioning 99 of its LAN interfaces, and fetches other configuration information 100 from the service provider network. Automatic provisioning of more 101 complex topology than a single router with multiple LAN interfaces is 102 out of scope for this document. In some cases, manual provisioning 103 may be acceptable, when intended for a small number of customers. 105 See [RFC4779] for a discussion of options available for deploying 106 IPv6 in service provider access networks. 108 This document also covers the IP transition technologies required in 109 a world where IPv4 addresses are no longer available, so the service 110 providers need to provision IPv6-only WAN access, while at the same 111 time ensuring that IPv4-only or IPv6-only devices or applications in 112 the customer LANs can still reach IPv4-only devices or applications 113 in Internet, which still don't have IPv6 support. 115 1.1. Requirements Language 117 Take careful note: Unlike other IETF documents, the key words "MUST", 118 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 119 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 120 described in RFC 2119 [RFC2119]. This document uses these keywords 121 not strictly for the purpose of interoperability, but rather for the 122 purpose of establishing industry-common baseline functionality. As 123 such, the document points to several other specifications (preferable 124 in RFC or stable form) to provide additional guidance to implementers 125 regarding any protocol implementation required to produce a 126 successful CE router that interoperates successfully with a 127 particular subset of currently deploying and planned common IPv6 128 access networks. 130 2. Terminology 132 End-User Network one or more links attached to the IPv6 CE 133 router that connect IPv6 hosts. 135 IPv6 Customer Edge Router a node intended for home or small-office 136 use that forwards IPv6 packets not 137 explicitly addressed to itself. The IPv6 138 CE router connects the end-user network to 139 a service provider network. In other 140 documents, the CE is named as CPE (Customer 141 Premises Equipment or Customer Provided 142 Equipment). In the context of this 143 document, both terminologies are 144 synonymous. 146 IPv6 Host any device implementing an IPv6 stack 147 receiving IPv6 connectivity through the 148 IPv6 CE router. 150 LAN Interface an IPv6 CE router's attachment to a link in 151 the end-user network. Examples are 152 Ethernet (simple or bridged), 802.11 153 wireless, or other LAN technologies. An 154 IPv6 CE router may have one or more 155 network-layer LAN interfaces. 157 Service Provider an entity that provides access to the 158 Internet. In this document, a service 159 provider specifically offers Internet 160 access using IPv6, and it may also offer 161 IPv4 Internet access. The service provider 162 can provide such access over a variety of 163 different transport methods such as FTTH, 164 DSL, cable, wireless, LTE, and others. 166 WAN Interface an IPv6 CE router's attachment to a link 167 used to provide connectivity to the service 168 provider network; example link technologies 169 include Ethernet (simple or bridged), PPP 170 links, Frame Relay, or ATM networks, as 171 well as Internet-layer (or higher-layer) 172 "tunnels", such as tunnels over IPv4 or 173 IPv6 itself. 175 3. Usage Scenarios 177 The IPv6 CE router described in this document is expected to be used 178 typically, in any of the following scenarios: 180 1. Residential/household users. Common usage is any kind of 181 Internet access (web, email, streaming, online gaming, etc.). 183 2. Residential with Small Office/Home Office (SOHO). Same usage as 184 for the first scenario. 186 3. Small Office/Home Office (SOHO). Same usage as for the first 187 scenario. 189 4. Small and Medium Enterprise (SME). Same usage as for the first 190 scenario. 192 5. Residential/household with advanced requirements. Same basic 193 usage as for the first scenario, however there may be 194 requirements for exporting services to the WAN (IP cameras, web, 195 DNS, email, VPN, etc.). 197 6. Small and Medium Enterprise (SME) with advanced requirements. 198 Same basic usage as for the first scenario, however there may be 199 requirements for exporting services to the WAN (IP cameras, web, 200 DNS, email, VPN, etc.). 202 The above list is not intended to be comprehensive of all the 203 possible usage scenarios, just the main ones. In fact, combinations 204 of the above usages are also possible, for example a residential with 205 SOHO and advanced requirements. 207 The mechanisms for exporting IPv6 services are commonly "naturally" 208 available in any IPv6 router, as when using GUA, unless they are 209 blocked by firewall rules, which may require some manual 210 configuration by means of a GUI and/or CLI. 212 However, in the case of IPv4, because the usage of private addresses 213 and NAT, it typically requires some degree of manual configuration 214 such as setting up a DMZ, virtual servers, or port/protocol 215 forwarding. In general, CE routers already provide GUI and/or CLI to 216 manually configure them, or the possibility to setup the CE in bridge 217 mode, so another CE behind it, takes care of that. It is out of the 218 scope of this document the definition of any requirements for that. 220 The main difference for an IPv6 CE router to support one or several 221 of the above indicated scenarios, is related to the packet processing 222 capabilities, performance, even other details such as the number of 223 WAN/LAN interfaces, their maximum speed, memory for keeping tables or 224 tracking connections, etc. So, it is out of the scope of this 225 document to classify them. 227 For example, an SME may have just 10 employees (micro-SME), which 228 commonly will be considered same as a SOHO, but a small SME can have 229 up to 50 employees, or 250 for a medium one. Depending on the IPv6 230 CE router capabilities or even how it is being configured (for 231 instance, using SLAAC or DHCPv6), it may support even a higher number 232 of employees if the traffic in the LANs is low, or switched by 233 another device(s), or the WAN bandwidth requirements are low, etc. 234 The actual bandwidth capabilities of access with technologies such as 235 FTTH, cable and even LTE, allows the support of such usages, and 236 indeed, is a very common situation that access networks and the CE 237 provided by the service provider are the same for SMEs and 238 residential users. 240 There is also no difference in terms of who actually provides the 241 IPv6 CE router. In most of the cases is the service provider, and in 242 fact is responsible, typically, of provisioning/managing at least the 243 WAN side. However, commonly the user has access to configure the LAN 244 interfaces, firewall, DMZ, and many other aspects. In fact, in many 245 cases, the user must supply, or at least can replace the IPv6 CE 246 router, which makes even more relevant that all the IPv6 CE routers, 247 support the same requirements defined in this document. 249 The IPv6 CE router described in this document is not intended for 250 usage in other scenarios such as bigger Enterprises, Data Centers, 251 Content Providers, etc. So, even if the documented requirements meet 252 their needs, may have additional requirements, which are out of the 253 scope of this document. 255 4. Architecture 257 4.1. Current IPv4 End-User Network Architecture 259 An end-user network will likely support both IPv4 and IPv6. It is 260 not expected that an end user will change their existing network 261 topology with the introduction of IPv6. There are some differences 262 in how IPv6 works and is provisioned; these differences have 263 implications for the network architecture. A typical IPv4 end-user 264 network consists of a "plug and play" router with NAT functionality 265 and a single link behind it, connected to the service provider 266 network. 268 A typical IPv4 NAT deployment by default blocks all incoming 269 connections. Opening of ports is typically allowed using a Universal 270 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 271 other firewall control protocol. 273 Another consequence of using private address space in the end-user 274 network is that it provides stable addressing; that is, it never 275 changes even when you change service providers, and the addresses are 276 always there even when the WAN interface is down or the customer edge 277 router has not yet been provisioned. 279 Many existing routers support dynamic routing (which learns routes 280 from other routers), and advanced end-users can build arbitrary, 281 complex networks using manual configuration of address prefixes 282 combined with a dynamic routing protocol. 284 4.2. IPv6 End-User Network Architecture 286 The end-user network architecture for IPv6 should provide equivalent 287 or better capabilities and functionality than the current IPv4 288 architecture. 290 The end-user network is a stub network. Figure 1 illustrates the 291 model topology for the end-user network. 293 +-------+-------+ \ 294 | Service | \ 295 | Provider | | Service 296 | Router | | Provider 297 +-------+-------+ | Network 298 | / 299 | Customer / 300 | Internet Connection / 301 | 302 +------+--------+ \ 303 | IPv6 | \ 304 | Customer Edge | \ 305 | Router | / 306 +---+-------+-+-+ / 307 Network A | | Network B | End-User 308 ---+-------------+----+- --+--+-------------+--- | Network(s) 309 | | | | \ 310 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 311 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 312 | | | | | | | | / 313 +----------+ +-----+----+ +----------+ +----------+ / 315 Figure 1: An Example of a Typical End-User Network 317 This architecture describes the: 319 o Basic capabilities of an IPv6 CE router 321 o Provisioning of the WAN interface connecting to the service 322 provider 324 o Provisioning of the LAN interfaces 326 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 327 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 328 multicast routing protocol. 330 The IPv6 CE router may be manually configured in an arbitrary 331 topology with a dynamic routing protocol. Automatic provisioning and 332 configuration is described for a single IPv6 CE router only. 334 4.2.1. Local Communication 336 Link-local IPv6 addresses are used by hosts communicating on a single 337 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 338 by hosts communicating within the end-user network across multiple 339 links, but without requiring the application to use a globally 340 routable address. The IPv6 CE router defaults to acting as the 341 demarcation point between two networks by providing a ULA boundary, a 342 multicast zone boundary, and ingress and egress traffic filters. 344 At the time of this writing, several host implementations do not 345 handle the case where they have an IPv6 address configured and no 346 IPv6 connectivity, either because the address itself has a limited 347 topological reachability (e.g., ULA) or because the IPv6 CE router is 348 not connected to the IPv6 network on its WAN interface. To support 349 host implementations that do not handle multihoming in a multi-prefix 350 environment [RFC7157], the IPv6 CE router should not, as detailed in 351 the requirements below, advertise itself as a default router on the 352 LAN interface(s) when it does not have IPv6 connectivity on the WAN 353 interface or when it is not provisioned with IPv6 addresses. For 354 local IPv6 communication, the mechanisms specified in [RFC4191] are 355 used. 357 ULA addressing is useful where the IPv6 CE router has multiple LAN 358 interfaces with hosts that need to communicate with each other. If 359 the IPv6 CE router has only a single LAN interface (IPv6 link), then 360 link-local addressing can be used instead. 362 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 363 conform to these recommendations, especially requirements ULA-5 and 364 L-4 below. 366 5. Requirements 368 5.1. General Requirements 370 The IPv6 CE router is responsible for implementing IPv6 routing; that 371 is, the IPv6 CE router must look up the IPv6 destination address in 372 its routing table to decide to which interface it should send the 373 packet. 375 In this role, the IPv6 CE router is responsible for ensuring that 376 traffic using its ULA addressing does not go out the WAN interface 377 and does not originate from the WAN interface. 379 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 380 Requirements specification [RFC6434]. 382 G-2: The IPv6 CE router MUST implement ICMPv6 according to 383 [RFC4443]. In particular, point-to-point links MUST be handled 384 as described in Section 3.1 of [RFC4443]. 386 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 387 its LAN interface(s) and its WAN interface until the router has 388 successfully completed the IPv6 address and the delegated 389 prefix acquisition process. 391 G-4: By default, an IPv6 CE router that has no default router(s) on 392 its WAN interface MUST NOT advertise itself as an IPv6 default 393 router on its LAN interfaces. That is, the "Router Lifetime" 394 field is set to zero in all Router Advertisement messages it 395 originates [RFC4861]. 397 G-5: By default, if the IPv6 CE router is an advertising router and 398 loses its IPv6 default router(s) and/or detects loss of 399 connectivity on the WAN interface, it MUST explicitly 400 invalidate itself as an IPv6 default router on each of its 401 advertising interfaces by immediately transmitting one or more 402 Router Advertisement messages with the "Router Lifetime" field 403 set to zero [RFC4861]. 405 5.2. WAN-Side Configuration 407 The IPv6 CE router will need to support connectivity to one or more 408 access network architectures. This document describes an IPv6 CE 409 router that is not specific to any particular architecture or service 410 provider and that supports all commonly used architectures. 412 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 413 IPv6-supported link layer, and there is no need for a link-layer- 414 specific configuration protocol for IPv6 network-layer configuration 415 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 416 section makes the assumption that the same mechanism will work for 417 any link layer, be it Ethernet, the Data Over Cable Service Interface 418 Specification (DOCSIS), PPP, or others. 420 WAN-side requirements: 422 W-1: When the router is attached to the WAN interface link, it MUST 423 act as an IPv6 host for the purposes of stateless [RFC4862] or 424 stateful [RFC3315] interface address assignment. 426 W-2: The IPv6 CE router MUST generate a link-local address and 427 finish Duplicate Address Detection according to [RFC4862] prior 428 to sending any Router Solicitations on the interface. The 429 source address used in the subsequent Router Solicitation MUST 430 be the link-local address on the WAN interface. 432 W-3: Absent other routing information, the IPv6 CE router MUST use 433 Router Discovery as specified in [RFC4861] to discover a 434 default router(s) and install a default route(s) in its routing 435 table with the discovered router's address as the next hop. 437 W-4: The router MUST act as a requesting router for the purposes of 438 DHCPv6 prefix delegation ([RFC3633]). 440 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 441 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 442 network-interface resets or IPv6 CE router reboots. 444 W-6: The WAN interface of the CE router SHOULD support a Port 445 Control Protocol (PCP) client as specified in [RFC6887] for use 446 by applications on the CE router. The PCP client SHOULD follow 447 the procedure specified in Section 8.1 of [RFC6887] to discover 448 its PCP server. This document takes no position on whether 449 such functionality is enabled by default or mechanisms by which 450 users would configure the functionality. Handling PCP requests 451 from PCP clients in the LAN side of the CE router is out of 452 scope. 454 Link-layer requirements: 456 WLL-1: If the WAN interface supports Ethernet encapsulation, then 457 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 459 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 460 router MUST support IPv6 over PPP [RFC5072]. 462 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 463 stack environment with IPCP and IPV6CP running over one PPP 464 logical channel, the Network Control Protocols (NCPs) MUST be 465 treated as independent of each other and start and terminate 466 independently. 468 Address assignment requirements: 470 WAA-1: The IPv6 CE router MUST support Stateless Address 471 Autoconfiguration (SLAAC) [RFC4862]. 473 WAA-2: The IPv6 CE router MUST follow the recommendations in 474 Section 4 of [RFC5942], and in particular the handling of 475 the L flag in the Router Advertisement Prefix Information 476 option. 478 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 479 behavior. 481 WAA-4: The IPv6 CE router MUST be able to support the following 482 DHCPv6 options: Identity Association for Non-temporary 483 Address (IA_NA), Reconfigure Accept [RFC3315], and 484 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 485 support the DNS Search List (DNSSL) option as specified in 486 [RFC3646]. 488 WAA-5: The IPv6 CE router SHOULD implement the Network Time 489 Protocol (NTP) as specified in [RFC5905] to provide a time 490 reference common to the service provider for other 491 protocols, such as DHCPv6, to use. If the CE router 492 implements NTP, it requests the NTP Server DHCPv6 option 493 [RFC5908] and uses the received list of servers as primary 494 time reference, unless explicitly configured otherwise. LAN 495 side support of NTP is out of scope for this document. 497 WAA-6: If the IPv6 CE router receives a Router Advertisement 498 message (described in [RFC4861]) with the M flag set to 1, 499 the IPv6 CE router MUST do DHCPv6 address assignment 500 (request an IA_NA option). 502 WAA-7: If the IPv6 CE router does not acquire a global IPv6 503 address(es) from either SLAAC or DHCPv6, then it MUST create 504 a global IPv6 address(es) from its delegated prefix(es) and 505 configure those on one of its internal virtual network 506 interfaces, unless configured to require a global IPv6 507 address on the WAN interface. 509 WAA-8: The CE router MUST support the SOL_MAX_RT option [RFC7083] 510 and request the SOL_MAX_RT option in an Option Request 511 Option (ORO). 513 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 514 (Weak End System) model [RFC1122]. When originating packets 515 from an interface, it will use a source address from another 516 one of its interfaces if the outgoing interface does not 517 have an address of suitable scope. 519 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 520 Time option and associated client behavior as specified in 521 [RFC4242]. 523 Prefix delegation requirements: 525 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 526 requesting router behavior as specified in [RFC3633] 527 (Identity Association for Prefix Delegation (IA_PD) option). 529 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 530 router the size of the prefix it requires. If so, it MUST 531 ask for a prefix large enough to assign one /64 for each of 532 its interfaces, rounded up to the nearest nibble, and SHOULD 533 be configurable to ask for more. 535 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 536 prefix size different from what is given in the hint. If the 537 delegated prefix is too small to address all of its 538 interfaces, the IPv6 CE router SHOULD log a system management 539 error. [RFC6177] covers the recommendations for service 540 providers for prefix allocation sizes. 542 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 543 delegation when either the M or O flags are set to 1 in a 544 received Router Advertisement (RA) message. Behavior of the 545 CE router to use DHCPv6 prefix delegation when the CE router 546 has not received any RA or received an RA with the M and the 547 O bits set to zero is out of scope for this document. 549 WPD-5: Any packet received by the CE router with a destination 550 address in the prefix(es) delegated to the CE router but not 551 in the set of prefixes assigned by the CE router to the LAN 552 must be dropped. In other words, the next hop for the 553 prefix(es) delegated to the CE router should be the null 554 destination. This is necessary to prevent forwarding loops 555 when some addresses covered by the aggregate are not 556 reachable [RFC4632]. 558 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 559 Unreachable message in accordance with Section 3.1 of 560 [RFC4443] back to the source of the packet, if the 561 packet is to be dropped due to this rule. 563 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 564 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 565 Advertise/Reply messages, even if the message does not 566 contain any addresses, unless configured to only obtain its 567 WAN IPv6 address via DHCPv6; see [RFC7550]. 569 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 570 routing protocol on its WAN interface. 572 WPD-8: The IPv6 CE router SHOULD support the [RFC6603] Prefix 573 Exclude option. 575 5.3. LAN-Side Configuration 577 The IPv6 CE router distributes configuration information obtained 578 during WAN interface provisioning to IPv6 hosts and assists IPv6 579 hosts in obtaining IPv6 addresses. It also supports connectivity of 580 these devices in the absence of any working WAN interface. 582 An IPv6 CE router is expected to support an IPv6 end-user network and 583 IPv6 hosts that exhibit the following characteristics: 585 1. Link-local addresses may be insufficient for allowing IPv6 586 applications to communicate with each other in the end-user 587 network. The IPv6 CE router will need to enable this 588 communication by providing globally scoped unicast addresses or 589 ULAs [RFC4193], whether or not WAN connectivity exists. 591 2. IPv6 hosts should be capable of using SLAAC and may be capable of 592 using DHCPv6 for acquiring their addresses. 594 3. IPv6 hosts may use DHCPv6 for other configuration information, 595 such as the DNS_SERVERS option for acquiring DNS information. 597 Unless otherwise specified, the following requirements apply to the 598 IPv6 CE router's LAN interfaces only. 600 ULA requirements: 602 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 603 prefix [RFC4193]. 605 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 606 consistently across reboots. 608 ULA-3: The value of the ULA prefix SHOULD be configurable. 610 ULA-4: By default, the IPv6 CE router MUST act as a site border 611 router according to Section 4.3 of [RFC4193] and filter 612 packets with local IPv6 source or destination addresses 613 accordingly. 615 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 616 router with a Router Lifetime greater than zero whenever all 617 of its configured and delegated prefixes are ULA prefixes. 619 LAN requirements: 621 L-1: The IPv6 CE router MUST support router behavior according to 622 Neighbor Discovery for IPv6 [RFC4861]. 624 L-2: The IPv6 CE router MUST assign a separate /64 from its 625 delegated prefix(es) (and ULA prefix if configured to provide 626 ULA addressing) for each of its LAN interfaces. 628 L-3: An IPv6 CE router MUST advertise itself as a router for the 629 delegated prefix(es) (and ULA prefix if configured to provide 630 ULA addressing) using the "Route Information Option" specified 631 in Section 2.3 of [RFC4191]. This advertisement is 632 independent of having or not having IPv6 connectivity on the 633 WAN interface. 635 L-4: An IPv6 CE router MUST NOT advertise itself as a default 636 router with a Router Lifetime [RFC4861] greater than zero if 637 it has no prefixes configured or delegated to it. 639 L-5: The IPv6 CE router MUST make each LAN interface an advertising 640 interface according to [RFC4861]. 642 L-6: In Router Advertisement messages ([RFC4861]), the Prefix 643 Information option's A and L flags MUST be set to 1 by 644 default. 646 L-7: The A and L flags' ([RFC4861]) settings SHOULD be user 647 configurable. 649 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 650 IPv6 address assignment according to [RFC3315] OR a stateless 651 DHCPv6 server according to [RFC3736] on its LAN interfaces. 653 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 654 IA_NA option, it SHOULD set the M flag to zero and the O flag 655 to 1 in its Router Advertisement messages [RFC4861]. 657 L-10: The IPv6 CE router MUST support providing DNS information in 658 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 660 L-11: The IPv6 CE router MUST support providing DNS information in 661 the Router Advertisement Recursive DNS Server (RDNSS) and DNS 662 Search List options. Both options are specified in [RFC6106]. 664 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 665 options (as listed in Section 5.3 of [RFC3736]) received from 666 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 667 server. 669 L-13: If the delegated prefix changes, i.e., the current prefix is 670 replaced with a new prefix without any overlapping time 671 period, then the IPv6 CE router MUST immediately advertise the 672 old prefix with a Preferred Lifetime of zero and a Valid 673 Lifetime of either a) zero or b) the lower of the current 674 Valid Lifetime and two hours (which must be decremented in 675 real time) in a Router Advertisement message as described in 676 Section 5.5.3, (e) of [RFC4862]. 678 L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 679 message, code 5 (Source address failed ingress/egress policy) 680 for packets forwarded to it that use an address from a prefix 681 that has been invalidated. 683 L-15: The IPv6 CE router SHOULD provide HNCP (Home Networking 684 Control Protocol) services, as specified in [RFC7788]. 686 5.4. Transition Technologies Support 688 5.4.1. 464XLAT 690 464XLAT [RFC6877] is a technique to provide IPv4 access service to 691 IPv6-only edge networks without encapsulation. 693 The CE router SHOULD support CLAT functionality. If 464XLAT is 694 supported, it MUST be implemented according to [RFC6877]. The 695 following CE Requirements also apply: 697 464XLAT requirements: 699 464XLAT-1: The IPv6 CE router MUST perform IPv4 Network Address 700 Translation (NAT) on IPv4 traffic translated using the 701 CLAT, unless a dedicated /64 prefix has been acquired 702 using DHCPv6-PD [RFC3633]. 704 464XLAT-2: The CE router MUST implement [RFC7050] in order to 705 discover the PLAT-side translation IPv4 and IPv6 706 prefix(es)/suffix(es). In environments with PCP support, 707 the CE SHOULD follow [RFC7225] to learn the PLAT-side 708 translation IPv4 and IPv6 prefix(es)/suffix(es) used by 709 an upstream PCP-controlled NAT64 device. Alternatively 710 SHOULD support draft-li-intarea-nat64-prefix-dhcp-option. 712 464XLAT-3: The CE router MUST implement a DNS proxy as described in 713 [RFC5625]. 715 464XLAT-4: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP 716 4o6) transport described in [RFC7341]. 718 5.4.2. 6in4 720 6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to 721 manually configure IPv6 support via a service provider's IPv4 network 722 infrastructure. 724 The CE router MAY support 6in4 functionality. If 6rd is implemented, 725 6in4 MUST be supported as well. If 6in4 is supported, it MUST be 726 implemented according to [RFC4213]. The following CE Requirements 727 also apply: 729 6in4 requirements: 731 6IN4-1: The IPv6 CE router SHOULD support 6in4 automated 732 configuration by means of the 6rd DHCPv4 Option 212. If the 733 CE router has obtained an IPv4 network address through some 734 other means such as PPP, it SHOULD use the DHCPINFORM 735 request message [RFC2131] to request the 6rd DHCPv4 Option. 736 The IPv6 CE router MAY use other mechanisms to configure 737 6in4 parameters. Such mechanisms are outside the scope of 738 this document. 740 6IN4-2: If the IPv6 CE router is capable of automated configuration 741 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 742 support user-entered configuration of 6in4. 744 6IN4-3: If the CE router supports configuration mechanisms other 745 than the 6rd DHCPv4 Option 212 (user-entered, TR-069 746 [TR-069], etc.), the CE router MUST support 6in4 in "hub and 747 spoke" mode. 6in4 in "hub and spoke" requires all IPv6 748 traffic to go to the 6rd Border Relay. In effect, this 749 requirement removes the "direct connect to 6rd" route 750 defined in Section 7.1.1 of [RFC5969]. 752 6IN4-4: A CE router MUST allow 6in4 and native IPv6 WAN interfaces 753 to be active alone as well as simultaneously in order to 754 support coexistence of the two technologies during an 755 incremental transition period such as a transition from 6in4 756 to native IPv6. 758 6IN4-5: Each packet sent on a 6in4 or native WAN interface MUST be 759 directed such that its source IP address is derived from the 760 delegated prefix associated with the particular interface 761 from which the packet is being sent (Section 4.3 of 762 [RFC3704]). 764 6IN4-6: The CE router MUST allow different as well as identical 765 delegated prefixes to be configured via each (6in4 or 766 native) WAN interface. 768 6IN4-7: In the event that forwarding rules produce a tie between 769 6in4 and native IPv6, by default, the IPv6 CE router MUST 770 prefer native IPv6. 772 5.4.3. 6rd 774 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 775 advance deployment of IPv6 to end users via a service provider's IPv4 776 network infrastructure. Key aspects include automatic IPv6 prefix 777 delegation to sites, stateless operation, simple provisioning, and 778 service that is equivalent to native IPv6 at the sites that are 779 served by the mechanism. It is expected that such traffic is 780 forwarded over the CE router's native IPv4 WAN interface and not 781 encapsulated in another tunnel. 783 The CE router MAY support 6rd functionality. If 6rd is supported, it 784 MUST be implemented according to [RFC5969]. The following CE 785 Requirements also apply: 787 6rd requirements: 789 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 790 DHCPv4 Option 212. If the CE router has obtained an IPv4 791 network address through some other means such as PPP, it 792 SHOULD use the DHCPINFORM request message [RFC2131] to 793 request the 6rd DHCPv4 Option. The IPv6 CE router MAY use 794 other mechanisms to configure 6rd parameters. Such 795 mechanisms are outside the scope of this document. 797 6RD-2: If the IPv6 CE router is capable of automated configuration 798 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 799 support user-entered configuration of 6rd. 801 6RD-3: If the CE router supports configuration mechanisms other than 802 the 6rd DHCPv4 Option 212 (user-entered, TR-069 [TR-069], 803 etc.), the CE router MUST support 6rd in "hub and spoke" 804 mode. 6rd in "hub and spoke" requires all IPv6 traffic to go 805 to the 6rd Border Relay. In effect, this requirement removes 806 the "direct connect to 6rd" route defined in Section 7.1.1 of 807 [RFC5969]. 809 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to 810 be active alone as well as simultaneously in order to support 811 coexistence of the two technologies during an incremental 812 transition period such as a transition from 6rd to native 813 IPv6. 815 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be 816 directed such that its source IP address is derived from the 817 delegated prefix associated with the particular interface 818 from which the packet is being sent (Section 4.3 of 819 [RFC3704]). 821 6RD-6: The CE router MUST allow different as well as identical 822 delegated prefixes to be configured via each (6rd or native) 823 WAN interface. 825 6RD-7: In the event that forwarding rules produce a tie between 6rd 826 and native IPv6, by default, the IPv6 CE router MUST prefer 827 native IPv6. 829 5.4.4. Dual-Stack Lite (DS-Lite) 831 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 832 services and incentives for the deployment of IPv6. It also 833 de-couples IPv6 deployment in the service provider network from the 834 rest of the Internet, making incremental deployment easier. Dual- 835 Stack Lite enables a broadband service provider to share IPv4 836 addresses among customers by combining two well-known technologies: 837 IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is 838 expected that DS-Lite traffic is forwarded over the CE router's 839 native IPv6 WAN interface, and not encapsulated in another tunnel. 841 The IPv6 CE router SHOULD implement DS-Lite functionality. If 842 DS-Lite is supported, it MUST be implemented according to [RFC6333]. 843 This document takes no position on simultaneous operation of Dual- 844 Stack Lite and native IPv4. The following CE router requirements 845 also apply: 847 DS-Lite requirements: 849 DSLITE-1: The CE router MUST support configuration of DS-Lite via 850 the DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE router 851 MAY use other mechanisms to configure DS-Lite parameters. 852 Such mechanisms are outside the scope of this document. 854 DSLITE-2: The CE router MUST support the DHCPv6 S46 priority option 855 described in [RFC8026]. 857 DSLITE-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP 858 4o6) transport described in [RFC7341]. 860 DSLITE-4: The IPv6 CE router MUST NOT perform IPv4 Network Address 861 Translation (NAT) on IPv4 traffic encapsulated using DS- 862 Lite. 864 DSLITE-5: If the IPv6 CE router is configured with an IPv4 address 865 on its WAN interface, then the IPv6 CE router SHOULD 866 disable the DS-Lite Basic Bridging BroadBand (B4) element. 868 5.4.5. Lightweight 4over6 (lw4o6) 870 Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the 871 NAPT function from the DS-Lite tunnel concentrator to the tunnel 872 client located in the IPv6 CE router, removing the requirement for a 873 CGN function in the tunnel concentrator and reducing the amount of 874 centralized state. 876 The IPv6 CE router SHOULD implement lw4o6 functionality. If DS-Lite 877 is implemented, lw4o6 MUST be supported as well. If lw4o6 is 878 supported, it MUST be implemented according to [RFC7596]. This 879 document takes no position on simultaneous operation of lw4o6 and 880 native IPv4. The following CE router Requirements also apply: 882 Lw4o6 requirements: 884 LW4O6-1: The CE router MUST support configuration of lw4o6 via the 885 lw4o6 DHCPv6 options [RFC7598]. The IPv6 CE router MAY use 886 other mechanisms to configure lw4o6 parameters. Such 887 mechanisms are outside the scope of this document. 889 LW4O6-2: The CE router MUST support the DHCPv6 S46 priority option 890 described in [RFC8026]. 892 LW4O6-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP 893 4o6) transport described in [RFC7341]. 895 LW4O6-4: The IPv6 CE router MUST perform IPv4 Network Address 896 Translation (NAT) on IPv4 traffic encapsulated using lw4o6. 898 LW4O6-5: If the IPv6 CE router is configured with an IPv4 address on 899 its WAN interface, then the IPv6 CE router SHOULD disable 900 the Lightweight Basic Bridging BroadBand (B4) element. 902 5.4.6. MAP-E 904 MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across 905 an IPv6 network using IP encapsulation, including a generic mechanism 906 for mapping between IPv6 addresses and IPv4 addresses as well as 907 transport-layer ports. 909 The CE router SHOULD support MAP-E functionality. If MAP-E is 910 supported, it MUST be implemented according to [RFC7597]. The 911 following CE Requirements also apply: 913 MAP-E requirements: 915 MAPE-1: The CE router MUST support configuration of MAP-E via the 916 MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use 917 other mechanisms to configure MAP-E parameters. Such 918 mechanisms are outside the scope of this document. 920 MAPE-2: The CE router MUST support the DHCPv6 S46 priority option 921 described in [RFC8026]. 923 MAPE-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP 4o6) 924 transport described in [RFC7341]. 926 MAPE-4: The IPv6 CE router MUST perform IPv4 Network Address 927 Translation (NAT) on IPv4 traffic encapsulated using MAP-E. 929 5.4.7. MAP-T 931 MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in 932 that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as 933 the form of IPv6 domain transport. 935 The CE router SHOULD support MAP-T functionality. If MAP-T is 936 supported, it MUST be implemented according to [RFC7599]. The 937 following CE Requirements also apply: 939 MAP-T requirements: 941 MAPT-1: The CE router MUST support configuration of MAP-T via the 942 MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use 943 other mechanisms to configure MAP-E parameters. Such 944 mechanisms are outside the scope of this document. 946 MAPT-2: The CE router MUST support the DHCPv6 S46 priority option 947 described in [RFC8026]. 949 MAPT-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP 4o6) 950 transport described in [RFC7341]. 952 MAPT-4: The IPv6 CE router MUST perform IPv4 Network Address 953 Translation (NAT) on IPv4 traffic translated using MAP-T. 955 5.5. IPv4 Multicast Support 957 Actual deployments support IPv4 multicast for services such as IPTV. 958 In the transition phase it is expected that multicast services will 959 still be provided using IPv4 to the customer LANs. 961 In order to support the delivery of IPv4 multicast services to IPv4 962 clients over an IPv6 multicast network, the CE router SHOULD support 963 [RFC8114] and [RFC8115]. 965 5.6. Security Considerations 967 It is considered a best practice to filter obviously malicious 968 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 969 the IPv6 CE router ought to support basic stateless egress and 970 ingress filters. The CE router is also expected to offer mechanisms 971 to filter traffic entering the customer network; however, the method 972 by which vendors implement configurable packet filtering is beyond 973 the scope of this document. 975 Security requirements: 977 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 978 the IPv6 CE router SHOULD support functionality sufficient for 979 implementing the set of recommendations in [RFC6092], 980 Section 4. This document takes no position on whether such 981 functionality is enabled by default or mechanisms by which 982 users would configure it. 984 S-2: The IPv6 CE router SHOULD support ingress filtering in 985 accordance with BCP 38 [RFC2827]. Note that this requirement 986 was downgraded from a MUST from RFC 6204 due to the difficulty 987 of implementation in the CE router and the feature's redundancy 988 with upstream router ingress filtering. 990 S-3: If the IPv6 CE router firewall is configured to filter incoming 991 tunneled data, the firewall SHOULD provide the capability to 992 filter decapsulated packets from a tunnel. 994 6. Acknowledgements 996 Thanks to Mohamed Boucadair for his review and comments. 998 This document is an update of RFC7084, whose original authors were: 999 Hemant Singh, Wes Beebee, Chris Donley and Barbara Stark. The rest 1000 of the text on this section and the Contributors section, are the 1001 original acknowledgements and Contributors sections of the earlier 1002 version of this document. 1004 Thanks to the following people (in alphabetical order) for their 1005 guidance and feedback: 1007 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 1008 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 1009 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 1010 Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas 1011 Herbst, Ray Hunter, Joel Jaeggli, Kevin Johns, Erik Kline, Stephen 1012 Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, 1013 David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, 1014 Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen, 1015 Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark 1016 Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James 1017 Woodyatt, Carl Wuyts, and Cor Zwart. 1019 This document is based in part on CableLabs' eRouter specification. 1020 The authors wish to acknowledge the additional contributors from the 1021 eRouter team: 1023 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 1024 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 1025 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 1026 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 1027 Torbet, and Greg White. 1029 7. Contributors 1031 The following people have participated as co-authors or provided 1032 substantial contributions to this document: Ralph Droms, Kirk 1033 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 1034 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole 1035 Troan for editorship in the original RFC 6204 document. 1037 8. ANNEX A: Code Considerations 1039 One of the apparent main issues for vendors to include new 1040 functionalities, such as support for new transition mechanisms, is 1041 the lack of space in the flash (or equivalent) memory. However, it 1042 has been confirmed from existing open source implementations 1043 (OpenWRT/LEDE), that adding the support for the new transitions 1044 mechanisms, requires around 10-12 Kbytes (because most of the code is 1045 shared among several transition mechanisms), which typically means 1046 about 0,15% of the existing code size in popular CEs in the market. 1048 It is also clear that the new requirements don't have extra cost in 1049 terms of RAM memory, neither other hardware requirements such as more 1050 powerful CPUs. 1052 The other issue seems to be the cost of developing the code for those 1053 new functionalities. However at the time of writing this document, 1054 it has been confirmed that there are several open source versions of 1055 the required code for supporting the new transition mechanisms, so 1056 the development cost is negligent, and only integration and testing 1057 cost may become a minor issue. 1059 9. ANNEX B: Changes from RFC7084 1061 The -bis version of this document has some minor text edits here and 1062 there. Significant updates are: 1064 1. New section "Usage Scenarios". 1066 2. Added support of HNCP ([RFC7788]) in LAN (L-15). 1068 3. Added support of 464XLAT ([RFC6877]). 1070 4. Added support of lw4o6 ([RFC7596]). 1072 5. Added support of MAP-E ([RFC7597]) and MAP-T ([RFC7599]). 1074 6. As the main scope of this document is the IPv6-only CE (IPv6-only 1075 in the WAN link), the support of 6rd ([RFC5969]) has been changed 1076 to MAY. 6in4 ([RFC4213]) support has been included as well in 1077 case 6rd is supported, as it doesn't require additional code. 1079 7. New section "IPv4 Multicast Support". 1081 10. References 1083 10.1. Normative References 1085 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1086 Communication Layers", STD 3, RFC 1122, 1087 DOI 10.17487/RFC1122, October 1989, 1088 . 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, 1092 DOI 10.17487/RFC2119, March 1997, 1093 . 1095 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1096 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1097 . 1099 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1100 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1101 . 1103 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1104 Defeating Denial of Service Attacks which employ IP Source 1105 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1106 May 2000, . 1108 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1109 C., and M. Carney, "Dynamic Host Configuration Protocol 1110 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1111 2003, . 1113 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1114 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1115 DOI 10.17487/RFC3633, December 2003, 1116 . 1118 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1119 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1120 DOI 10.17487/RFC3646, December 2003, 1121 . 1123 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1124 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1125 2004, . 1127 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1128 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 1129 April 2004, . 1131 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1132 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1133 November 2005, . 1135 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1136 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1137 . 1139 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1140 for IPv6 Hosts and Routers", RFC 4213, 1141 DOI 10.17487/RFC4213, October 2005, 1142 . 1144 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1145 Time Option for Dynamic Host Configuration Protocol for 1146 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 1147 2005, . 1149 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1150 Control Message Protocol (ICMPv6) for the Internet 1151 Protocol Version 6 (IPv6) Specification", RFC 4443, 1152 DOI 10.17487/RFC4443, March 2006, 1153 . 1155 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1156 "Internet Group Management Protocol (IGMP) / Multicast 1157 Listener Discovery (MLD)-Based Multicast Forwarding 1158 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 1159 August 2006, . 1161 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1162 (CIDR): The Internet Address Assignment and Aggregation 1163 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1164 2006, . 1166 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 1167 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 1168 Access Networks", RFC 4779, DOI 10.17487/RFC4779, January 1169 2007, . 1171 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1172 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1173 DOI 10.17487/RFC4861, September 2007, 1174 . 1176 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1177 Address Autoconfiguration", RFC 4862, 1178 DOI 10.17487/RFC4862, September 2007, 1179 . 1181 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1182 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1183 . 1185 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1186 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1187 . 1189 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1190 "Network Time Protocol Version 4: Protocol and Algorithms 1191 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1192 . 1194 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 1195 Server Option for DHCPv6", RFC 5908, DOI 10.17487/RFC5908, 1196 June 2010, . 1198 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1199 Model: The Relationship between Links and Subnet 1200 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1201 . 1203 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1204 Infrastructures (6rd) -- Protocol Specification", 1205 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1206 . 1208 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1209 Capabilities in Customer Premises Equipment (CPE) for 1210 Providing Residential IPv6 Internet Service", RFC 6092, 1211 DOI 10.17487/RFC6092, January 2011, 1212 . 1214 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1215 "IPv6 Router Advertisement Options for DNS Configuration", 1216 RFC 6106, DOI 10.17487/RFC6106, November 2010, 1217 . 1219 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1220 Assignment to End Sites", BCP 157, RFC 6177, 1221 DOI 10.17487/RFC6177, March 2011, 1222 . 1224 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1225 Stack Lite Broadband Deployments Following IPv4 1226 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1227 . 1229 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1230 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 1231 RFC 6334, DOI 10.17487/RFC6334, August 2011, 1232 . 1234 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1235 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1236 2011, . 1238 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 1239 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 1240 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 1241 . 1243 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1244 Combination of Stateful and Stateless Translation", 1245 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1246 . 1248 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1249 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1250 DOI 10.17487/RFC6887, April 2013, 1251 . 1253 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1254 the IPv6 Prefix Used for IPv6 Address Synthesis", 1255 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1256 . 1258 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 1259 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 1260 2013, . 1262 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1263 Port Control Protocol (PCP)", RFC 7225, 1264 DOI 10.17487/RFC7225, May 2014, 1265 . 1267 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1268 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 1269 RFC 7341, DOI 10.17487/RFC7341, August 2014, 1270 . 1272 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1273 Farrer, "Lightweight 4over6: An Extension to the Dual- 1274 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1275 July 2015, . 1277 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1278 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1279 Port with Encapsulation (MAP-E)", RFC 7597, 1280 DOI 10.17487/RFC7597, July 2015, 1281 . 1283 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 1284 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 1285 Configuration of Softwire Address and Port-Mapped 1286 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 1287 . 1289 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1290 and T. Murakami, "Mapping of Address and Port using 1291 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1292 2015, . 1294 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1295 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1296 2016, . 1298 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 1299 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based 1300 Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, 1301 November 2016, . 1303 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1304 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1305 over an IPv6 Multicast Network", RFC 8114, 1306 DOI 10.17487/RFC8114, March 2017, 1307 . 1309 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 1310 Option for IPv4-Embedded Multicast and Unicast IPv6 1311 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 1312 . 1314 10.2. Informative References 1316 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1317 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1318 April 2011, . 1320 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 1321 and D. Wing, "IPv6 Multihoming without Network Address 1322 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 1323 . 1325 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 1326 Recommendations with Multiple Stateful DHCPv6 Options", 1327 RFC 7550, DOI 10.17487/RFC7550, May 2015, 1328 . 1330 [TR-069] Broadband Forum, "CPE WAN Management Protocol", TR-069 1331 Amendment 4, July 2011, 1332 . 1334 [UPnP-IGD] 1335 UPnP Forum, , "InternetGatewayDevice:2 Device Template 1336 Version 1.01", December 2010, 1337 . 1339 Author's Address 1341 Jordi Palet Martinez 1342 Consulintel, S.L. 1343 Molino de la Navata, 75 1344 La Navata - Galapagar, Madrid 28420 1345 Spain 1347 EMail: jordi.palet@consulintel.es 1348 URI: http://www.consulintel.es/