idnits 2.17.1 draft-ietf-v6ops-6204bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2012) is 4194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3704' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC4864' is defined on line 837, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-28 ** 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 (~~), 6 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: May 3, 2013 CableLabs 7 B. Stark 8 AT&T 9 October 30, 2012 11 Basic Requirements for IPv6 Customer Edge Routers 12 draft-ietf-v6ops-6204bis-12 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 May 3, 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, in order to 86 establish an industry baseline for features to be implemented on such 87 a router. 89 These routers typically also support IPv4. 91 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 92 the CE router) can be more complex if the IPv6-only devices are using 93 a translator to access IPv4 servers [RFC6144]. Support for such 94 mixed environments is not in scope of this document. 96 This document specifies how an IPv6 CE router automatically 97 provisions its WAN interface, acquires address space for provisioning 98 of its LAN interfaces, and fetches other configuration information 99 from the service provider network. Automatic provisioning of more 100 complex topology than a single router with multiple LAN interfaces is 101 out of scope for this document. 103 See [RFC4779] for a discussion of options available for deploying 104 IPv6 in service provider access networks. 106 The document also covers the IP transition technologies that were 107 available at the time this document was written. Two transition 108 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in 109 the document. 111 1.1. Requirements Language 113 Take careful note: Unlike other IETF documents, the key words "MUST", 114 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 115 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 116 described in RFC 2119 [RFC2119]. This document uses these keyword 117 not strictly for the purpose of interoperability, but rather for the 118 purpose of establishing industry-common baseline functionality. As 119 such, the document points to several other specifications (preferable 120 in RFC or stable form) to provide additional guidance to implementers 121 regarding any protocol implementation required to produce a 122 successful CPE router that interoperates successfully with a 123 particular subset of currently deploying and planned common IPv6 124 access networks. 126 2. Terminology 127 End-User Network one or more links attached to the IPv6 CE 128 router that connect IPv6 hosts. 130 IPv6 Customer Edge Router a node intended for home or small-office 131 use that forwards IPv6 packets not 132 explicitly addressed to itself. The IPv6 133 CE router connects the end-user network to 134 a service provider network. 136 IPv6 Host any device implementing an IPv6 stack 137 receiving IPv6 connectivity through the 138 IPv6 CE router. 140 LAN Interface an IPv6 CE router's attachment to a link in 141 the end-user network. Examples are 142 Ethernet (simple or bridged), 802.11 143 wireless, or other LAN technologies. An 144 IPv6 CE router may have one or more 145 network-layer LAN interfaces. 147 Service Provider an entity that provides access to the 148 Internet. In this document, a service 149 provider specifically offers Internet 150 access using IPv6, and may also offer IPv4 151 Internet access. The service provider can 152 provide such access over a variety of 153 different transport methods such as DSL, 154 cable, wireless, and others. 156 WAN Interface an IPv6 CE router's attachment to a link 157 used to provide connectivity to the service 158 provider network; example link technologies 159 include Ethernet (simple or bridged), PPP 160 links, Frame Relay, or ATM networks, as 161 well as Internet-layer (or higher-layer) 162 "tunnels", such as tunnels over IPv4 or 163 IPv6 itself. 165 3. Architecture 167 3.1. Current IPv4 End-User Network Architecture 169 An end-user network will likely support both IPv4 and IPv6. It is 170 not expected that an end-user will change their existing network 171 topology with the introduction of IPv6. There are some differences 172 in how IPv6 works and is provisioned; these differences have 173 implications for the network architecture. A typical IPv4 end-user 174 network consists of a "plug and play" router with NAT functionality 175 and a single link behind it, connected to the service provider 176 network. 178 A typical IPv4 NAT deployment by default blocks all incoming 179 connections. Opening of ports is typically allowed using a Universal 180 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 181 other firewall control protocol. 183 Another consequence of using private address space in the end-user 184 network is that it provides stable addressing; i.e., it never changes 185 even when you change service providers, and the addresses are always 186 there even when the WAN interface is down or the customer edge router 187 has not yet been provisioned. 189 Many existing routers support dynamic routing (which learns routes 190 from other routers), and advanced end-users can build arbitrary, 191 complex networks using manual configuration of address prefixes 192 combined with a dynamic routing protocol. 194 3.2. IPv6 End-User Network Architecture 196 The end-user network architecture for IPv6 should provide equivalent 197 or better capabilities and functionality than the current IPv4 198 architecture. 200 The end-user network is a stub network. Figure 1 illustrates the 201 model topology for the end-user network. 203 +-------+-------+ \ 204 | Service | \ 205 | Provider | | Service 206 | Router | | Provider 207 +-------+-------+ | network 208 | / 209 | Customer / 210 | Internet connection / 211 | 212 +------+--------+ \ 213 | IPv6 | \ 214 | Customer Edge | \ 215 | Router | / 216 +---+-------+-+-+ / 217 Network A | | Network B | End-User 218 ---+-------------+----+- --+--+-------------+--- | network(s) 219 | | | | \ 220 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 221 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 222 | | | | | | | | / 223 +----------+ +-----+----+ +----------+ +----------+ / 225 Figure 1: An Example of a Typical End-User Network 227 This architecture describes the: 229 o Basic capabilities of an IPv6 CE router 231 o Provisioning of the WAN interface connecting to the service 232 provider 234 o Provisioning of the LAN interfaces 236 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 237 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 238 multicast routing protocol. 240 The IPv6 CE router may be manually configured in an arbitrary 241 topology with a dynamic routing protocol. Automatic provisioning and 242 configuration are described for a single IPv6 CE router only. 244 3.2.1. Local Communication 246 Link-local IPv6 addresses are used by hosts communicating on a single 247 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 248 by hosts communicating within the end-user network across multiple 249 links, but without requiring the application to use a globally 250 routable address. The IPv6 CE router defaults to acting as the 251 demarcation point between two networks by providing a ULA boundary, a 252 multicast zone boundary, and ingress and egress traffic filters. 254 At the time of this writing, several host implementations do not 255 handle the case where they have an IPv6 address configured and no 256 IPv6 connectivity, either because the address itself has a limited 257 topological reachability (e.g., ULA) or because the IPv6 CE router is 258 not connected to the IPv6 network on its WAN interface. To support 259 host implementations that do not handle multihoming in a multi-prefix 260 environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 261 as detailed in the requirements below, advertise itself as a default 262 router on the LAN interface(s) when it does not have IPv6 263 connectivity on the WAN interface or when it is not provisioned with 264 IPv6 addresses. For local IPv6 communication, the mechanisms 265 specified in [RFC4191] are used. 267 ULA addressing is useful where the IPv6 CE router has multiple LAN 268 interfaces with hosts that need to communicate with each other. If 269 the IPv6 CE router has only a single LAN interface (IPv6 link), then 270 link-local addressing can be used instead. 272 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 273 conform to these recommendations, especially requirements ULA-5 and 274 L-4 below. 276 4. Requirements 278 4.1. General Requirements 280 The IPv6 CE router is responsible for implementing IPv6 routing; that 281 is, the IPv6 CE router must look up the IPv6 destination address in 282 its routing table to decide to which interface it should send the 283 packet. 285 In this role, the IPv6 CE router is responsible for ensuring that 286 traffic using its ULA addressing does not go out the WAN interface, 287 and does not originate from the WAN interface. 289 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 290 Requirements [RFC6434] specification. 292 G-2: The IPv6 CE router MUST implement ICMPv6 according to 293 [RFC4443]. In particular, point-to-point links MUST be handled 294 as described in Section 3.1 of [RFC4443]. 296 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 297 its LAN interface(s) and its WAN interface until the router has 298 successfully completed the IPv6 address and the delegated 299 prefix acquisition process. 301 G-4: By default, an IPv6 CE router that has no default router(s) on 302 its WAN interface MUST NOT advertise itself as an IPv6 default 303 router on its LAN interfaces. That is, the "Router Lifetime" 304 field is set to zero in all Router Advertisement messages it 305 originates [RFC4861]. 307 G-5: By default, if the IPv6 CE router is an advertising router and 308 loses its IPv6 default router(s) and/or detects loss of 309 connectivity on the WAN interface, it MUST explicitly 310 invalidate itself as an IPv6 default router on each of its 311 advertising interfaces by immediately transmitting one or more 312 Router Advertisement messages with the "Router Lifetime" field 313 set to zero [RFC4861]. 315 4.2. WAN-Side Configuration 317 The IPv6 CE router will need to support connectivity to one or more 318 access network architectures. This document describes an IPv6 CE 319 router that is not specific to any particular architecture or service 320 provider and that supports all commonly used architectures. 322 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 323 IPv6-supported link layer, and there is no need for a link-layer- 324 specific configuration protocol for IPv6 network-layer configuration 325 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 326 section makes the assumption that the same mechanism will work for 327 any link layer, be it Ethernet, the Data Over Cable Service Interface 328 Specification (DOCSIS), PPP, or others. 330 WAN-side requirements: 332 W-1: When the router is attached to the WAN interface link, it MUST 333 act as an IPv6 host for the purposes of stateless [RFC4862] or 334 stateful [RFC3315] interface address assignment. 336 W-2: The IPv6 CE router MUST generate a link-local address and 337 finish Duplicate Address Detection according to [RFC4862] prior 338 to sending any Router Solicitations on the interface. The 339 source address used in the subsequent Router Solicitation MUST 340 be the link-local address on the WAN interface. 342 W-3: Absent other routing information, the IPv6 CE router MUST use 343 Router Discovery as specified in [RFC4861] to discover a 344 default router(s) and install default route(s) in its routing 345 table with the discovered router's address as the next hop. 347 W-4: The router MUST act as a requesting router for the purposes of 348 DHCPv6 prefix delegation ([RFC3633]). 350 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 351 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 352 network interface resets or IPv6 CE router reboots. 354 W-6: The WAN interface of the CE router SHOULD support a PCP client 355 as specified in [I-D.ietf-pcp-base] for use by applications on 356 the CE Router. The PCP client SHOULD follow the procedure 357 specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its 358 PCP server. This document takes no position on whether such 359 functionality is enabled by default or mechanisms by which 360 users would configure the functionality. Handling PCP requests 361 from PCP clients in the LAN side of the CE Router is out of 362 scope. 364 Link-layer requirements: 366 WLL-1: If the WAN interface supports Ethernet encapsulation, then 367 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 369 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 370 router MUST support IPv6 over PPP [RFC5072]. 372 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 373 stack environment with IPCP and IPV6CP running over one PPP 374 logical channel, the Network Control Protocols (NCPs) MUST be 375 treated as independent of each other and start and terminate 376 independently. 378 Address assignment requirements: 380 WAA-1: The IPv6 CE router MUST support Stateless Address 381 Autoconfiguration (SLAAC) [RFC4862]. 383 WAA-2: The IPv6 CE router MUST follow the recommendations in 384 Section 4 of [RFC5942], and in particular the handling of 385 the L flag in the Router Advertisement Prefix Information 386 option. 388 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 389 behavior. 391 WAA-4: The IPv6 CE router MUST be able to support the following 392 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 393 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 394 support the DNS Search List DNSSL option as specified in 395 [RFC3646]. 397 WAA-5: The IPv6 CE router SHOULD implement the Network Time 398 Protocol (NTP) as specified in [RFC5905] to provide a time 399 reference common to the service provider for other 400 protocols, such as DHCPv6, to use. If the CE router 401 implements NTP, it requests the NTP Server DHCPv6 option 402 [RFC5908] and uses the received list of servers as primary 403 time reference, unless explicitly configured otherwise. LAN 404 side support of NTP is out of scope for this document. 406 WAA-6: If the IPv6 CE router receives a Router Advertisement 407 message (described in [RFC4861]) with the M flag set to 1, 408 the IPv6 CE router MUST do DHCPv6 address assignment 409 (request an IA_NA option). 411 WAA-7: If the IPv6 CE router does not acquire global IPv6 412 address(es) from either SLAAC or DHCPv6, then it MUST create 413 global IPv6 address(es) from its delegated prefix(es) and 414 configure those on one of its internal virtual network 415 interfaces, unless configured to require a global IPv6 416 address on the WAN interface. 418 WAA-8: The CE router must support the SOL_MAX_RT option 419 [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the 420 SOL_MAX_RT option in an ORO. 422 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 423 (Weak ES) model [RFC1122]. When originating packets from an 424 interface, it will use a source address from another one of 425 its interfaces if the outgoing interface does not have an 426 address of suitable scope. 428 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 429 Time option and associated client behavior as specified in 430 [RFC4242]. 432 Prefix delegation requirements: 434 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 435 requesting router behavior as specified in [RFC3633] (IA_PD 436 option). 438 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 439 router the size of the prefix it requires. If so, it MUST 440 ask for a prefix large enough to assign one /64 for each of 441 its interfaces, rounded up to the nearest nibble, and SHOULD 442 be configurable to ask for more. 444 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 445 prefix size different from what is given in the hint. If the 446 delegated prefix is too small to address all of its 447 interfaces, the IPv6 CE router SHOULD log a system management 448 error. [RFC6177] covers the recommendations for service 449 providers for prefix allocation sizes. 451 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 452 delegation when either the M or O flags are set to 1 in a 453 received Router Advertisement (RA) message. Behavior of the 454 CE router to use DHCPv6 prefix delegation when the CE router 455 has not received any RA or received an RA with the M and the 456 O bits set to zero is out of scope for this document. 458 WPD-5: Any packet received by the CE router with a destination 459 address in the prefix(es) delegated to the CE router but not 460 in the set of prefixes assigned by the CE router to the LAN 461 must be dropped. In other words, the next hop for the 462 prefix(es) delegated to the CE router should be the null 463 destination. This is necessary to prevent forwarding loops 464 when some addresses covered by the aggregate are not 465 reachable [RFC4632]. 467 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 468 Unreachable message in accordance with Section 3.1 of 469 [RFC4443] back to the source of the packet, if the 470 packet is to be dropped due to this rule. 472 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 473 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 474 Advertise/Reply messages, even if the message does not 475 contain any addresses, unless configured to only obtain its 476 WAN IPv6 address via DHCPv6. See 477 [I-D.ietf-dhc-dhcpv6-stateful-issues] 479 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 480 routing protocol on its WAN interface. 482 WPD-8: The IPv6 CE Router SHOULD support the 483 [I-D.ietf-dhc-pd-exclude] PD-Exclude option. 485 4.3. LAN-Side Configuration 487 The IPv6 CE router distributes configuration information obtained 488 during WAN interface provisioning to IPv6 hosts and assists IPv6 489 hosts in obtaining IPv6 addresses. It also supports connectivity of 490 these devices in the absence of any working WAN interface. 492 An IPv6 CE router is expected to support an IPv6 end-user network and 493 IPv6 hosts that exhibit the following characteristics: 495 1. Link-local addresses may be insufficient for allowing IPv6 496 applications to communicate with each other in the end-user 497 network. The IPv6 CE router will need to enable this 498 communication by providing globally scoped unicast addresses or 499 ULAs [RFC4193], whether or not WAN connectivity exists. 501 2. IPv6 hosts should be capable of using SLAAC and may be capable of 502 using DHCPv6 for acquiring their addresses. 504 3. IPv6 hosts may use DHCPv6 for other configuration information, 505 such as the DNS_SERVERS option for acquiring DNS information. 507 Unless otherwise specified, the following requirements apply to the 508 IPv6 CE router's LAN interfaces only. 510 ULA requirements: 512 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 513 prefix [RFC4193]. 515 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 516 consistently across reboots. 518 ULA-3: The value of the ULA prefix SHOULD be configurable. 520 ULA-4: By default, the IPv6 CE router MUST act as a site border 521 router according to Section 4.3 of [RFC4193] and filter 522 packets with local IPv6 source or destination addresses 523 accordingly. 525 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 526 router with a Router Lifetime greater than zero whenever all 527 of its configured and delegated prefixes are ULA prefixes. 529 LAN requirements: 531 L-1: The IPv6 CE router MUST support router behavior according to 532 Neighbor Discovery for IPv6 [RFC4861]. 534 L-2: The IPv6 CE router MUST assign a separate /64 from its 535 delegated prefix(es) (and ULA prefix if configured to provide 536 ULA addressing) for each of its LAN interfaces. 538 L-3: An IPv6 CE router MUST advertise itself as a router for the 539 delegated prefix(es) (and ULA prefix if configured to provide 540 ULA addressing) using the "Route Information Option" specified 541 in Section 2.3 of [RFC4191]. This advertisement is 542 independent of having or not having IPv6 connectivity on the 543 WAN interface. 545 L-4: An IPv6 CE router MUST NOT advertise itself as a default 546 router with a Router Lifetime [RFC4861] greater than zero if 547 it has no prefixes configured or delegated to it. 549 L-5: The IPv6 CE router MUST make each LAN interface an advertising 550 interface according to [RFC4861]. 552 L-6: In Router Advertisement messages ([RFC4861]), the Prefix 553 Information option's A and L flags MUST be set to 1 by 554 default. 556 L-7: The A and L flags' ([RFC4861]) settings SHOULD be user- 557 configurable. 559 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 560 IPv6 address assignment according to [RFC3315] OR a stateless 561 DHCPv6 server according to [RFC3736] on its LAN interfaces. 563 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 564 IA_NA option, it SHOULD set the M flag to 0 and the O flag to 565 1 in its Router Advertisement messages [RFC4861]. 567 L-10: The IPv6 CE router MUST support providing DNS information in 568 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 570 L-11: The IPv6 CE router MUST support providing DNS information in 571 the Router Advertisement Recursive DNS Server (RDNSS) and DNS 572 Search List options. Both options are specified in [RFC6106]. 574 L-12: 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-13: 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-14: 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 4.4. Transition Technologies Support 595 4.4.1. 6rd 597 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 598 advance deployment of IPv6 to end users via a service provider's IPv4 599 network infrastructure. Key aspects include automatic IPv6 prefix 600 delegation to sites, stateless operation, simple provisioning, and 601 service that is equivalent to native IPv6 at the sites that are 602 served by the mechanism. It is expected that such traffic is 603 forwarded over the CE Router's native IPv4 WAN interface, and not 604 encapsulated in another tunnel. 606 The CE Router SHOULD support 6rd functionality. If 6rd is supported, 607 it MUST be implemented according to [RFC5969]. The following CE 608 Requirements also apply: 610 6rd requirements: 612 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 613 DHCPv4 Option (212). If the CE router has obtained an IPv4 614 network address through some other means such as PPP, it 615 SHOULD use the DHCPINFORM request message [RFC2131] to 616 request the 6rd DHCPv4 Option. The IPv6 CE router MAY use 617 other mechanisms to configure 6rd parameters. Such 618 mechanisms are outside the scope of this document. 620 6RD-2: If the IPv6 CE router is capable of automated configuration 621 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 622 support user-entered configuration of 6rd. 624 6RD-3: If the CE router supports configuration mechanisms other than 625 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE 626 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub 627 and spoke" requires all IPv6 traffic to go to the 6rd Border 628 Relay. In effect, this requirement removes the "direct 629 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. 631 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to 632 be active alone as well as simultaneously in order to support 633 coexistence of the two technologies during an incremental 634 migration period such as a migration from 6rd to native IPv6. 636 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be 637 directed such that its source IP address is derived from the 638 delegated prefix associated with the particular interface 639 from which the packet is being sent[Section 4.3 [RFC3704]]. 641 6RD-6: The CE router MUST allow different as well as identical 642 delegated prefixes to be configured via each (6rd or native) 643 WAN interface. 645 6RD-7: In the event that forwarding rules produce a tie between 6rd 646 and native IPv6, by default, the IPv6 CE Router MUST prefer 647 native IPv6. 649 4.4.2. Dual-Stack Lite (DS-Lite) 651 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 652 services and incentives for the deployment of IPv6. It also de- 653 couples IPv6 deployment in the Service Provider network from the rest 654 of the Internet, making incremental deployment easier. Dual-Stack 655 Lite enables a broadband service provider to share IPv4 addresses 656 among customers by combining two well-known technologies: IP in IP 657 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 658 that DS-Lite traffic is forwarded over the CE Router's native IPv6 659 WAN interface, and not encapsulated in another tunnel. 661 The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS- 662 Lite is supported, it MUST be implemented according to [RFC6333]. 663 This document takes no position on simultaneous operation of Dual- 664 Stack Lite and native IPv4. The following CE Router requirements 665 also apply: 667 WAN requirements: 669 DLW-1: The CE Router MUST support configuration of DS-Lite via the 670 DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE Router MAY use 671 other mechanisms to configure DS-Lite parameters. Such 672 mechanisms are outside the scope of this document. 674 DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address 675 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 677 DLW-3: If the IPv6 CE Router is configured with an IPv4 address on 678 its WAN interface then the IPv6 CE Router SHOULD disable the 679 DS-Lite B4 element. 681 4.5. Security Considerations 683 It is considered a best practice to filter obviously malicious 684 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 685 the IPv6 CE router ought to support basic stateless egress and 686 ingress filters. The CE router is also expected to offer mechanisms 687 to filter traffic entering the customer network; however, the method 688 by which vendors implement configurable packet filtering is beyond 689 the scope of this document. 691 Security requirements: 693 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 694 the IPv6 CE router SHOULD support functionality sufficient for 695 implementing the set of recommendations in [RFC6092], 696 Section 4. This document takes no position on whether such 697 functionality is enabled by default or mechanisms by which 698 users would configure it. 700 S-2: The IPv6 CE router SHOULD support ingress filtering in 701 accordance with BCP 38 [RFC2827]. Note that this requirement 702 was downgraded from a MUST from RFC 6204 due to the difficulty 703 of implementation in the CE router and the feature's redundancy 704 with upstream router ingress filtering. 706 S-3: If the IPv6 CE router firewall is configured to filter incoming 707 tunneled data, the firewall SHOULD provide the capability to 708 filter decapsulated packets from a tunnel. 710 5. IANA Considerations 712 This document has no actions for IANA. 714 6. Acknowledgements 716 Thanks to the following people (in alphabetical order) for their 717 guidance and feedback: 719 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 720 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 721 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 722 Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas 723 Herbst, Ray Hunter, Kevin Johns, Joel Jaeggli, Erik Kline, Stephen 724 Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, 725 David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, 726 Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen, 727 Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark 728 Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James 729 Woodyatt, Carl Wuyts, and Cor Zwart. 731 This document is based in part on CableLabs' eRouter specification. 732 The authors wish to acknowledge the additional contributors from the 733 eRouter team: 735 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 736 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 737 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 738 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 739 Torbet, and Greg White. 741 7. Contributors 743 The following people have participated as co-authors or provided 744 substantial contributions to this document: Ralph Droms, Kirk 745 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 746 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole 747 Troan for editorship in the original RFC 6204 document. 749 8. References 751 8.1. Normative References 753 [I-D.droms-dhc-dhcpv6-solmaxrt-update] 754 Droms, R., "Modification to Default Value of SOL_MAX_RT", 755 draft-droms-dhc-dhcpv6-solmaxrt-update-03 (work in 756 progress), August 2012. 758 [I-D.ietf-dhc-pd-exclude] 759 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 760 "Prefix Exclude Option for DHCPv6-based Prefix 761 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 762 progress), December 2011. 764 [I-D.ietf-pcp-base] 765 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 766 Selkirk, "Port Control Protocol (PCP)", 767 draft-ietf-pcp-base-28 (work in progress), October 2012. 769 [RFC1122] Braden, R., "Requirements for Internet Hosts - 770 Communication Layers", STD 3, RFC 1122, October 1989. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 776 RFC 2131, March 1997. 778 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 779 Networks", RFC 2464, December 1998. 781 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 782 Defeating Denial of Service Attacks which employ IP Source 783 Address Spoofing", BCP 38, RFC 2827, May 2000. 785 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 786 and M. Carney, "Dynamic Host Configuration Protocol for 787 IPv6 (DHCPv6)", RFC 3315, July 2003. 789 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 790 Host Configuration Protocol (DHCP) version 6", RFC 3633, 791 December 2003. 793 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 794 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 795 December 2003. 797 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 798 Networks", BCP 84, RFC 3704, March 2004. 800 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 801 (DHCP) Service for IPv6", RFC 3736, April 2004. 803 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 804 More-Specific Routes", RFC 4191, November 2005. 806 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 807 Addresses", RFC 4193, October 2005. 809 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 810 Time Option for Dynamic Host Configuration Protocol for 811 IPv6 (DHCPv6)", RFC 4242, November 2005. 813 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 814 Message Protocol (ICMPv6) for the Internet Protocol 815 Version 6 (IPv6) Specification", RFC 4443, March 2006. 817 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 818 "Internet Group Management Protocol (IGMP) / Multicast 819 Listener Discovery (MLD)-Based Multicast Forwarding 820 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 822 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 823 (CIDR): The Internet Address Assignment and Aggregation 824 Plan", BCP 122, RFC 4632, August 2006. 826 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 827 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 828 Access Networks", RFC 4779, January 2007. 830 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 831 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 832 September 2007. 834 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 835 Address Autoconfiguration", RFC 4862, September 2007. 837 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 838 E. Klein, "Local Network Protection for IPv6", RFC 4864, 839 May 2007. 841 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 842 PPP", RFC 5072, September 2007. 844 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 845 Time Protocol Version 4: Protocol and Algorithms 846 Specification", RFC 5905, June 2010. 848 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 849 Server Option for DHCPv6", RFC 5908, June 2010. 851 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 852 Model: The Relationship between Links and Subnet 853 Prefixes", RFC 5942, July 2010. 855 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 856 Infrastructures (6rd) -- Protocol Specification", 857 RFC 5969, August 2010. 859 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 860 Customer Premises Equipment (CPE) for Providing 861 Residential IPv6 Internet Service", RFC 6092, 862 January 2011. 864 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 865 "IPv6 Router Advertisement Options for DNS Configuration", 866 RFC 6106, November 2010. 868 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 869 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 871 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 872 Stack Lite Broadband Deployments Following IPv4 873 Exhaustion", RFC 6333, August 2011. 875 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 876 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 877 RFC 6334, August 2011. 879 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 880 Requirements", RFC 6434, December 2011. 882 8.2. Informative References 884 [I-D.ietf-dhc-dhcpv6-stateful-issues] 885 Troan, O. and B. Volz, "Issues with multiple stateful 886 DHCPv6 options", draft-ietf-dhc-dhcpv6-stateful-issues-00 887 (work in progress), May 2012. 889 [MULTIHOMING-WITHOUT-NAT] 890 Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 891 and D. Wing, "IPv6 Multihoming without Network Address 892 Translation", Work in Progress, December 2010. 894 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 895 IPv4/IPv6 Translation", RFC 6144, March 2011. 897 [UPnP-IGD] 898 UPnP Forum, "Universal Plug and Play (UPnP) Internet 899 Gateway Device (IGD)", November 2001, 900 . 902 Appendix A. Changes from RFC 6204 904 1. Added IP transition technologies available in RFC form. 906 2. Changed requirement G-5 to augment the condition of losing IPv6 907 default router(s) with loss of connectivity. 909 3. Removed requirement WAA-7 due to not reaching consensus by 910 various service provider standards bodies. The removal of text 911 does not remove any critical functionality from the CE 912 specification. 914 4. Changed requirement WAA-8 to qualify WAN behavior only if not 915 configured to perform DHCPv6. This way a deployment specific 916 profile can mandate DHCPv6 numbered WAN without conflicting with 917 this document. 919 5. Changed the WPD-2 requirement from MUST be configurable to 920 SHOULD be configurable. 922 6. Changed requirement WPD-4 for a default behavior without 923 compromising any prior specification of the CE device. The 924 change was needed by a specific layer 2 deployment which wanted 925 to specify a MUST for DHCPv6 in their layer 2 profile and not 926 conflict with this document. 928 7. Changed requirement WPD-7 to qualify text for DHCPv6. Removed 929 W-5 and WPD-5 because the text does not have consensus from the 930 IETF DHC Working Group for what the final solution related to 931 the removed requirements will be. 933 8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 934 that if an service provider does not have DHCPv6 service enabled 935 CE routers do not send too frequent DHCPv6 requests to the 936 service provider DHCPv6 server. 938 9. Changed requirement L-11 from SHOULD provide DNS options in the 939 RA to MUST provide DNS option in the RA. 941 10. New requirement added to the Security Considerations section due 942 to addition of transition technology. The CE router filters 943 decapsulated 6rd data. 945 11. Minor change involved changing ICMP to ICMPv6. 947 12. Added PCP client requirement for the WAN. 949 13. Added a requirement for the DHCPv6 pd-exclude option. 951 Authors' Addresses 953 Hemant Singh 954 Cisco Systems, Inc. 955 1414 Massachusetts Ave. 956 Boxborough, MA 01719 957 USA 959 Phone: +1 978 936 1622 960 EMail: shemant@cisco.com 961 URI: http://www.cisco.com/ 963 Wes Beebee 964 Cisco Systems, Inc. 965 1414 Massachusetts Ave. 966 Boxborough, MA 01719 967 USA 969 Phone: +1 978 936 2030 970 EMail: wbeebee@cisco.com 971 URI: http://www.cisco.com/ 973 Chris Donley 974 CableLabs 975 858 Coal Creek Circle 976 Louisville, CO 80027 977 USA 979 EMail: c.donley@cablelabs.com 981 Barbara Stark 982 AT&T 983 725 W Peachtree St. 984 Atlanta, GA 30308 985 USA 987 EMail: barbara.stark@att.com