idnits 2.17.1 draft-baker-homenet-prefix-assignment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 4, 2011) is 4587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3971' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 480, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-chown-homenet-arch-00 -- 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft R. Droms 4 Intended status: Informational Cisco Systems 5 Expires: April 6, 2012 October 4, 2011 7 IPv6 Prefix Assignment in Small Networks 8 draft-baker-homenet-prefix-assignment-00 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 Requirements 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 [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 April 6, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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. Scope of this Document . . . . . . . . . . . . . . . . . . . . 4 59 3. Simple Tree Network Case . . . . . . . . . . . . . . . . . . . 4 60 3.1. Assignment of prefxies in a simple network . . . . . . . . 4 61 3.1.1. CPE Router Behavior . . . . . . . . . . . . . . . . . 5 62 3.1.2. Interior Router Behavior . . . . . . . . . . . . . . . 5 63 4. Issues in a simple cascade procedure . . . . . . . . . . . . . 8 64 4.1. Sequence of subnet number allocation . . . . . . . . . . . 8 65 4.2. Multihoming Issues . . . . . . . . . . . . . . . . . . . . 8 66 4.3. Race Conditions . . . . . . . . . . . . . . . . . . . . . 8 67 4.4. Scaling Issues . . . . . . . . . . . . . . . . . . . . . . 9 68 4.5. Prefix Stability . . . . . . . . . . . . . . . . . . . . . 9 69 4.6. When you run out of prefixes . . . . . . . . . . . . . . . 9 70 5. Router Advertisement Allocator Information Element . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 10 74 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 One of the objectives of the design of IPv6 [RFC2460] has been to 83 reduce or minimize the need for manual configuration in networks. 84 IPv4 [RFC0791] networks, when it became widely deployed in the 85 1980's, required manual configuration, and the scaling limits of the 86 approach quickly became apparent. One of the outcomes of that was 87 the Dynamic Host Configuration Protocol [RFC2131] (DHCP), which 88 facilitated central administration of desktop computers. In 89 practice, DHCP itself has been of limited utility in the 90 administration of network equipment; while it is conceptually 91 possible to use it for any kind of configuration, more flexible 92 protocols such as the Network Configuration Protocol 93 [RFC6241][RFC6242] have been preferred. 95 Allocation of prefixes in small networks calls for an approach that 96 can be completely automated. This note documents a procedure that 97 has been suggested by several. It builds on a few basic assumptions: 99 o IPv6 prefixes are allocated to a small network by one or more 100 upstream service providers using [RFC3315] and [RFC3363]. 102 o IPv6 prefixes may allocated to LAN within a small network by the 103 CPE Router using [RFC3315] and [RFC3363]. 105 o Occasional inefficiencies such as allocating two /64s to a LAN 106 from a given upstream prefix are acceptable, especially if short- 107 lived. 109 o Small networks, such as described in Home Networking Architecture 110 for IPv6 [I-D.chown-homenet-arch], are simple enough in structure 111 that the mechanism described in this note is adequate. 113 These assumptions bear analysis. The first two, that prefixes can 114 and may be allocated using mechanisms designed for the purpose, seems 115 self-evident. The third builds on the IPv6 premise that a host may 116 have more than one prefix on an interface and one or more addresses 117 in each prefix; in such a case, while it may be suboptimal to 118 allocate more than one /64 from the same upstream prefix, the hosts 119 will not complain and the routing protocols will route them. The 120 fourth may be considered the limit of applicability; if a network 121 requires a prefix aggregation design or is otherwise too complex for 122 this procedure to be effective, other procedures are more 123 appropriate. 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 prefxies 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. 189 After assigning the interface addresses, the CPE router begins 190 sending Router Advertisement (RA) messages [RFC4861] advertising the 191 appropriate prefix on each attached link. 193 The CPE router includes a Router Advertisement Allocator Information 194 (RAAI) option, identifying itself as the allocating server for 195 prefixes related to the prefix announced in the RA. The RAs include 196 preferred and valid lifetimes derived from the lifetimes associated 197 with the delegated prefix from the service provider. The RA also 198 advertises the CPE router as the default router for the link. Other 199 fields in the RAs are set as appropriate. 201 At this point, the links to which the CPE router is attached is now 202 provisioned with prefixes taken from the prefix obtained from the 203 service provider. The CPE router uses ongoing DHCPv6 messages 204 exchanges according to [RFC3315] and [RFC3363] to maintain and update 205 its delegated prefix. 207 The CPE router uses a DHCPv6 server for prefix subdelegation 208 throughout the rest of the network. In preparation for assigning 209 prefixes to links in the rest of the network, the CPE router makes 210 all of the remaining prefixes from the network prefix available for 211 subdelegation through a DHCPv6 server. The CPE router configures the 212 preferred and valid lifetimes for the subdelegated prefixes from the 213 values received from the service provider. 215 3.1.2. Interior Router Behavior 217 When an interior router is connected to the home network, its 218 upstream interface is attached to a link in the home network, and its 219 downstream interfaces are connected to other links to be added to the 220 home network. 222 3.1.2.1. Network with a Tree Topology 224 After the upstream interface is attached to a link, the interior 225 router listens for RAs on the upstream interface and configures the 226 upstream interface according to the information contained in the 227 received RAs. 229 When the interior router receives an RA with an RAAI option, the 230 router initiates a DHCPv6 message exchange to obtain prefixes from 231 the prefix managed by the allocating router. The interior router 232 requests the delegation of a separate /64 prefix for each of its 233 downstream interfaces. The DHCPv6 service in the home network 234 delivers the DHCPv6 traffic between the interior router and the CPE 235 router. 237 Discussion: The interior router conducts the DHCPv6 message exchange 238 directly with the allocating DHCPv6 server using IPv6 unicast. 239 This technique assumes that the interior router has already 240 obtained an address of sufficient scope through SLAAC or an 241 earlier DHCPv6 address assignment. This technique also breaks the 242 rule in RFC 3315 requiring the use of multicast and the DHCPv6 243 client's link-local address. 245 The requirements regarding DHCPv6 message addressing in RFC 3315 246 are based primarily on the need for some sort of address on the 247 DHCPv6 client before address assigment is completed and the desire 248 to forward all DHCPv6 traffic through a relay agent to allow for 249 relay agent processing. The procedures in this specification 250 require that the interior router (DHCPv6 client) already has an 251 IPv6 address of sufficient scope before initiating any DHCPv6 252 message exchanges for prefix delegation. There is no need, in 253 this specification, for realy agent processing, so direct 254 communication between the interior router and the allocating 255 DHCPv6 server is allowed. 257 The primary advantage to allowing direct DHCPv6 message exchanges 258 in this specification is the avoiding the need for a relay agent 259 infrastrcuture throughout the network. Otherwise, each interior 260 router would have to act as a realy agent for potentially several 261 DHCPv6 servers delegating prefixes for the network. 263 The CPE router delegates the requested prefixes from the prefix 264 delegated to the network. The interior router then assigns a prefix 265 to each link attached to which a downstream interface is attached, 266 configures those downstream interfaces with addresses from the 267 assigned prefixes and begins sending RAs on the downstream 268 interfaces. The interior router includes an RAAI option in the RAs, 269 indentifying the CPE router as the allocating DHCPv6 server. The 270 preferred and valid lifetimes for the advertised prefix are derived 271 from the lifetimes in the DHCPv6 delegation, and the RAs advertise 272 the interior router as the default router for the link. 274 3.1.2.2. Non-tree Topologies 276 It is quite likely that real world deployments will violate the 277 assumption in the previous section that only one downstream interface 278 will be attached to each link in the home network. In this 279 situation, it is desirable that the link only be assigned one prefix 280 and, therefore, only one of the interior routers with a downstream 281 interface on the link be responsible for assigning a prefix and 282 sending RAs on the link. 284 To avoid duplicate address assignment, a router first listens for RAs 285 on the link attached to its downstream interface. If the router does 286 not receive an RA after listening for INTERVAL1 microfortnights, the 287 router assumes it is responsible for assigning a prefix to that link 288 and initiates the DHCPv6 process for obtaining a delegated prefix. 290 After the router determines it is responsible for the link attached 291 to its downstream interface, it continues to listen for RAs from 292 other routers on the link. If it receives an RA from another router, 293 it deassigns its delegated prefix from the link, unconfigures any 294 addresses assigned from that prefix and releases the delegated prefix 295 to the CPE router using DHCPv6. 297 If a router hears an RA such as described in Section 3.1.2, it uses 298 IPv6 Stateless Address Autoconfiguration [RFC4862][RFC4941] or a 299 DHCPv6 [RFC3315] request to each announced allocator to generate an 300 address within the prefix for use in that subnet. 302 After the router determines that some other router is responsible for 303 the link attached to its downstream interface, it continues to listen 304 on the interface for RAs. If the router receives no RA on the 305 interface for INTERVAL2 microfortnights, the router takes 306 responsibility for the link and initiates the process described above 307 to obtain and assign a prefix to the link. 309 3.1.2.3. Multi-homed Network 311 If a network has multiple service provider networks, it will have 312 multiple prefixes. This situation is easiest to describe if the 313 network is connected to each service provider through a separate CPE 314 router. 316 Each CPE router obtains a delegated prefix from its service provider 317 and then manages the prefix according to the 319 First layer of interior router get multiple direct DHCPv6 prefixes. 320 Assigns each prefix in parallel. Sets up DHCPv6 relay agent to point 321 to each of the CPE routers. 323 Next layer receives DHCPv6 transaction from each CPE router because 324 upstream router forwards DHCPv6 messages to each of the CPE routers. 326 4. Issues in a simple cascade procedure 328 There are a number of potential issues in this procedure. 330 4.1. Sequence of subnet number allocation 332 Apart from cases in which the administration has chosen to fix a 333 given subnet to a given LAN, such as to support server deployment in 334 DNS, it is generally advised that subnet numbers be randomized. This 335 is to make certain network attacks a little more difficult. 337 4.2. Multihoming Issues 339 One issue is "what happens if one has multiple upstream networks with 340 multiple CPE Routers and therefore multiple allocators?" The design 341 of the RA information element announcing the allocator is intended to 342 simplify that by announcing an allocator. 344 4.3. Race Conditions 346 In the simplest case, there are no race conditions; the home has 347 exactly one router, it obtains a prefix from its upstream network, 348 and sub-allocates to its interfaces. If there are additional routers 349 in the home, however, either there are one or more links that are not 350 attached to the CPE Router or there are zero; in the event that there 351 are one or more such links, they may be connected by one router or by 352 multiple routers. 354 One race condition is when two interior routers are attached to the 355 same LANs as the CPE. For example, one might have a wireless router 356 in the home that connects both to the wired and the wireless network 357 that the CPE Router is on. In such a case, it will hear and 358 interpret one of the CPE Router's RAs first, and then the other some 359 amount of time later. The purpose of the INTERVAL1 delay in 360 Section 3.1.2 is to allow this race condition to stabilize before the 361 router acts on this information it has. 363 A second race condition occurs when two "subsequent" routers are on 364 the same LAN but it is not serviced by the CPE Router. These routers 365 will both use the procedure of Section 3.1.2 to attempt to allocate a 366 prefix to the LAN and so create a subnet. It is RECOMMENDED that the 367 allocator allocate at most one prefix per INTERVAL2, ignoring all 368 other requests, in order to allow the "subsequent" routers to sort 369 out this class of race condition. If needed, ignored routers will 370 re-request the allocation. 372 Due to the possibility of packet loss in the network, it is possible 373 that these race conditions may result in a given LAN developing 374 multiple subnets. While suboptimal, this is not a violation of the 375 architecture and should cause no issues. However, in the event that 376 two routers observe that they are announcing different subnets in the 377 same upstream prefix on the same LAN, the one with the numerically 378 least subnet number SHOULD NOT allow its prefix to expire, but any 379 others SHOULD allow their prefixes to expire. 381 4.4. Scaling Issues 383 Obviously, use of this procedure in a complex network results in a 384 serialization of prefix allocation that may take more time to settle 385 than is operationally desirable (number of LANs times INTERVAL2). In 386 such cases, the administration will have to decide how it wants to 387 handle the issue. One approach would be to divide the network into 388 easily-aggregated sections and use the procedure within each section; 389 another would be to use a different procedure. 391 In such networks, the routers requesting prefixes can also act as a 392 denial of service attack, by flooding the CPE Router with requests. 393 Given that the procedure eventually terminates, this is undesirable 394 but of limited duration. 396 4.5. Prefix Stability 398 In networks that contain servers or names that are announced in DNS, 399 it is often valuable to have the same LAN always have the same subnet 400 number applied to it. The procedure as described could accomplish 401 that if the CPE Router maintains memory of what router it has 402 allocated a given prefix to recently, or would fail to provide that 403 if it does not. The distinction is essentially a marketing 404 requirement that the implementation will need to decide for itself. 406 4.6. When you run out of prefixes 408 If a network runs out of subnet numbers and therefore subnet 409 prefixes, this is considered a provisioning failure. It can result 410 when multiple prefixes are allocated to the same LAN, which should be 411 unusual and will end when one of the routers releases its prefix. It 412 can also result when the upstream network allocates a prefix that is 413 too long and as a result contains too few potential prefixes. In 414 that case, the administration is forced to either reorganize its 415 network or negotiate for a shorter prefix. 417 5. Router Advertisement Allocator Information Element 419 On a Neighbor Discovery RA, Section 3.1.2 and Section 3.1.2 call for 420 the RA to identify the allocator that a "subsequent" router may use 421 to request a related prefix for use on a different interface. This 422 information element contains a list of the IPv6 addresses of one or 423 more allocators, and an element length option to permit parsing of 424 the information element. 426 6. IANA Considerations 428 In Section 5, this note specifies an information element to be 429 carried in the Router Advertisement message specified in Neighbor 430 Discovery. 432 7. Security Considerations 434 436 7.1. Privacy Considerations 438 440 8. Change Log 442 Initial Version: 4 Octoboer 2011 444 9. References 446 9.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 9.2. Informative References 453 [I-D.chown-homenet-arch] 454 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 455 Networking Architecture for IPv6", 456 draft-chown-homenet-arch-00 (work in progress), 457 September 2011. 459 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 460 September 1981. 462 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 463 RFC 2131, March 1997. 465 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 466 (IPv6) Specification", RFC 2460, December 1998. 468 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 469 and M. Carney, "Dynamic Host Configuration Protocol for 470 IPv6 (DHCPv6)", RFC 3315, July 2003. 472 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 473 Hain, "Representing Internet Protocol version 6 (IPv6) 474 Addresses in the Domain Name System (DNS)", RFC 3363, 475 August 2002. 477 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 478 Neighbor Discovery (SEND)", RFC 3971, March 2005. 480 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 481 Proxies (ND Proxy)", RFC 4389, April 2006. 483 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 484 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 485 September 2007. 487 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 488 Address Autoconfiguration", RFC 4862, September 2007. 490 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 491 Extensions for Stateless Address Autoconfiguration in 492 IPv6", RFC 4941, September 2007. 494 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 495 Bierman, "Network Configuration Protocol (NETCONF)", 496 RFC 6241, June 2011. 498 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 499 Shell (SSH)", RFC 6242, June 2011. 501 Authors' Addresses 503 Fred Baker 504 Cisco Systems 505 Santa Barbara, California 93117 506 USA 508 Email: fred@cisco.com 510 Ralph Droms 511 Cisco Systems 512 1414 Massachusetts Avenue 513 Boxborough, Massachusetts 01719 514 USA 516 Email: rdroms@cisco.com