idnits 2.17.1 draft-ietf-v6ops-ipv6-cpe-router-00.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 126: '... and, therefore, MUST follow IPv6 Node...' RFC 2119 keyword, line 220: '... The CPE Router SHOULD support the ab...' RFC 2119 keyword, line 235: '... The CPE Router MUST support at least...' RFC 2119 keyword, line 291: '... hosts MAY send RS's to solicit an R...' RFC 2119 keyword, line 292: '... of a CPE Router SHOULD send an RS aft...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: It is possible that in future, IPv6 global unicast prefix can expand beyond 2000::/3. Therefore the CPE Router MUST not have hard coded filters tied to only allow prefixes in a given range. The CPE Router SHOULD be capable of treating any address not already reserved for a specific use by the IETF (such as Link-Local and Multicast addresses) as a potential global unicast address. == 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 (March 25, 2009) is 5482 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2453' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC3769' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'RFC5214' is defined on line 951, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-6man-ipv6-subnet-model-03 == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-02 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-00 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-hs-framework-l2tpv2-12 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-04 -- 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) -- Obsolete informational reference (is this intentional?): RFC 4214 (Obsoleted by RFC 5214) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 9 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: BCP Cisco Systems, Inc. 5 Expires: September 26, 2009 March 25, 2009 7 IPv6 CPE Router Recommendations 8 draft-ietf-v6ops-ipv6-cpe-router-00 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 September 26, 2009. 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.6.1. Softwire Support (DEV) . . . . . . . . . . . . . . . . 11 94 5.7. Stateful DHCPv6 Server (CORE) . . . . . . . . . . . . . . 12 95 6. Cascading of Routers behind the CPE Router (MEDIUM) . . . . . 12 96 7. IPv6 Data Forwarding (CORE) . . . . . . . . . . . . . . . . . 12 97 7.1. IPv6 ND Proxy Behavior (DEV) . . . . . . . . . . . . . . . 13 98 7.2. IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . . 14 99 8. Other IPv6 Features . . . . . . . . . . . . . . . . . . . . . 14 100 8.1. Path MTU Discovery Support (MEDIUM) . . . . . . . . . . . 14 101 8.2. Optional RIPng Support (CORE) . . . . . . . . . . . . . . 15 102 8.3. Firewall (DEV) . . . . . . . . . . . . . . . . . . . . . . 15 103 8.3.1. Packet Filters (DEV) . . . . . . . . . . . . . . . . . 15 104 8.4. Zero Configuration Support (MEDIUM) . . . . . . . . . . . 15 105 8.5. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite 106 (DEV)/ISATAP (MEDIUM) . . . . . . . . . . . . . . . . . . 16 107 8.6. DNS Support (DEV) . . . . . . . . . . . . . . . . . . . . 16 108 8.7. Quality Of Service(QoS) . . . . . . . . . . . . . . . . . 17 109 9. IPv4 Support (CORE) . . . . . . . . . . . . . . . . . . . . . 17 110 10. DEVICE Constants . . . . . . . . . . . . . . . . . . . . . . . 18 111 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 114 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 115 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 116 15.1. Normative References . . . . . . . . . . . . . . . . . . . 18 117 15.2. Informative References . . . . . . . . . . . . . . . . . . 19 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 120 1. Introduction 122 This document defines IPv6 features for a residential or small office 123 router referred to as a CPE Router. Typically, CPE Router devices 124 support IPv4, as discussed in the "IPv4 Support" section. Also, this 125 document does not go into configuration details for the CPE Router. 126 A CPE Router is an IPv6 Node and, therefore, MUST follow IPv6 Node 127 Requirements draft-ietf-6man-node-req-bis-01 128 [I-D.ietf-6man-node-req-bis]. 130 The document discusses IPv6 implications for the attached Service 131 Provider network. The document notes that the CPE Router may be 132 deployed in home in one of two ways. Either the Service Provider or 133 the home user may manage this device. When the CPE Router is managed 134 by the Service Provider, the router may need additional management 135 and routing properties like a new MIB definition and routing 136 protocols communicating between the CPE Router and the Service 137 Provider network. The CPE router has one or more WAN interface(s) to 138 connect to the Service Provider and zero or more LAN interfaces to 139 the home network devices. The WAN interface is preferred to be 140 Ethernet encapsulated but it may support other encapsulations such as 141 PPP. 143 Technologies are labelled as: CORE (widely deployed in the field, 144 many years of operational experience, one or more standards-track 145 RFC's exist), MEDIUM (standards-track RFC exists, but is a recent 146 development and/or has limited deployments, or still has known 147 unresolved problems), under DEVelopment (no standards-track RFC 148 exists and/or has not yet been deployed). 150 2. Terminology and Abbreviations 152 Host - this is a personal computer or any other network device in 153 a home that connects to the Internet via the CPE Router. 155 LAN interface(s) - an optional set of network interfaces on the 156 CPE Router that are used to connect hosts in the home. This set 157 of ports could be switched, bridged, or routed. If no LAN 158 interface is present, then there is no need for the CPE router to 159 provide LAN side services such as DHCPv6 PD or ULA's. 161 WLAN interface - an optional wireless access point interface on 162 the CPE Router used to connect wireless hosts in the home in 163 either managed or ad-hoc modes. 165 WAN interface - usually a single physical network interface on the 166 standalone CPE Router that is used to connect the router to the 167 access network of the Service Provider. When the CPE Router is 168 embedded in a device that connects to the WAN, this interface is a 169 logical network interface that bridges the device to the CPE 170 Router. Some devices which can have an embedded CPE router are: a 171 cable or DSL modem, or a cellular telephone, etc. A CPE router 172 with more than one WAN interface will need a more complicated 173 provisioning and multicast model than is described in this 174 document. 176 GRE tunnel - Generic Routing Encapsulation tunnel. 178 SLAAC - StateLess Address Auto Configuration. 180 IPTV - Internet Protocol TeleVision. 182 mDNS - Multicast Domain Name System - see http://www.zeroconf.org. 184 3. Operational Behavior 186 The CPE Router is a gateway to the Internet for a home. The router 187 is also intended to provide home networking functionality. The CPE 188 Router may have a console or web interface for configuration. This 189 document defines the core set of features that are supported by the 190 CPE Router, however individual implementations may include value- 191 added features such as WLAN capability. 193 The core set of IPv6 features for the CPE Router includes 194 provisioning the CPE Router for IPv6, IPv6 data forwarding including 195 IPv6 multicast, CPE Router provisioning hosts on its LAN 196 interface(s), firewall, and QoS behavior. An IPv6 firewall is 197 discussed briefly in the Firewall section where the section refers 198 the draft-ietf-v6ops-cpe-simple-security 199 [I-D.ietf-v6ops-cpe-simple-security] for more details. 201 3.1. Conceptual Configuration Variables 203 The CPE Router maintains such a list of conceptual optional 204 configuration variables. 206 1. Loopback interface enable. 208 2. PPPOE enable. 210 3. Softwire enable. 212 4. RIPng enable. 214 5. If DHCPv6 fails, the CPE Router may initiate PPPOE, L2TPv2 215 Softwire tunnel, or 6to4 [RFC3056] operation. 217 4. Router Initialization 219 Before the CPE Router is initialized, the device must have IPv6 220 enabled. The CPE Router SHOULD support the ability to disable its 221 IPv6 stack. The CPE Router also has the ability to block or forward 222 IPv6 traffic to and from the router's LAN interface(s). [RFC2669] 223 includes a MIB definition to block the IPv4 or IPv6 Ethertype in the 224 upstream or downstream interface(s) of a device such as the CPE 225 Router. Some portion of this MIB may need to be modified for use 226 with the CPE Router. 228 The CPE Router supports at least one of two modes of initialization: 229 either the LAN interface(s) become operational first or the WAN 230 interface becomes operational first. More details have been provided 231 in the Basic IPv6 Provisioning section. 233 5. Basic IPv6 Provisioning 235 The CPE Router MUST support at least one of two WAN interface models, 236 one of which will be active on the CPE Router at any given time. In 237 the Numbered model, the WAN interface acquires a global unicast 238 address (GUA) using a combination of SLAAC and stateful DHCPv6 for 239 IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA) and 240 IA_PD. IA_PD is acquired using stateful DHCPv6 as described in 241 [RFC3633]. A Loopback interface (which can be used as a stable 242 peering point for routing protocols or to respond to the anycast 243 address) is optional. If stateful DHCPv6 is not used to obtain other 244 IPv6 configuration, then stateless DHCPv6 [RFC3736] must be initiated 245 by the WAN interface to obtain other IPv6 configuration. Further, in 246 the numbered model, we recommend the CPE Router WAN interface acquire 247 its global IPv6 address using stateful DHCPv6 for administrative 248 control of the router. Manual configuration may be supported by the 249 CPE router for IPv6 address configuration of the WAN interface. 250 However, manual configuration is beyond the scope of this document. 252 In the Unnumbered model, the WAN interface only constructs a LLA, 253 then the WAN interface initiates stateful DHCPv6 for IA_PD. The 254 IA_PD is sub-delegated to the LAN interface(s) and an optional 255 Loopback interface (or the addresses for the LAN/Loopback interfaces 256 could come from IA_NAs). Either the Loopback or the LAN interface 257 can be used to source WAN-facing traffic. Other IPv6 configuration 258 information is obtained using stateless DHCPv6. 260 The CPE Router acquires its IPv6 addresses from the Service Provider 261 along with any other IPv6 configuration any time the WAN interface is 262 connected to the Service Provider network. Thereafter the CPE Router 263 provisions its LAN interface(s) for IPv6 router functionality 264 including provisioning global IPv6 addresses on the LAN interface(s). 265 Even if LAN interface(s) have been operational and provisioned 266 earlier, the global IPv6 configuration of LAN interface(s) is still 267 required. More details for provisioning the CPE Router are given in 268 the following sections. 270 5.1. Construct Link-Local Address (CORE) 272 If an interface of the CPE Router is configured for IPv6, when the 273 interface initializes itself, as per [RFC4862], the CPE Router must 274 create a link-local address for the interface. We recommend the CPE 275 Router use the EUI-64 identifier as a link-local address for each of 276 its interfaces. Refer to EUI-64 details in [RFC4291]. Further, as 277 per [RFC4862], the CPE Router must perform Duplicate Address 278 Detection (DAD) on all unicast addresses unless a layer 2-specific 279 document specifies that DupAddrDetectTransmits is zero for that 280 linktype. If the CPE Router detects a duplicate address assigned to 281 an interface, the CPE Router must not send IPv6 packets from the 282 interface. 284 5.2. Process RAs (CORE) 286 The CPE Router must process incoming RAs received on the WAN 287 interface as specified in section 6.3 of [RFC4861]. The CPE Router 288 locates routers that reside on the attached WAN link from the 289 received RAs. With respect to RS behavior, the WAN interface of the 290 CPE Router acts as a host. Section 4.1 of [RFC4861] states that 291 hosts MAY send RS's to solicit an RA quickly. The WAN interface(s) 292 of a CPE Router SHOULD send an RS after link-local address 293 construction. 295 5.3. Acquire IPv6 Address and Other Configuration Parameters (CORE) 297 The CPE Router must process RAs received on the WAN interface. As 298 per [RFC4861] if the M bit is set in the RA, the WAN interface must 299 perform stateful DHCPv6- if the O bit is set in the RA, the WAN 300 interface acquires other configuration information. If stateful 301 DHCPv6 is not used to obtain other IPv6 configuration, then stateless 302 must be initiated by the WAN interface to obtain other IPV6 303 configuration. If the A bit in the RA is clear or the RA does not 304 include any Prefix Information Option (PIO), the WAN interface must 305 not perform SLAAC. IPv6 deployments that configure RA to not include 306 any PIO are discussed in draft-ietf-6man-ipv6-subnet-model 307 [I-D.ietf-6man-ipv6-subnet-model]. 309 5.3.1. Numbered Model (CORE) 311 As instructed by the RA message, the WAN interface acquires global 312 IPv6 address using stateful DHCPv6 or SLAAC. 314 5.3.2. Unnumbered Model (MEDIUM) 316 When the CPE router is configured for Unnumbered model, the WAN 317 interface only constructs a LLA, then the WAN interface initiates 318 stateful DHCPv6 for IA_PD. Then the IA_PD is sub-delegated to the 319 LAN interface(s) and an optional Loopback interface (or the addresses 320 for the LAN/Loopback interfaces could come from IA_NAs). Either the 321 Loopback or the LAN interface can be used to source WAN-facing 322 traffic. When the Loopback or the LAN interface is used to source 323 WAN-facing traffic, both the CPE Router and the Service Provider 324 Router must consider the traffic to be off-link to the link 325 connecting the CPE Router with the Service Provider Router. Other 326 IPv6 configuration information is obtained using stateless DHCPv6. A 327 CPE Router acts as a host for packets originating from or destined 328 for the CPE Router. Such packets may include SNMP or web-based 329 router configuration, tunnel encapsulation/decapsulation, or PPP 330 endpoint packets. The Unnumbered model is incompatible with the 331 strong host model [RFC1122] on the CPE router (such as a personal 332 computer running PPP and routing code). The unnumbered model may be 333 inappropriate for use with certain deployments where a device that 334 uses the strong host model can operate as a CPE Router. 336 5.3.3. Both Models 338 At any instance in time of the CPE Router operation, the router does 339 not forward any traffic between its WAN and LAN interface(s) if the 340 router has not completed IPv6 provisioning process that involves the 341 acquisition of a global IPv6 address by the WAN or if the WAN is 342 unnumbered and there is no GUA available to source WAN packets. The 343 LAN interface(s) must also be provisioned for a global or Unique 344 Local Address. 346 5.4. Details for DHCPv6 Address Acquisition (CORE) 348 If the WAN interface uses stateful DHCPv6, the interface sends a 349 DHCPv6 Solicit message as described in section 17.1.1 of [RFC3315]. 350 The Solicit message must include an IA_NA option as specified by 351 [RFC3315]. If the WAN interfaces uses stateless DHCPv6, the WAN 352 interface sends an Information Request. Both the DHCPv6 SOLICIT and 353 Information Request also include other options like a Reconfigure 354 Accept option to inform the server that client is willing to accept 355 Reconfigure message from server, and the Options Request option that 356 includes the DNS Recursive Name server option as specified in 358 [RFC3646]. The Solicit may also include the Rapid Commit option if 359 the CPE Router is willing to accept a 2-message DHCPv6 exchange with 360 the server. 362 When the CPE Router processes a DHCPv6 response from the server, if 363 the response message (e.g. ADVERTISE or REPLY) received does not 364 include an IA_PD option (if stateful DHCPv6 was initiated), or 365 Reconfigure Accept option, then the CPE Router has failed DHCPv6 366 address acquisition. If stateful DHCPv6 succeeds, the CPE Router 367 must perform DAD for any IPv6 address acquired from DHCPv6. If the 368 CPE Router detects a duplicate, the CPE Router must send a DHCPv6 369 Decline message to the DHCPv6 server. 371 The CPE Router may support the Reconfigure Key Authentication 372 Protocol, as described in section 21.5 of [RFC3315]. The CPE Router 373 may also support prefix sub-delegation. Prefix sub-delegation 374 involves DHCPv6 server support with IA_PD on the CPE router and the 375 ability to provision the server from a DHCPv6 REPLY with IA_PD option 376 received on the WAN interface. 378 5.5. IPv6 Provisioning of Home Devices (CORE) 380 The CPE Router may include a stateful DHCPv6 server to assign 381 addresses to home devices connected via the LAN interface(s) of the 382 CPE Router. The home devices can also acquire addresses via SLAAC. 384 If the LAN interface(s) are switched or bridged ports, then the CPE 385 Router assigns a single global IPv6 address to a conceptual virtual 386 interface serving all the LAN interface(s). If each LAN interface is 387 a routed port, then the CPE router will assign a global IPv6 address 388 and unique subnet to each LAN interface. In either case, when the 389 CPE Router needs to assign a single IPv6 address to LAN interface(s) 390 or multiple IPv6 addresses, the CPE Router redistributes the 391 addresses and subnets from the prefix received in IA_PD option by the 392 WAN interface. If the IA_PD changes, the CPE Router must reconfigure 393 the LAN interface(s) with new IPv6 addresses derived from the new 394 IA_PD and then also renumber the IPv6 ND RA configuration on the LAN 395 interface(s). 397 This document recommends the RA sent out by LAN Interface(S) to be 398 configured for SLAAC so that the prefix advertised in the RA is 399 derived from the IA_PD assigned to the CPE Router by the Service 400 Provider; the O-bit is also set so that the CPE Router can pass 401 Domain Name Server(s) IPv6 address(es) to home devices. The CPE 402 Router obtained the Domain Name Server(s) in OPTION_DNS_SERVERS 403 option from the DHCPv6 server when the CPE Router WAN interface 404 completed DHCPv6. 406 5.5.1. LAN Initialization before WAN Initialization 408 On power up, the LAN interface(s) of the CPE Router may become 409 operational before the WAN interface. This mode is appropriate for 410 manual user configuration of the CPE Router. After any LAN interface 411 has constructed a link-local address, the address can be used for 412 user configuration via the network. The interface can assign itself 413 a Unique Local Address automatically through the pseudo-random number 414 generation algorithm described in [RFC4193]. Note that the ULA must 415 have a larger subnet than a /64 if multiple routers are cascaded 416 behind the CPE router and prefix sub-delegation is used (see the 417 Cascading of Routers behind the CPE Router section below). Once the 418 IPv6 address configuration of the LAN interface(s) is complete with a 419 ULA, as per [RFC4862], the CPE Router sends Router Advertisements 420 (RA) to devices in the home. Hosts receiving the RA from LAN 421 interface(s) will process the RA and perform IPv6 address 422 acquisition. After all the LAN interface(s) have become operational, 423 if the WAN interface is connected to the Service Provider network, 424 then the WAN interface provisions itself and may acquire an IA_PD. 425 If an IA_PD is acquired, it may be sub-delegated to any cascaded 426 routers or used for SLAAC provisioning of hosts in the home. Based 427 on the IA_PD, the CPE Router configures global address(es) on the LAN 428 interface(s) and sends an RA containing the global address and unique 429 local prefixes out the LAN interface(s). After this process, every 430 LAN interface has a link-local unicast address, a ULA, and a GUA. 431 Therefore, the interface has to apply source address selection to 432 determine which address to use as a source for outgoing packets. 433 Since the GUA has a larger scope than the link-local address, or the 434 ULA (rule #2 of [RFC3484]), the GUA will be used as a source address 435 of outgoing packets that are not subject to rule #1. If a user 436 desires to keep CPE Router configuration traffic local to the home 437 network, the user can do the following: 439 Use the ULA of the CPE Router as the destination of the 440 configuration traffic. 442 Use access control lists (ACL)s to block any ULA sourced packet 443 from being sent out the WAN interface. 445 Rule #1 of [RFC3484] and the ACLs ensure that the traffic does not 446 escape the home network. 448 After the WAN interface initializes, then the LAN interface(s) can 449 acquire global unicast addresses. 451 5.5.2. WAN initialization before LAN Initialization 453 On power up, the WAN interface of the CPE Router may become 454 operational before the LAN interface(s). This mode is appropriate 455 for Service Provider configuration of the CPE Router (such as a Cable 456 DOCSIS eRouter). After the IPv6 address configuration for WAN 457 interface is completed, the CPE Router configures IPv6 address for 458 LAN interface(s). 460 Once IPv6 address configuration of the LAN interface(s) is complete, 461 as per [RFC4862], the CPE Router sends Router Advertisements (RA) to 462 devices in the home. Hosts receiving the RA from LAN interface(s) 463 will process the RA and perform IPv6 address acquisition. 465 5.6. IPv6 over PPP 467 In some deployments IPv6 over PPP is preferred to connect the home to 468 the Service Provider. For such a deployment, another configuration 469 variable on the CPE Router enables optional IPv6 over PPP support. 470 After IPv6CP negotiates IPv6 over PPP and the WAN interface has 471 constructed a LLA, steps mentioned in the "Acquire IPv6 Address and 472 Other Configuration Parameters" section above are followed to acquire 473 a GUA for WAN interface and also an IA_PD. If an IA_PD is acquired 474 by the WAN interface, the CPE Router assigns global address(es) to 475 its LAN interface(s) and sub-delegates the IA_PD to hosts connected 476 to the LAN interface(s). IPv6 over PPP follows [RFC5072]. As per 477 [RFC5072], the CPE router does not initiate any DAD for unicast IPv6 478 addresses since DupAddrDetectTransmits variable from [RFC4862] is 479 zero for IPv6 over PPP. 481 If the Service Provider deployment supports dual-stack PPP support, 482 then the CPE Router WAN interface may initiate one PPP logical 483 channel and support NCP IPv4 and IPv6 control protocols over one PPP 484 logical channel. [RFC4241] describes such behavior. The IPv4 and 485 IPv6 NCP's are independent of each other and start and terminate 486 independently. 488 5.6.1. Softwire Support (DEV) 490 If the CPE Router is deployed in a deployment where the home includes 491 IPv6 hosts but the Service Provider network does not support IPv6, an 492 optional softwire feature may be enabled on the CPE Router. The 493 softwire draft-ietf-softwire-hs-framework-l2tpv2 494 [I-D.ietf-softwire-hs-framework-l2tpv2] initiates L2TPv2 tunnel from 495 the CPE Router to tunnel IPv6 data from the home over an IPv4 496 network. The feature is enabled before any IPv6 host in the home is 497 connected to the CPE Router or the WAN interface of the CPE Router is 498 operational. If the CPE Router supports the Softwire feature, then 499 the CPE Router must support the deployment scenario of Router CPE as 500 Softwire Initiator described in section 3.1.2 of 501 draft-ietf-softwire-hs-framework-l2tpv2 502 [I-D.ietf-softwire-hs-framework-l2tpv2]. IPV6CP negotiates IPv6 over 503 PPP which also provides the capability for the Service Provider to 504 assign the 64-bit Interface-Identifier to the WAN interface of the 505 CPE Router. After the WAN interface has acquired an IA_PD option, 506 global addresses from the IA_PD are assigned to the LAN interface(s) 507 and the IA_PD is also sub-delegated to clients connected to the LAN 508 interface(s). 510 5.7. Stateful DHCPv6 Server (CORE) 512 The CPE Router may support a stateful DHCPv6 server to serve clients 513 on the CPE Router LAN interface(s). If the CPE Router needs to 514 support a stateful DHCPv6 server, then more details will be added to 515 this section specifying the minimal functionality that the stateful 516 DHCPv6 server needs to support. 518 6. Cascading of Routers behind the CPE Router (MEDIUM) 520 To support cascading routers behind the CPE Router this document 521 recommends using prefix sub-delegation of the prefix obtained either 522 via IA_PD from WAN interface or a ULA from the LAN interface. The 523 network interface of the downstream router may obtain an IA_PD either 524 via stateful DHCPv6 or stateless DHCPv6. If the CPE router supports 525 cascading of routers through automatic prefix sub-delegation, the CPE 526 router MUST support a DHCPv6 server or DHCPv6 relay agent. If an 527 IA_PD is used, the Service Provider or user MUST allocate an IA_PD or 528 ULA prefix short enough to be sub-delegated and subsequently used for 529 SLAAC. Therefore, a prefix length shorter than /64 is needed. The 530 CPE Router MAY support RIPng in the home network. 532 7. IPv6 Data Forwarding (CORE) 534 Each of the WAN and LAN interface(s) of the CPE Router must have its 535 own L2 (e.g. MAC) address. The CPE Router supports ND protocol on 536 both the WAN interface and LAN interface(s) to advertise itself as a 537 router to neighbors in the Service Provider and home networks. 539 The CPE Router forwards packets between the Service Provider and the 540 home network. To do this, the CPE Router looks up the destination 541 address of the packet in the routing table and decide which route to 542 use to forward the packet. The CPE Router routing table will be 543 initialized during CPE Router initialization. The routing table is 544 filled by directly connected, static, and routing protocol routes. 546 The CPE Router consumes any packet destined to its WAN or LAN 547 interface. The CPE Router forwards other packets destined to hosts 548 attached to CPE Router LAN interface(s). Any packet that is not 549 routable by the CPE Router must be dropped. 551 The CPE Router must support the ND protocol specified by [RFC4861]. 552 Proxy Neighbor Advertisements as described in Section 7.2.8 of 553 [RFC4861] as applicable to the CPE Router are discussed in the IPv6 554 ND Proxy Behavior section. Also note, as per section 6.2.8 of 555 [RFC4861] the link-local address on a router should rarely change, if 556 ever. As per [RFC2460], the CPE Router decrements the Hop Limit by 1 557 for any packet it forwards. The packet is discarded if Hop Limit is 558 decremented to zero and the CPE Router also sends an ICMP Time 559 Exceeded message to the source of the packet. 561 A null route SHOULD be added to the routing table (to prevent routing 562 loops) that is lower priority than any route except the default 563 route. The choice to drop the packet or send an ICMPv6 Destination 564 Unreachable to the source address of the packet is implementation- 565 dependent. The installation of this null route MAY be automatic. 567 7.1. IPv6 ND Proxy Behavior (DEV) 569 If the CPE Router has only one /64 prefix to be used across multiple 570 LAN interfaces and the CPE Router supports any two LAN interfaces 571 that cannot bridge data between them because the two interfaces have 572 disparate MAC layer, then the CPE Router MUST support ND Proxy 573 [RFC4389]. If any two LAN interfaces support bridging between the 574 interfaces, then ND Proxy is not necessary between the two 575 interfaces. Legacy 3GPP networks have the following requirements: 577 1. No DHCPv6 prefix is delegated to the CPE Router. 579 2. Only one /64 is available on the WAN link. 581 3. The link types between the WAN interface and LAN interface(s) are 582 disparate and, therefore, can't be bridged. 584 4. No NAT66 is to be used. 586 5. Each LAN interface needs global connectivity. 588 6. Uses SLAAC to configure LAN interface addresses. 590 For these legacy 3GPP networks, the CPE Router MUST support ND Proxy 591 between the WAN and LAN interface(s). However, if the CPE Router has 592 multiple prefixes available for use on LAN interfaces(s), then ND 593 Proxy is not necessary. 595 7.2. IPv6 Multicast Behavior (CORE) 597 The CPE Router SHOULD follow the model described for MLD Proxy in 598 [RFC4605] to implement multicast. The MLD Proxy model was chosen 599 because it is simpler to implement than more complicated multicast 600 routing functionality. 602 Querier Election rules as described in section 7.6.2 of [RFC3810] do 603 not apply to the CPE Router (even when the home has multiple cascaded 604 routers) since every CPE Router in the cascade is the only router in 605 its own multicast domain. Every CPE Router in the cascade will send 606 MLDv2 Reports with aggregated multicast Group Membership information 607 to the next upstream router. 609 If the CPE Router hardware includes a network bridge between the WAN 610 interface and the LAN interface(s), then the CPE Router MUST support 611 MLDv2 snooping as per [RFC4541]. 613 Consistent with [RFC4605], the CPE Router must not implement the 614 router portion of MLDv2 for the WAN interface. Likewise, the LAN 615 interfaces on the CPE router must not implement an MLDv2 Multicast 616 Listener. However, if a user at home wants to create a new multicast 617 group and send multicast data to other nodes on the Service Provider 618 network, then Protocol Independent Multicast-Source Specific 619 Multicast (PIM-SSM) [RFC3569] is recommended to handle multicast 620 traffic flowing in the upstream direction as a one-to-many multicast 621 flow. 623 8. Other IPv6 Features 625 8.1. Path MTU Discovery Support (MEDIUM) 627 GRE tunnels, such as IPv6 to IPv4 tunnels (which may be terminated on 628 the CPE Router), can modify the default Ethernet MTU of 1500 bytes. 629 Also, in the future, Ethernet Jumbo frames (9000+ bytes) may also be 630 supported. Since the MTU can vary, a newly initiated TCP stream must 631 detect the largest packet that can be sent to the destination without 632 fragmentation. This can be detected using Path MTU Discovery 633 [RFC1981]. Routers which may encounter a packet too large to be 634 forwarded from source to destination may drop the packet and send an 635 ICMPv6 Packet Too Big message to the source. The CPE Router must 636 route back to the source any ICMPv6 Packet Too Big messages generated 637 anywhere on this path. 639 8.2. Optional RIPng Support (CORE) 641 The CPE Router may support RIPng routing protocol [RFC2080] so that 642 RIPng operates between the CPE Router and the Service Provider 643 network. RIPng has scaling and security implications for the Service 644 Provider network where one Service Provider router may terminate 645 several tens of thousands of CPE routers. However, RIPng does 646 provide one solution from the CPE Router to the Service Provider 647 network for prefix route injection. 649 8.3. Firewall (DEV) 651 The CPE Router must support an IPv6 Firewall feature. The firewall 652 may include features like access-control lists. The firewall may 653 support interpretation or recognition of most IPv6 extension header 654 information including inspecting fragmentation header. The firewall 655 must support stateful and stateless Packet Filters as follows. 657 8.3.1. Packet Filters (DEV) 659 The CPE Router must support packet filtering based on IP headers, 660 extended headers, UDP and TCP ports etc. There are numerous filters 661 mentioned (section 3.2) in draft-ietf-v6ops-cpe-simple-security 662 [I-D.ietf-v6ops-cpe-simple-security], like some that allow IKE, IPSec 663 packets while another filter may block Teredo packets. 665 It is possible that in future, IPv6 global unicast prefix can expand 666 beyond 2000::/3. Therefore the CPE Router MUST not have hard coded 667 filters tied to only allow prefixes in a given range. The CPE Router 668 SHOULD be capable of treating any address not already reserved for a 669 specific use by the IETF (such as Link-Local and Multicast addresses) 670 as a potential global unicast address. 672 6to4 and ISATAP tunnels may be initiated by hosts behind the CPE 673 Router. The CPE Router MUST NOT block 6to4 or ISATAP packets without 674 a configurable override. 676 8.4. Zero Configuration Support (MEDIUM) 678 The CPE Router MAY support manual configuration via the web using a 679 URL string like http://router.local as per mDNS described in the 680 Terminology and Abbreviations section. Note that mDNS is a link- 681 local protocol, so extra functionality is required if configuration 682 is to be supported over cascaded routers. Support of configuration 683 through cascaded routers is beyond the scope of this document. 685 8.5. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)/ISATAP 686 (MEDIUM) 688 If the IPv4 address assigned to the WAN interface of the CPE Router 689 is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire 690 an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring 691 the IPv4 address, then the 6to4 tunneling protocol [RFC3056] SHOULD 692 be enabled automatically, allowing tunneling of IPv6 packets over 693 IPv4 without requiring user configuration. If an anycast 6to4 server 694 cannot be located, the CPE Router MAY initiate ISATAP [RFC4214] to 695 establish IPv6 connectivity over the IPv4 network. If an IPv6 696 address is acquired, but no IPv4 address is acquired before 697 WAN_IP_ACQUIRE_TIMEOUT seconds after the IPv6 address was acquired, 698 then the CPE Router SHOULD use DS-Lite and disable NAT44 in the CPE 699 Router. If both IPv6 and IPv4 addresses are acquired within 700 WAN_IP_ACQUIRE_TIMEOUT seconds of each other, then the CPE Router 701 operates in dual stack mode, and does not need either 6to4 or DS- 702 Lite. If no IPv4 and no IPv6 address has been acquired, then the CPE 703 Router retries acquisition. 705 6to4 can be useful in the scenario where the Service Provider does 706 not yet support IPv6, but devices in the home use IPv6. An IPv6 707 address is constructed automatically from the IPv4 address (V4ADDR) 708 configured on the interface using the prefix 2002:V4ADDR::/48. A 709 6to4 tunnel can be automatically created using a pre-configured 6to4 710 gateway end-point for the tunnel. 712 Several proposals are being considered by IETF related to the problem 713 of IPv4 address depletion, but have not yet achieved working group 714 consensus for publication as an RFC. Dual-stack lite ietf-softwire- 715 dual-stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] requires the 716 CPE Router to support features such as v4 in v6 encapsulation and 717 softwires. Further, any approach which requires the use of a tunnel 718 MUST take into account the reduced MTU. The tunnel software on the 719 CPE Router MUST be capable of fragmenting data packets. 721 For DS-Lite, the CPE Router also discovers the IPv6 address of the 722 Carrier Grade NAT node in the deployment. The ietf-softwire-dual- 723 stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] draft has yet to 724 fully describe the method of discovery. 726 8.6. DNS Support (DEV) 728 For local DNS queries for configuration, the CPE Router may include a 729 DNS server to handle local queries. Non-local queries can be 730 forwarded unchanged to a DNS server specified in the DNS server 731 DHCPv6 option. The CPE Router may also include DNS64 functionality. 732 In that case, the prefix used is either a well-known prefix or 733 configured through DHCPv6 or SNMP. An A record is simply passed 734 through untouched. An AAAA record is relayed to the server. If the 735 CPE Router receives no response, then an A query is used. If the A 736 query returns a response, then an AAAA record is synthesized using 737 the prefix and sent to the host. If DNSSEC is used, then both an A 738 record (authenticated with DNSSEC), and the synthesized AAAA record 739 (possibly tagged as synthetic with an EDNS0 option, IDENT bit(s), or 740 using a well-known prefix) is returned. This allows unmodified hosts 741 to simply use the synthetic AAAA record (without DNSSEC). Modified 742 hosts can look at the DNSSEC A record, authenticate it, then 743 synthesize its own AAAA record in a stub resolver located in the 744 host. Therefore, unmodified hosts can get connectivity, but modified 745 hosts can also authenticate DNS records. The local DNS server MAY 746 also handle renumbering from the Service Provider provided prefix for 747 local names used exclusively inside the home (the local AAAA records 748 are updated). This capability provides connectivity using local DNS 749 names in the home after a Service Provider renumbering. A CPE Router 750 MAY add local DNS entries based on dynamic requests from the LAN 751 segment(s). The protocol to carry such requests from hosts to the 752 CPE Router is yet to be described. 754 8.7. Quality Of Service(QoS) 756 The CPE router MAY support differentiated services [RFC2474]. 758 9. IPv4 Support (CORE) 760 IPv4 support is largely out of scope for this document. However, a 761 brief overview of current practice in the market may be helpful since 762 the CPE Router may support both IPv4 and IPv6. This section does NOT 763 require the CPE Router to support IPv4. For background information 764 on IPv4 routing capabilities, please refer to [RFC1812]. Typically, 765 CPE Routers which support IPv4, also support IPv4 NAT for translating 766 private [RFC1918] addresses (e.g. 192.168.x.x) into a single non- 767 [RFC1918] WAN address assigned through DHCPv4 or manually configured. 768 In addition to NAT, CPE Routers that support IPv4 typically also 769 support Application Layer Gateway functionality (ALG), such as the 770 FTP ALG. The IPv4 NAT functionality typically has a built-in DHCPv4 771 server. A CPE Router which supports IPv4 also supports ARP and basic 772 unicast IPv4 forwarding. Some CPE Routers which support IPv4 also 773 support IPv4 multicast forwarding ([RFC5135]) and basic firewall 774 capabilities. A stateful firewall can enhance security by examining 775 the state of each connection and only allow traffic which conforms to 776 an expected packet flow. 778 10. DEVICE Constants 780 1. WAN_IP_ACQUIRE_TIMEOUT 180 seconds. 782 The default value of WAN_IP_ACQUIRE_TIMEOUT can be overidden by link- 783 type specific documents. 785 11. Future Work 787 1. Enumerate requirements in list form (to be done after 788 requirements are solidified). 790 2. Preferred Lifetime vs. Valid Lifetime for ULA's and Source 791 Address Selection. 793 12. Security Considerations 795 Security considerations of a CPE router are covered by 796 draft-ietf-v6ops-cpe-simple-security 797 [I-D.ietf-v6ops-cpe-simple-security]. 799 13. IANA Considerations 801 None. 803 14. Acknowledgements 805 Thanks (in alphabetical order) to Antonio Querubin, Barbara Stark, 806 Bernie Volz, Brian Carpenter, Carlos Pignataro, Dan Wing, David 807 Miles, Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark 808 Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, Shin 809 Miyakawa, Teemu Savolainen, Thomas Herbst, and Tony Hain for their 810 input on the document. 812 15. References 814 15.1. Normative References 816 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 817 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 818 September 2007. 820 15.2. Informative References 822 [I-D.ietf-6man-ipv6-subnet-model] 823 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 824 Model: the Relationship between Links and Subnet 825 Prefixes", draft-ietf-6man-ipv6-subnet-model-03 (work in 826 progress), March 2009. 828 [I-D.ietf-6man-node-req-bis] 829 Loughney, J., "IPv6 Node Requirements RFC 4294-bis", 830 draft-ietf-6man-node-req-bis-02 (work in progress), 831 November 2008. 833 [I-D.ietf-softwire-dual-stack-lite] 834 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 835 "Dual-stack lite broadband deployments post IPv4 836 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 837 in progress), March 2009. 839 [I-D.ietf-softwire-hs-framework-l2tpv2] 840 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 841 Tremblay, "Softwire Hub & Spoke Deployment Framework with 842 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-12 (work 843 in progress), March 2009. 845 [I-D.ietf-v6ops-cpe-simple-security] 846 Woodyatt, J., "Recommended Simple Security Capabilities in 847 Customer Premises Equipment for Providing Residential 848 IPv6 Internet Service", 849 draft-ietf-v6ops-cpe-simple-security-04 (work in 850 progress), March 2009. 852 [RFC1122] Braden, R., "Requirements for Internet Hosts - 853 Communication Layers", STD 3, RFC 1122, October 1989. 855 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 856 RFC 1812, June 1995. 858 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 859 E. Lear, "Address Allocation for Private Internets", 860 BCP 5, RFC 1918, February 1996. 862 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 863 for IP version 6", RFC 1981, August 1996. 865 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 866 January 1997. 868 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 869 November 1998. 871 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 872 (IPv6) Specification", RFC 2460, December 1998. 874 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 875 "Definition of the Differentiated Services Field (DS 876 Field) in the IPv4 and IPv6 Headers", RFC 2474, 877 December 1998. 879 [RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device 880 Management Information Base for DOCSIS compliant Cable 881 Modems and Cable Modem Termination Systems", RFC 2669, 882 August 1999. 884 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 885 via IPv4 Clouds", RFC 3056, February 2001. 887 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 888 and M. Carney, "Dynamic Host Configuration Protocol for 889 IPv6 (DHCPv6)", RFC 3315, July 2003. 891 [RFC3484] Draves, R., "Default Address Selection for Internet 892 Protocol version 6 (IPv6)", RFC 3484, February 2003. 894 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 895 Multicast (SSM)", RFC 3569, July 2003. 897 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 898 Host Configuration Protocol (DHCP) version 6", RFC 3633, 899 December 2003. 901 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 902 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 903 December 2003. 905 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 906 (DHCP) Service for IPv6", RFC 3736, April 2004. 908 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 909 Delegation", RFC 3769, June 2004. 911 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 912 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 914 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 915 Addresses", RFC 4193, October 2005. 917 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 918 "Intra-Site Automatic Tunnel Addressing Protocol 919 (ISATAP)", RFC 4214, October 2005. 921 [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. 922 Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet 923 Access Service", RFC 4241, December 2005. 925 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 926 Architecture", RFC 4291, February 2006. 928 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 929 Proxies (ND Proxy)", RFC 4389, April 2006. 931 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 932 "Considerations for Internet Group Management Protocol 933 (IGMP) and Multicast Listener Discovery (MLD) Snooping 934 Switches", RFC 4541, May 2006. 936 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 937 "Internet Group Management Protocol (IGMP) / Multicast 938 Listener Discovery (MLD)-Based Multicast Forwarding 939 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 941 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 942 Address Autoconfiguration", RFC 4862, September 2007. 944 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 945 PPP", RFC 5072, September 2007. 947 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 948 Network Address Translator (NAT) and a Network Address 949 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 951 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 952 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 953 March 2008. 955 Authors' Addresses 957 Hemant Singh 958 Cisco Systems, Inc. 959 1414 Massachusetts Ave. 960 Boxborough, MA 01719 961 USA 963 Phone: +1 978 936 1622 964 Email: shemant@cisco.com 965 URI: http://www.cisco.com/ 967 Wes Beebee 968 Cisco Systems, Inc. 969 1414 Massachusetts Ave. 970 Boxborough, MA 01719 971 USA 973 Phone: +1 978 936 2030 974 Email: wbeebee@cisco.com 975 URI: http://www.cisco.com/