idnits 2.17.1 draft-gmann-homenet-relay-autoconf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-donley-dhc-cer-id-option-00 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-05 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6204 (Obsoleted by RFC 7084) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Grundemann 3 Internet-Draft C. Donley 4 Intended status: Informational CableLabs 5 Expires: September 13, 2012 March 12, 2012 7 Home Network Autoconfiguration via DHCPv6 Relay 8 draft-gmann-homenet-relay-autoconf-01 10 Abstract 12 This document describes a method for efficiently delegating subnets 13 of an IPv6 prefix among home routers while simultaneously creating 14 functional routing tables in all home routers without the need for a 15 routing protocol. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Expected Home Network Topologies . . . . . . . . . . . . . . . 3 59 3. Home Router Behavior . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. CER Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. IR Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Home Router Provisioning Example . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 There are several mechanisms for distributing IPv6 address and 72 routing information within a home network. However, many of these 73 require complex new protocols, or hierarchical addressing topologies. 74 A simpler and more efficient solution to home network 75 autoconfiguration is to provide centralized prefix delegation 76 control, utilize an existing protocol [RFC3315], and remove the need 77 for a routing protocol. This simpler approach can be achieved by 78 relaying all DHCPv6 IA_PD [RFC3633] requests and responses to and 79 from the CPE Edge Router (CER) and snooping their contents along the 80 way. This approach is analogous to how many Service Providers plan 81 to distribute IPv6 prefixes to subscribers in the WAN. 83 2. Expected Home Network Topologies 85 It is expected that home networks will be arbitrarily constructed by 86 home users. Figure 1 illustrates an example multi-router home 87 network topology. 89 This document assumes that the vast majority of home networks will 90 connect to a single ISP and will be generally constructed in a tree 91 architecture. This document also assumes that IPv6 hosts are capable 92 of dealing with multiple IPv6 addresses and have some manner of 93 address selection functionality (internal multi-homing). 95 +-------+-------+ \ 96 | Service | \ 97 | Provider | | Service 98 | Router | | Provider 99 +-------+-------+ | network 100 | / 101 | Customer / 102 | Internet connection 103 | 104 +------+--------+ \ 105 | IPv6 | \ 106 | Customer Edge | \ 107 | Router | | 108 +----+-+---+----+ | 109 Network A | | | Network B/E | 110 ----+-------------+----+ | +---+-------------+------+ | 111 | | | | | | | | 112 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 113 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 114 | | | | | | | | | | | 115 +----------+ +----------+ | +----------+ +----------+ | | 116 | | | | | 117 | ---+------+------+-----+ | 118 | | Network B/E | 119 +------+--------+ | | End-User 120 | IPv6 | | | networks 121 | Interior +------+ | 122 | Router | | 123 +---+-------+---+ | 124 Network C | | Network D | 125 ----+-------------+---+- --+---+-------------+--- | 126 | | | | | 127 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 128 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 129 | | | | | | | | / 130 +----------+ +----------+ +----------+ +----------+ / 132 Figure 1 134 3. Home Router Behavior 136 All routers within a home MUST be capable of determining whether or 137 not they are the CER for their home. This document recommends use of 138 the CER_ID [I-D.donley-dhc-cer-id-option] but other methods may also 139 be used. 141 3.1. CER Behavior 143 Once a home router has determined that it is the CER, it is 144 responsible for requesting, receiving and sub-delegating a GUA prefix 145 from the ISP [RFC6204], [I-D.ietf-v6ops-6204bis]. 147 Once the CER obtains a GUA prefix, it responds to all DHCPv6 requests 148 on its LAN interface. The CER MUST add a route to its routing table 149 mapping each delegated prefix to the DHCP client or DHCP relay to 150 which it was sent. 152 3.2. IR Behavior 154 Once a home router has determined that it is an Internal Router (IR) 155 (e.g. via receipt of the DHCP CER ID Option 156 [I-D.donley-dhc-cer-id-option] specifying a different router as CER) 157 and received an IA_PD, the IR MUST relay DHCPv6 IA_PD requests 158 [RFC3633] received on its LAN interface to the delegating router or 159 relay agent from which it received its IA_PD. 161 The IR MUST prefer its CER as its default router when directly 162 connected and MUST install an entry for IA_PD observed in DHCPv6 163 Relay message in its routing and forwarding tables. This behavior is 164 referred to as 'DHCP snooping'. When installing an entry in the 165 routing and forwarding tables for the observed IA_PD assignments, the 166 IR MUST map the IA_PD to the IR transmitting the request. The IR 167 MUST purge the IA_PD entry and the route to the prefix upon IA_PD 168 lease expiration. 170 4. Home Router Provisioning Example 172 1. CER Receives a GUA and IA_PD from the ISP. 174 2. CER configures a /64 on its LAN interface(s) and advertises 175 itself as a default router candidate in its RA. 177 3. Directly attached internal routers (Level 1 IRs) install a 178 default router based on RAs received from the CER and initiate 179 SLAAC when appropriate. When multiple default routers are 180 advertised, L1 IRs will choose the default router that matches 181 the received CER_ID whenever possible. 183 4. Level 1 IRs initiate DHCPv6 with CER. 185 A. Requests include IA_PD and CER_ID options, and may include 186 an IA_NA. 188 B. The CER responds to the IR with an IA_PD (e.g. /64), a 189 CER_ID that contains the CER's LAN IP, and IA_NA when 190 applicable. 192 5. The CER records to which IR each delegated prefix is distributed 193 and construct its routing and forwarding tables accordingly 194 [RFC3633]. 196 6. Level 1 IRs (L1IRs) advertise themselves as default router 197 candidates via their RAs and indicate whether DHCPv6 information 198 is available. 200 7. Indirectly attached (e.g. Level 2) IRs install a default router 201 based on RAs received from directly upstream IR(s) and initiate 202 SLAAC when appropriate. 204 8. Indirectly attached IRs initiate DHCPv6. 206 A. Requests include IA_PD and CER_ID options, and may include 207 an IA_NA. 209 B. The directly upstream IR responds with: CER_ID that contains 210 the CER's LAN IP, and IA_NA when applicable. 212 C. The directly attached IR relays the IA_PD request to the 213 delegating router or relay from which it obtained its IA_PD. 215 D. The CER responds to the IA_PD request with an IR IPv6 Prefix 216 (e.g. /64). 218 E. This response is relayed back to the IR via one or more 219 relays. 221 9. The CER records the IR or DHCPv6 relay to which the delegated 222 prefix is distributed and uses the mapping to build its routing 223 and forwarding tables. 225 10. IRs inspect the contents of all relayed IA_PD response and 226 record both the prefix contained and IR/downstream DHCPv6 relay 227 the message is sent to. These prefix/address tuples are used to 228 construct local routing and forwarding tables. 230 11. Indirectly attached IRs advertise themselves as default router 231 candidates via their RAs and indicate whether DHCPv6 information 232 is available. 234 12. Repeat steps 7 through 10 as needed. 236 5. IANA Considerations 238 This document makes no request of IANA. 240 Note to RFC Editor: this section may be removed on publication as an 241 RFC. 243 6. Security Considerations 245 TBD 247 7. Acknowledgements 249 TBD 251 8. Normative References 253 [I-D.donley-dhc-cer-id-option] 254 Donley, C. and C. Grundemann, "Customer Edge Router 255 Identification Option", draft-donley-dhc-cer-id-option-00 256 (work in progress), March 2012. 258 [I-D.ietf-v6ops-6204bis] 259 Stark, B., Donley, C., Singh, H., Troan, O., and W. 260 Beebee, "Basic Requirements for IPv6 Customer Edge 261 Routers", draft-ietf-v6ops-6204bis-05 (work in progress), 262 December 2011. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 268 and M. Carney, "Dynamic Host Configuration Protocol for 269 IPv6 (DHCPv6)", RFC 3315, July 2003. 271 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 272 Host Configuration Protocol (DHCP) version 6", RFC 3633, 273 December 2003. 275 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 276 Troan, "Basic Requirements for IPv6 Customer Edge 277 Routers", RFC 6204, April 2011. 279 Authors' Addresses 281 Chris Grundemann 282 CableLabs 283 858 Coal Creek Cir 284 Louisville, CO 80027 285 US 287 Email: c.grundemann@cablelabs.com 289 Chris Donley 290 CableLabs 291 858 Coal Creek Cir 292 Louisville, CO 80027 293 US 295 Email: c.donley@cablelabs.com