idnits 2.17.1 draft-ietf-v6ops-6204bis-08.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 (April 6, 2012) is 4403 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-24 ** Obsolete normative reference: RFC 2030 (Obsoleted by RFC 4330) ** 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 6434 (Obsoleted by RFC 8504) Summary: 6 errors (**), 0 flaws (~~), 2 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: October 8, 2012 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 April 6, 2012 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-6204bis-08 16 Abstract 18 This document specifies requirements for an IPv6 Customer Edge (CE) 19 router. Specifically, the current version of this document focuses 20 on the basic provisioning of an IPv6 CE router and the provisioning 21 of IPv6 hosts attached to it. The document also covers IP transition 22 technologies. Two transition technologies in RFC 5969's 6rd and RFC 23 6333's DS-Lite are covered in the document. The document obsoletes 24 RFC 6204, if approved. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 8, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4 65 3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5 66 3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 69 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 70 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 71 4.4. Transition Technologies Support . . . . . . . . . . . . . 13 72 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14 74 4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 81 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 This document defines basic IPv6 features for a residential or small- 87 office router, referred to as an IPv6 CE router. Typically, these 88 routers also support IPv4. 90 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 91 the CE router) can be more complex if the IPv6-only devices are using 92 a translator to access IPv4 servers [RFC6144]. Support for such 93 mixed environments is not in scope of this document. 95 This document specifies how an IPv6 CE router automatically 96 provisions its WAN interface, acquires address space for provisioning 97 of its LAN interfaces, and fetches other configuration information 98 from the service provider network. Automatic provisioning of more 99 complex topology than a single router with multiple LAN interfaces is 100 out of scope for this document. 102 See [RFC4779] for a discussion of options available for deploying 103 IPv6 in service provider access networks. 105 The document also covers IP transition technologies. Two transition 106 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in 107 the document. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Terminology 117 End-User Network one or more links attached to the IPv6 CE 118 router that connect IPv6 hosts. 120 IPv6 Customer Edge Router a node intended for home or small-office 121 use that forwards IPv6 packets not 122 explicitly addressed to itself. The IPv6 123 CE router connects the end-user network to 124 a service provider network. 126 IPv6 Host any device implementing an IPv6 stack 127 receiving IPv6 connectivity through the 128 IPv6 CE router. 130 LAN Interface an IPv6 CE router's attachment to a link in 131 the end-user network. Examples are 132 Ethernet (simple or bridged), 802.11 133 wireless, or other LAN technologies. An 134 IPv6 CE router may have one or more 135 network-layer LAN interfaces. 137 Service Provider an entity that provides access to the 138 Internet. In this document, a service 139 provider specifically offers Internet 140 access using IPv6, and may also offer IPv4 141 Internet access. The service provider can 142 provide such access over a variety of 143 different transport methods such as DSL, 144 cable, wireless, and others. 146 WAN Interface an IPv6 CE router's attachment to a link 147 used to provide connectivity to the service 148 provider network; example link technologies 149 include Ethernet (simple or bridged), PPP 150 links, Frame Relay, or ATM networks, as 151 well as Internet-layer (or higher-layer) 152 "tunnels", such as tunnels over IPv4 or 153 IPv6 itself. 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; i.e., it never changes 175 even when you change service providers, and the addresses are always 176 there even when the WAN interface is down or the customer edge router 177 has not yet been provisioned. 179 Rewriting addresses on the edge of the network also allows for some 180 rudimentary multihoming, even though using NATs for multihoming does 181 not preserve connections during a fail-over event [RFC4864]. 183 Many existing routers support dynamic routing, and advanced end-users 184 can build arbitrary, complex networks using manual configuration of 185 address prefixes combined with a dynamic routing protocol. 187 3.2. IPv6 End-User Network Architecture 189 The end-user network architecture for IPv6 should provide equivalent 190 or better capabilities and functionality than the current IPv4 191 architecture. 193 The end-user network is a stub network. Figure 1 illustrates the 194 model topology for the end-user 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 223 o Provisioning of the WAN interface connecting to the service 224 provider 226 o Provisioning of the LAN interfaces 228 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 229 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 230 multicast routing protocol. 232 The IPv6 CE router may be manually configured in an arbitrary 233 topology with a dynamic routing protocol. Automatic provisioning and 234 configuration are described for a single IPv6 CE router only. 236 3.2.1. Local Communication 238 Link-local IPv6 addresses are used by hosts communicating on a single 239 link. Unique Local IPv6 Unicast Addresses (ULA's) [RFC4193] are used 240 by hosts communicating within the end-user network across multiple 241 links, but without requiring the application to use a globally 242 routable address. The IPv6 CE router defaults to acting as the 243 demarcation point between two networks by providing a ULA boundary, a 244 multicast zone boundary, and ingress and egress traffic filters. 246 At the time of this writing, several host implementations do not 247 handle the case where they have an IPv6 address configured and no 248 IPv6 connectivity, either because the address itself has a limited 249 topological reachability (e.g., ULA) or because the IPv6 CE router is 250 not connected to the IPv6 network on its WAN interface. To support 251 host implementations that do not handle multihoming in a multi-prefix 252 environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 253 as detailed in the requirements below, advertise itself as a default 254 router on the LAN interface(s) when it does not have IPv6 255 connectivity on the WAN interface or when it is not provisioned with 256 IPv6 addresses. For local IPv6 communication, the mechanisms 257 specified in [RFC4191] are used. 259 ULA addressing is useful where the IPv6 CE router has multiple LAN 260 interfaces with hosts that need to communicate with each other. If 261 the IPv6 CE router has only a single LAN interface (IPv6 link), then 262 link-local addressing can be used instead. 264 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 265 conform to these recommendations, especially requirements ULA-5 and 266 L-4 below. 268 4. Requirements 270 4.1. General Requirements 272 The IPv6 CE router is responsible for implementing IPv6 routing; that 273 is, the IPv6 CE router must look up the IPv6 destination address in 274 its routing table to decide to which interface it should send the 275 packet. 277 In this role, the IPv6 CE router is responsible for ensuring that 278 traffic using its ULA addressing does not go out the WAN interface, 279 and does not originate from the WAN interface. 281 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 282 Requirements [RFC6434] specification. 284 G-2: The IPv6 CE router MUST implement ICMPv6 according to 285 [RFC4443]. In particular, point-to-point links MUST be handled 286 as described in Section 3.1 of [RFC4443]. 288 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 289 its LAN interface(s) and its WAN interface until the router has 290 successfully completed the IPv6 address and the delegated 291 prefix acquisition process. 293 G-4: By default, an IPv6 CE router that has no default router(s) on 294 its WAN interface MUST NOT advertise itself as an IPv6 default 295 router on its LAN interfaces. That is, the "Router Lifetime" 296 field is set to zero in all Router Advertisement messages it 297 originates [RFC4861]. 299 G-5: By default, if the IPv6 CE router is an advertising router and 300 loses its IPv6 default router(s) and/or detects loss of 301 connectivity on the WAN interface, it MUST explicitly 302 invalidate itself as an IPv6 default router on each of its 303 advertising interfaces by immediately transmitting one or more 304 Router Advertisement messages with the "Router Lifetime" field 305 set to zero [RFC4861]. 307 4.2. WAN-Side Configuration 309 The IPv6 CE router will need to support connectivity to one or more 310 access network architectures. This document describes an IPv6 CE 311 router that is not specific to any particular architecture or service 312 provider and that supports all commonly used architectures. 314 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 315 IPv6-supported link layer, and there is no need for a link-layer- 316 specific configuration protocol for IPv6 network-layer configuration 317 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 318 section makes the assumption that the same mechanism will work for 319 any link layer, be it Ethernet, the Data Over Cable Service Interface 320 Specification (DOCSIS), PPP, or others. 322 WAN-side requirements: 324 W-1: When the router is attached to the WAN interface link, it MUST 325 act as an IPv6 host for the purposes of stateless [RFC4862] or 326 stateful [RFC3315] interface address assignment. 328 W-2: The IPv6 CE router MUST generate a link-local address and 329 finish Duplicate Address Detection according to [RFC4862] prior 330 to sending any Router Solicitations on the interface. The 331 source address used in the subsequent Router Solicitation MUST 332 be the link-local address on the WAN interface. 334 W-3: Absent other routing information, the IPv6 CE router MUST use 335 Router Discovery as specified in [RFC4861] to discover a 336 default router(s) and install default route(s) in its routing 337 table with the discovered router's address as the next hop. 339 W-4: The router MUST act as a requesting router for the purposes of 340 DHCPv6 prefix delegation ([RFC3633]). 342 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 343 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 344 network interface resets or IPv6 CE router reboots. 346 W-6: The WAN interface of the CE router SHOULD support a PCP client 347 as specified in [I-D.ietf-pcp-base] for use by applications on 348 the CE Router. The PCP client SHOULD follow the procedure 349 specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its 350 PCP server. This document takes no position on whether such 351 functionality is enabled by default or mechanisms by which 352 users would configure the functionality. Handling PCP requests 353 from PCP clients in the LAN side of the CE Router is out of 354 scope. 356 Link-layer requirements: 358 WLL-1: If the WAN interface supports Ethernet encapsulation, then 359 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 361 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 362 router MUST support IPv6 over PPP [RFC5072]. 364 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 365 stack environment with IPCP and IPV6CP running over one PPP 366 logical channel, the Network Control Protocols (NCP's) MUST 367 be treated as independent of each other and start and 368 terminate independently. 370 Address assignment requirements: 372 WAA-1: The IPv6 CE router MUST support Stateless Address 373 Autoconfiguration (SLAAC) [RFC4862]. 375 WAA-2: The IPv6 CE router MUST follow the recommendations in 376 Section 4 of [RFC5942], and in particular the handling of 377 the L flag in the Router Advertisement Prefix Information 378 option. 380 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 381 behavior. 383 WAA-4: The IPv6 CE router MUST be able to support the following 384 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 385 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 386 support the DNS Search List DNSSL option as specified in 387 [RFC3646]. 389 WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time 390 Protocol (SNTP) as specified in [RFC2030]. If the CE router 391 implements SNTP, it requests the SNTP option [RFC4075] and 392 uses the received list of servers as primary time reference, 393 unless explicitly configured otherwise. 395 WAA-6: If the IPv6 CE router receives a Router Advertisement 396 message (described in [RFC4861]) with the M flag set to 1, 397 the IPv6 CE router MUST do DHCPv6 address assignment 398 (request an IA_NA option). 400 WAA-7: If the IPv6 CE router does not acquire global IPv6 401 address(es) from either SLAAC or DHCPv6, then it MUST create 402 global IPv6 address(es) from its delegated prefix(es) and 403 configure those on one of its internal virtual network 404 interfaces, unless configured to require a global IPv6 405 address on the WAN interface. 407 WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option 408 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 409 Advertise or Reply message and set its internal SOL_MAX_RT 410 parameter to the value contained in the SOL_MAX_RT option. 412 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 413 (Weak ES) model [RFC1122]. When originating packets from an 414 interface, it will use a source address from another one of 415 its interfaces if the outgoing interface does not have an 416 address of suitable scope. 418 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh 419 Time option and associated client behavior as specified in 420 [RFC4242]. 422 Prefix delegation requirements: 424 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 425 requesting router behavior as specified in [RFC3633] (IA_PD 426 option). 428 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 429 router the size of the prefix it requires. If so, it MUST 430 ask for a prefix large enough to assign one /64 for each of 431 its interfaces, rounded up to the nearest nibble, and SHOULD 432 be configurable to ask for more. 434 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 435 prefix size different from what is given in the hint. If the 436 delegated prefix is too small to address all of its 437 interfaces, the IPv6 CE router SHOULD log a system management 438 error. [RFC6177] covers the recommendations for service 439 providers for prefix allocation sizes. 441 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 442 delegation when either the M or O flags are set to 1 in a 443 received Router Advertisement message. 445 WPD-5: If the delegated prefix(es) are aggregate route(s) of 446 multiple, more-specific routes, the IPv6 CE router MUST 447 discard packets that match the aggregate route(s), but not 448 any of the more-specific routes. In other words, the next 449 hop for the aggregate route(s) should be the null 450 destination. This is necessary to prevent forwarding loops 451 when some addresses covered by the aggregate are not 452 reachable [RFC4632]. 454 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 455 Unreachable message in accordance with Section 3.1 of 456 [RFC4443] back to the source of the packet, if the 457 packet is to be dropped due to this rule. 459 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 460 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 461 Advertise/Reply messages, even if the message does not 462 contain any addresses, unless configured to only obtain its 463 WAN IPv6 address via DHCPv6. See 464 [I-D.troan-dhc-dhcpv6-stateful-issues] 466 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 467 routing protocol on its WAN interface. 469 WPD-8: The IPv6 CE Router SHOULD support the 470 [I-D.ietf-dhc-pd-exclude] PD-Exclude option. 472 4.3. LAN-Side Configuration 474 The IPv6 CE router distributes configuration information obtained 475 during WAN interface provisioning to IPv6 hosts and assists IPv6 476 hosts in obtaining IPv6 addresses. It also supports connectivity of 477 these devices in the absence of any working WAN interface. 479 An IPv6 CE router is expected to support an IPv6 end-user network and 480 IPv6 hosts that exhibit the following characteristics: 482 1. Link-local addresses may be insufficient for allowing IPv6 483 applications to communicate with each other in the end-user 484 network. The IPv6 CE router will need to enable this 485 communication by providing globally scoped unicast addresses or 486 ULA's [RFC4193], whether or not WAN connectivity exists. 488 2. IPv6 hosts should be capable of using SLAAC and may be capable of 489 using DHCPv6 for acquiring their addresses. 491 3. IPv6 hosts may use DHCPv6 for other configuration information, 492 such as the DNS_SERVERS option for acquiring DNS information. 494 Unless otherwise specified, the following requirements apply to the 495 IPv6 CE router's LAN interfaces only. 497 ULA requirements: 499 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 500 prefix [RFC4193]. 502 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 503 consistently across reboots. 505 ULA-3: The value of the ULA prefix SHOULD be user-configurable. 507 ULA-4: By default, the IPv6 CE router MUST act as a site border 508 router according to Section 4.3 of [RFC4193] and filter 509 packets with local IPv6 source or destination addresses 510 accordingly. 512 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 513 router with a Router Lifetime greater than zero whenever all 514 of its configured and delegated prefixes are ULA prefixes. 516 LAN requirements: 518 L-1: The IPv6 CE router MUST support router behavior according to 519 Neighbor Discovery for IPv6 [RFC4861]. 521 L-2: The IPv6 CE router MUST assign a separate /64 from its 522 delegated prefix(es) (and ULA prefix if configured to provide 523 ULA addressing) for each of its LAN interfaces. 525 L-3: An IPv6 CE router MUST advertise itself as a router for the 526 delegated prefix(es) (and ULA prefix if configured to provide 527 ULA addressing) using the "Route Information Option" specified 528 in Section 2.3 of [RFC4191]. This advertisement is 529 independent of having or not having IPv6 connectivity on the 530 WAN interface. 532 L-4: An IPv6 CE router MUST NOT advertise itself as a default 533 router with a Router Lifetime [RFC4861] greater than zero if 534 it has no prefixes configured or delegated to it. 536 L-5: The IPv6 CE router MUST make each LAN interface an advertising 537 interface according to [RFC4861]. 539 L-6: In Router Advertisement messages, the Prefix Information 540 option's A and L flags MUST be set to 1 by default. 542 L-7: The A and L flags' settings SHOULD be user-configurable. 544 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 545 IPv6 address assignment according to [RFC3315] OR a stateless 546 DHCPv6 server according to [RFC3736] on its LAN interfaces. 548 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 549 IA_NA option, it SHOULD set the M flag to 0 and the O flag to 550 1 in its Router Advertisement messages [RFC4861]. 552 L-10: The IPv6 CE router MUST support providing DNS information in 553 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 555 L-11: The IPv6 CE router MUST support providing DNS information in 556 the Router Advertisement Recursive DNS Server (RDNSS) and 557 DNSSL options. 559 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 560 options (as listed in Section 5.3 of [RFC3736]) received from 561 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 562 server. 564 L-13: If the delegated prefix changes, i.e., the current prefix is 565 replaced with a new prefix without any overlapping time 566 period, then the IPv6 CE router MUST immediately advertise the 567 old prefix with a Preferred Lifetime of zero and a Valid 568 Lifetime of either a) zero, or b) the lower of the current 569 Valid Lifetime and two hours (which must be decremented in 570 real time) in a Router Advertisement message as described in 571 Section 5.5.3, (e) of [RFC4862]. 573 L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 574 message, code 5 (Source address failed ingress/egress policy) 575 for packets forwarded to it that use an address from a prefix 576 that has been deprecated. 578 4.4. Transition Technologies Support 580 4.4.1. 6rd 582 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 583 advance deployment of IPv6 to end users via a service provider's IPv4 584 network infrastructure. Key aspects include automatic IPv6 prefix 585 delegation to sites, stateless operation, simple provisioning, and 586 service that is equivalent to native IPv6 at the sites that are 587 served by the mechanism. It is expected that such traffic is 588 forwarded over the CE Router's native IPv4 WAN interface, and not 589 encapsulated in another tunnel. 591 The CE Router SHOULD support 6rd functionality. If 6rd is supported, 592 it MUST be implemented according to [RFC5969]. The following CE 593 Requirements also apply: 595 6rd requirements: 597 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 598 DHCPv4 Option (212). If the CE router has obtained an IPv4 599 network address through some other means such as PPP, it 600 SHOULD use the DHCPINFORM request message [RFC2131] to 601 request the 6rd DHCPv4 Option. The IPv6 CE router MAY use 602 other mechanisms to configure 6rd parameters. Such 603 mechanisms are outside the scope of this document. 605 6RD-2: If the IPv6 CE router is capable of automated configuration 606 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 607 support user-entered configuration of 6rd. 609 6RD-3: If the CE router supports configuration mechanisms other than 610 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE 611 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub 612 and spoke" requires all IPv6 traffic to go to the 6rd Border 613 Relay. In effect, this requirement removes the "direct 614 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. 616 6RD-4: Per [RFC3704], Section 4.3, the CE router MUST send traffic 617 using a prefix learned via 6rd over the 6rd tunnel. 619 6RD-5: The IPv6 CE router MUST support two operational modes: 620 different prefixes on 6rd and native interfaces or identical 621 prefixes on 6rd and native interfaces. 623 6RD-6: By default, the IPv6 CE router MUST prefer a native IPv6 624 interface over a 6rd virtual interface. 626 6RD-7: The IPv6 CE router SHOULD support independent WAN interface 627 configuration for 6rd and native IPv6. 629 4.4.2. Dual-Stack Lite (DS-Lite) 631 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 632 services and incentives for the deployment of IPv6. It also de- 633 couples IPv6 deployment in the Service Provider network from the rest 634 of the Internet, making incremental deployment easier. Dual-Stack 635 Lite enables a broadband service provider to share IPv4 addresses 636 among customers by combining two well-known technologies: IP in IP 637 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 638 that DS-Lite traffic is forwarded over the CE Router's native IPv6 639 WAN interface, and not encapsulated in another tunnel. 641 The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS- 642 Lite is supported, it MUST be implemented according to [RFC6333]. 643 This document takes no position on simultaneous operation of Dual- 644 Stack Lite and native IPv4. The following CE Router requirements 645 also apply: 647 WAN requirements: 649 DLW-1: The CE Router MUST support DS-Lite via the DS-Lite DHCPv6 650 option [RFC6334]. The IPv6 CE Router MAY use other 651 mechanisms to configure DS-Lite parameters. Such mechanisms 652 are outside the scope of this document. 654 DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address 655 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 657 DLW-3: If the IPv6 CE Router is configured with an IPv4 address on 658 its WAN interface then the IPv6 CE Router SHOULD disable the 659 DS-Lite B4 element. 661 4.5. Security Considerations 663 It is considered a best practice to filter obviously malicious 664 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 665 the IPv6 CE router ought to support basic stateless egress and 666 ingress filters. The CE router is also expected to offer mechanisms 667 to filter traffic entering the customer network; however, the method 668 by which vendors implement configurable packet filtering is beyond 669 the scope of this document. 671 Security requirements: 673 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 674 the IPv6 CE router SHOULD support functionality sufficient for 675 implementing the set of recommendations in [RFC6092], 676 Section 4. This document takes no position on whether such 677 functionality is enabled by default or mechanisms by which 678 users would configure it. 680 S-2: The IPv6 CE router SHOULD support ingress filtering in 681 accordance with BCP 38 [RFC2827]. 683 S-3: If the IPv6 CE router firewall is configured to filter incoming 684 tunneled data, the firewall SHOULD provide the capability to 685 filter decapsulated packets from a tunnel. 687 5. IANA Considerations 689 This document has no actions for IANA. 691 6. Acknowledgements 693 Thanks to the following people (in alphabetical order) for their 694 guidance and feedback: 696 Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott 697 Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos 698 Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, 699 Alain Durand, Katsunori Fukuoka, Tony Hain, Thomas Herbst, Ray 700 Hunter, Kevin Johns, Erik Kline, Stephen Kramer, Victor Kuarsingh, 701 Francois-Xavier Le Bail, Arifumi Matsumoto, David Miles, Shin 702 Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos Pignataro, John 703 Pomeroy, Antonio Querubin, Daniel Roesen, Hiroki Sato, Teemu 704 Savolainen, Matt Schmitt, David Thaler, Mark Townsley, Bernie Volz, 705 Dan Wing, James Woodyatt, Carl Wuyts, and Cor Zwart. 707 This document is based in part on CableLabs' eRouter specification. 708 The authors wish to acknowledge the additional contributors from the 709 eRouter team: 711 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 712 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 713 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 714 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 715 Torbet, and Greg White. 717 7. Contributors 719 The following people have participated as co-authors or provided 720 substantial contributions to this document: Ralph Droms, Kirk 721 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 722 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. 724 8. References 726 8.1. Normative References 728 [I-D.droms-dhc-dhcpv6-maxsolrt-update] 729 Droms, R., "Modification to Default Value of MAX_SOL_RT", 730 draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in 731 progress), November 2011. 733 [I-D.ietf-dhc-pd-exclude] 734 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 735 "Prefix Exclude Option for DHCPv6-based Prefix 736 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 737 progress), December 2011. 739 [I-D.ietf-pcp-base] 740 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 741 Selkirk, "Port Control Protocol (PCP)", 742 draft-ietf-pcp-base-24 (work in progress), March 2012. 744 [RFC1122] Braden, R., "Requirements for Internet Hosts - 745 Communication Layers", STD 3, RFC 1122, October 1989. 747 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 748 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 754 RFC 2131, March 1997. 756 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 757 Networks", RFC 2464, December 1998. 759 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 760 Defeating Denial of Service Attacks which employ IP Source 761 Address Spoofing", BCP 38, RFC 2827, May 2000. 763 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 764 and M. Carney, "Dynamic Host Configuration Protocol for 765 IPv6 (DHCPv6)", RFC 3315, July 2003. 767 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 768 Host Configuration Protocol (DHCP) version 6", RFC 3633, 769 December 2003. 771 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 772 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 773 December 2003. 775 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 776 Networks", BCP 84, RFC 3704, March 2004. 778 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 779 (DHCP) Service for IPv6", RFC 3736, April 2004. 781 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 782 Configuration Option for DHCPv6", RFC 4075, May 2005. 784 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 785 More-Specific Routes", RFC 4191, November 2005. 787 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 788 Addresses", RFC 4193, October 2005. 790 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 791 Time Option for Dynamic Host Configuration Protocol for 792 IPv6 (DHCPv6)", RFC 4242, November 2005. 794 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 795 Message Protocol (ICMPv6) for the Internet Protocol 796 Version 6 (IPv6) Specification", RFC 4443, March 2006. 798 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 799 "Internet Group Management Protocol (IGMP) / Multicast 800 Listener Discovery (MLD)-Based Multicast Forwarding 801 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 803 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 804 (CIDR): The Internet Address Assignment and Aggregation 805 Plan", BCP 122, RFC 4632, August 2006. 807 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 808 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 809 Access Networks", RFC 4779, January 2007. 811 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 812 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 813 September 2007. 815 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 816 Address Autoconfiguration", RFC 4862, September 2007. 818 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 819 E. Klein, "Local Network Protection for IPv6", RFC 4864, 820 May 2007. 822 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 823 PPP", RFC 5072, September 2007. 825 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 826 Model: The Relationship between Links and Subnet 827 Prefixes", RFC 5942, July 2010. 829 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 830 Infrastructures (6rd) -- Protocol Specification", 831 RFC 5969, August 2010. 833 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 834 Customer Premises Equipment (CPE) for Providing 835 Residential IPv6 Internet Service", RFC 6092, 836 January 2011. 838 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 839 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 841 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 842 Stack Lite Broadband Deployments Following IPv4 843 Exhaustion", RFC 6333, August 2011. 845 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 846 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 847 RFC 6334, August 2011. 849 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 850 Requirements", RFC 6434, December 2011. 852 8.2. Informative References 854 [I-D.troan-dhc-dhcpv6-stateful-issues] 855 Troan, O. and B. Volz, "Issues with multiple stateful 856 DHCPv6 options", draft-troan-dhc-dhcpv6-stateful-issues-00 857 (work in progress), March 2012. 859 [MULTIHOMING-WITHOUT-NAT] 860 Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 861 and D. Wing, "IPv6 Multihoming without Network Address 862 Translation", Work in Progress, December 2010. 864 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 865 IPv4/IPv6 Translation", RFC 6144, March 2011. 867 [UPnP-IGD] 868 UPnP Forum, "Universal Plug and Play (UPnP) Internet 869 Gateway Device (IGD)", November 2001, 870 . 872 Appendix A. Changes from RFC 6204 874 1. Added IP transition technologies available in RFC form. 876 2. Changed bullet G-5 to augment the condition of losing IPv6 877 default router(s) with loss of connectivity. 879 3. Removed bullet WAA-7 due to not reaching consensus by various 880 service provider standards bodies. The removal of text does not 881 remove any critical functionality from the CE specification. 883 4. Changed bullet WAA-8 to qualify WAN behavior only if not 884 configured to perform DHCPv6. This way a deployment specific 885 profile can mandate DHCPv6 numbered WAN without conflicting with 886 this document. 888 5. Changed the WPD-2 bullet from MUST be configurable to SHOULD be 889 configurable. 891 6. Changed bullet WPD-4 for a default behavior without compromising 892 any prior specification of the CE device. The change was needed 893 by a specific layer 1 deployment which wanted to specify a MUST 894 for DHCPv6 in their layer 1 profile and not conflict with this 895 document. 897 7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5 898 and WPD-5 because the text does not have consensus from the IETF 899 DHC Working Group for what the final solution related to the 900 removed bullets will be. 902 8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 903 that if an service provider does not have DHCPv6 service enabled 904 CE routers do not send too frequent DHCPv6 requests to the 905 service provider DHCPv6 server. 907 9. Changed bullet L-11 from SHOULD provide DNS options in the RA to 908 MUST provide DNS option in the RA. 910 10. New bullet added to the Security Considerations section due to 911 addition of transition technology. The CE router filters 912 decapsulated 6rd data. 914 11. Minor change involved changing ICMP to ICMPv6. 916 12. Added PCP client requirement for the WAN. 918 13. Added a requirement for the DHCPv6 pd-exclude option. 920 Authors' Addresses 922 Hemant Singh 923 Cisco Systems, Inc. 924 1414 Massachusetts Ave. 925 Boxborough, MA 01719 926 USA 928 Phone: +1 978 936 1622 929 EMail: shemant@cisco.com 930 URI: http://www.cisco.com/ 932 Wes Beebee 933 Cisco Systems, Inc. 934 1414 Massachusetts Ave. 935 Boxborough, MA 01719 936 USA 938 Phone: +1 978 936 2030 939 EMail: wbeebee@cisco.com 940 URI: http://www.cisco.com/ 942 Chris Donley 943 CableLabs 944 858 Coal Creek Circle 945 Louisville, CO 80027 946 USA 948 EMail: c.donley@cablelabs.com 950 Barbara Stark 951 AT&T 952 725 W Peachtree St. 953 Atlanta, GA 30308 954 USA 956 EMail: barbara.stark@att.com 957 Ole Troan (editor) 958 Cisco Systems, Inc. 959 Telemarksvingen 20 960 N-0655 OSLO, 961 Norway 963 EMail: ot@cisco.com