idnits 2.17.1 draft-ietf-v6ops-6204bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2012) is 4224 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3704' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC4864' is defined on line 833, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-27 ** 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) == Outdated reference: A later version (-12) exists of draft-ietf-dhc-dhcpv6-stateful-issues-00 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Singh 3 Internet-Draft W. Beebee 4 Obsoletes: 6204 (if approved) Cisco Systems, Inc. 5 Intended status: Informational C. Donley 6 Expires: March 29, 2013 CableLabs 7 B. Stark 8 AT&T 9 September 25, 2012 11 Basic Requirements for IPv6 Customer Edge Routers 12 draft-ietf-v6ops-6204bis-11 14 Abstract 16 This document specifies requirements for an IPv6 Customer Edge (CE) 17 router. Specifically, the current version of this document focuses 18 on the basic provisioning of an IPv6 CE router and the provisioning 19 of IPv6 hosts attached to it. The document also covers IP transition 20 technologies. Two transition technologies in RFC 5969's 6rd and RFC 21 6333's DS-Lite are covered in the document. The document obsoletes 22 RFC 6204, if approved. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 29, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4 63 3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5 64 3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 67 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 8 68 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 12 69 4.4. Transition Technologies Support . . . . . . . . . . . . . 14 70 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 15 72 4.5. Security Considerations . . . . . . . . . . . . . . . . . 16 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 79 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 This document defines basic IPv6 features for a residential or small- 85 office router, referred to as an IPv6 CE router. Typically, these 86 routers also support IPv4. 88 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 89 the CE router) can be more complex if the IPv6-only devices are using 90 a translator to access IPv4 servers [RFC6144]. Support for such 91 mixed environments is not in scope of this document. 93 This document specifies how an IPv6 CE router automatically 94 provisions its WAN interface, acquires address space for provisioning 95 of its LAN interfaces, and fetches other configuration information 96 from the service provider network. Automatic provisioning of more 97 complex topology than a single router with multiple LAN interfaces is 98 out of scope for this document. 100 See [RFC4779] for a discussion of options available for deploying 101 IPv6 in service provider access networks. 103 The document also covers the IP transition technologies that were 104 available at the time this document was written. Two transition 105 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in 106 the document. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 Even though this document has Informational status, it specifies 115 requirements using RFC 2119 language, but not strictly for the 116 purpose of interoperability. Some requirements are intentionally 117 specified for the purpose of establishing industry-common baseline 118 functionality. As such, the document points to several other 119 specifications (preferable in RFC or stable form) to provide 120 additional guidance to implementers regarding any protocol 121 implementation required to produce a successful CPE router that 122 interoperates successfully with a particular subset of currently 123 deploying and planned common IPv6 access networks. 125 2. Terminology 126 End-User Network one or more links attached to the IPv6 CE 127 router that connect IPv6 hosts. 129 IPv6 Customer Edge Router a node intended for home or small-office 130 use that forwards IPv6 packets not 131 explicitly addressed to itself. The IPv6 132 CE router connects the end-user network to 133 a service provider network. 135 IPv6 Host any device implementing an IPv6 stack 136 receiving IPv6 connectivity through the 137 IPv6 CE router. 139 LAN Interface an IPv6 CE router's attachment to a link in 140 the end-user network. Examples are 141 Ethernet (simple or bridged), 802.11 142 wireless, or other LAN technologies. An 143 IPv6 CE router may have one or more 144 network-layer LAN interfaces. 146 Service Provider an entity that provides access to the 147 Internet. In this document, a service 148 provider specifically offers Internet 149 access using IPv6, and may also offer IPv4 150 Internet access. The service provider can 151 provide such access over a variety of 152 different transport methods such as DSL, 153 cable, wireless, and others. 155 WAN Interface an IPv6 CE router's attachment to a link 156 used to provide connectivity to the service 157 provider network; example link technologies 158 include Ethernet (simple or bridged), PPP 159 links, Frame Relay, or ATM networks, as 160 well as Internet-layer (or higher-layer) 161 "tunnels", such as tunnels over IPv4 or 162 IPv6 itself. 164 3. Architecture 166 3.1. Current IPv4 End-User Network Architecture 168 An end-user network will likely support both IPv4 and IPv6. It is 169 not expected that an end-user will change their existing network 170 topology with the introduction of IPv6. There are some differences 171 in how IPv6 works and is provisioned; these differences have 172 implications for the network architecture. A typical IPv4 end-user 173 network consists of a "plug and play" router with NAT functionality 174 and a single link behind it, connected to the service provider 175 network. 177 A typical IPv4 NAT deployment by default blocks all incoming 178 connections. Opening of ports is typically allowed using a Universal 179 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 180 other firewall control protocol. 182 Another consequence of using private address space in the end-user 183 network is that it provides stable addressing; i.e., it never changes 184 even when you change service providers, and the addresses are always 185 there even when the WAN interface is down or the customer edge router 186 has not yet been provisioned. 188 Many existing routers support dynamic routing (which learns routes 189 from other routers), and advanced end-users can build arbitrary, 190 complex networks using manual configuration of address prefixes 191 combined with a dynamic routing protocol. 193 3.2. IPv6 End-User Network Architecture 195 The end-user network architecture for IPv6 should provide equivalent 196 or better capabilities and functionality than the current IPv4 197 architecture. 199 The end-user network is a stub network. Figure 1 illustrates the 200 model topology for the end-user network. 202 +-------+-------+ \ 203 | Service | \ 204 | Provider | | Service 205 | Router | | Provider 206 +-------+-------+ | network 207 | / 208 | Customer / 209 | Internet connection / 210 | 211 +------+--------+ \ 212 | IPv6 | \ 213 | Customer Edge | \ 214 | Router | / 215 +---+-------+-+-+ / 216 Network A | | Network B | End-User 217 ---+-------------+----+- --+--+-------------+--- | network(s) 218 | | | | \ 219 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 220 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 221 | | | | | | | | / 222 +----------+ +-----+----+ +----------+ +----------+ / 224 Figure 1: An Example of a Typical End-User Network 226 This architecture describes the: 228 o Basic capabilities of an IPv6 CE router 230 o Provisioning of the WAN interface connecting to the service 231 provider 233 o Provisioning of the LAN interfaces 235 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 236 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 237 multicast routing protocol. 239 The IPv6 CE router may be manually configured in an arbitrary 240 topology with a dynamic routing protocol. Automatic provisioning and 241 configuration are described for a single IPv6 CE router only. 243 3.2.1. Local Communication 245 Link-local IPv6 addresses are used by hosts communicating on a single 246 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 247 by hosts communicating within the end-user network across multiple 248 links, but without requiring the application to use a globally 249 routable address. The IPv6 CE router defaults to acting as the 250 demarcation point between two networks by providing a ULA boundary, a 251 multicast zone boundary, and ingress and egress traffic filters. 253 At the time of this writing, several host implementations do not 254 handle the case where they have an IPv6 address configured and no 255 IPv6 connectivity, either because the address itself has a limited 256 topological reachability (e.g., ULA) or because the IPv6 CE router is 257 not connected to the IPv6 network on its WAN interface. To support 258 host implementations that do not handle multihoming in a multi-prefix 259 environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 260 as detailed in the requirements below, advertise itself as a default 261 router on the LAN interface(s) when it does not have IPv6 262 connectivity on the WAN interface or when it is not provisioned with 263 IPv6 addresses. For local IPv6 communication, the mechanisms 264 specified in [RFC4191] are used. 266 ULA addressing is useful where the IPv6 CE router has multiple LAN 267 interfaces with hosts that need to communicate with each other. If 268 the IPv6 CE router has only a single LAN interface (IPv6 link), then 269 link-local addressing can be used instead. 271 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 272 conform to these recommendations, especially requirements ULA-5 and 273 L-4 below. 275 4. Requirements 277 4.1. General Requirements 279 The IPv6 CE router is responsible for implementing IPv6 routing; that 280 is, the IPv6 CE router must look up the IPv6 destination address in 281 its routing table to decide to which interface it should send the 282 packet. 284 In this role, the IPv6 CE router is responsible for ensuring that 285 traffic using its ULA addressing does not go out the WAN interface, 286 and does not originate from the WAN interface. 288 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 289 Requirements [RFC6434] specification. 291 G-2: The IPv6 CE router MUST implement ICMPv6 according to 292 [RFC4443]. In particular, point-to-point links MUST be handled 293 as described in Section 3.1 of [RFC4443]. 295 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 296 its LAN interface(s) and its WAN interface until the router has 297 successfully completed the IPv6 address and the delegated 298 prefix acquisition process. 300 G-4: By default, an IPv6 CE router that has no default router(s) on 301 its WAN interface MUST NOT advertise itself as an IPv6 default 302 router on its LAN interfaces. That is, the "Router Lifetime" 303 field is set to zero in all Router Advertisement messages it 304 originates [RFC4861]. 306 G-5: By default, if the IPv6 CE router is an advertising router and 307 loses its IPv6 default router(s) and/or detects loss of 308 connectivity on the WAN interface, it MUST explicitly 309 invalidate itself as an IPv6 default router on each of its 310 advertising interfaces by immediately transmitting one or more 311 Router Advertisement messages with the "Router Lifetime" field 312 set to zero [RFC4861]. 314 4.2. WAN-Side Configuration 316 The IPv6 CE router will need to support connectivity to one or more 317 access network architectures. This document describes an IPv6 CE 318 router that is not specific to any particular architecture or service 319 provider and that supports all commonly used architectures. 321 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 322 IPv6-supported link layer, and there is no need for a link-layer- 323 specific configuration protocol for IPv6 network-layer configuration 324 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 325 section makes the assumption that the same mechanism will work for 326 any link layer, be it Ethernet, the Data Over Cable Service Interface 327 Specification (DOCSIS), PPP, or others. 329 WAN-side requirements: 331 W-1: When the router is attached to the WAN interface link, it MUST 332 act as an IPv6 host for the purposes of stateless [RFC4862] or 333 stateful [RFC3315] interface address assignment. 335 W-2: The IPv6 CE router MUST generate a link-local address and 336 finish Duplicate Address Detection according to [RFC4862] prior 337 to sending any Router Solicitations on the interface. The 338 source address used in the subsequent Router Solicitation MUST 339 be the link-local address on the WAN interface. 341 W-3: Absent other routing information, the IPv6 CE router MUST use 342 Router Discovery as specified in [RFC4861] to discover a 343 default router(s) and install default route(s) in its routing 344 table with the discovered router's address as the next hop. 346 W-4: The router MUST act as a requesting router for the purposes of 347 DHCPv6 prefix delegation ([RFC3633]). 349 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 350 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 351 network interface resets or IPv6 CE router reboots. 353 W-6: The WAN interface of the CE router SHOULD support a PCP client 354 as specified in [I-D.ietf-pcp-base] for use by applications on 355 the CE Router. The PCP client SHOULD follow the procedure 356 specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its 357 PCP server. This document takes no position on whether such 358 functionality is enabled by default or mechanisms by which 359 users would configure the functionality. Handling PCP requests 360 from PCP clients in the LAN side of the CE Router is out of 361 scope. 363 Link-layer requirements: 365 WLL-1: If the WAN interface supports Ethernet encapsulation, then 366 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 368 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 369 router MUST support IPv6 over PPP [RFC5072]. 371 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 372 stack environment with IPCP and IPV6CP running over one PPP 373 logical channel, the Network Control Protocols (NCPs) MUST be 374 treated as independent of each other and start and terminate 375 independently. 377 Address assignment requirements: 379 WAA-1: The IPv6 CE router MUST support Stateless Address 380 Autoconfiguration (SLAAC) [RFC4862]. 382 WAA-2: The IPv6 CE router MUST follow the recommendations in 383 Section 4 of [RFC5942], and in particular the handling of 384 the L flag in the Router Advertisement Prefix Information 385 option. 387 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 388 behavior. 390 WAA-4: The IPv6 CE router MUST be able to support the following 391 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 392 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 393 support the DNS Search List DNSSL option as specified in 394 [RFC3646]. 396 WAA-5: The IPv6 CE router SHOULD implement the Network Time 397 Protocol (NTP) as specified in [RFC5905] to provide a time 398 reference common to the service provider for other 399 protocols, such as DHCPv6, to use. If the CE router 400 implements NTP, it requests the NTP Server DHCPv6 option 401 [RFC5908] and uses the received list of servers as primary 402 time reference, unless explicitly configured otherwise. LAN 403 side support of NTP is out of scope for this document. 405 WAA-6: If the IPv6 CE router receives a Router Advertisement 406 message (described in [RFC4861]) with the M flag set to 1, 407 the IPv6 CE router MUST do DHCPv6 address assignment 408 (request an IA_NA option). 410 WAA-7: If the IPv6 CE router does not acquire global IPv6 411 address(es) from either SLAAC or DHCPv6, then it MUST create 412 global IPv6 address(es) from its delegated prefix(es) and 413 configure those on one of its internal virtual network 414 interfaces, unless configured to require a global IPv6 415 address on the WAN interface. 417 WAA-8: The CE router must support the SOL_MAX_RT option 418 [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the 419 SOL_MAX_RT option in an ORO. 421 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 422 (Weak ES) model [RFC1122]. When originating packets from an 423 interface, it will use a source address from another one of 424 its interfaces if the outgoing interface does not have an 425 address of suitable scope. 427 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 428 Time option and associated client behavior as specified in 429 [RFC4242]. 431 Prefix delegation requirements: 433 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 434 requesting router behavior as specified in [RFC3633] (IA_PD 435 option). 437 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 438 router the size of the prefix it requires. If so, it MUST 439 ask for a prefix large enough to assign one /64 for each of 440 its interfaces, rounded up to the nearest nibble, and SHOULD 441 be configurable to ask for more. 443 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 444 prefix size different from what is given in the hint. If the 445 delegated prefix is too small to address all of its 446 interfaces, the IPv6 CE router SHOULD log a system management 447 error. [RFC6177] covers the recommendations for service 448 providers for prefix allocation sizes. 450 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 451 delegation when either the M or O flags are set to 1 in a 452 received Router Advertisement message. 454 WPD-5: If the delegated prefix(es) are aggregate route(s) of 455 multiple, more-specific routes, the IPv6 CE router MUST 456 discard packets that match the aggregate route(s), but not 457 any of the more-specific routes. In other words, the next 458 hop for the aggregate route(s) should be the null 459 destination. This is necessary to prevent forwarding loops 460 when some addresses covered by the aggregate are not 461 reachable [RFC4632]. 463 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 464 Unreachable message in accordance with Section 3.1 of 465 [RFC4443] back to the source of the packet, if the 466 packet is to be dropped due to this rule. 468 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 469 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 470 Advertise/Reply messages, even if the message does not 471 contain any addresses, unless configured to only obtain its 472 WAN IPv6 address via DHCPv6. See 473 [I-D.ietf-dhc-dhcpv6-stateful-issues] 475 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 476 routing protocol on its WAN interface. 478 WPD-8: The IPv6 CE Router SHOULD support the 479 [I-D.ietf-dhc-pd-exclude] PD-Exclude option. 481 4.3. LAN-Side Configuration 483 The IPv6 CE router distributes configuration information obtained 484 during WAN interface provisioning to IPv6 hosts and assists IPv6 485 hosts in obtaining IPv6 addresses. It also supports connectivity of 486 these devices in the absence of any working WAN interface. 488 An IPv6 CE router is expected to support an IPv6 end-user network and 489 IPv6 hosts that exhibit the following characteristics: 491 1. Link-local addresses may be insufficient for allowing IPv6 492 applications to communicate with each other in the end-user 493 network. The IPv6 CE router will need to enable this 494 communication by providing globally scoped unicast addresses or 495 ULAs [RFC4193], whether or not WAN connectivity exists. 497 2. IPv6 hosts should be capable of using SLAAC and may be capable of 498 using DHCPv6 for acquiring their addresses. 500 3. IPv6 hosts may use DHCPv6 for other configuration information, 501 such as the DNS_SERVERS option for acquiring DNS information. 503 Unless otherwise specified, the following requirements apply to the 504 IPv6 CE router's LAN interfaces only. 506 ULA requirements: 508 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 509 prefix [RFC4193]. 511 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 512 consistently across reboots. 514 ULA-3: The value of the ULA prefix SHOULD be configurable. 516 ULA-4: By default, the IPv6 CE router MUST act as a site border 517 router according to Section 4.3 of [RFC4193] and filter 518 packets with local IPv6 source or destination addresses 519 accordingly. 521 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 522 router with a Router Lifetime greater than zero whenever all 523 of its configured and delegated prefixes are ULA prefixes. 525 LAN requirements: 527 L-1: The IPv6 CE router MUST support router behavior according to 528 Neighbor Discovery for IPv6 [RFC4861]. 530 L-2: The IPv6 CE router MUST assign a separate /64 from its 531 delegated prefix(es) (and ULA prefix if configured to provide 532 ULA addressing) for each of its LAN interfaces. 534 L-3: An IPv6 CE router MUST advertise itself as a router for the 535 delegated prefix(es) (and ULA prefix if configured to provide 536 ULA addressing) using the "Route Information Option" specified 537 in Section 2.3 of [RFC4191]. This advertisement is 538 independent of having or not having IPv6 connectivity on the 539 WAN interface. 541 L-4: An IPv6 CE router MUST NOT advertise itself as a default 542 router with a Router Lifetime [RFC4861] greater than zero if 543 it has no prefixes configured or delegated to it. 545 L-5: The IPv6 CE router MUST make each LAN interface an advertising 546 interface according to [RFC4861]. 548 L-6: In Router Advertisement messages ([RFC4861]), the Prefix 549 Information option's A and L flags MUST be set to 1 by 550 default. 552 L-7: The A and L flags' ([RFC4861]) settings SHOULD be user- 553 configurable. 555 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 556 IPv6 address assignment according to [RFC3315] OR a stateless 557 DHCPv6 server according to [RFC3736] on its LAN interfaces. 559 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 560 IA_NA option, it SHOULD set the M flag to 0 and the O flag to 561 1 in its Router Advertisement messages [RFC4861]. 563 L-10: The IPv6 CE router MUST support providing DNS information in 564 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 566 L-11: The IPv6 CE router MUST support providing DNS information in 567 the Router Advertisement Recursive DNS Server (RDNSS) and DNS 568 Search List options. Both options are specified in [RFC6106]. 570 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 571 options (as listed in Section 5.3 of [RFC3736]) received from 572 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 573 server. 575 L-13: If the delegated prefix changes, i.e., the current prefix is 576 replaced with a new prefix without any overlapping time 577 period, then the IPv6 CE router MUST immediately advertise the 578 old prefix with a Preferred Lifetime of zero and a Valid 579 Lifetime of either a) zero, or b) the lower of the current 580 Valid Lifetime and two hours (which must be decremented in 581 real time) in a Router Advertisement message as described in 582 Section 5.5.3, (e) of [RFC4862]. 584 L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 585 message, code 5 (Source address failed ingress/egress policy) 586 for packets forwarded to it that use an address from a prefix 587 that has been invalidated. 589 4.4. Transition Technologies Support 591 4.4.1. 6rd 593 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 594 advance deployment of IPv6 to end users via a service provider's IPv4 595 network infrastructure. Key aspects include automatic IPv6 prefix 596 delegation to sites, stateless operation, simple provisioning, and 597 service that is equivalent to native IPv6 at the sites that are 598 served by the mechanism. It is expected that such traffic is 599 forwarded over the CE Router's native IPv4 WAN interface, and not 600 encapsulated in another tunnel. 602 The CE Router SHOULD support 6rd functionality. If 6rd is supported, 603 it MUST be implemented according to [RFC5969]. The following CE 604 Requirements also apply: 606 6rd requirements: 608 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 609 DHCPv4 Option (212). If the CE router has obtained an IPv4 610 network address through some other means such as PPP, it 611 SHOULD use the DHCPINFORM request message [RFC2131] to 612 request the 6rd DHCPv4 Option. The IPv6 CE router MAY use 613 other mechanisms to configure 6rd parameters. Such 614 mechanisms are outside the scope of this document. 616 6RD-2: If the IPv6 CE router is capable of automated configuration 617 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 618 support user-entered configuration of 6rd. 620 6RD-3: If the CE router supports configuration mechanisms other than 621 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE 622 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub 623 and spoke" requires all IPv6 traffic to go to the 6rd Border 624 Relay. In effect, this requirement removes the "direct 625 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. 627 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to 628 be active alone as well as simultaneously in order to support 629 coexistence of the two technologies during an incremental 630 migration period such as a migration from 6rd to native IPv6. 632 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be 633 directed such that its source IP address is derived from the 634 delegated prefix associated with the particular interface 635 from which the packet is being sent[Section 4.3 [RFC3704]]. 637 6RD-6: The CE router MUST allow different as well as identical 638 delegated prefixes to be configured via each (6rd or native) 639 WAN interface. 641 6RD-7: In the event that forwarding rules produce a tie between 6rd 642 and native IPv6, by default, the IPv6 CE Router MUST prefer 643 native IPv6. 645 4.4.2. Dual-Stack Lite (DS-Lite) 647 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 648 services and incentives for the deployment of IPv6. It also de- 649 couples IPv6 deployment in the Service Provider network from the rest 650 of the Internet, making incremental deployment easier. Dual-Stack 651 Lite enables a broadband service provider to share IPv4 addresses 652 among customers by combining two well-known technologies: IP in IP 653 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 654 that DS-Lite traffic is forwarded over the CE Router's native IPv6 655 WAN interface, and not encapsulated in another tunnel. 657 The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS- 658 Lite is supported, it MUST be implemented according to [RFC6333]. 659 This document takes no position on simultaneous operation of Dual- 660 Stack Lite and native IPv4. The following CE Router requirements 661 also apply: 663 WAN requirements: 665 DLW-1: The CE Router MUST support configuration of DS-Lite via the 666 DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE Router MAY use 667 other mechanisms to configure DS-Lite parameters. Such 668 mechanisms are outside the scope of this document. 670 DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address 671 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 673 DLW-3: If the IPv6 CE Router is configured with an IPv4 address on 674 its WAN interface then the IPv6 CE Router SHOULD disable the 675 DS-Lite B4 element. 677 4.5. Security Considerations 679 It is considered a best practice to filter obviously malicious 680 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 681 the IPv6 CE router ought to support basic stateless egress and 682 ingress filters. The CE router is also expected to offer mechanisms 683 to filter traffic entering the customer network; however, the method 684 by which vendors implement configurable packet filtering is beyond 685 the scope of this document. 687 Security requirements: 689 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 690 the IPv6 CE router SHOULD support functionality sufficient for 691 implementing the set of recommendations in [RFC6092], 692 Section 4. This document takes no position on whether such 693 functionality is enabled by default or mechanisms by which 694 users would configure it. 696 S-2: The IPv6 CE router SHOULD support ingress filtering in 697 accordance with BCP 38 [RFC2827]. Note that this requirement 698 was downgraded from a MUST from RFC 6204 due to the difficulty 699 of implementation in the CE router and the feature's redundancy 700 with upstream router ingress filtering. 702 S-3: If the IPv6 CE router firewall is configured to filter incoming 703 tunneled data, the firewall SHOULD provide the capability to 704 filter decapsulated packets from a tunnel. 706 5. IANA Considerations 708 This document has no actions for IANA. 710 6. Acknowledgements 712 Thanks to the following people (in alphabetical order) for their 713 guidance and feedback: 715 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 716 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 717 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 718 Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas 719 Herbst, Ray Hunter, Kevin Johns, Joel Jaeggli, Erik Kline, Stephen 720 Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, 721 David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, 722 Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen, 723 Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark 724 Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James 725 Woodyatt, Carl Wuyts, and Cor Zwart. 727 This document is based in part on CableLabs' eRouter specification. 728 The authors wish to acknowledge the additional contributors from the 729 eRouter team: 731 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 732 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 733 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 734 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 735 Torbet, and Greg White. 737 7. Contributors 739 The following people have participated as co-authors or provided 740 substantial contributions to this document: Ralph Droms, Kirk 741 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 742 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole 743 Troan for editorship in the original RFC 6204 document. 745 8. References 747 8.1. Normative References 749 [I-D.droms-dhc-dhcpv6-solmaxrt-update] 750 Droms, R., "Modification to Default Value of SOL_MAX_RT", 751 draft-droms-dhc-dhcpv6-solmaxrt-update-03 (work in 752 progress), August 2012. 754 [I-D.ietf-dhc-pd-exclude] 755 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 756 "Prefix Exclude Option for DHCPv6-based Prefix 757 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 758 progress), December 2011. 760 [I-D.ietf-pcp-base] 761 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 762 Selkirk, "Port Control Protocol (PCP)", 763 draft-ietf-pcp-base-27 (work in progress), September 2012. 765 [RFC1122] Braden, R., "Requirements for Internet Hosts - 766 Communication Layers", STD 3, RFC 1122, October 1989. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 772 RFC 2131, March 1997. 774 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 775 Networks", RFC 2464, December 1998. 777 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 778 Defeating Denial of Service Attacks which employ IP Source 779 Address Spoofing", BCP 38, RFC 2827, May 2000. 781 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 782 and M. Carney, "Dynamic Host Configuration Protocol for 783 IPv6 (DHCPv6)", RFC 3315, July 2003. 785 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 786 Host Configuration Protocol (DHCP) version 6", RFC 3633, 787 December 2003. 789 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 790 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 791 December 2003. 793 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 794 Networks", BCP 84, RFC 3704, March 2004. 796 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 797 (DHCP) Service for IPv6", RFC 3736, April 2004. 799 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 800 More-Specific Routes", RFC 4191, November 2005. 802 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 803 Addresses", RFC 4193, October 2005. 805 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 806 Time Option for Dynamic Host Configuration Protocol for 807 IPv6 (DHCPv6)", RFC 4242, November 2005. 809 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 810 Message Protocol (ICMPv6) for the Internet Protocol 811 Version 6 (IPv6) Specification", RFC 4443, March 2006. 813 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 814 "Internet Group Management Protocol (IGMP) / Multicast 815 Listener Discovery (MLD)-Based Multicast Forwarding 816 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 818 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 819 (CIDR): The Internet Address Assignment and Aggregation 820 Plan", BCP 122, RFC 4632, August 2006. 822 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 823 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 824 Access Networks", RFC 4779, January 2007. 826 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 827 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 828 September 2007. 830 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 831 Address Autoconfiguration", RFC 4862, September 2007. 833 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 834 E. Klein, "Local Network Protection for IPv6", RFC 4864, 835 May 2007. 837 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 838 PPP", RFC 5072, September 2007. 840 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 841 Time Protocol Version 4: Protocol and Algorithms 842 Specification", RFC 5905, June 2010. 844 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 845 Server Option for DHCPv6", RFC 5908, June 2010. 847 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 848 Model: The Relationship between Links and Subnet 849 Prefixes", RFC 5942, July 2010. 851 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 852 Infrastructures (6rd) -- Protocol Specification", 853 RFC 5969, August 2010. 855 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 856 Customer Premises Equipment (CPE) for Providing 857 Residential IPv6 Internet Service", RFC 6092, 858 January 2011. 860 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 861 "IPv6 Router Advertisement Options for DNS Configuration", 862 RFC 6106, November 2010. 864 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 865 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 867 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 868 Stack Lite Broadband Deployments Following IPv4 869 Exhaustion", RFC 6333, August 2011. 871 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 872 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 873 RFC 6334, August 2011. 875 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 876 Requirements", RFC 6434, December 2011. 878 8.2. Informative References 880 [I-D.ietf-dhc-dhcpv6-stateful-issues] 881 Troan, O. and B. Volz, "Issues with multiple stateful 882 DHCPv6 options", draft-ietf-dhc-dhcpv6-stateful-issues-00 883 (work in progress), May 2012. 885 [MULTIHOMING-WITHOUT-NAT] 886 Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 887 and D. Wing, "IPv6 Multihoming without Network Address 888 Translation", Work in Progress, December 2010. 890 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 891 IPv4/IPv6 Translation", RFC 6144, March 2011. 893 [UPnP-IGD] 894 UPnP Forum, "Universal Plug and Play (UPnP) Internet 895 Gateway Device (IGD)", November 2001, 896 . 898 Appendix A. Changes from RFC 6204 900 1. Added IP transition technologies available in RFC form. 902 2. Changed requirement G-5 to augment the condition of losing IPv6 903 default router(s) with loss of connectivity. 905 3. Removed requirement WAA-7 due to not reaching consensus by 906 various service provider standards bodies. The removal of text 907 does not remove any critical functionality from the CE 908 specification. 910 4. Changed requirement WAA-8 to qualify WAN behavior only if not 911 configured to perform DHCPv6. This way a deployment specific 912 profile can mandate DHCPv6 numbered WAN without conflicting with 913 this document. 915 5. Changed the WPD-2 requirement from MUST be configurable to 916 SHOULD be configurable. 918 6. Changed requirement WPD-4 for a default behavior without 919 compromising any prior specification of the CE device. The 920 change was needed by a specific layer 2 deployment which wanted 921 to specify a MUST for DHCPv6 in their layer 2 profile and not 922 conflict with this document. 924 7. Changed requirement WPD-7 to qualify text for DHCPv6. Removed 925 W-5 and WPD-5 because the text does not have consensus from the 926 IETF DHC Working Group for what the final solution related to 927 the removed requirements will be. 929 8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 930 that if an service provider does not have DHCPv6 service enabled 931 CE routers do not send too frequent DHCPv6 requests to the 932 service provider DHCPv6 server. 934 9. Changed requirement L-11 from SHOULD provide DNS options in the 935 RA to MUST provide DNS option in the RA. 937 10. New requirement added to the Security Considerations section due 938 to addition of transition technology. The CE router filters 939 decapsulated 6rd data. 941 11. Minor change involved changing ICMP to ICMPv6. 943 12. Added PCP client requirement for the WAN. 945 13. Added a requirement for the DHCPv6 pd-exclude option. 947 Authors' Addresses 949 Hemant Singh 950 Cisco Systems, Inc. 951 1414 Massachusetts Ave. 952 Boxborough, MA 01719 953 USA 955 Phone: +1 978 936 1622 956 EMail: shemant@cisco.com 957 URI: http://www.cisco.com/ 959 Wes Beebee 960 Cisco Systems, Inc. 961 1414 Massachusetts Ave. 962 Boxborough, MA 01719 963 USA 965 Phone: +1 978 936 2030 966 EMail: wbeebee@cisco.com 967 URI: http://www.cisco.com/ 969 Chris Donley 970 CableLabs 971 858 Coal Creek Circle 972 Louisville, CO 80027 973 USA 975 EMail: c.donley@cablelabs.com 977 Barbara Stark 978 AT&T 979 725 W Peachtree St. 980 Atlanta, GA 30308 981 USA 983 EMail: barbara.stark@att.com