idnits 2.17.1 draft-ietf-v6ops-6204bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC6204, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2011) is 4523 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1102' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'RFC1104' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC6106' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 882, but no explicit reference was found in the text ** 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 4294 (Obsoleted by RFC 6434) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 6204 (Obsoleted by RFC 7084) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 Updates: 6204 (if approved) Cisco Systems, Inc. 5 Intended status: Informational C. Donley 6 Expires: June 7, 2012 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 December 5, 2011 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-6204bis-04 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 and transition technologies coexistence. Two transition 23 technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in 24 the document. 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 June 7, 2012. 43 Copyright Notice 45 Copyright (c) 2011 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.4.3. Transition Technologies Coexistence . . . . . . . . . 15 75 4.5. Security Considerations . . . . . . . . . . . . . . . . . 16 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 81 Appendix A. DS-Lite Sunsetting . . . . . . . . . . . . . . . . . 20 82 Appendix B. Changes from RFC 6204 . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 This document defines basic IPv6 features for a residential or small- 88 office router, referred to as an IPv6 CE router. Typically, these 89 routers 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 IP transition technologies and transition 107 technologies coexistence. Two transition technologies in 6rd 108 [RFC5969] and DS-Lite [RFC6333] are covered in the document. At the 109 time of writing this document these were the only two transition 110 technologies available in RFC form to be included in this document. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Terminology 120 End-User Network one or more links attached to the IPv6 CE 121 router that connect IPv6 hosts. 123 IPv6 Customer Edge Router a node intended for home or small-office 124 use that forwards IPv6 packets not 125 explicitly addressed to itself. The IPv6 126 CE router connects the end-user network to 127 a service provider network. 129 IPv6 Host any device implementing an IPv6 stack 130 receiving IPv6 connectivity through the 131 IPv6 CE router. 133 LAN Interface an IPv6 CE router's attachment to a link in 134 the end-user network. Examples are 135 Ethernets (simple or bridged), 802.11 136 wireless, or other LAN technologies. An 137 IPv6 CE router may have one or more 138 network-layer LAN interfaces. 140 Service Provider an entity that provides access to the 141 Internet. In this document, a service 142 provider specifically offers Internet 143 access using IPv6, and may also offer IPv4 144 Internet access. The service provider can 145 provide such access over a variety of 146 different transport methods such as DSL, 147 cable, wireless, and others. 149 WAN Interface an IPv6 CE router's attachment to a link 150 used to provide connectivity to the service 151 provider network; example link technologies 152 include Ethernets (simple or bridged), PPP 153 links, Frame Relay, or ATM networks, as 154 well as Internet-layer (or higher-layer) 155 "tunnels", such as tunnels over IPv4 or 156 IPv6 itself. 158 3. Architecture 160 3.1. Current IPv4 End-User Network Architecture 162 An end-user network will likely support both IPv4 and IPv6. It is 163 not expected that an end-user will change their existing network 164 topology with the introduction of IPv6. There are some differences 165 in how IPv6 works and is provisioned; these differences have 166 implications for the network architecture. A typical IPv4 end-user 167 network consists of a "plug and play" router with NAT functionality 168 and a single link behind it, connected to the service provider 169 network. 171 A typical IPv4 NAT deployment by default blocks all incoming 172 connections. Opening of ports is typically allowed using a Universal 173 Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 174 other firewall control protocol. 176 Another consequence of using private address space in the end-user 177 network is that it provides stable addressing; i.e., it never changes 178 even when you change service providers, and the addresses are always 179 there even when the WAN interface is down or the customer edge router 180 has not yet been provisioned. 182 Rewriting addresses on the edge of the network also allows for some 183 rudimentary multihoming, even though using NATs for multihoming does 184 not preserve connections during a fail-over event [RFC4864]. 186 Many existing routers support dynamic routing, and advanced end-users 187 can build arbitrary, complex networks using manual configuration of 188 address prefixes combined with a dynamic routing protocol. 190 3.2. IPv6 End-User Network Architecture 192 The end-user network architecture for IPv6 should provide equivalent 193 or better capabilities and functionality than the current IPv4 194 architecture. 196 The end-user network is a stub network. Figure 1 illustrates the 197 model topology for the end-user network. 199 +-------+-------+ \ 200 | Service | \ 201 | Provider | | Service 202 | Router | | Provider 203 +-------+-------+ | network 204 | / 205 | Customer / 206 | Internet connection / 207 | 208 +------+--------+ \ 209 | IPv6 | \ 210 | Customer Edge | \ 211 | Router | / 212 +---+-------+-+-+ / 213 Network A | | Network B | End-User 214 ---+-------------+----+- --+--+-------------+--- | network(s) 215 | | | | \ 216 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 217 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 218 | | | | | | | | / 219 +----------+ +-----+----+ +----------+ +----------+ / 221 Figure 1: An Example of a Typical End-User Network 223 This architecture describes the: 225 o Basic capabilities of an IPv6 CE router 227 o Provisioning of the WAN interface connecting to the service 228 provider 230 o Provisioning of the LAN interfaces 232 For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 233 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 234 multicast routing protocol. 236 The IPv6 CE router may be manually configured in an arbitrary 237 topology with a dynamic routing protocol. Automatic provisioning and 238 configuration are described for a single IPv6 CE router only. 240 3.2.1. Local Communication 242 Link-local IPv6 addresses are used by hosts communicating on a single 243 link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 244 by hosts communicating within the end-user network across multiple 245 links, but without requiring the application to use a globally 246 routable address. The IPv6 CE router defaults to acting as the 247 demarcation point between two networks by providing a ULA boundary, a 248 multicast zone boundary, and ingress and egress traffic filters. 250 At the time of this writing, several host implementations do not 251 handle the case where they have an IPv6 address configured and no 252 IPv6 connectivity, either because the address itself has a limited 253 topological reachability (e.g., ULA) or because the IPv6 CE router is 254 not connected to the IPv6 network on its WAN interface. To support 255 host implementations that do not handle multihoming in a multi-prefix 256 environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 257 as detailed in the requirements below, advertise itself as a default 258 router on the LAN interface(s) when it does not have IPv6 259 connectivity on the WAN interface or when it is not provisioned with 260 IPv6 addresses. For local IPv6 communication, the mechanisms 261 specified in [RFC4191] are used. 263 ULA addressing is useful where the IPv6 CE router has multiple LAN 264 interfaces with hosts that need to communicate with each other. If 265 the IPv6 CE router has only a single LAN interface (IPv6 link), then 266 link-local addressing can be used instead. 268 Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to 269 conform to these recommendations, especially requirements ULA-5 and 270 L-4 below. 272 4. Requirements 274 4.1. General Requirements 276 The IPv6 CE router is responsible for implementing IPv6 routing; that 277 is, the IPv6 CE router must look up the IPv6 destination address in 278 its routing table to decide to which interface it should send the 279 packet. 281 In this role, the IPv6 CE router is responsible for ensuring that 282 traffic using its ULA addressing does not go out the WAN interface, 283 and does not originate from the WAN interface. 285 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 286 Requirements [RFC4294] specification. 288 G-2: The IPv6 CE router MUST implement ICMPv6 according to 289 [RFC4443]. In particular, point-to-point links MUST be handled 290 as described in Section 3.1 of [RFC4443]. 292 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 293 its LAN interface(s) and its WAN interface until the router has 294 successfully completed the IPv6 address acquisition process. 296 G-4: By default, an IPv6 CE router that has no default router(s) on 297 its WAN interface MUST NOT advertise itself as an IPv6 default 298 router on its LAN interfaces. That is, the "Router Lifetime" 299 field is set to zero in all Router Advertisement messages it 300 originates [RFC4861]. 302 G-5: By default, if the IPv6 CE router is an advertising router and 303 loses its IPv6 default router(s) and/or detects loss of 304 connectivity on the WAN interface, it MUST explicitly 305 invalidate itself as an IPv6 default router on each of its 306 advertising interfaces by immediately transmitting one or more 307 Router Advertisement messages with the "Router Lifetime" field 308 set to zero [RFC4861]. 310 4.2. WAN-Side Configuration 312 The IPv6 CE router will need to support connectivity to one or more 313 access network architectures. This document describes an IPv6 CE 314 router that is not specific to any particular architecture or service 315 provider and that supports all commonly used architectures. 317 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 318 IPv6-supported link layer, and there is no need for a link-layer- 319 specific configuration protocol for IPv6 network-layer configuration 320 options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 321 section makes the assumption that the same mechanism will work for 322 any link layer, be it Ethernet, the Data Over Cable Service Interface 323 Specification (DOCSIS), PPP, or others. 325 WAN-side requirements: 327 W-1: When the router is attached to the WAN interface link, it MUST 328 act as an IPv6 host for the purposes of stateless [RFC4862] or 329 stateful [RFC3315] interface address assignment. 331 W-2: The IPv6 CE router MUST generate a link-local address and 332 finish Duplicate Address Detection according to [RFC4862] prior 333 to sending any Router Solicitations on the interface. The 334 source address used in the subsequent Router Solicitation MUST 335 be the link-local address on the WAN interface. 337 W-3: Absent other routing information, the IPv6 CE router MUST use 338 Router Discovery as specified in [RFC4861] to discover a 339 default router(s) and install default route(s) in its routing 340 table with the discovered router's address as the next hop. 342 W-4: The router MUST act as a requesting router for the purposes of 343 DHCPv6 prefix delegation ([RFC3633]). 345 W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation 346 (IA_PD) SHOULD be done as a single DHCPv6 session. 348 W-6: The IPv6 CE router MUST use a persistent DHCP Unique Identifier 349 (DUID) for DHCPv6 messages. The DUID MUST NOT change between 350 network interface resets or IPv6 CE router reboots. 352 Link-layer requirements: 354 WLL-1: If the WAN interface supports Ethernet encapsulation, then 355 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 357 WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE 358 router MUST support IPv6 over PPP [RFC5072]. 360 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 361 stack environment with IPCP and IPV6CP running over one PPP 362 logical channel, the Network Control Protocols (NCPs) MUST be 363 treated as independent of each other and start and terminate 364 independently. 366 Address assignment requirements: 368 WAA-1: The IPv6 CE router MUST support Stateless Address 369 Autoconfiguration (SLAAC) [RFC4862]. 371 WAA-2: The IPv6 CE router MUST follow the recommendations in Section 372 4 of [RFC5942], and in particular the handling of the L flag 373 in the Router Advertisement Prefix Information option. 375 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 376 behavior. 378 WAA-4: The IPv6 CE router MUST be able to support the following 379 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 380 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to 381 support the DNS Search List DNSSL option as specified in 382 [RFC3646]. 384 WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network 385 Time Protocol (SNTP) option [RFC4075] and the Information 386 Refresh Time option [RFC4242]. 388 WAA-6: If the IPv6 CE router receives a Router Advertisement message 389 (described in [RFC4861]) with the M flag set to 1, the IPv6 390 CE router MUST do DHCPv6 address assignment (request an IA_NA 391 option). 393 WAA-7: If the IPv6 CE router does not acquire global IPv6 394 address(es) from either SLAAC or DHCPv6, then it MUST create 395 global IPv6 address(es) from its delegated prefix(es) and 396 configure those on one of its internal virtual network 397 interfaces, unless explicitly configured to require a global 398 IPv6 address on the WAN interface. 400 WAA-8: The CE Router MUST parse the DHCPv6 SOL_MAX_RT option 401 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 402 Advertise or Reply message and set its internal SOL_MAX_RT 403 parameter to the value contained in the SOL_MAX_RT option. 405 WAA-9: As a router, the IPv6 CE router MUST follow the weak host 406 (Weak ES) model [RFC1122]. When originating packets from an 407 interface, it will use a source address from another one of 408 its interfaces if the outgoing interface does not have an 409 address of suitable scope. 411 Prefix delegation requirements: 413 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 414 requesting router behavior as specified in [RFC3633] (IA_PD 415 option). 417 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 418 router the size of the prefix it requires. If so, it MUST 419 ask for a prefix large enough to assign one /64 for each of 420 its interfaces, rounded up to the nearest nibble, and SHOULD 421 be configurable to ask for more. 423 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 424 prefix size different from what is given in the hint. If the 425 delegated prefix is too small to address all of its 426 interfaces, the IPv6 CE router SHOULD log a system management 427 error. 429 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix 430 delegation when either the M or O flags are set to 1 in a 431 received Router Advertisement message. 433 WPD-5: If the IPv6 CE router is configured to initiate DHCPv6 before 434 receiving a Router Advertisement, it MUST also request an 435 IA_NA option in DHCPv6. 437 WPD-6: If the delegated prefix(es) are aggregate route(s) of 438 multiple, more-specific routes, the IPv6 CE router MUST 439 discard packets that match the aggregate route(s), but not 440 any of the more-specific routes. In other words, the next 441 hop for the aggregate route(s) should be the null 442 destination. This is necessary to prevent forwarding loops 443 when some addresses covered by the aggregate are not 444 reachable [RFC4632]. 446 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 447 Unreachable message in accordance with Section 3.1 of 448 [RFC4443] back to the source of the packet, if the 449 packet is to be dropped due to this rule. 451 WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD 452 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 453 Advertise/Reply messages, even if the message does not 454 contain any addresses, unless explicitly configured to only 455 obtain its WAN IPv6 address via DHCPv6. 457 WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic 458 routing protocol on its WAN interface. 460 4.3. LAN-Side Configuration 462 The IPv6 CE router distributes configuration information obtained 463 during WAN interface provisioning to IPv6 hosts and assists IPv6 464 hosts in obtaining IPv6 addresses. It also supports connectivity of 465 these devices in the absence of any working WAN interface. 467 An IPv6 CE router is expected to support an IPv6 end-user network and 468 IPv6 hosts that exhibit the following characteristics: 470 1. Link-local addresses may be insufficient for allowing IPv6 471 applications to communicate with each other in the end-user 472 network. The IPv6 CE router will need to enable this 473 communication by providing globally scoped unicast addresses or 474 ULAs [RFC4193], whether or not WAN connectivity exists. 476 2. IPv6 hosts should be capable of using SLAAC and may be capable of 477 using DHCPv6 for acquiring their addresses. 479 3. IPv6 hosts may use DHCPv6 for other configuration information, 480 such as the DNS_SERVERS option for acquiring DNS information. 482 Unless otherwise specified, the following requirements apply to the 483 IPv6 CE router's LAN interfaces only. 485 ULA requirements: 487 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 488 prefix [RFC4193]. 490 ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 491 consistently across reboots. 493 ULA-3: The value of the ULA prefix SHOULD be user-configurable. 495 ULA-4: By default, the IPv6 CE router MUST act as a site border 496 router according to Section 4.3 of [RFC4193] and filter 497 packets with local IPv6 source or destination addresses 498 accordingly. 500 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 501 router with a Router Lifetime greater than zero whenever all 502 of its configured and delegated prefixes are ULA prefixes. 504 LAN requirements: 506 L-1: The IPv6 CE router MUST support router behavior according to 507 Neighbor Discovery for IPv6 [RFC4861]. 509 L-2: The IPv6 CE router MUST assign a separate /64 from its 510 delegated prefix(es) (and ULA prefix if configured to provide 511 ULA addressing) for each of its LAN interfaces. 513 L-3: An IPv6 CE router MUST advertise itself as a router for the 514 delegated prefix(es) (and ULA prefix if configured to provide 515 ULA addressing) using the "Route Information Option" specified 516 in Section 2.3 of [RFC4191]. This advertisement is 517 independent of having or not having IPv6 connectivity on the 518 WAN interface. 520 L-4: An IPv6 CE router MUST NOT advertise itself as a default 521 router with a Router Lifetime [RFC4861] greater than zero if 522 it has no prefixes configured or delegated to it. 524 L-5: The IPv6 CE router MUST make each LAN interface an advertising 525 interface according to [RFC4861]. 527 L-6: In Router Advertisement messages, the Prefix Information 528 option's A and L flags MUST be set to 1 by default. 530 L-7: The A and L flags' settings SHOULD be user-configurable. 532 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 533 IPv6 address assignment according to [RFC3315] OR a stateless 534 DHCPv6 server according to [RFC3736] on its LAN interfaces. 536 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 537 IA_NA option, it SHOULD set the M flag to 0 and the O flag to 538 1 in its Router Advertisement messages [RFC4861]. 540 L-10: The IPv6 CE router MUST support providing DNS information in 541 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 543 L-11: The IPv6 CE router MUST support providing DNS information in 544 the Router Advertisement Recursive DNS Server (RDNSS) and 545 DNSSL options. 547 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 548 options (as listed in Section 5.3 of [RFC3736]) received from 549 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 550 server. 552 L-13: If the delegated prefix changes, i.e., the current prefix is 553 replaced with a new prefix without any overlapping time 554 period, then the IPv6 CE router MUST immediately advertise the 555 old prefix with a Preferred Lifetime of zero and a Valid 556 Lifetime of the lower of the current Valid Lifetime and two 557 hours (which must be decremented in real time) in a Router 558 Advertisement message as described in Section 5.5.3, (e) of 559 [RFC4862]. 561 L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable 562 message, code 5 (Source address failed ingress/egress policy) 563 for packets forwarded to it that use an address from a prefix 564 that has been deprecated. 566 4.4. Transition Technologies Support 568 4.4.1. 6rd 570 The IPv6 CE Router can be used to offer IPv6 service to a LAN, even 571 when the WAN access network only supports IPv4. One technology that 572 supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment 573 (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside 574 IPv4 at the IPv6 CE Router and sends it to a Service Provider Border 575 Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6 576 prefix during 6rd configuration, and sub-delegates the 6rd delegated 577 prefix to devices in the LAN. 579 The IPv6 CE Router SHOULD implement 6rd functionality as specified in 580 [RFC5969]. 582 6rd requirements: 584 6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE 585 Router WAN interface MUST support at least one 6rd Virtual 586 Interface. 588 6RD-2: If the IPv6 CE router implements 6rd functionality, it MUST 589 support 6rd configuration via the 6rd DHCPv4 Option (212) and 590 if the IPv6 CE router is capable of automated configuration 591 of IPv4 through IPCP (i.e., over a PPP connection), it MUST 592 support user-entered configuration of 6rd. The IPv6 CE 593 router MAY use other mechanisms to configure 6rd parameters. 594 Such mechanisms are outside the scope of this document. 596 6RD-3: If the CE router implements 6rd functionality, it MUST allow 597 the user to specify whether all IPv6 traffic goes to the 6rd 598 Border Relay, or whether IPv6 traffic to other destinations 599 within the same 6rd domain are routed directly to those 600 destinations. The CE router MAY use other mechanisms to 601 configure this. Such mechanisms are outside the scope of 602 this document. 604 6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data 605 MUST NOT be sent on any 6rd tunnel. 607 6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite 608 ([RFC6333]) tunnel. 610 6RD-6: 6rd MUST NOT be initiated if the WAN-side interface has a CE 611 IPv4 address [RFC5969] that is not unique within the 6rd 612 domain. 614 4.4.2. Dual-Stack Lite(DS-Lite) 616 Even as users migrate from IPv4 to IPv6 addressing, a significant 617 percentage of Internet resources and content will remain accessible 618 only through IPv4. Also, many end-user devices will only support 619 IPv4. As a consequence, Service Providers require mechanisms to 620 allow customers to continue to access content and resources using 621 IPv4 even after the last IPv4 allocations have been fully depleted. 622 One technology that can be used for IPv4 address extension is DS- 623 Lite. 625 DS-Lite enables a Service Provider to share IPv4 addresses among 626 multiple customers by combining two well-known technologies: IP in IP 627 (IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically, 628 Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at 629 the IPv6 CE Router and sends it to a Service Provider Address Family 630 Transition Router (AFTR). Configuration of the IPv6 CE Router to 631 support IPv4 LAN traffic is outside the scope of this document. 633 The IPv6 CE Router SHOULD implement DS-Lite functionality as 634 specified in [RFC6333]. 636 WAN requirements: 638 DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE 639 Router supports DS-Lite functionality, the CE Router WAN 640 interface MUST implement a B4 Interface as specified in 641 [RFC6333]. 643 DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the 644 CE Router MUST support using a DS-Lite DHCPv6 option 645 [RFC6334] to configure the DS-Lite tunnel. The IPv6 CE 646 Router MAY use other mechanisms to configure DS-Lite 647 parameters. Such mechanisms are outside the scope of this 648 document. 650 DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address 651 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 653 DLW-4: If the IPv6 CE Router is configured with an IPv4 address on 654 its WAN interface then the IPv6 CE Router SHOULD disable the 655 DS-Lite B4 element. 657 DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast 658 data MUST NOT be sent on any DS-Lite tunnel. 660 DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD 661 tunnel. 663 4.4.3. Transition Technologies Coexistence 665 Supporting transition technologies that may coexist with native 666 service requires control over provisioning and sunsetting. Some 667 guidelines follow: 669 1. Initiate native IPv4/IPv6 provisioning (e.g. via DHCP) 670 simultaneously. 672 2. After IPv4 provisioning completes, if 6rd parameters are obtained 673 from the DHCPv4 transaction or configured on the device, initiate 674 6rd. 676 3. After IPv6 provisioning completes, if DS-Lite parameters are 677 obtained from the DHCPv6 transaction or configured on the device, 678 initiate DS-Lite. 680 4. Routes over the DS-Lite tunnel always have a higher 681 administrative distance than native IPv4 routes. 683 5. Selection of 6rd tunnel or native IPv6 output interface on the CE 684 router is determined by the source IPv6 address of the packet 685 from a host, when different prefixes are available over 6rd vs. 686 native IPv6. If the two interfaces provide the CE router with 687 the same prefix, then the CE router prefers the native IPv6 688 interface to the 6rd interface for forwarding traffic out the WAN 689 when both 6rd and native IPv6 interfaces are active. 691 6. The CE router messages to the host the use of native IPv6 in 692 preference to 6rd, in the case where the two interfaces use 693 different prefixes. 695 During a sunsetting activity such as deprecating 6rd and moving to 696 native IPv6, the IPv6 CE router MUST immediately advertise the 6rd 697 prefix with a Preferred Lifetime of zero and a Valid Lifetime of the 698 lower of the current Valid Lifetime and two hours (which must be 699 decremented in real time) in a Router Advertisement message as 700 described in Section 5.5.3, (e) of [RFC4862]. Due to the two hours 701 rule specified in [RFC4862], the 6rd and the native IPv6 prefix will 702 coexist in the home network. The two hours rule specified in section 703 5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node 704 even when an RA has sent a Preferred Lifetime of zero to expire the 705 prefix to the node. During such coexistence of multiple prefixes, 706 the CE router sends an ICMPv6 error for packets sourced or destined 707 related to the deprecated prefix. Note this document already 708 includes text in bullet L-14 in section 4.3 for such a provision. 710 4.5. Security Considerations 712 It is considered a best practice to filter obviously malicious 713 traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 714 the IPv6 CE router ought to support basic stateless egress and 715 ingress filters. The CE router is also expected to offer mechanisms 716 to filter traffic entering the customer network; however, the method 717 by which vendors implement configurable packet filtering is beyond 718 the scope of this document. 720 Security requirements: 722 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 723 the IPv6 CE router SHOULD support functionality sufficient for 724 implementing the set of recommendations in [RFC6092], 725 Section 4. This document takes no position on whether such 726 functionality is enabled by default or mechanisms by which 727 users would configure it. 729 S-2: The IPv6 CE router MUST support ingress filtering in accordance 730 with BCP 38 [RFC2827]. 732 S-3: If the IPv6 CE router firewall is configured to filter incoming 733 tunneled data, the firewall SHOULD provide the capability to 734 filter decapsulated packets from a tunnel. 736 5. Acknowledgements 738 Thanks to the following people (in alphabetical order) for their 739 guidance and feedback: 741 Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker, Mohamed 742 Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou, 743 Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand, 744 Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline, 745 Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi 746 Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael 747 Newbery, Carlos Pignataro, John Pomeroy, Antonio Querubin, Hiroki 748 Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark Townsley, 749 Bernie Volz, Dan Wing, James Woodyatt, Carl Wuyts, and Cor Zwart. 751 This document is based in part on CableLabs' eRouter specification. 752 The authors wish to acknowledge the additional contributors from the 753 eRouter team: 755 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 756 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 757 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 758 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 759 Torbet, and Greg White. 761 6. Contributors 763 The following people have participated as co-authors or provided 764 substantial contributions to this document: Ralph Droms, Kirk 765 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 766 Yiu Lee, John Jason Brzozowski, and Heather Kirksey. 768 7. References 770 7.1. Normative References 772 [I-D.droms-dhc-dhcpv6-maxsolrt-update] 773 Droms, R., "Modification to Default Value of MAX_SOL_RT", 774 draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in 775 progress), November 2011. 777 [RFC1102] Clark, D., "Policy routing in Internet protocols", 778 RFC 1102, May 1989. 780 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 781 June 1989. 783 [RFC1122] Braden, R., "Requirements for Internet Hosts - 784 Communication Layers", STD 3, RFC 1122, October 1989. 786 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 787 E. Lear, "Address Allocation for Private Internets", 788 BCP 5, RFC 1918, February 1996. 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 794 Networks", RFC 2464, December 1998. 796 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 797 Defeating Denial of Service Attacks which employ IP Source 798 Address Spoofing", BCP 38, RFC 2827, May 2000. 800 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 801 and M. Carney, "Dynamic Host Configuration Protocol for 802 IPv6 (DHCPv6)", RFC 3315, July 2003. 804 [RFC3484] Draves, R., "Default Address Selection for Internet 805 Protocol version 6 (IPv6)", RFC 3484, February 2003. 807 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 808 Host Configuration Protocol (DHCP) version 6", RFC 3633, 809 December 2003. 811 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 812 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 813 December 2003. 815 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 816 (DHCP) Service for IPv6", RFC 3736, April 2004. 818 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 819 Configuration Option for DHCPv6", RFC 4075, May 2005. 821 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 822 More-Specific Routes", RFC 4191, November 2005. 824 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 825 Addresses", RFC 4193, October 2005. 827 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 828 Time Option for Dynamic Host Configuration Protocol for 829 IPv6 (DHCPv6)", RFC 4242, November 2005. 831 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 832 April 2006. 834 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 835 Message Protocol (ICMPv6) for the Internet Protocol 836 Version 6 (IPv6) Specification", RFC 4443, March 2006. 838 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 839 "Internet Group Management Protocol (IGMP) / Multicast 840 Listener Discovery (MLD)-Based Multicast Forwarding 841 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 843 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 844 (CIDR): The Internet Address Assignment and Aggregation 845 Plan", BCP 122, RFC 4632, August 2006. 847 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 848 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 849 Access Networks", RFC 4779, January 2007. 851 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 852 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 853 September 2007. 855 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 856 Address Autoconfiguration", RFC 4862, September 2007. 858 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 859 E. Klein, "Local Network Protection for IPv6", RFC 4864, 860 May 2007. 862 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 863 PPP", RFC 5072, September 2007. 865 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 866 Model: The Relationship between Links and Subnet 867 Prefixes", RFC 5942, July 2010. 869 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 870 Infrastructures (6rd) -- Protocol Specification", 871 RFC 5969, August 2010. 873 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 874 Customer Premises Equipment (CPE) for Providing 875 Residential IPv6 Internet Service", RFC 6092, 876 January 2011. 878 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 879 "IPv6 Router Advertisement Options for DNS Configuration", 880 RFC 6106, November 2010. 882 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 883 Troan, "Basic Requirements for IPv6 Customer Edge 884 Routers", RFC 6204, April 2011. 886 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 887 Stack Lite Broadband Deployments Following IPv4 888 Exhaustion", RFC 6333, August 2011. 890 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 891 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 892 RFC 6334, August 2011. 894 7.2. Informative References 896 [MULTIHOMING-WITHOUT-NAT] 897 Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 898 and D. Wing, "IPv6 Multihoming without Network Address 899 Translation", Work in Progress, December 2010. 901 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 902 IPv4/IPv6 Translation", RFC 6144, March 2011. 904 [UPnP-IGD] 905 UPnP Forum, "Universal Plug and Play (UPnP) Internet 906 Gateway Device (IGD)", November 2001, 907 . 909 Appendix A. DS-Lite Sunsetting 911 Two deployment scenarios of interest are: 913 1. DHCPv4 address configured on the WAN without DS-Lite configured, 915 2. and no DHCPv4 address configured on the WAN and DS-Lite 916 configured. 918 The service provider enables transitions between these two scenarios 919 as follows: 921 From scenario 1 to scenario 2: 923 a) CE router performs a DHCPv4 message exchange and receives no 924 address from the service provider. 926 b) CE router performs a DHCPv6 message exchange and receives an 927 IA_ADDRESS in an IA_NA and DS-Lite configuration. 929 c) When DS-Lite is configured, the CE router turns off DHCPv4. 931 From scenario 2 to scenario 1: 933 a) CE router performs a DHCPv6 message exchange and receives no 934 DS-Lite configuration. 936 b) CE router continues performing a DHCPv4 message exchange until 937 it receives an address. 939 Proposed rules (under discussion) to add to the Coexistence section: 941 1. If the CE router performs a DHCPv6 message exchange and receives 942 DS-Lite configuration, stop any ongoing DHCPv4 operation. 944 2. If the CE router performs a DHCPv6 message exchange and does not 945 receive DS-Lite configuration, perform a DHCPv4 message exchange 946 to receive an address. 948 Appendix B. Changes from RFC 6204 950 1. Added IP transition technologies available in RFC form. 952 2. Added IP transition technologies coexistence. 954 3. Changed bullet G-5 to augment the condition of losing IPv6 955 default router(s) with loss of connectivity. 957 4. Removed bullet WAA-7 due to not reaching consensus by various 958 service provider standards bodies. The removal of text does not 959 remove any critical functionality from the CE specification. 961 5. Changed bullet WAA-8 to qualify WAN behavior only if not 962 configured to perform DHCPv6. This way a deployment specific 963 profile can mandate DHCPv6 numbered WAN wihout conflicting with 964 this document. 966 6. Changed the WPD-2 bullet from MUST be configurable to SHOULD be 967 configurable. 969 7. Changed bullet WPD-4 for a default behavior without compromising 970 any prior specification of the CE device. The change was needed 971 by a specific layer 1 deployment which wanted to specify a MUST 972 for DHCPv6 in their layer 1 profile and not conflict with this 973 document. 975 8. Changed bullet WPD-7 to qualify text for DHCPv6. 977 9. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 978 that if an service provider does not have DHCPv6 service enabled 979 CE routers do not send too frequent DHCPv6 requests to the 980 service provider DHCPv6 server. 982 10. Changed bullet L-11 from SHOULD provide DNS options in the RA to 983 MUST provide DNS option in the RA. 985 11. New bullet added to the Security Considerations section due to 986 addition of transition technology. The CE router filters 987 decapsulated 6rd data. 989 12. Minor change involved changing ICMP to ICMPv6. 991 Authors' Addresses 993 Hemant Singh 994 Cisco Systems, Inc. 995 1414 Massachusetts Ave. 996 Boxborough, MA 01719 997 USA 999 Phone: +1 978 936 1622 1000 EMail: shemant@cisco.com 1001 URI: http://www.cisco.com/ 1003 Wes Beebee 1004 Cisco Systems, Inc. 1005 1414 Massachusetts Ave. 1006 Boxborough, MA 01719 1007 USA 1009 Phone: +1 978 936 2030 1010 EMail: wbeebee@cisco.com 1011 URI: http://www.cisco.com/ 1013 Chris Donley 1014 CableLabs 1015 858 Coal Creek Circle 1016 Louisville, CO 80027 1017 USA 1019 EMail: c.donley@cablelabs.com 1020 Barbara Stark 1021 AT&T 1022 725 W Peachtree St. 1023 Atlanta, GA 30308 1024 USA 1026 EMail: barbara.stark@att.com 1028 Ole Troan (editor) 1029 Cisco Systems, Inc. 1030 Telemarksvingen 20 1031 N-0655 OSLO, 1032 Norway 1034 EMail: ot@cisco.com