idnits 2.17.1 draft-ietf-v6ops-ipv6-cpe-router-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '... and, therefore, MUST follow IPv6 Node...' RFC 2119 keyword, line 213: '... The CPE Router SHOULD support the ab...' RFC 2119 keyword, line 228: '... The CPE Router MUST support at least...' RFC 2119 keyword, line 285: '... hosts MAY send RS's to solicit an R...' RFC 2119 keyword, line 286: '... of a CPE Router SHOULD send an RS aft...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 18, 2009) is 5364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2453' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'RFC3769' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC4779' is defined on line 894, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-6man-ipv6-subnet-model-05 == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-03 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-01 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-07 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2669 (Obsoleted by RFC 4639) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 8 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 Intended status: Informational Cisco Systems, Inc. 5 Expires: February 19, 2010 August 18, 2009 7 IPv6 CPE Router Recommendations 8 draft-ietf-v6ops-ipv6-cpe-router-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 19, 2010. 43 Copyright Notice 45 Copyright (c) 2009 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 in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document recommends IPv6 behavior for Customer Premises 57 Equipment (CPE) routers in Internet-enabled homes and small offices. 58 The CPE Router may be a standalone device. The CPE Router may also 59 be embedded in a device such as a cable modem, DSL modem, cellular 60 phone, etc. This document describes the router portion of such a 61 device. The purpose behind this document is to provide minimal 62 functionality for interoperability and create consistency in the 63 customer experience and satisfy customer expectations for the device. 64 Further, the document also provide some guidance for implementers to 65 expedite availability of IPv6 CPE router products in the marketplace. 66 It is expected that standards bodies other than the IETF developing 67 standards for specific products in this area (e.g. CableLabs 68 eRouter, Broadband Forum, Home Gateway Initiative, etc.) may 69 reference this work for basic functionality and provide value-added 70 or linktype-specific customizations and enhancements which are beyond 71 the scope of this document. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 77 3. Operational Behavior . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Conceptual Configuration Variables . . . . . . . . . . . . 5 79 4. Router Initialization . . . . . . . . . . . . . . . . . . . . 6 80 5. Basic IPv6 Provisioning . . . . . . . . . . . . . . . . . . . 6 81 5.1. Construct Link-Local Address (CORE) . . . . . . . . . . . 7 82 5.2. Process RAs (CORE) . . . . . . . . . . . . . . . . . . . . 7 83 5.3. Acquire IPv6 Address and Other Configuration 84 Parameters (CORE) . . . . . . . . . . . . . . . . . . . . 7 85 5.3.1. Numbered Model (CORE) . . . . . . . . . . . . . . . . 8 86 5.3.2. Unnumbered Model (MEDIUM) . . . . . . . . . . . . . . 8 87 5.3.3. Both Models . . . . . . . . . . . . . . . . . . . . . 8 88 5.4. Details for DHCPv6 Address Acquisition (CORE) . . . . . . 8 89 5.5. IPv6 Provisioning of Home Devices (CORE) . . . . . . . . . 9 90 5.5.1. LAN Initialization before WAN Initialization . . . . . 10 91 5.5.2. WAN initialization before LAN Initialization . . . . . 11 92 5.6. IPv6 over PPP . . . . . . . . . . . . . . . . . . . . . . 11 93 5.7. Stateful DHCPv6 Server (CORE) . . . . . . . . . . . . . . 12 94 6. CPE Router Behavior in a routed network (MEDIUM) . . . . . . . 12 95 7. IPv6 Data Forwarding (CORE) . . . . . . . . . . . . . . . . . 12 96 7.1. IPv6 ND Proxy Behavior (MEDIUM) . . . . . . . . . . . . . 13 97 7.2. IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . . 14 98 8. Other IPv6 Features . . . . . . . . . . . . . . . . . . . . . 14 99 8.1. Path MTU Discovery Support (MEDIUM) . . . . . . . . . . . 14 100 8.2. Optional RIPng Support (CORE) . . . . . . . . . . . . . . 15 101 8.3. Automated Tunneling (MEDIUM) . . . . . . . . . . . . . . . 15 102 8.4. DNS Support (CORE) . . . . . . . . . . . . . . . . . . . . 16 103 8.5. Quality Of Service(QoS) . . . . . . . . . . . . . . . . . 16 104 9. IPv4 Support (CORE) . . . . . . . . . . . . . . . . . . . . . 16 105 10. DEVICE Constants . . . . . . . . . . . . . . . . . . . . . . . 16 106 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 108 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 109 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 110 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 111 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 112 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 115 1. Introduction 117 This document defines IPv6 features for a residential or small office 118 router referred to as a CPE Router. Typically, CPE Router devices 119 support IPv4, as discussed in the "IPv4 Support" section. Also, this 120 document does not go into configuration details for the CPE Router. 121 A CPE Router is an IPv6 Node and, therefore, MUST follow IPv6 Node 122 Requirements draft-ietf-6man-node-req-bis-01 123 [I-D.ietf-6man-node-req-bis]. 125 The document discusses IPv6 implications for the attached Service 126 Provider network. The document notes that the CPE Router may be 127 deployed in home in one of two ways. Either the Service Provider or 128 the home user may manage this device. When the CPE Router is managed 129 by the Service Provider, the router may need additional management 130 and routing properties like a new MIB definition and routing 131 protocols communicating between the CPE Router and the Service 132 Provider network. The CPE router has one or more WAN interface(s) to 133 connect to the Service Provider and zero or more LAN interfaces to 134 the home network devices. In the case of zero LAN interfaces, any 135 LAN-applicable initialization and behavior is skipped. The WAN 136 interface is preferred to be Ethernet encapsulated but it may support 137 other encapsulations such as PPP. 139 Technologies are labeled as: CORE (widely deployed in the field, many 140 years of operational experience, one or more standards-track RFC's 141 exist), MEDIUM (standards-track RFC exists, but is a recent 142 development and/or has limited deployments. Technologies under 143 DEVelopment (no standards-track RFC exists and/or has not yet been 144 deployed) have been moved to a bis(updates) version of this document. 146 2. Terminology and Abbreviations 148 Host - this is a personal computer or any other network device in 149 a home that connects to the Internet via the CPE Router. A more 150 formal definition of a host exists in the Terminology section of 151 [RFC2460]. 153 LAN interface(s) - an optional set of network interfaces on the 154 CPE Router that are used to connect hosts in the home. This set 155 of ports could be switched, bridged, or routed. If no LAN 156 interface is present, then there is no need for the CPE router to 157 provide LAN side services such as DHCPv6 PD or ULA's. 159 WLAN interface - an optional wireless access point interface on 160 the CPE Router used to connect wireless hosts in the home in 161 either managed or ad-hoc modes. 163 WAN interface - usually a single physical network interface on the 164 standalone CPE Router that is used to connect the router to the 165 access network of the Service Provider. When the CPE Router is 166 embedded in a device that connects to the WAN, this interface is a 167 logical network interface that bridges the device to the CPE 168 Router. Some devices which can have an embedded CPE router are: a 169 cable or DSL modem, or a cellular telephone, etc. A CPE router 170 with more than one WAN interface will need a more complicated 171 provisioning and multicast model than is described in this 172 document. 174 GRE tunnel - Generic Routing Encapsulation tunnel. 176 SLAAC - StateLess Address Auto Configuration. 178 IPTV - Internet Protocol TeleVision. 180 3. Operational Behavior 182 The CPE Router is a gateway to the Internet for a home. The router 183 is also intended to provide home networking functionality. The CPE 184 Router may have a console or web interface for configuration. This 185 document defines the core set of features that are supported by the 186 CPE Router, however individual implementations may include value- 187 added features such as WLAN capability. 189 The core set of IPv6 features for the CPE Router includes 190 provisioning the CPE Router for IPv6, IPv6 data forwarding including 191 IPv6 multicast, CPE Router provisioning hosts on its LAN 192 interface(s), firewall, and QoS behavior. 194 3.1. Conceptual Configuration Variables 196 The CPE Router maintains such a list of conceptual optional 197 configuration variables. 199 1. Loopback interface enable. 201 2. PPPOE enable. 203 3. RIPng enable. 205 4. If DHCPv6 fails, the CPE Router may initiate PPPOE, L2TPv2 206 tunnel, and 6rd draft-townsley-ipv6-6rd [I-D.townsley-ipv6-6rd] 207 operation. If 6rd is attempted and fails, then 6to4 [RFC3056] 208 operation is attempted. 210 4. Router Initialization 212 Before the CPE Router is initialized, the device must have IPv6 213 enabled. The CPE Router SHOULD support the ability to disable its 214 IPv6 stack. The CPE Router also has the ability to block or forward 215 IPv6 traffic to and from the router's LAN interface(s). [RFC2669] 216 includes a MIB definition to block the IPv4 or IPv6 Ethertype in the 217 upstream or downstream interface(s) of a device such as the CPE 218 Router. Some portion of this MIB may need to be modified for use 219 with the CPE Router. 221 The CPE Router supports at least one of two modes of initialization: 222 either the LAN interface(s) become operational first or the WAN 223 interface becomes operational first. More details have been provided 224 in the Basic IPv6 Provisioning section. 226 5. Basic IPv6 Provisioning 228 The CPE Router MUST support at least one of two WAN interface models, 229 one of which will be active on the CPE Router at any given time. In 230 the Numbered model, the WAN interface acquires a global unicast 231 address (GUA) using a combination of SLAAC and stateful DHCPv6 for 232 IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA) and 233 IA_PD. IA_PD is acquired using stateful DHCPv6 as described in 234 [RFC3633]. Assigning a stable global unicast address to a loopback 235 interface (which can be used as a stable peering point for routing 236 protocols or to respond to the anycast address) is optional. If 237 stateful DHCPv6 is not used to obtain other IPv6 configuration, then 238 stateless DHCPv6 [RFC3736] must be initiated by the WAN interface to 239 obtain other IPv6 configuration. Further, in the numbered model, we 240 recommend the CPE Router WAN interface acquire its global IPv6 241 address using stateful DHCPv6 for administrative control of the 242 router. Manual configuration may be supported by the CPE router for 243 IPv6 address configuration of the WAN interface. However, manual 244 configuration is beyond the scope of this document. 246 In the Unnumbered model, the WAN interface only constructs a Link- 247 Local Address, then the WAN interface initiates stateful DHCPv6 for 248 IA_PD. The IA_PD is sub-delegated to the LAN interface(s) and an 249 optional Loopback interface (or the addresses for the LAN/Loopback 250 interfaces could come from IA_NAs). Either the Loopback or the LAN 251 interface can be used to source WAN-facing traffic. Other IPv6 252 configuration information is obtained using stateless DHCPv6. 254 The CPE Router acquires its IPv6 addresses from the Service Provider 255 along with any other IPv6 configuration any time the WAN interface is 256 connected to the Service Provider network. Thereafter the CPE Router 257 provisions its LAN interface(s) for IPv6 router functionality 258 including provisioning global IPv6 addresses on the LAN interface(s). 259 Even if LAN interface(s) have been operational and provisioned 260 earlier, the global IPv6 configuration of LAN interface(s) is still 261 required. More details for provisioning the CPE Router are given in 262 the following sections. 264 5.1. Construct Link-Local Address (CORE) 266 If an interface of the CPE Router is configured for IPv6, when the 267 interface initializes itself, as per [RFC4862], the CPE Router must 268 create a link-local address for the interface. We recommend the CPE 269 Router use the EUI-64 identifier as a link-local address for each of 270 its interfaces. Refer to EUI-64 details in [RFC4291]. Further, as 271 per [RFC4862], the CPE Router must perform Duplicate Address 272 Detection (DAD) on all unicast addresses unless a layer 2-specific 273 document specifies that DupAddrDetectTransmits is zero for that 274 linktype. If the CPE Router detects a duplicate address assigned to 275 an interface, the CPE Router must not send IPv6 packets from the 276 interface. 278 5.2. Process RAs (CORE) 280 The CPE Router must process incoming RAs received on the WAN 281 interface as specified in section 6.3 of [RFC4861]. The CPE Router 282 locates routers that reside on the attached WAN link from the 283 received RAs. With respect to RS behavior, the WAN interface of the 284 CPE Router acts as a host. Section 4.1 of [RFC4861] states that 285 hosts MAY send RS's to solicit an RA quickly. The WAN interface(s) 286 of a CPE Router SHOULD send an RS after link-local address 287 construction. 289 5.3. Acquire IPv6 Address and Other Configuration Parameters (CORE) 291 The CPE Router must process RAs received on the WAN interface. As 292 per [RFC4861] if the M bit is set in the RA, the WAN interface must 293 perform stateful DHCPv6- if the O bit is set in the RA, the WAN 294 interface acquires other configuration information. If stateful 295 DHCPv6 is not used to obtain other IPv6 configuration, then stateless 296 must be initiated by the WAN interface to obtain other IPV6 297 configuration. If the A bit in the RA is clear or the RA does not 298 include any Prefix Information Option (PIO), the WAN interface must 299 not perform SLAAC. IPv6 deployments that configure RA to not include 300 any PIO are discussed in draft-ietf-6man-ipv6-subnet-model 301 [I-D.ietf-6man-ipv6-subnet-model]. 303 5.3.1. Numbered Model (CORE) 305 As instructed by the RA message, the WAN interface acquires global 306 IPv6 address using stateful DHCPv6 or SLAAC. 308 5.3.2. Unnumbered Model (MEDIUM) 310 When the CPE router is configured for Unnumbered model, the WAN 311 interface only constructs a Link-Local-Address, then the WAN 312 interface initiates stateful DHCPv6 for IA_PD. Then the IA_PD is 313 sub-delegated to the LAN interface(s) and an optional Loopback 314 interface (or the addresses for the LAN/Loopback interfaces could 315 come from IA_NAs). Either the Loopback or the LAN interface can be 316 used to source WAN-facing traffic. When the Loopback or the LAN 317 interface is used to source WAN-facing traffic, both the CPE Router 318 and the Service Provider Router must consider the traffic to be off- 319 link to the link connecting the CPE Router with the Service Provider 320 Router. Other IPv6 configuration information is obtained using 321 stateless DHCPv6. A CPE Router acts as a host for packets 322 originating from or destined for the CPE Router. Such packets may 323 include SNMP or web-based router configuration, tunnel encapsulation/ 324 decapsulation, or PPP endpoint packets. The Unnumbered model is 325 incompatible with the strong host model [RFC1122] on the CPE router 326 (such as a personal computer running PPP and routing code). The 327 unnumbered model may be inappropriate for use with certain 328 deployments where a device that uses the strong host model can 329 operate as a CPE Router. 331 5.3.3. Both Models 333 At any instance in time of the CPE Router operation, the router does 334 not forward any traffic between its WAN and LAN interface(s) if the 335 router has not completed IPv6 provisioning process that involves the 336 acquisition of a global IPv6 address by the WAN or if the WAN is 337 unnumbered and there is no GUA available to source WAN packets. The 338 LAN interface(s) must also be provisioned for a global or Unique 339 Local Address. 341 5.4. Details for DHCPv6 Address Acquisition (CORE) 343 If the WAN interface uses stateful DHCPv6, the interface sends a 344 DHCPv6 Solicit message as described in section 17.1.1 of [RFC3315]. 345 The Solicit message must include an IA_NA option as specified by 346 [RFC3315]. If the WAN interfaces uses stateless DHCPv6, the WAN 347 interface sends an Information Request. Both the DHCPv6 SOLICIT and 348 Information Request also include other options like a Reconfigure 349 Accept option to inform the server that client is willing to accept 350 Reconfigure message from server, and the Options Request option that 351 includes the DNS Recursive Name server option as specified in 352 [RFC3646]. The Solicit may also include the Rapid Commit option if 353 the CPE Router is willing to accept a 2-message DHCPv6 exchange with 354 the server. 356 When the CPE Router processes a DHCPv6 response from the server, if 357 the response message (e.g. ADVERTISE or REPLY) received does not 358 include an IA_PD option (if stateful DHCPv6 was initiated), or 359 Reconfigure Accept option, then the CPE Router has failed DHCPv6 360 address acquisition. If stateful DHCPv6 succeeds, the CPE Router 361 must perform DAD for any IPv6 address acquired from DHCPv6. If the 362 CPE Router detects a duplicate, the CPE Router must send a DHCPv6 363 Decline message to the DHCPv6 server. 365 The CPE Router may support the Reconfigure Key Authentication 366 Protocol, as described in section 21.5 of [RFC3315]. The CPE Router 367 may also support prefix sub-delegation as described in 368 draft-baker-ipv6-prefix-subdelegation 369 [I-D.baker-ipv6-prefix-subdelegation]. Prefix sub-delegation 370 involves DHCPv6 server support with IA_PD on the CPE router and the 371 ability to provision the server from a DHCPv6 REPLY with IA_PD option 372 received on the WAN interface. 374 5.5. IPv6 Provisioning of Home Devices (CORE) 376 The CPE Router may include a stateful DHCPv6 server to assign 377 addresses to home devices connected via the LAN interface(s) of the 378 CPE Router. The home devices can also acquire addresses via SLAAC. 380 If the LAN interface(s) are switched or bridged ports, then the CPE 381 Router assigns a single global IPv6 address to a conceptual virtual 382 interface serving all the LAN interface(s). If each LAN interface is 383 a routed port, then the CPE router will assign a global IPv6 address 384 and unique subnet to each LAN interface . In either case, when the 385 CPE Router needs to assign a single IPv6 address to LAN interface(s) 386 or multiple IPv6 addresses, the CPE Router redistributes the 387 addresses and subnets from the prefix received in IA_PD option by the 388 WAN interface. If the IA_PD changes, the CPE Router must reconfigure 389 the LAN interface(s) with new IPv6 addresses derived from the new 390 IA_PD and then also renumber the IPv6 ND RA configuration on the LAN 391 interface(s). 393 This document recommends the RA sent out by LAN Interface(S) to be 394 configured for SLAAC so that the prefix advertised in the RA is 395 derived from the IA_PD assigned to the CPE Router by the Service 396 Provider; the O-bit is also set so that the CPE Router can pass 397 Domain Name Server(s) IPv6 address(es) to home devices. The CPE 398 Router obtained the Domain Name Server(s) in OPTION_DNS_SERVERS 399 option from the DHCPv6 server when the CPE Router WAN interface 400 completed DHCPv6. 402 5.5.1. LAN Initialization before WAN Initialization 404 On power up, the LAN interface(s) of the CPE Router may become 405 operational before the WAN interface. This mode is appropriate for 406 manual user configuration of the CPE Router. After any LAN interface 407 has constructed a link-local address, the address can be used for 408 user configuration via the network. The interface MAY assign itself 409 a Unique Local Address automatically through the pseudo-random number 410 generation algorithm described in [RFC4193]. Once the IPv6 address 411 configuration of the LAN interface(s) is complete with a ULA, as per 412 [RFC4862], the CPE Router sends Router Advertisements (RA) to devices 413 in the home. Hosts receiving the RA from LAN interface(s) will 414 process the RA and perform IPv6 address acquisition. After all the 415 LAN interface(s) have become operational, if the WAN interface is 416 connected to the Service Provider network, then the WAN interface 417 provisions itself and may acquire an IA_PD. If an IA_PD is acquired, 418 it may be sub-delegated to any cascaded routers or used for SLAAC 419 provisioning of hosts in the home. Based on the IA_PD, the CPE 420 Router configures global address(es) on the LAN interface(s) and 421 sends an RA containing the global address and unique local prefixes 422 out the LAN interface(s) . After this process, every LAN interface 423 has a link-local unicast address, a ULA, and a GUA. Therefore, the 424 interface has to apply source address selection to determine which 425 address to use as a source for outgoing packets. Since the GUA and 426 ULA have a larger scope than the link-local address (rule #2 of 427 [RFC3484]), the GUA or ULA will be used as a source address of 428 outgoing packets that are not subject to rule #1. For source address 429 selection between a GUA and ULA, rule #8 of [RFC3484] will be 430 used. If a user desires to keep CPE Router configuration traffic 431 local to the home network, the user can do the following: 433 Use the ULA of the CPE Router as the destination of the 434 configuration traffic. 436 Use access control lists (ACL)s to block any ULA sourced packet 437 from being sent out the WAN interface. 439 Rule #1 of [RFC3484] and the ACLs ensure that the traffic does not 440 escape the home network. 442 After the WAN interface initializes, then the LAN interface(s) can 443 acquire global unicast addresses. 445 If the residential/SOHO network has multiple LANs, the CPE Router 446 MUST calculate and distribute a ULA with different subnets on the 447 different LANs, and the ULA MUST be saved in non-volatile memory in 448 order to make it consistent across reboots. The ULA provides for 449 intra-site connectivity when global addresses are unavailable such as 450 during an uplink outage. It is RECOMMENDED that the ULA on each LAN 451 be displayed in a user interface and be configurable. The CPE Router 452 MAY calculate a ULA when the network consists of one LAN, perhaps 453 under configuration control, although Link Local addresses may 454 suffice in the case. 456 5.5.2. WAN initialization before LAN Initialization 458 On power up, the WAN interface of the CPE Router may become 459 operational before the LAN interface(s). This mode is appropriate 460 for Service Provider configuration of the CPE Router (such as a Cable 461 DOCSIS eRouter). After the IPv6 address configuration for WAN 462 interface is completed, the CPE Router configures IPv6 address for 463 LAN interface(s) . 465 Once IPv6 address configuration of the LAN interface(s) is complete, 466 as per [RFC4862], the CPE Router sends Router Advertisements (RA) to 467 devices in the home. Hosts receiving the RA from LAN interface(s) 468 will process the RA and perform IPv6 address acquisition. 470 5.6. IPv6 over PPP 472 In some deployments IPv6 over PPP is preferred to connect the home to 473 the Service Provider. For such a deployment, another configuration 474 variable on the CPE Router enables optional IPv6 over PPP support. 475 After IPv6CP negotiates IPv6 over PPP and the WAN interface has 476 constructed a Link-Local Address, steps mentioned in the "Acquire 477 IPv6 Address and Other Configuration Parameters" section above are 478 followed to acquire a GUA for WAN interface and also an IA_PD. If an 479 IA_PD is acquired by the WAN interface, the CPE Router assigns global 480 address(es) to its LAN interface(s) and sub-delegates the IA_PD to 481 hosts connected to the LAN interface(s) . IPv6 over PPP follows 482 [RFC5072]. As per [RFC5072], the CPE router does not initiate any 483 DAD for unicast IPv6 addresses since DupAddrDetectTransmits variable 484 from [RFC4862] is zero for IPv6 over PPP. 486 If the Service Provider deployment supports dual-stack PPP support, 487 then the CPE Router WAN interface may initiate one PPP logical 488 channel and support NCP IPv4 and IPv6 control protocols over one PPP 489 logical channel. [RFC4241] describes such behavior. The IPv4 and 490 IPv6 NCP's are independent of each other and start and terminate 491 independently. 493 5.7. Stateful DHCPv6 Server (CORE) 495 The CPE Router may support a stateful DHCPv6 server to serve clients 496 on the CPE Router LAN interface(s) . If the CPE Router needs to 497 support a stateful DHCPv6 server, then more details will be added to 498 this section specifying the minimal functionality that the stateful 499 DHCPv6 server needs to support. 501 6. CPE Router Behavior in a routed network (MEDIUM) 503 One example of the CPE Router use in the home is shown below. The 504 home has a broadband modem combined with a CPE Router, all in one 505 device. The LAN interface of the device is connected to another 506 standalone CPE Router that supports a wireless access point. To 507 support such a network, this document recommends using prefix sub- 508 delegation of the prefix obtained either via IA_PD from WAN interface 509 or a ULA from the LAN interface . The network interface of the 510 downstream router may obtain an IA_PD via stateful DHCPv6. If the 511 CPE router supports the routed network through automatic prefix sub- 512 delegation, the CPE router MUST support a DHCPv6 server or DHCPv6 513 relay agent. Further, if an IA_PD is used, the Service Provider or 514 user MUST allocate an IA_PD or ULA prefix short enough to be sub- 515 delegated and subsequently used for SLAAC. Therefore, a prefix 516 length shorter than /64 is needed. The CPE Router MAY support RIPng 517 in the home network. 519 /-------+------------\ /------------+-----\ 520 SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC 521 \-------+------------/ \------------+-----/ 523 WAP = Wireless Access Point 525 Figure 1. 527 7. IPv6 Data Forwarding (CORE) 529 Each of the WAN and LAN interface(s) of the CPE Router must have its 530 own L2 (e.g. MAC) address. The CPE Router supports ND protocol on 531 both the WAN interface and LAN interface(s) and sends Router 532 Solicitations (RS) on the WAN interface and sends Router 533 Advertisement(s) (RA) on the LAN interface(s). 535 The CPE Router forwards packets between the Service Provider and the 536 home network. To do this, the CPE Router looks up the destination 537 address of the packet in the routing table and decide which route to 538 use to forward the packet. The CPE Router routing table will be 539 initialized during CPE Router initialization. The routing table is 540 filled by directly connected, static, and routing protocol routes. 542 The CPE Router consumes any packet destined to its WAN or LAN 543 interface. The CPE Router forwards other packets destined to hosts 544 attached to CPE Router LAN interface(s). Any packet that is not 545 routable by the CPE Router must be dropped. 547 The CPE Router must support the ND protocol specified by [RFC4861]. 548 Proxy Neighbor Advertisements as described in Section 7.2.8 of 549 [RFC4861] as applicable to the CPE Router are discussed in the IPv6 550 ND Proxy Behavior section. Also note, as per section 6.2.8 of 551 [RFC4861] the link-local address on a router should rarely change, if 552 ever. As per [RFC2460], the CPE Router decrements the Hop Limit by 1 553 for any packet it forwards. The packet is discarded if Hop Limit is 554 decremented to zero and the CPE Router also sends an ICMP Time 555 Exceeded message to the source of the packet. 557 A null route SHOULD be added to the routing table (to prevent routing 558 loops) that is lower priority than any route except the default 559 route. The choice to drop the packet or send an ICMPv6 Destination 560 Unreachable to the source address of the packet is implementation- 561 dependent. The installation of this null route MAY be automatic. 563 7.1. IPv6 ND Proxy Behavior (MEDIUM) 565 If the CPE Router has only one /64 prefix to be used across multiple 566 LAN interfaces and the CPE Router supports any two LAN interfaces 567 that cannot bridge data between them because the two interfaces have 568 disparate MAC layers, then the CPE Router MUST support ND Proxy 569 [RFC4389]. If any two LAN interfaces support bridging between the 570 interfaces, then ND Proxy is not necessary between the two 571 interfaces. Legacy 3GPP networks have the following requirements: 573 1. No DHCPv6 prefix is delegated to the CPE Router. 575 2. Only one /64 is available on the WAN link. 577 3. The link types between the WAN interface and LAN interface(s) are 578 disparate and, therefore, can't be bridged. 580 4. No NAT66 is to be used. 582 5. Each LAN interface needs global connectivity. 584 6. Uses SLAAC to configure LAN interface addresses. 586 For these legacy 3GPP networks, the CPE Router MUST support ND Proxy 587 between the WAN and LAN interface(s). However, if the CPE Router has 588 multiple prefixes available for use on LAN interfaces(s), then ND 589 Proxy is not necessary. 591 7.2. IPv6 Multicast Behavior (CORE) 593 The CPE Router SHOULD follow the model described for MLD Proxy in 594 [RFC4605] to implement multicast. The MLD Proxy model was chosen 595 because it is simpler to implement than more complicated multicast 596 routing functionality. 598 Querier Election rules as described in section 7.6.2 of [RFC3810] do 599 not apply to the CPE Router (even when the home has multiple cascaded 600 routers) since every CPE Router in the cascade is the only router in 601 its own multicast domain. Every CPE Router in the cascade will send 602 MLDv2 Reports with aggregated multicast Group Membership information 603 to the next upstream router. 605 If the CPE Router hardware includes a network bridge between the WAN 606 interface and the LAN interface(s), then the CPE Router MUST support 607 MLDv2 snooping as per [RFC4541]. 609 Consistent with [RFC4605], the CPE Router must not implement the 610 router portion of MLDv2 for the WAN interface. Likewise, the LAN 611 interfaces on the CPE router must not implement an MLDv2 Multicast 612 Listener. However, if a user at home wants to create a new multicast 613 group and send multicast data to other nodes on the Service Provider 614 network, then Protocol Independent Multicast-Source Specific 615 Multicast (PIM-SSM) [RFC3569] is recommended to handle multicast 616 traffic flowing in the upstream direction as a one-to-many multicast 617 flow. 619 8. Other IPv6 Features 621 8.1. Path MTU Discovery Support (MEDIUM) 623 GRE tunnels, such as IPv6 to IPv4 tunnels (which may be terminated on 624 the CPE Router), can modify the default Ethernet MTU of 1500 bytes. 625 Also, in the future, Ethernet Jumbo frames (> 1500 bytes) may also be 626 supported. Since the MTU can vary, a newly initiated TCP stream must 627 detect the largest packet that can be sent to the destination without 628 fragmentation. This can be detected using Path MTU Discovery 630 [RFC1981]. Routers which may encounter a packet too large to be 631 forwarded from source to destination may drop the packet and send an 632 ICMPv6 Packet Too Big message to the source. The CPE Router must 633 route back to the source any ICMPv6 Packet Too Big messages generated 634 anywhere on this path. Issues and solutions to problems with MTUs 635 and tunnels are described more fully in [RFC4459]. 637 8.2. Optional RIPng Support (CORE) 639 The CPE Router may support RIPng routing protocol [RFC2080] so that 640 RIPng operates between the CPE Router and the Service Provider 641 network. RIPng has scaling and security implications for the Service 642 Provider network where one Service Provider router may terminate 643 several tens of thousands of CPE routers. However, RIPng does 644 provide one solution from the CPE Router to the Service Provider 645 network for prefix route injection. 647 8.3. Automated Tunneling (MEDIUM) 649 If the IPv4 address assigned to the WAN interface of the CPE Router 650 is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire 651 an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring 652 the IPv4 address, then the 6rd tunneling protocol SHOULD be enabled 653 (if supported). If 6rd fails to find a usable relay, then 6to4 654 tunneling protocol [RFC3056] SHOULD be enabled automatically, 655 allowing tunneling of IPv6 packets over IPv4 without requiring user 656 configuration. If both IPv6 and IPv4 addresses are acquired within 657 WAN_IP_ACQUIRE_TIMEOUT seconds of each other, then the CPE Router 658 operates in dual stack mode, and does not need 6rd or 6to4. If no 659 IPv4 and no IPv6 address has been acquired, then the CPE Router 660 retries address acquisition. 662 6to4 can be useful in the scenario where the Service Provider does 663 not yet support IPv6, but devices in the home use IPv6. An IPv6 664 address is constructed automatically from the IPv4 address (V4ADDR) 665 configured on the interface using the prefix 2002:V4ADDR::/48. A 666 6to4 tunnel can be automatically created using a pre-configured 6to4 667 gateway end-point for the tunnel. 669 6rd is similar to 6to4, however it uses a service provider prefix 670 instead of a well-known prefix. The 6rd relay is typically managed 671 by the service provider. The 6rd protocol is described more fully in 672 draft-townsley-ipv6-6rd [I-D.townsley-ipv6-6rd]. A deployment of 6rd 673 is described in draft-despres-6rd [I-D.despres-6rd]. 675 Several proposals are being considered by IETF related to the problem 676 of IPv4 address depletion, but have not yet achieved working group 677 consensus for publication as an RFC. Dual-stack lite ietf-softwire- 678 dual-stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] requires the 679 CPE Router to support features such as v4 in v6 encapsulation and 680 softwires. Since Dual-stack lite ietf-softwire-dual-stack-lite-00 681 [I-D.ietf-softwire-dual-stack-lite] is under development in the IETF, 682 it has been moved to the bis version of this document. 684 8.4. DNS Support (CORE) 686 For local DNS queries for configuration, the CPE Router may include a 687 DNS server to handle local queries. Non-local queries can be 688 forwarded unchanged to a DNS server specified in the DNS server 689 DHCPv6 option. The local DNS server MAY also handle renumbering from 690 the Service Provider provided prefix for local names used exclusively 691 inside the home (the local AAAA and PTR records are updated). This 692 capability provides connectivity using local DNS names in the home 693 after a Service Provider renumbering. 695 8.5. Quality Of Service(QoS) 697 The CPE router MAY support differentiated services [RFC2474]. 699 9. IPv4 Support (CORE) 701 IPv4 support is largely out of scope for this document. However, a 702 brief overview of current practice in the market may be helpful since 703 the CPE Router may support both IPv4 and IPv6. This section does NOT 704 require the CPE Router to support IPv4. For background information 705 on IPv4 routing capabilities, please refer to [RFC1812]. Typically, 706 CPE Routers which support IPv4, also support IPv4 NAT for translating 707 private [RFC1918] addresses (e.g. 192.168.x.x) into a single non- 708 [RFC1918] WAN address assigned through DHCPv4 or manually configured. 709 In addition to NAT, CPE Routers that support IPv4 typically also 710 support Application Layer Gateway functionality (ALG), such as the 711 FTP ALG. The IPv4 NAT functionality typically has a built-in DHCPv4 712 server. A CPE Router which supports IPv4 also supports ARP and basic 713 unicast IPv4 forwarding. Some CPE Routers which support IPv4 also 714 support IPv4 multicast forwarding ([RFC5135]) and basic firewall 715 capabilities. A stateful firewall can enhance security by examining 716 the state of each connection and only allow traffic which conforms to 717 an expected packet flow. 719 10. DEVICE Constants 721 1. WAN_IP_ACQUIRE_TIMEOUT 180 seconds. 723 The default value of WAN_IP_ACQUIRE_TIMEOUT can be overidden by link- 724 type specific documents. 726 11. Future Work 728 All of the future work has been moved to a bis(updates) version of 729 this document. 731 12. Security Considerations 733 Security considerations of a CPE router are covered by 734 draft-ietf-v6ops-cpe-simple-security 735 [I-D.ietf-v6ops-cpe-simple-security]. 737 13. IANA Considerations 739 None. 741 14. Acknowledgements 743 Thanks (in alphabetical order) to Antonio Querubin, Barbara Stark, 744 Bernie Volz, Brian Carpenter, Carlos Pignataro, Dan Wing, David 745 Miles, Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark 746 Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, Shin 747 Miyakawa, Teemu Savolainen, Thomas Herbst, and Tony Hain for their 748 input on the document. 750 15. References 752 15.1. Normative References 754 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 755 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 756 September 2007. 758 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 759 Address Autoconfiguration", RFC 4862, September 2007. 761 15.2. Informative References 763 [I-D.baker-ipv6-prefix-subdelegation] 764 Baker, F., "Prefix Sub-delegation in a SOHO/SMB 765 Environment", draft-baker-ipv6-prefix-subdelegation-00 766 (work in progress), July 2009. 768 [I-D.despres-6rd] 769 Despres, R., "IPv6 Rapid Deployment on IPv4 770 infrastructures (6rd)", draft-despres-6rd-03 (work in 771 progress), April 2009. 773 [I-D.ietf-6man-ipv6-subnet-model] 774 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 775 Model: the Relationship between Links and Subnet 776 Prefixes", draft-ietf-6man-ipv6-subnet-model-05 (work in 777 progress), May 2009. 779 [I-D.ietf-6man-node-req-bis] 780 Loughney, J. and T. Narten, "IPv6 Node Requirements RFC 781 4294-bis", draft-ietf-6man-node-req-bis-03 (work in 782 progress), July 2009. 784 [I-D.ietf-softwire-dual-stack-lite] 785 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 786 Y., and R. Bush, "Dual-stack lite broadband deployments 787 post IPv4 exhaustion", 788 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 789 July 2009. 791 [I-D.ietf-v6ops-cpe-simple-security] 792 Woodyatt, J., "Recommended Simple Security Capabilities in 793 Customer Premises Equipment for Providing Residential 794 IPv6 Internet Service", 795 draft-ietf-v6ops-cpe-simple-security-07 (work in 796 progress), July 2009. 798 [I-D.townsley-ipv6-6rd] 799 Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider 800 Networks", draft-townsley-ipv6-6rd-01 (work in progress), 801 July 2009. 803 [RFC1122] Braden, R., "Requirements for Internet Hosts - 804 Communication Layers", STD 3, RFC 1122, October 1989. 806 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 807 RFC 1812, June 1995. 809 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 810 E. Lear, "Address Allocation for Private Internets", 811 BCP 5, RFC 1918, February 1996. 813 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 814 for IP version 6", RFC 1981, August 1996. 816 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 817 January 1997. 819 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 820 November 1998. 822 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 823 (IPv6) Specification", RFC 2460, December 1998. 825 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 826 "Definition of the Differentiated Services Field (DS 827 Field) in the IPv4 and IPv6 Headers", RFC 2474, 828 December 1998. 830 [RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device 831 Management Information Base for DOCSIS compliant Cable 832 Modems and Cable Modem Termination Systems", RFC 2669, 833 August 1999. 835 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 836 via IPv4 Clouds", RFC 3056, February 2001. 838 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 839 and M. Carney, "Dynamic Host Configuration Protocol for 840 IPv6 (DHCPv6)", RFC 3315, July 2003. 842 [RFC3484] Draves, R., "Default Address Selection for Internet 843 Protocol version 6 (IPv6)", RFC 3484, February 2003. 845 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 846 Multicast (SSM)", RFC 3569, July 2003. 848 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 849 Host Configuration Protocol (DHCP) version 6", RFC 3633, 850 December 2003. 852 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 853 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 854 December 2003. 856 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 857 (DHCP) Service for IPv6", RFC 3736, April 2004. 859 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 860 Delegation", RFC 3769, June 2004. 862 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 863 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 865 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 866 More-Specific Routes", RFC 4191, November 2005. 868 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 869 Addresses", RFC 4193, October 2005. 871 [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. 872 Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet 873 Access Service", RFC 4241, December 2005. 875 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 876 Architecture", RFC 4291, February 2006. 878 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 879 Proxies (ND Proxy)", RFC 4389, April 2006. 881 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 882 Network Tunneling", RFC 4459, April 2006. 884 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 885 "Considerations for Internet Group Management Protocol 886 (IGMP) and Multicast Listener Discovery (MLD) Snooping 887 Switches", RFC 4541, May 2006. 889 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 890 "Internet Group Management Protocol (IGMP) / Multicast 891 Listener Discovery (MLD)-Based Multicast Forwarding 892 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 894 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 895 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 896 Access Networks", RFC 4779, January 2007. 898 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 899 PPP", RFC 5072, September 2007. 901 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 902 Network Address Translator (NAT) and a Network Address 903 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 905 Authors' Addresses 907 Hemant Singh 908 Cisco Systems, Inc. 909 1414 Massachusetts Ave. 910 Boxborough, MA 01719 911 USA 913 Phone: +1 978 936 1622 914 Email: shemant@cisco.com 915 URI: http://www.cisco.com/ 917 Wes Beebee 918 Cisco Systems, Inc. 919 1414 Massachusetts Ave. 920 Boxborough, MA 01719 921 USA 923 Phone: +1 978 936 2030 924 Email: wbeebee@cisco.com 925 URI: http://www.cisco.com/