idnits 2.17.1 draft-baker-homenet-prefix-assignment-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 8, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Home Networking F. Baker 3 Internet-Draft R. Droms 4 Intended status: Informational Cisco Systems 5 Expires: September 9, 2012 March 8, 2012 7 IPv6 Prefix Assignment in Small Networks 8 draft-baker-homenet-prefix-assignment-01 10 Abstract 12 It is necessary to allocate prefixes in small networks, which include 13 residential and Small Office/Home Office (SOHO) networks in a manner 14 that minimizes or eliminates manual configuration. This note 15 suggests an approach. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 9, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 4 54 3. Simple Tree Network Case . . . . . . . . . . . . . . . . . . . 4 55 3.1. Assignment of prefixes in a simple network . . . . . . . . 5 56 3.1.1. CPE Router Behavior . . . . . . . . . . . . . . . . . 5 57 3.1.2. Interior Router Behavior . . . . . . . . . . . . . . . 6 58 4. Issues in a simple cascade procedure . . . . . . . . . . . . . 7 59 4.1. Sequence of subnet number allocation . . . . . . . . . . . 8 60 4.2. Multihoming Issues . . . . . . . . . . . . . . . . . . . . 8 61 4.3. Race Conditions . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Scaling Issues . . . . . . . . . . . . . . . . . . . . . . 9 63 4.5. Prefix Stability . . . . . . . . . . . . . . . . . . . . . 9 64 4.6. When you run out of prefixes . . . . . . . . . . . . . . . 9 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 10 68 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 One of the objectives of the design of IPv6 [RFC2460] has been to 77 reduce or minimize the need for manual configuration in networks. 78 IPv4 [RFC0791] networks, when it became widely deployed in the 79 1980's, required manual configuration, and the scaling limits of the 80 approach quickly became apparent. One of the outcomes of that was 81 the Dynamic Host Configuration Protocol [RFC2131] (DHCP), which 82 facilitated central administration of desktop computers. In 83 practice, DHCP itself has been of limited utility in the 84 administration of network equipment; while it is conceptually 85 possible to use it for any kind of configuration, more flexible 86 protocols such as the Network Configuration Protocol 87 [RFC6241][RFC6242] have been preferred. 89 Allocation of prefixes in small networks calls for an approach that 90 can be completely automated. This note documents a procedure that 91 has been suggested by several. It builds on a few basic assumptions: 93 o IPv6 prefixes are allocated to a small network by one or more 94 upstream service providers using [RFC3315] and [RFC3363]. 96 o IPv6 prefixes may allocated to LAN within a small network by the 97 CPE Router using [RFC3315] and [RFC3363]. 99 o Occasional inefficiencies such as allocating two /64s to a LAN 100 from a given upstream prefix are acceptable, especially if short- 101 lived. 103 o Small networks, such as described in Home Networking Architecture 104 for IPv6 [I-D.chown-homenet-arch], are simple enough in structure 105 that the mechanism described in this note is adequate. 107 These assumptions bear analysis. The first two, that prefixes can 108 and may be allocated using mechanisms designed for the purpose, seems 109 self-evident. The third builds on the IPv6 premise that a host may 110 have more than one prefix on an interface and one or more addresses 111 in each prefix; in such a case, while it may be suboptimal to 112 allocate more than one /64 from the same upstream prefix, the hosts 113 will not complain and the routing protocols will route them. The 114 fourth may be considered the limit of applicability; if a network 115 requires a prefix aggregation design or is otherwise too complex for 116 this procedure to be effective, other procedures are more 117 appropriate. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Scope of this Document 127 This document describes a procedure for prefix delegation and 128 assignment. It results in the assignment of a series of /64 prefixes 129 on the links in a small home network. 131 While this document describes the use of DHCPv6 for prefix 132 delegation, specification of the use of DHCPv6 for address assignment 133 and other purposes is out of scope. 135 If a network includes interior routers and the CPE router is not 136 directly to all of the links in the network, the routers in the 137 network will need routing information to forward traffic in the 138 network and between the network and the service provider network. 139 The specification of a routing protocol or other mechanism to provide 140 that routing information to the routers is beyond the scope of this 141 document. 143 3. Simple Tree Network Case 145 The first case to describe is that of a network with a simple tree 146 topology. In this network, there is a single CPE router attached to 147 a single SP network. The interior of the network is organized as a 148 tree. Each interior router has one "upstream" interface and one or 149 more "downstream" interfaces. Each link in the network has a single 150 interior router with a downstream interface attached and zero or more 151 interior routers with an upstream interface attached. 153 The fundamental procedure for prefix allocation takes three phases: 155 o Allocating a prefix from the upstream network, 157 o Prefix allocation by the CPE Router, and 159 o Prefix allocation by a subsequent router. 161 3.1. Assignment of prefixes in a simple network 163 This section describes the assignment of prefixes in a simple 164 network. The network is assumed to be tree-structured, including one 165 CPE router that is connected to a SP network and one or more interior 166 routers. The interior routers each have a single "upstream" 167 interface and one or more "downstream" interfaces. The upstream 168 interface of each interior router is connected to a link in the 169 network to which a downstream interface of a router closer to the CPE 170 router is already connected. 172 The CPE router obtains a delegated prefix for the entire home 173 network, and manages prefix allocations for all of the interior 174 routers. Each interior router uses DHCPv6 on its upstream interface 175 to obtain delegated prefixes from the CPE router for each of the 176 interior routers downstream interfaces. 178 3.1.1. CPE Router Behavior 180 The CPE router obtains a delegated prefix from the SP provisioning 181 system using [RFC3315] and [RFC3363] and other appropriate 182 provisioning systems. The prefix delegated from the service provider 183 includes a preferred and valid lifetime for the prefix. 185 Once the CPE router has received a delegated prefix, it assigns a /64 186 subprefix to each of the links to which the router is attached. The 187 CPE router configures an address to each of its interfaces from the 188 prefix assigned to the link to which the interface is attached. 190 After assigning the interface addresses, the CPE router begins 191 sending Router Advertisement (RA) messages [RFC4861] advertising the 192 appropriate prefix on each attached link. The RAs include preferred 193 and valid lifetimes derived from the lifetimes associated with the 194 delegated prefix from the service provider. The RA also advertises 195 the CPE router as the default router for the link. Other fields in 196 the RAs are set as appropriate. 198 At this point, the links to which the CPE router is attached are now 199 provisioned with prefixes taken from the prefix obtained from the 200 service provider. The CPE router uses ongoing DHCPv6 messages 201 exchanges according to [RFC3315] and [RFC3363] to maintain and update 202 its delegated prefix. 204 The CPE router implements a DHCPv6 server for prefix subdelegation 205 throughout the rest of the network. In preparation for assigning 206 prefixes to links in the rest of the network, the CPE router makes 207 all of the remaining prefixes from the network prefix available for 208 subdelegation through a DHCPv6 server. The CPE router configures the 209 preferred and valid lifetimes for the subdelegated prefixes from the 210 values received from the service provider. 212 3.1.2. Interior Router Behavior 214 When an interior router is connected to the home network, its 215 upstream interface is attached to a link in the home network, and its 216 downstream interfaces are connected to other links to be added to the 217 home network. 219 3.1.2.1. Network with a Tree Topology 221 After the upstream interface is attached to a link, the interior 222 router listens for RAs on the upstream interface and configures the 223 upstream interface according to the information contained in the 224 received RAs. 226 When the interior router receives an RA, the router initiates a 227 DHCPv6 message exchange to obtain any needed prefixes from the prefix 228 managed by the allocating router. The interior router requests the 229 delegation of a separate /64 prefix for each of its downstream 230 interfaces. The DHCPv6 service in the home network delivers the 231 DHCPv6 traffic between the interior router and the CPE router. 233 The CPE router delegates the requested prefixes from the prefix 234 delegated to the network. The interior router then assigns a prefix 235 to each link attached to which a downstream interface is attached, 236 configures those downstream interfaces with addresses from the 237 assigned prefixes and begins sending RAs on the downstream 238 interfaces. The preferred and valid lifetimes for the advertised 239 prefix are derived from the lifetimes in the DHCPv6 delegation, and 240 the RAs advertise the interior router as the default router for the 241 link. 243 3.1.2.2. Non-tree Topologies 245 It is quite likely that real world deployments will violate the 246 assumption in the previous section that only one downstream interface 247 will be attached to each link in the home network. In this 248 situation, it is desirable that the link only be assigned one prefix 249 and, therefore, only one of the interior routers with a downstream 250 interface on the link be responsible for assigning a prefix and 251 sending RAs on the link. 253 To avoid duplicate address assignment, a router first listens for RAs 254 on the link attached to its downstream interface. If the router does 255 not receive an RA after listening for INTERVAL1 microfortnights, the 256 router assumes it is responsible for assigning a prefix to that link 257 and initiates the DHCPv6 process for obtaining a delegated prefix. 259 After the router determines it is responsible for the link attached 260 to its downstream interface, it continues to listen for RAs from 261 other routers on the link. If it receives an RA from another router, 262 it deassigns its delegated prefix from the link, unconfigures any 263 addresses assigned from that prefix and releases the delegated prefix 264 to the CPE router using DHCPv6. 266 Discussion: there is a race condition in this; two routers may 267 make the decision to manage the link's prefix simultaneously. To 268 avoid this, the timing should be jittered enough to make this 269 unlikely. 271 If a router hears an RA such as described in Section 3.1.2, it uses 272 IPv6 Stateless Address Autoconfiguration [RFC4862][RFC4941] or a 273 DHCPv6 [RFC3315] request to each announced allocator to generate an 274 address within the prefix for use in that subnet. 276 After the router determines that some other router is responsible for 277 the link attached to its downstream interface, it continues to listen 278 on the interface for RAs. If the router receives no RA on the 279 interface for INTERVAL2 microfortnights, the router takes 280 responsibility for the link and initiates the process described above 281 to obtain and assign a prefix to the link. 283 3.1.2.3. Multi-homed Network 285 If a network has multiple service provider networks, it will have 286 multiple prefixes. This situation is easiest to describe if the 287 network is connected to each service provider through a separate CPE 288 router. 290 Each CPE router obtains a delegated prefix from its service provider 291 and then manages the prefix according to the discussion in Section 1. 293 First layer of interior router get multiple direct DHCPv6 prefixes. 294 Assigns each prefix in parallel. Sets up DHCPv6 relay agent to point 295 to each of the CPE routers. 297 Next layer receives DHCPv6 transaction from each CPE router because 298 upstream router forwards DHCPv6 messages to each of the CPE routers. 300 4. Issues in a simple cascade procedure 302 There are a number of potential issues in this procedure. 304 4.1. Sequence of subnet number allocation 306 Apart from cases in which the administration has chosen to fix a 307 given subnet to a given LAN, such as to support server deployment in 308 DNS, it is generally advised that subnet numbers be randomized. This 309 is to make certain network attacks a little more difficult. 311 4.2. Multihoming Issues 313 One issue is "what happens if one has multiple upstream networks with 314 multiple CPE Routers and therefore multiple allocators?" The design 315 of the RA information element announcing the allocator is intended to 316 simplify that by announcing an allocator. 318 4.3. Race Conditions 320 In the simplest case, there are no race conditions; the home has 321 exactly one router, it obtains a prefix from its upstream network, 322 and sub-allocates to its interfaces. If there are additional routers 323 in the home, however, either there are one or more links that are not 324 attached to the CPE Router or there are zero; in the event that there 325 are one or more such links, they may be connected by one router or by 326 multiple routers. 328 One race condition is when two interior routers are attached to the 329 same LANs as the CPE. For example, one might have a wireless router 330 in the home that connects both to the wired and the wireless network 331 that the CPE Router is on. In such a case, it will hear and 332 interpret one of the CPE Router's RAs first, and then the other some 333 amount of time later. The purpose of the INTERVAL1 delay in 334 Section 3.1.2 is to allow this race condition to stabilize before the 335 router acts on this information it has. 337 A second race condition occurs when two "subsequent" routers are on 338 the same LAN but it is not serviced by the CPE Router. These routers 339 will both use the procedure of Section 3.1.2 to attempt to allocate a 340 prefix to the LAN and so create a subnet. It is RECOMMENDED that the 341 allocator allocate at most one prefix per INTERVAL2, ignoring all 342 other requests, in order to allow the "subsequent" routers to sort 343 out this class of race condition. If needed, ignored routers will 344 re-request the allocation. 346 Due to the possibility of packet loss in the network, it is possible 347 that these race conditions may result in a given LAN developing 348 multiple subnets. While suboptimal, this is not a violation of the 349 architecture and should cause no issues. However, in the event that 350 two routers observe that they are announcing different subnets in the 351 same upstream prefix on the same LAN, the one with the numerically 352 least subnet number SHOULD NOT allow its prefix to expire, but any 353 others SHOULD allow their prefixes to expire. 355 4.4. Scaling Issues 357 Obviously, use of this procedure in a complex network results in a 358 serialization of prefix allocation that may take more time to settle 359 than is operationally desirable (number of LANs times INTERVAL2). In 360 such cases, the administration will have to decide how it wants to 361 handle the issue. One approach would be to divide the network into 362 easily-aggregated sections and use the procedure within each section; 363 another would be to use a different procedure. 365 In such networks, the routers requesting prefixes can also act as a 366 denial of service attack, by flooding the CPE Router with requests. 367 Given that the procedure eventually terminates, this is undesirable 368 but of limited duration. 370 4.5. Prefix Stability 372 In networks that contain servers or names that are announced in DNS, 373 it is often valuable to have the same LAN always have the same subnet 374 number applied to it. The procedure as described could accomplish 375 that if the CPE Router maintains memory of what router it has 376 allocated a given prefix to recently, or would fail to provide that 377 if it does not. The distinction is essentially a marketing 378 requirement that the implementation will need to decide for itself. 380 4.6. When you run out of prefixes 382 If a network runs out of subnet numbers and therefore subnet 383 prefixes, this is considered a provisioning failure. It can result 384 when multiple prefixes are allocated to the same LAN, which should be 385 unusual and will end when one of the routers releases its prefix. It 386 can also result when the upstream network allocates a prefix that is 387 too long and as a result contains too few potential prefixes. In 388 that case, the administration is forced to either reorganize its 389 network or negotiate for a shorter prefix. 391 5. IANA Considerations 393 This specification makes no request of the IANA. 395 6. Security Considerations 397 399 6.1. Privacy Considerations 401 403 7. Change Log 405 Initial Version: 4 October 2011 407 March 2012 Removed RA option. 409 8. References 411 8.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 8.2. Informative References 418 [I-D.chown-homenet-arch] 419 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 420 Networking Architecture for IPv6", 421 draft-chown-homenet-arch-01 (work in progress), 422 October 2011. 424 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 425 September 1981. 427 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 428 RFC 2131, March 1997. 430 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 431 (IPv6) Specification", RFC 2460, December 1998. 433 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 434 and M. Carney, "Dynamic Host Configuration Protocol for 435 IPv6 (DHCPv6)", RFC 3315, July 2003. 437 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 438 Hain, "Representing Internet Protocol version 6 (IPv6) 439 Addresses in the Domain Name System (DNS)", RFC 3363, 440 August 2002. 442 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 443 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 444 September 2007. 446 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 447 Address Autoconfiguration", RFC 4862, September 2007. 449 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 450 Extensions for Stateless Address Autoconfiguration in 451 IPv6", RFC 4941, September 2007. 453 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 454 Bierman, "Network Configuration Protocol (NETCONF)", 455 RFC 6241, June 2011. 457 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 458 Shell (SSH)", RFC 6242, June 2011. 460 Authors' Addresses 462 Fred Baker 463 Cisco Systems 464 Santa Barbara, California 93117 465 USA 467 Email: fred@cisco.com 469 Ralph Droms 470 Cisco Systems 471 1414 Massachusetts Avenue 472 Boxborough, Massachusetts 01719 473 USA 475 Email: rdroms@cisco.com