idnits 2.17.1 draft-ietf-v6ops-6204bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1102' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC1104' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC6106' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 818, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** 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 6204 (Obsoleted by RFC 7084) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) Summary: 9 errors (**), 0 flaws (~~), 8 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: September 7, 2012 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 March 6, 2012 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-6204bis-06 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 September 7, 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 . . . . . . . . . . . . . . . . . 14 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 This document defines basic IPv6 features for a residential or small- 86 office router, referred to as an IPv6 CE router. Typically, these 87 routers also support IPv4. 89 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 90 the CE router) can be more complex if the IPv6-only devices are using 91 a translator to access IPv4 servers [RFC6144]. Support for such 92 mixed environments is not in scope of this document. 94 This document specifies how an IPv6 CE router automatically 95 provisions its WAN interface, acquires address space for provisioning 96 of its LAN interfaces, and fetches other configuration information 97 from the service provider network. Automatic provisioning of more 98 complex topology than a single router with multiple LAN interfaces is 99 out of scope for this document. 101 See [RFC4779] for a discussion of options available for deploying 102 IPv6 in service provider access networks. 104 The document also covers IP transition technologies. Two transition 105 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in 106 the document. At the time of writing this document these were the 107 only two transition technologies available in RFC form to be included 108 in this document. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Terminology 118 End-User Network one or more links attached to the IPv6 CE 119 router that connect IPv6 hosts. 121 IPv6 Customer Edge Router a node intended for home or small-office 122 use that forwards IPv6 packets not 123 explicitly addressed to itself. The IPv6 124 CE router connects the end-user network to 125 a service provider network. 127 IPv6 Host any device implementing an IPv6 stack 128 receiving IPv6 connectivity through the 129 IPv6 CE router. 131 LAN Interface an IPv6 CE router's attachment to a link in 132 the end-user network. Examples are 133 Ethernets (simple or bridged), 802.11 134 wireless, or other LAN technologies. An 135 IPv6 CE router may have one or more 136 network-layer LAN interfaces. 138 Service Provider an entity that provides access to the 139 Internet. In this document, a service 140 provider specifically offers Internet 141 access using IPv6, and may also offer IPv4 142 Internet access. The service provider can 143 provide such access over a variety of 144 different transport methods such as DSL, 145 cable, wireless, and others. 147 WAN Interface an IPv6 CE router's attachment to a link 148 used to provide connectivity to the service 149 provider network; example link technologies 150 include Ethernets (simple or bridged), PPP 151 links, Frame Relay, or ATM networks, as 152 well as Internet-layer (or higher-layer) 153 "tunnels", such as tunnels over IPv4 or 154 IPv6 itself. 156 3. Architecture 158 3.1. Current IPv4 End-User Network Architecture 160 An end-user network will likely support both IPv4 and IPv6. It is 161 not expected that an end-user will change their existing network 162 topology with the introduction of IPv6. There are some differences 163 in how IPv6 works and is provisioned; these differences have 164 implications for the network architecture. A typical IPv4 end-user 165 network consists of a "plug and play" router with NAT functionality 166 and a single link behind it, connected to the service provider 167 network. 169 A typical IPv4 NAT deployment by default blocks all incoming 170 connections. Opening of ports is typically allowed using a Universal 171 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 172 other firewall control protocol. 174 Another consequence of using private address space in the end-user 175 network is that it provides stable addressing; i.e., it never changes 176 even when you change service providers, and the addresses are always 177 there even when the WAN interface is down or the customer edge router 178 has not yet been provisioned. 180 Rewriting addresses on the edge of the network also allows for some 181 rudimentary multihoming, even though using NATs for multihoming does 182 not preserve connections during a fail-over event [RFC4864]. 184 Many existing routers support dynamic routing, and advanced end-users 185 can build arbitrary, complex networks using manual configuration of 186 address prefixes combined with a dynamic routing protocol. 188 3.2. IPv6 End-User Network Architecture 190 The end-user network architecture for IPv6 should provide equivalent 191 or better capabilities and functionality than the current IPv4 192 architecture. 194 The end-user network is a stub network. Figure 1 illustrates the 195 model topology for the end-user network. 197 +-------+-------+ \ 198 | Service | \ 199 | Provider | | Service 200 | Router | | Provider 201 +-------+-------+ | network 202 | / 203 | Customer / 204 | Internet connection / 205 | 206 +------+--------+ \ 207 | IPv6 | \ 208 | Customer Edge | \ 209 | Router | / 210 +---+-------+-+-+ / 211 Network A | | Network B | End-User 212 ---+-------------+----+- --+--+-------------+--- | network(s) 213 | | | | \ 214 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 215 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 216 | | | | | | | | / 217 +----------+ +-----+----+ +----------+ +----------+ / 219 Figure 1: An Example of a Typical End-User Network 221 This architecture describes the: 223 o Basic capabilities of an IPv6 CE router 225 o Provisioning of the WAN interface connecting to the service 226 provider 228 o Provisioning of the LAN interfaces 230 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 231 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 232 multicast routing protocol. 234 The IPv6 CE router may be manually configured in an arbitrary 235 topology with a dynamic routing protocol. Automatic provisioning and 236 configuration are described for a single IPv6 CE router only. 238 3.2.1. Local Communication 240 Link-local IPv6 addresses are used by hosts communicating on a single 241 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 242 by hosts communicating within the end-user network across multiple 243 links, but without requiring the application to use a globally 244 routable address. The IPv6 CE router defaults to acting as the 245 demarcation point between two networks by providing a ULA boundary, a 246 multicast zone boundary, and ingress and egress traffic filters. 248 At the time of this writing, several host implementations do not 249 handle the case where they have an IPv6 address configured and no 250 IPv6 connectivity, either because the address itself has a limited 251 topological reachability (e.g., ULA) or because the IPv6 CE router is 252 not connected to the IPv6 network on its WAN interface. To support 253 host implementations that do not handle multihoming in a multi-prefix 254 environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 255 as detailed in the requirements below, advertise itself as a default 256 router on the LAN interface(s) when it does not have IPv6 257 connectivity on the WAN interface or when it is not provisioned with 258 IPv6 addresses. For local IPv6 communication, the mechanisms 259 specified in [RFC4191] are used. 261 ULA addressing is useful where the IPv6 CE router has multiple LAN 262 interfaces with hosts that need to communicate with each other. If 263 the IPv6 CE router has only a single LAN interface (IPv6 link), then 264 link-local addressing can be used instead. 266 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 267 conform to these recommendations, especially requirements ULA-5 and 268 L-4 below. 270 4. Requirements 272 4.1. General Requirements 274 The IPv6 CE router is responsible for implementing IPv6 routing; that 275 is, the IPv6 CE router must look up the IPv6 destination address in 276 its routing table to decide to which interface it should send the 277 packet. 279 In this role, the IPv6 CE router is responsible for ensuring that 280 traffic using its ULA addressing does not go out the WAN interface, 281 and does not originate from the WAN interface. 283 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 284 Requirements [RFC6434] specification. 286 G-2: The IPv6 CE router MUST implement ICMPv6 according to 287 [RFC4443]. In particular, point-to-point links MUST be handled 288 as described in Section 3.1 of [RFC4443]. 290 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 291 its LAN interface(s) and its WAN interface until the router has 292 successfully completed the IPv6 address and the delegated 293 prefix acquisition process. 295 G-4: By default, an IPv6 CE router that has no default router(s) on 296 its WAN interface MUST NOT advertise itself as an IPv6 default 297 router on its LAN interfaces. That is, the "Router Lifetime" 298 field is set to zero in all Router Advertisement messages it 299 originates [RFC4861]. 301 G-5: By default, if the IPv6 CE router is an advertising router and 302 loses its IPv6 default router(s) and/or detects loss of 303 connectivity on the WAN interface, it MUST explicitly 304 invalidate itself as an IPv6 default router on each of its 305 advertising interfaces by immediately transmitting one or more 306 Router Advertisement messages with the "Router Lifetime" field 307 set to zero [RFC4861]. 309 4.2. WAN-Side Configuration 311 The IPv6 CE router will need to support connectivity to one or more 312 access network architectures. This document describes an IPv6 CE 313 router that is not specific to any particular architecture or service 314 provider and that supports all commonly used architectures. 316 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 317 IPv6-supported link layer, and there is no need for a link-layer- 318 specific configuration protocol for IPv6 network-layer configuration 319 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 320 section makes the assumption that the same mechanism will work for 321 any link layer, be it Ethernet, the Data Over Cable Service Interface 322 Specification (DOCSIS), PPP, or others. 324 WAN-side requirements: 326 W-1: When the router is attached to the WAN interface link, it MUST 327 act as an IPv6 host for the purposes of stateless [RFC4862] or 328 stateful [RFC3315] interface address assignment. 330 W-2: The IPv6 CE router MUST generate a link-local address and 331 finish Duplicate Address Detection according to [RFC4862] prior 332 to sending any Router Solicitations on the interface. The 333 source address used in the subsequent Router Solicitation MUST 334 be the link-local address on the WAN interface. 336 W-3: Absent other routing information, the IPv6 CE router MUST use 337 Router Discovery as specified in [RFC4861] to discover a 338 default router(s) and install default route(s) in its routing 339 table with the discovered router's address as the next hop. 341 W-4: The router MUST act as a requesting router for the purposes of 342 DHCPv6 prefix delegation ([RFC3633]). 344 W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 345 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 346 network interface resets or IPv6 CE router reboots. 348 W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP 349 client as specified in [I-D.ietf-pcp-base] for use by 350 applications on the CE Router. This document takes no position 351 on whether such functionality is enabled by default or 352 mechanisms by which users would configure the functionality. 354 Link-layer requirements: 356 WLL-1: If the WAN interface supports Ethernet encapsulation, then 357 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 359 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 360 router MUST support IPv6 over PPP [RFC5072]. 362 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 363 stack environment with IPCP and IPV6CP running over one PPP 364 logical channel, the Network Control Protocols (NCPs) MUST be 365 treated as independent of each other and start and terminate 366 independently. 368 Address assignment requirements: 370 WAA-1: The IPv6 CE router MUST support Stateless Address 371 Autoconfiguration (SLAAC) [RFC4862]. 373 WAA-2: The IPv6 CE router MUST follow the recommendations in Section 374 4 of [RFC5942], and in particular the handling of the L flag 375 in the Router Advertisement Prefix Information option. 377 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 378 behavior. 380 WAA-4: The IPv6 CE router MUST be able to support the following 381 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 382 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 383 support the DNS Search List DNSSL option as specified in 384 [RFC3646]. 386 WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network 387 Time Protocol (SNTP) option [RFC4075] and the Information 388 Refresh Time option [RFC4242]. 390 WAA-6: If the IPv6 CE router receives a Router Advertisement message 391 (described in [RFC4861]) with the M flag set to 1, the IPv6 392 CE router MUST do DHCPv6 address assignment (request an IA_NA 393 option). 395 WAA-7: If the IPv6 CE router does not acquire global IPv6 396 address(es) from either SLAAC or DHCPv6, then it MUST create 397 global IPv6 address(es) from its delegated prefix(es) and 398 configure those on one of its internal virtual network 399 interfaces, unless configured to require a global IPv6 400 address on the WAN interface. 402 WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option 403 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 404 Advertise or Reply message and set its internal SOL_MAX_RT 405 parameter to the value contained in the SOL_MAX_RT option. 407 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 408 (Weak ES) model [RFC1122]. When originating packets from an 409 interface, it will use a source address from another one of 410 its interfaces if the outgoing interface does not have an 411 address of suitable scope. 413 Prefix delegation requirements: 415 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 416 requesting router behavior as specified in [RFC3633] (IA_PD 417 option). The IPv6 CE Router SHOULD support the 418 [I-D.ietf-dhc-pd-exclude] PD-Exclude option. 420 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 421 router the size of the prefix it requires. If so, it MUST 422 ask for a prefix large enough to assign one /64 for each of 423 its interfaces, rounded up to the nearest nibble, and SHOULD 424 be configurable to ask for more. 426 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 427 prefix size different from what is given in the hint. If the 428 delegated prefix is too small to address all of its 429 interfaces, the IPv6 CE router SHOULD log a system management 430 error. 432 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 433 delegation when either the M or O flags are set to 1 in a 434 received Router Advertisement message. 436 WPD-5: If the delegated prefix(es) are aggregate route(s) of 437 multiple, more-specific routes, the IPv6 CE router MUST 438 discard packets that match the aggregate route(s), but not 439 any of the more-specific routes. In other words, the next 440 hop for the aggregate route(s) should be the null 441 destination. This is necessary to prevent forwarding loops 442 when some addresses covered by the aggregate are not 443 reachable [RFC4632]. 445 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 446 Unreachable message in accordance with Section 3.1 of 447 [RFC4443] back to the source of the packet, if the 448 packet is to be dropped due to this rule. 450 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD 451 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 452 Advertise/Reply messages, even if the message does not 453 contain any addresses, unless configured to only obtain its 454 WAN IPv6 address via DHCPv6. 456 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic 457 routing protocol on its WAN interface. 459 4.3. LAN-Side Configuration 461 The IPv6 CE router distributes configuration information obtained 462 during WAN interface provisioning to IPv6 hosts and assists IPv6 463 hosts in obtaining IPv6 addresses. It also supports connectivity of 464 these devices in the absence of any working WAN interface. 466 An IPv6 CE router is expected to support an IPv6 end-user network and 467 IPv6 hosts that exhibit the following characteristics: 469 1. Link-local addresses may be insufficient for allowing IPv6 470 applications to communicate with each other in the end-user 471 network. The IPv6 CE router will need to enable this 472 communication by providing globally scoped unicast addresses or 473 ULAs [RFC4193], whether or not WAN connectivity exists. 475 2. IPv6 hosts should be capable of using SLAAC and may be capable of 476 using DHCPv6 for acquiring their addresses. 478 3. IPv6 hosts may use DHCPv6 for other configuration information, 479 such as the DNS_SERVERS option for acquiring DNS information. 481 Unless otherwise specified, the following requirements apply to the 482 IPv6 CE router's LAN interfaces only. 484 ULA requirements: 486 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 487 prefix [RFC4193]. 489 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 490 consistently across reboots. 492 ULA-3: The value of the ULA prefix SHOULD be user-configurable. 494 ULA-4: By default, the IPv6 CE router MUST act as a site border 495 router according to Section 4.3 of [RFC4193] and filter 496 packets with local IPv6 source or destination addresses 497 accordingly. 499 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 500 router with a Router Lifetime greater than zero whenever all 501 of its configured and delegated prefixes are ULA prefixes. 503 LAN requirements: 505 L-1: The IPv6 CE router MUST support router behavior according to 506 Neighbor Discovery for IPv6 [RFC4861]. 508 L-2: The IPv6 CE router MUST assign a separate /64 from its 509 delegated prefix(es) (and ULA prefix if configured to provide 510 ULA addressing) for each of its LAN interfaces. 512 L-3: An IPv6 CE router MUST advertise itself as a router for the 513 delegated prefix(es) (and ULA prefix if configured to provide 514 ULA addressing) using the "Route Information Option" specified 515 in Section 2.3 of [RFC4191]. This advertisement is 516 independent of having or not having IPv6 connectivity on the 517 WAN interface. 519 L-4: An IPv6 CE router MUST NOT advertise itself as a default 520 router with a Router Lifetime [RFC4861] greater than zero if 521 it has no prefixes configured or delegated to it. 523 L-5: The IPv6 CE router MUST make each LAN interface an advertising 524 interface according to [RFC4861]. 526 L-6: In Router Advertisement messages, the Prefix Information 527 option's A and L flags MUST be set to 1 by default. 529 L-7: The A and L flags' settings SHOULD be user-configurable. 531 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 532 IPv6 address assignment according to [RFC3315] OR a stateless 533 DHCPv6 server according to [RFC3736] on its LAN interfaces. 535 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 536 IA_NA option, it SHOULD set the M flag to 0 and the O flag to 537 1 in its Router Advertisement messages [RFC4861]. 539 L-10: The IPv6 CE router MUST support providing DNS information in 540 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 542 L-11: The IPv6 CE router MUST support providing DNS information in 543 the Router Advertisement Recursive DNS Server (RDNSS) and 544 DNSSL options. 546 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 547 options (as listed in Section 5.3 of [RFC3736]) received from 548 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 549 server. 551 L-13: If the delegated prefix changes, i.e., the current prefix is 552 replaced with a new prefix without any overlapping time 553 period, then the IPv6 CE router MUST immediately advertise the 554 old prefix with a Preferred Lifetime of zero and a Valid 555 Lifetime of either a) zero, or b) the lower of the current 556 Valid Lifetime and two hours (which must be decremented in 557 real time) in a Router Advertisement message as described in 558 Section 5.5.3, (e) of [RFC4862]. 560 L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 561 message, code 5 (Source address failed ingress/egress policy) 562 for packets forwarded to it that use an address from a prefix 563 that has been deprecated. 565 4.4. Transition Technologies Support 567 4.4.1. 6rd 569 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to 570 advance deployment of IPv6 to end users via a service provider's IPv4 571 network infrastructure. Key aspects include automatic IPv6 prefix 572 delegation to sites, stateless operation, simple provisioning, and 573 service that is equivalent to native IPv6 at the sites that are 574 served by the mechanism. It is expected that such traffic is 575 forwarded over the CE Router's native IPv4 WAN interface, and not 576 encapsulated in another tunnel. 578 The CE Router SHOULD support 6rd functionality. If 6rd is supported, 579 it MUST be implemented according to [RFC5969]. The following CE 580 Requirements also apply: 582 . 584 6rd requirements: 586 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd 587 DHCPv4 Option (212). If the CE router has obtained an IPv4 588 network address through some other means such PPP, it SHOULD 589 use the DHCPINFORM request message [RFC2131] to request the 590 6rd DHCPv4 Option. The IPv6 CE router MAY use other 591 mechanisms to configure 6rd parameters. Such mechanisms are 592 outside the scope of this document. 594 6RD-2: If the IPv6 CE router is capable of automated configuration 595 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 596 support user-entered configuration of 6rd. 598 6RD-3: If the CE router supports configuration mechanisms other than 599 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE 600 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub 601 and spoke" requires all IPv6 traffic to go to the 6rd Border 602 Relay. In effect, this requirement removes the "direct 603 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. 605 4.4.2. Dual-Stack Lite (DS-Lite) 607 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 608 services and incentives for the deployment of IPv6. It also de- 609 couples IPv6 deployment in the Service Provider network from the rest 610 of the Internet, making incremental deployment easier. Dual-Stack 611 Lite enables a broadband service provider to share IPv4 addresses 612 among customers by combining two well-known technologies: IP in IP 613 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected 614 that DS-Lite traffic is forwarded over the CE Router's native IPv6 615 WAN interface, and not encapsulated in another tunnel. 617 The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS- 618 Lite is supported, it MUST be implemented according to [RFC6333]. 619 The following CE Router requirements also apply: 621 WAN requirements: 623 DLW-1: The CE Router MUST support DS-Lite via the DS-Lite DHCPv6 624 option [RFC6334]. The IPv6 CE Router MAY use other 625 mechanisms to configure DS-Lite parameters. Such mechanisms 626 are outside the scope of this document. 628 DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address 629 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 631 DLW-3: If the IPv6 CE Router is configured with an IPv4 address on 632 its WAN interface then the IPv6 CE Router SHOULD disable the 633 DS-Lite B4 element. 635 4.5. Security Considerations 637 It is considered a best practice to filter obviously malicious 638 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 639 the IPv6 CE router ought to support basic stateless egress and 640 ingress filters. The CE router is also expected to offer mechanisms 641 to filter traffic entering the customer network; however, the method 642 by which vendors implement configurable packet filtering is beyond 643 the scope of this document. 645 Security requirements: 647 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 648 the IPv6 CE router SHOULD support functionality sufficient for 649 implementing the set of recommendations in [RFC6092], 650 Section 4. This document takes no position on whether such 651 functionality is enabled by default or mechanisms by which 652 users would configure it. 654 S-2: The IPv6 CE router SHOULD support ingress filtering in 655 accordance with BCP 38 [RFC2827]. 657 S-3: If the IPv6 CE router firewall is configured to filter incoming 658 tunneled data, the firewall SHOULD provide the capability to 659 filter decapsulated packets from a tunnel. 661 5. Acknowledgements 663 Thanks to the following people (in alphabetical order) for their 664 guidance and feedback: 666 Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker, Mohamed 667 Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou, 668 Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand, 669 Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline, 670 Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi 671 Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael 672 Newbery, Carlos Pignataro, John Pomeroy, Antonio Querubin, Hiroki 673 Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark Townsley, 674 Bernie Volz, Dan Wing, James Woodyatt, Carl Wuyts, and Cor Zwart. 676 This document is based in part on CableLabs' eRouter specification. 677 The authors wish to acknowledge the additional contributors from the 678 eRouter team: 680 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 681 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 682 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 683 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 684 Torbet, and Greg White. 686 6. Contributors 688 The following people have participated as co-authors or provided 689 substantial contributions to this document: Ralph Droms, Kirk 690 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 691 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. 693 7. References 695 7.1. Normative References 697 [I-D.droms-dhc-dhcpv6-maxsolrt-update] 698 Droms, R., "Modification to Default Value of MAX_SOL_RT", 699 draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in 700 progress), November 2011. 702 [I-D.ietf-dhc-pd-exclude] 703 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 704 "Prefix Exclude Option for DHCPv6-based Prefix 705 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 706 progress), December 2011. 708 [I-D.ietf-pcp-base] 709 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. 710 Penno, "Port Control Protocol (PCP)", 711 draft-ietf-pcp-base-23 (work in progress), February 2012. 713 [RFC1102] Clark, D., "Policy routing in Internet protocols", 714 RFC 1102, May 1989. 716 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 717 June 1989. 719 [RFC1122] Braden, R., "Requirements for Internet Hosts - 720 Communication Layers", STD 3, RFC 1122, October 1989. 722 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 723 E. Lear, "Address Allocation for Private Internets", 724 BCP 5, RFC 1918, February 1996. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 730 RFC 2131, March 1997. 732 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 733 Networks", RFC 2464, December 1998. 735 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 736 Defeating Denial of Service Attacks which employ IP Source 737 Address Spoofing", BCP 38, RFC 2827, May 2000. 739 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 740 and M. Carney, "Dynamic Host Configuration Protocol for 741 IPv6 (DHCPv6)", RFC 3315, July 2003. 743 [RFC3484] Draves, R., "Default Address Selection for Internet 744 Protocol version 6 (IPv6)", RFC 3484, February 2003. 746 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 747 Host Configuration Protocol (DHCP) version 6", RFC 3633, 748 December 2003. 750 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 751 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 752 December 2003. 754 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 755 (DHCP) Service for IPv6", RFC 3736, April 2004. 757 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 758 Configuration Option for DHCPv6", RFC 4075, May 2005. 760 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 761 More-Specific Routes", RFC 4191, November 2005. 763 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 764 Addresses", RFC 4193, October 2005. 766 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 767 Time Option for Dynamic Host Configuration Protocol for 768 IPv6 (DHCPv6)", RFC 4242, November 2005. 770 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 771 Message Protocol (ICMPv6) for the Internet Protocol 772 Version 6 (IPv6) Specification", RFC 4443, March 2006. 774 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 775 "Internet Group Management Protocol (IGMP) / Multicast 776 Listener Discovery (MLD)-Based Multicast Forwarding 777 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 779 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 780 (CIDR): The Internet Address Assignment and Aggregation 781 Plan", BCP 122, RFC 4632, August 2006. 783 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 784 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 785 Access Networks", RFC 4779, January 2007. 787 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 788 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 789 September 2007. 791 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 792 Address Autoconfiguration", RFC 4862, September 2007. 794 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 795 E. Klein, "Local Network Protection for IPv6", RFC 4864, 796 May 2007. 798 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 799 PPP", RFC 5072, September 2007. 801 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 802 Model: The Relationship between Links and Subnet 803 Prefixes", RFC 5942, July 2010. 805 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 806 Infrastructures (6rd) -- Protocol Specification", 807 RFC 5969, August 2010. 809 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 810 Customer Premises Equipment (CPE) for Providing 811 Residential IPv6 Internet Service", RFC 6092, 812 January 2011. 814 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 815 "IPv6 Router Advertisement Options for DNS Configuration", 816 RFC 6106, November 2010. 818 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 819 Troan, "Basic Requirements for IPv6 Customer Edge 820 Routers", RFC 6204, April 2011. 822 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 823 Stack Lite Broadband Deployments Following IPv4 824 Exhaustion", RFC 6333, August 2011. 826 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 827 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 828 RFC 6334, August 2011. 830 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 831 Requirements", RFC 6434, December 2011. 833 7.2. Informative References 835 [MULTIHOMING-WITHOUT-NAT] 836 Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 837 and D. Wing, "IPv6 Multihoming without Network Address 838 Translation", Work in Progress, December 2010. 840 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 841 IPv4/IPv6 Translation", RFC 6144, March 2011. 843 [UPnP-IGD] 844 UPnP Forum, "Universal Plug and Play (UPnP) Internet 845 Gateway Device (IGD)", November 2001, 846 . 848 Appendix A. Changes from RFC 6204 850 1. Added IP transition technologies available in RFC form. 852 2. Changed bullet G-5 to augment the condition of losing IPv6 853 default router(s) with loss of connectivity. 855 3. Removed bullet WAA-7 due to not reaching consensus by various 856 service provider standards bodies. The removal of text does not 857 remove any critical functionality from the CE specification. 859 4. Changed bullet WAA-8 to qualify WAN behavior only if not 860 configured to perform DHCPv6. This way a deployment specific 861 profile can mandate DHCPv6 numbered WAN wihout conflicting with 862 this document. 864 5. Changed the WPD-2 bullet from MUST be configurable to SHOULD be 865 configurable. 867 6. Changed bullet WPD-4 for a default behavior without compromising 868 any prior specification of the CE device. The change was needed 869 by a specific layer 1 deployment which wanted to specify a MUST 870 for DHCPv6 in their layer 1 profile and not conflict with this 871 document. 873 7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5 874 and WPD-5 beause the text does not have consensus from the IETF 875 DHC Working Group for what the final solution related to the 876 removed bullets is. 878 8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 879 that if an service provider does not have DHCPv6 service enabled 880 CE routers do not send too frequent DHCPv6 requests to the 881 service provider DHCPv6 server. 883 9. Changed bullet L-11 from SHOULD provide DNS options in the RA to 884 MUST provide DNS option in the RA. 886 10. New bullet added to the Security Considerations section due to 887 addition of transition technology. The CE router filters 888 decapsulated 6rd data. 890 11. Minor change involved changing ICMP to ICMPv6. 892 12. Added PCP client requirement for the WAN. 894 13. Added a requirement for the DHCPv6 pd-exclude option. 896 Authors' Addresses 898 Hemant Singh 899 Cisco Systems, Inc. 900 1414 Massachusetts Ave. 901 Boxborough, MA 01719 902 USA 904 Phone: +1 978 936 1622 905 EMail: shemant@cisco.com 906 URI: http://www.cisco.com/ 908 Wes Beebee 909 Cisco Systems, Inc. 910 1414 Massachusetts Ave. 911 Boxborough, MA 01719 912 USA 914 Phone: +1 978 936 2030 915 EMail: wbeebee@cisco.com 916 URI: http://www.cisco.com/ 918 Chris Donley 919 CableLabs 920 858 Coal Creek Circle 921 Louisville, CO 80027 922 USA 924 EMail: c.donley@cablelabs.com 925 Barbara Stark 926 AT&T 927 725 W Peachtree St. 928 Atlanta, GA 30308 929 USA 931 EMail: barbara.stark@att.com 933 Ole Troan (editor) 934 Cisco Systems, Inc. 935 Telemarksvingen 20 936 N-0655 OSLO, 937 Norway 939 EMail: ot@cisco.com