idnits 2.17.1 draft-palet-v6ops-rfc7084-bis4-hncp-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.) ** 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 10, 2017) is 2510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TR-069' is defined on line 850, 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: 9 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) June 10, 2017 5 Intended status: Informational 6 Expires: December 12, 2017 8 Basic Requirements for IPv6 Customer Edge Routers with HNCP 9 draft-palet-v6ops-rfc7084-bis4-hncp-00 11 Abstract 13 This document specifies minimum requirements for an IPv6 Customer 14 Edge (CE) router. Specifically, the current version of this document 15 focuses on the basic provisioning of an IPv6 CE router and the 16 provisioning of IPv6 hosts attached to it. Includes support of HNCP 17 ([RFC7788]) for automated provisioning of downstream routers. The 18 document obsoletes RFC 7084. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 12, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Current IPv4 End-User Network Architecture . . . . . . . 4 59 3.2. IPv6 End-User Network Architecture . . . . . . . . . . . 4 60 3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6 61 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. General Requirements . . . . . . . . . . . . . . . . . . 6 63 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . 7 64 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . 11 65 4.4. Security Considerations . . . . . . . . . . . . . . . . . 13 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. ANNEX A: Changes from RFC7084 . . . . . . . . . . . . . . . . 14 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 8.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 74 1. Introduction 76 This document defines basic IPv6 features for a residential or small- 77 office router, referred to as an "IPv6 CE router", in order to 78 establish an industry baseline for features to be implemented on such 79 a router. 81 These routers typically also support IPv4, at least in the LAN side. 83 This document specifies how an IPv6 CE router automatically 84 provisions its WAN interface, acquires address space for provisioning 85 of its LAN interfaces, and fetches other configuration information 86 from the service provider network. Automatic provisioning of more 87 complex topology than a single router with multiple LAN interfaces 88 may be handled by means of HNCP ([RFC7788]). 90 This document doesn't cover the specific details of each possible 91 access technology. For example, if the CE is supporting built-in or 92 external 3GPP/LTE interfaces, [RFC7849] is a relevant reference. See 93 [RFC4779] for a discussion of options available for deploying IPv6 in 94 wireline service provider access networks. 96 1.1. Requirements Language 98 Take careful note: Unlike other IETF documents, the key words "MUST", 99 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 100 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 101 described in RFC 2119 [RFC2119]. This document uses these keywords 102 not strictly for the purpose of interoperability, but rather for the 103 purpose of establishing industry-common baseline functionality. As 104 such, the document points to several other specifications (preferable 105 in RFC or stable form) to provide additional guidance to implementers 106 regarding any protocol implementation required to produce a 107 successful IPv6 CE router that interoperates successfully with a 108 particular subset of currently deploying and planned common IPv6 109 access networks. 111 2. Terminology 113 End-User Network one or more links attached to the IPv6 CE 114 router that connect IPv6 hosts. 116 IPv6 Customer Edge Router a node intended for home or small-office 117 use that forwards IPv6 packets not 118 explicitly addressed to itself. The IPv6 119 CE router connects the end-user network to 120 a service provider network. In other 121 documents, the CE is named as CPE (Customer 122 Premises Equipment or Customer Provided 123 Equipment). In the context of this 124 document, both terminologies are 125 synonymous. 127 IPv6 Host any device implementing an IPv6 stack 128 receiving IPv6 connectivity through the 129 IPv6 CE router. 131 LAN Interface an IPv6 CE router's attachment to a link in 132 the end-user network. Examples are 133 Ethernet (simple or bridged), 802.11 134 wireless, or other LAN technologies. An 135 IPv6 CE router may have one or more 136 network-layer LAN interfaces. 138 Service Provider an entity that provides access to the 139 Internet. In this document, a service 140 provider specifically offers Internet 141 access using IPv6-only, and it may also 142 offer IPv4 Internet access, but non 143 intended to be supported by this IPv6 CE 144 router. The service provider can provide 145 such access over a variety of different 146 transport methods such as FTTH, DSL, cable, 147 wireless, 3GPP/LTE, and others. 149 WAN Interface an IPv6 CE router's attachment to a link 150 used to provide connectivity to the service 151 provider network; example link technologies 152 include Ethernet (simple or bridged), PPP 153 links, Frame Relay, or ATM networks. 155 3. Architecture 157 3.1. Current IPv4 End-User Network Architecture 159 An end-user network will likely support both IPv4 and IPv6. It is 160 not expected that an end user will change their existing network 161 topology with the introduction of IPv6. There are some differences 162 in how IPv6 works and is provisioned; these differences have 163 implications for the network architecture. A typical IPv4 end-user 164 network consists of a "plug and play" router with NAT functionality 165 and a single link behind it, connected to the service provider 166 network. 168 A typical IPv4 NAT deployment by default blocks all incoming 169 connections. Opening of ports is typically allowed using a Universal 170 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 171 other firewall control protocol. 173 Another consequence of using private address space in the end-user 174 network is that it provides stable addressing; that is, it never 175 changes even when you change service providers, and the addresses are 176 always there even when the WAN interface is down or the customer edge 177 router has not yet been provisioned. 179 Many existing routers support dynamic routing (which learns routes 180 from other routers), and advanced end-users can build arbitrary, 181 complex networks using manual configuration of address prefixes 182 combined with a dynamic routing protocol. 184 3.2. IPv6 End-User Network Architecture 186 The end-user network architecture for a simple IPv6-only network 187 should provide equivalent or better capabilities and functionality 188 than the current IPv4 architecture. 190 The end-user network is a stub network, in the sense that is not 191 providing transit to other external networks. However HNCP 192 ([RFC7788]) allows supporting automatic provisioning of downstream 193 routers. Figure 1 illustrates the model topology for the end-user 194 network. 196 +-------+-------+ \ 197 | Service | \ 198 | Provider | | Service 199 | Router | | Provider 200 +-------+-------+ | Network 201 | / 202 | Customer / 203 | Internet Connection / 204 | 205 +------+--------+ \ 206 | IPv6 | \ 207 | Customer Edge | \ 208 | Router | / 209 +---+-------+-+-+ / 210 Network A | | Network B | End-User 211 ---+-------------+----+- --+--+-------------+--- | Network(s) 212 | | | | \ 213 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 214 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 215 | | | | | | | | / 216 +----------+ +-----+----+ +----------+ +----------+ / 218 Figure 1: An Example of a Typical End-User Network 220 This architecture describes the: 222 o Basic capabilities of an IPv6 CE router 224 o Provisioning of the WAN interface connecting to the service 225 provider 227 o Provisioning of the LAN interfaces 229 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 230 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 231 multicast routing protocol. 233 The IPv6 CE router may be manually configured in an arbitrary 234 topology with a dynamic routing protocol or using HNCP ([RFC7788]). 235 Automatic provisioning and configuration is described for a single 236 IPv6 CE router only. 238 3.2.1. Local Communication 240 Link-local IPv6 addresses are used by hosts communicating on a single 241 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 242 by hosts communicating within the end-user network across multiple 243 links, but without requiring the application to use a globally 244 routable address. The IPv6 CE router defaults to acting as the 245 demarcation point between two networks by providing a ULA boundary, a 246 multicast zone boundary, and ingress and egress traffic filters. 248 At the time of this writing, several host implementations do not 249 handle the case where they have an IPv6 address configured and no 250 IPv6 connectivity, either because the address itself has a limited 251 topological reachability (e.g., ULA) or because the IPv6 CE router is 252 not connected to the IPv6 network on its WAN interface. To support 253 host implementations that do not handle multihoming in a multi-prefix 254 environment [RFC7157], the IPv6 CE router should not, as detailed in 255 the requirements below, advertise itself as a default router on the 256 LAN interface(s) when it does not have IPv6 connectivity on the WAN 257 interface or when it is not provisioned with IPv6 addresses. For 258 local IPv6 communication, the mechanisms specified in [RFC4191] are 259 used. 261 ULA addressing is useful where the IPv6 CE router has multiple LAN 262 interfaces with hosts that need to communicate with each other. If 263 the IPv6 CE router has only a single LAN interface (IPv6 link), then 264 link-local addressing can be used instead. 266 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 267 conform to these recommendations, especially requirements ULA-5 and 268 L-4 below. 270 4. Requirements 272 4.1. General Requirements 274 The IPv6 CE router is responsible for implementing IPv6 routing; that 275 is, the IPv6 CE router must look up the IPv6 destination address in 276 its routing table to decide to which interface it should send the 277 packet. 279 In this role, the IPv6 CE router is responsible for ensuring that 280 traffic using its ULA addressing does not go out the WAN interface 281 and does not originate from the WAN interface. 283 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 284 Requirements specification [RFC6434]. 286 G-2: The IPv6 CE router MUST implement ICMPv6 according to 287 [RFC4443]. In particular, point-to-point links MUST be handled 288 as described in Section 3.1 of [RFC4443]. 290 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 291 its LAN interface(s) and its WAN interface until the router has 292 successfully completed the IPv6 address and the delegated 293 prefix acquisition process. 295 G-4: By default, an IPv6 CE router that has no default router(s) on 296 its WAN interface MUST NOT advertise itself as an IPv6 default 297 router on its LAN interfaces. That is, the "Router Lifetime" 298 field is set to zero in all Router Advertisement messages it 299 originates [RFC4861]. 301 G-5: By default, if the IPv6 CE router is an advertising router and 302 loses its IPv6 default router(s) and/or detects loss of 303 connectivity on the WAN interface, it MUST explicitly 304 invalidate itself as an IPv6 default router on each of its 305 advertising interfaces by immediately transmitting one or more 306 Router Advertisement messages with the "Router Lifetime" field 307 set to zero [RFC4861]. 309 G-6: The IPv6 CE router MUST comply with [RFC7608]. 311 4.2. WAN-Side Configuration 313 The IPv6 CE router will need to support connectivity to one or more 314 access network architectures. This document describes an IPv6 CE 315 router that is not specific to any particular architecture or service 316 provider and that supports all commonly used architectures. 318 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 319 IPv6-supported link layer, and there is no need for a link-layer- 320 specific configuration protocol for IPv6 network-layer configuration 321 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 322 section makes the assumption that the same mechanism will work for 323 any link layer, be it Ethernet, the Data Over Cable Service Interface 324 Specification (DOCSIS), PPP, or others. 326 WAN-side requirements: 328 W-1: When the IPv6 CE router is attached to the WAN interface link, 329 it MUST act as an IPv6 host for the purposes of stateless 330 [RFC4862] or stateful [RFC3315] interface address assignment. 332 W-2: The IPv6 CE router MUST generate a link-local address and 333 finish Duplicate Address Detection according to [RFC4862] prior 334 to sending any Router Solicitations on the interface. The 335 source address used in the subsequent Router Solicitation MUST 336 be the link-local address on the WAN interface. 338 W-3: Absent other routing information, the IPv6 CE router MUST use 339 Router Discovery as specified in [RFC4861] to discover a 340 default router(s) and install a default route(s) in its routing 341 table with the discovered router's address as the next hop. 343 W-4: The IPv6 CE router MUST act as a requesting router for the 344 purposes of DHCPv6 prefix delegation ([RFC3633]). 346 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 347 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 348 network-interface resets or IPv6 CE router reboots. 350 W-6: The WAN interface of the IPv6 CE router SHOULD support a Port 351 Control Protocol (PCP) client as specified in [RFC6887] for use 352 by applications on the IPv6 CE router. The PCP client SHOULD 353 follow the procedure specified in Section 8.1 of [RFC6887] to 354 discover its PCP server. This document takes no position on 355 whether such functionality is enabled by default or mechanisms 356 by which users would configure the functionality. Handling PCP 357 requests from PCP clients in the LAN side of the IPv6 CE router 358 is out of scope. 360 Link-layer requirements: 362 WLL-1: If the WAN interface supports Ethernet encapsulation, then 363 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 365 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 366 router MUST support IPv6 over PPP [RFC5072]. 368 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 369 stack environment with IPCP and IPV6CP running over one PPP 370 logical channel, the Network Control Protocols (NCPs) MUST be 371 treated as independent of each other and start and terminate 372 independently. 374 Address assignment requirements: 376 WAA-1: The IPv6 CE router MUST support Stateless Address 377 Autoconfiguration (SLAAC) [RFC4862]. 379 WAA-2: The IPv6 CE router MUST follow the recommendations in 380 Section 4 of [RFC5942], and in particular the handling of 381 the L flag in the Router Advertisement Prefix Information 382 option. 384 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 385 behavior. 387 WAA-4: The IPv6 CE router MUST be able to support the following 388 DHCPv6 options: Identity Association for Non-temporary 389 Address (IA_NA), Reconfigure Accept [RFC3315], and 390 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 391 support the DNS Search List (DNSSL) option as specified in 392 [RFC3646]. 394 WAA-5: The IPv6 CE router SHOULD implement the Network Time 395 Protocol (NTP) as specified in [RFC5905] to provide a time 396 reference common to the service provider for other 397 protocols, such as DHCPv6, to use. If the IPv6 CE router 398 implements NTP, it requests the NTP Server DHCPv6 option 399 [RFC5908] and uses the received list of servers as primary 400 time reference, unless explicitly configured otherwise. LAN 401 side support of NTP is out of scope for this document. 403 WAA-6: If the IPv6 CE router receives a Router Advertisement 404 message (described in [RFC4861]) with the M flag set to 1, 405 the IPv6 CE router MUST do DHCPv6 address assignment 406 (request an IA_NA option). 408 WAA-7: If the IPv6 CE router does not acquire a global IPv6 409 address(es) from either SLAAC or DHCPv6, then it MUST create 410 a global IPv6 address(es) from its delegated prefix(es) and 411 configure those on one of its internal virtual network 412 interfaces, unless configured to require a global IPv6 413 address on the WAN interface. 415 WAA-8: The IPv6 CE router MUST support the SOL_MAX_RT option 416 [RFC7083] and request the SOL_MAX_RT option in an Option 417 Request Option (ORO). 419 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 420 (Weak End System) model [RFC1122]. When originating packets 421 from an interface, it will use a source address from another 422 one of its interfaces if the outgoing interface does not 423 have an address of suitable scope. 425 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 426 Time option and associated client behavior as specified in 427 [RFC4242]. 429 Prefix delegation requirements: 431 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 432 requesting router behavior as specified in [RFC3633] 433 (Identity Association for Prefix Delegation (IA_PD) option). 435 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 436 router the size of the prefix it requires. If so, it MUST 437 ask for a prefix large enough to assign one /64 for each of 438 its interfaces, rounded up to the nearest nibble, and SHOULD 439 be configurable to ask for more. 441 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 442 prefix size different from what is given in the hint. If the 443 delegated prefix is too small to address all of its 444 interfaces, the IPv6 CE router SHOULD log a system management 445 error. [RFC6177] covers the recommendations for service 446 providers for prefix allocation sizes. 448 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 449 delegation when either the M or O flags are set to 1 in a 450 received Router Advertisement (RA) message. Behavior of the 451 IPv6 CE router to use DHCPv6 prefix delegation when the IPv6 452 CE router has not received any RA or received an RA with the 453 M and the O bits set to zero is out of scope for this 454 document. 456 WPD-5: Any packet received by the IPv6 CE router with a destination 457 address in the prefix(es) delegated to the IPv6 CE router but 458 not in the set of prefixes assigned by the IPv6 CE router to 459 the LAN must be dropped. In other words, the next hop for 460 the prefix(es) delegated to the IPv6 CE router should be the 461 null destination. This is necessary to prevent forwarding 462 loops when some addresses covered by the aggregate are not 463 reachable [RFC4632]. 465 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 466 Unreachable message in accordance with Section 3.1 of 467 [RFC4443] back to the source of the packet, if the 468 packet is to be dropped due to this rule. 470 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 471 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 472 Advertise/Reply messages, even if the message does not 473 contain any addresses, unless configured to only obtain its 474 WAN IPv6 address via DHCPv6; see [RFC7550]. 476 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 477 routing protocol on its WAN interface. 479 WPD-8: The IPv6 CE router SHOULD support the [RFC6603] Prefix 480 Exclude option. 482 4.3. LAN-Side Configuration 484 The IPv6 CE router distributes configuration information obtained 485 during WAN interface provisioning to IPv6 hosts and assists IPv6 486 hosts in obtaining IPv6 addresses. It also supports connectivity of 487 these devices in the absence of any working WAN interface. 489 An IPv6 CE router is expected to support an IPv6 end-user network and 490 IPv6 hosts that exhibit the following characteristics: 492 1. Link-local addresses may be insufficient for allowing IPv6 493 applications to communicate with each other in the end-user 494 network. The IPv6 CE router will need to enable this 495 communication by providing globally scoped unicast addresses or 496 ULAs [RFC4193], whether or not WAN connectivity exists. 498 2. IPv6 hosts should be capable of using SLAAC and may be capable of 499 using DHCPv6 for acquiring their addresses. 501 3. IPv6 hosts may use DHCPv6 for other configuration information, 502 such as the DNS_SERVERS option for acquiring DNS information. 504 Unless otherwise specified, the following requirements apply to the 505 IPv6 CE router's LAN interfaces only. 507 ULA requirements: 509 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 510 prefix [RFC4193]. 512 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 513 consistently across reboots. 515 ULA-3: The value of the ULA prefix SHOULD be configurable. 517 ULA-4: By default, the IPv6 CE router MUST act as a site border 518 router according to Section 4.3 of [RFC4193] and filter 519 packets with local IPv6 source or destination addresses 520 accordingly. 522 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 523 router with a Router Lifetime greater than zero whenever all 524 of its configured and delegated prefixes are ULA prefixes. 526 LAN requirements: 528 L-1: The IPv6 CE router MUST support router behavior according to 529 Neighbor Discovery for IPv6 [RFC4861]. 531 L-2: The IPv6 CE router MUST assign a separate /64 from its 532 delegated prefix(es) (and ULA prefix if configured to provide 533 ULA addressing) for each of its LAN interfaces. 535 L-3: An IPv6 CE router MUST advertise itself as a router for the 536 delegated prefix(es) (and ULA prefix if configured to provide 537 ULA addressing) using the "Route Information Option" specified 538 in Section 2.3 of [RFC4191]. This advertisement is 539 independent of having or not having IPv6 connectivity on the 540 WAN interface. 542 L-4: An IPv6 CE router MUST NOT advertise itself as a default 543 router with a Router Lifetime [RFC4861] greater than zero if 544 it has no prefixes configured or delegated to it. 546 L-5: The IPv6 CE router MUST make each LAN interface an advertising 547 interface according to [RFC4861]. 549 L-6: In Router Advertisement messages ([RFC4861]), the Prefix 550 Information option's A and L flags MUST be set to 1 by 551 default. 553 L-7: The A and L flags' ([RFC4861]) settings SHOULD be user 554 configurable. 556 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 557 IPv6 address assignment according to [RFC3315] OR a stateless 558 DHCPv6 server according to [RFC3736] on its LAN interfaces. 560 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 561 IA_NA option, it SHOULD set the M flag to zero and the O flag 562 to 1 in its Router Advertisement messages [RFC4861]. 564 L-10: The IPv6 CE router MUST support providing DNS information in 565 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 567 L-11: The IPv6 CE router MUST support providing DNS information in 568 the Router Advertisement Recursive DNS Server (RDNSS) and DNS 569 Search List options. Both options are specified in [RFC6106]. 571 L-12: The IPv6 CE router SHOULD implement a DNS proxy as described 572 in [RFC5625]. 574 L-13: The IPv6 CE router SHOULD make available a subset of DHCPv6 575 options (as listed in Section 5.3 of [RFC3736]) received from 576 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 577 server. 579 L-14: If the delegated prefix changes, i.e., the current prefix is 580 replaced with a new prefix without any overlapping time 581 period, then the IPv6 CE router MUST immediately advertise the 582 old prefix with a Preferred Lifetime of zero and a Valid 583 Lifetime of either a) zero or b) the lower of the current 584 Valid Lifetime and two hours (which must be decremented in 585 real time) in a Router Advertisement message as described in 586 Section 5.5.3, (e) of [RFC4862]. 588 L-15: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 589 message, code 5 (Source address failed ingress/egress policy) 590 for packets forwarded to it that use an address from a prefix 591 that has been invalidated. 593 L-16: The IPv6 CE router SHOULD provide HNCP (Home Networking 594 Control Protocol) services, as specified in [RFC7788]. 596 4.4. Security Considerations 598 It is considered a best practice to filter obviously malicious 599 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 600 the IPv6 CE router ought to support basic stateless egress and 601 ingress filters. The IPv6 CE router is also expected to offer 602 mechanisms to filter traffic entering the customer network; however, 603 the method by which vendors implement configurable packet filtering 604 is beyond the scope of this document. 606 Security requirements: 608 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 609 the IPv6 CE router SHOULD support functionality sufficient for 610 implementing the set of recommendations in [RFC6092], 611 Section 4. This document takes no position on whether such 612 functionality is enabled by default or mechanisms by which 613 users would configure it. 615 S-2: The IPv6 CE router SHOULD support ingress filtering in 616 accordance with BCP 38 [RFC2827]. Note that this requirement 617 was downgraded from a MUST from RFC 6204 due to the difficulty 618 of implementation in the IPv6 CE router and the feature's 619 redundancy with upstream router ingress filtering. 621 S-3: If the IPv6 CE router firewall is configured to filter incoming 622 tunneled data, the firewall SHOULD provide the capability to 623 filter decapsulated packets from a tunnel. 625 5. Acknowledgements 627 This document is an update of RFC7084, whose original authors were: 628 Hemant Singh, Wes Beebee, Chris Donley and Barbara Stark. The rest 629 of the text on this section and the Contributors section, are the 630 original acknowledgements and Contributors sections of the earlier 631 version of this document. 633 Thanks to the following people (in alphabetical order) for their 634 guidance and feedback: 636 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 637 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 638 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 639 Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas 640 Herbst, Ray Hunter, Joel Jaeggli, Kevin Johns, Erik Kline, Stephen 641 Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, 642 David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, 643 Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen, 644 Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark 645 Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James 646 Woodyatt, Carl Wuyts, and Cor Zwart. 648 This document is based in part on CableLabs' eRouter specification. 649 The authors wish to acknowledge the additional contributors from the 650 eRouter team: 652 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 653 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 654 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 655 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 656 Torbet, and Greg White. 658 6. Contributors 660 The following people have participated as co-authors or provided 661 substantial contributions to this document: Ralph Droms, Kirk 662 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 663 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole 664 Troan for editorship in the original RFC 6204 document. 666 7. ANNEX A: Changes from RFC7084 668 The -bis-4-hncp version of this document has some minor text edits 669 here and there. Significant updates are: 671 1. G-6 added in order to comply with [RFC7608]. 673 2. L-12 added to support for DNS proxy [RFC5625] as general LAN 674 requirement. 676 3. Added support of HNCP ([RFC7788]) in LAN (L-16). 678 4. Removed transition support. 680 8. References 682 8.1. Normative References 684 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 685 Communication Layers", STD 3, RFC 1122, 686 DOI 10.17487/RFC1122, October 1989, 687 . 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 695 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 696 . 698 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 699 Defeating Denial of Service Attacks which employ IP Source 700 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 701 May 2000, . 703 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 704 C., and M. Carney, "Dynamic Host Configuration Protocol 705 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 706 2003, . 708 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 709 Host Configuration Protocol (DHCP) version 6", RFC 3633, 710 DOI 10.17487/RFC3633, December 2003, 711 . 713 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 714 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 715 DOI 10.17487/RFC3646, December 2003, 716 . 718 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 719 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 720 April 2004, . 722 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 723 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 724 November 2005, . 726 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 727 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 728 . 730 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 731 Time Option for Dynamic Host Configuration Protocol for 732 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 733 2005, . 735 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 736 Control Message Protocol (ICMPv6) for the Internet 737 Protocol Version 6 (IPv6) Specification", RFC 4443, 738 DOI 10.17487/RFC4443, March 2006, 739 . 741 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 742 "Internet Group Management Protocol (IGMP) / Multicast 743 Listener Discovery (MLD)-Based Multicast Forwarding 744 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 745 August 2006, . 747 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 748 (CIDR): The Internet Address Assignment and Aggregation 749 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 750 2006, . 752 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 753 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 754 Access Networks", RFC 4779, DOI 10.17487/RFC4779, January 755 2007, . 757 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 758 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 759 DOI 10.17487/RFC4861, September 2007, 760 . 762 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 763 Address Autoconfiguration", RFC 4862, 764 DOI 10.17487/RFC4862, September 2007, 765 . 767 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 768 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 769 . 771 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 772 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 773 . 775 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 776 "Network Time Protocol Version 4: Protocol and Algorithms 777 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 778 . 780 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 781 Server Option for DHCPv6", RFC 5908, DOI 10.17487/RFC5908, 782 June 2010, . 784 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 785 Model: The Relationship between Links and Subnet 786 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 787 . 789 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 790 Capabilities in Customer Premises Equipment (CPE) for 791 Providing Residential IPv6 Internet Service", RFC 6092, 792 DOI 10.17487/RFC6092, January 2011, 793 . 795 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 796 "IPv6 Router Advertisement Options for DNS Configuration", 797 RFC 6106, DOI 10.17487/RFC6106, November 2010, 798 . 800 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 801 Assignment to End Sites", BCP 157, RFC 6177, 802 DOI 10.17487/RFC6177, March 2011, 803 . 805 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 806 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 807 2011, . 809 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 810 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 811 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 812 . 814 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 815 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 816 DOI 10.17487/RFC6887, April 2013, 817 . 819 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 820 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 821 2013, . 823 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 824 Length Recommendation for Forwarding", BCP 198, RFC 7608, 825 DOI 10.17487/RFC7608, July 2015, 826 . 828 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 829 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 830 2016, . 832 8.2. Informative References 834 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 835 and D. Wing, "IPv6 Multihoming without Network Address 836 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 837 . 839 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 840 Recommendations with Multiple Stateful DHCPv6 Options", 841 RFC 7550, DOI 10.17487/RFC7550, May 2015, 842 . 844 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 845 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 846 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, 847 DOI 10.17487/RFC7849, May 2016, 848 . 850 [TR-069] Broadband Forum, "CPE WAN Management Protocol", TR-069 851 Amendment 4, July 2011, 852 . 854 [UPnP-IGD] 855 UPnP Forum, "InternetGatewayDevice:2 Device Template 856 Version 1.01", December 2010, 857 . 859 Author's Address 860 Jordi Palet Martinez 861 Consulintel, S.L. 862 Molino de la Navata, 75 863 La Navata - Galapagar, Madrid 28420 864 Spain 866 EMail: jordi.palet@consulintel.es 867 URI: http://www.consulintel.es/