idnits 2.17.1 draft-arkko-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2011) is 4558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- No information found for draft-acee-ospf-ospv3-autoconfig - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-01) exists of draft-chown-homenet-arch-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Lindem 4 Intended status: Informational Ericsson 5 Expires: May 3, 2012 October 31, 2011 7 Prefix Assignment in a Home Network 8 draft-arkko-homenet-prefix-assignment-01 10 Abstract 12 This memo describes a prefix assignment mechanism for home networks. 13 It is expected that home gateway routers are assigned an IPv6 prefix 14 through DHCPv6 Prefix Delegation (PD). This prefix needs to be 15 divided among the multiple subnets in a home network. This memo 16 describes a mechanism for such division via OSPFv3. This is an 17 alternative design to using DHCPv6 PD also for the prefix assignment. 18 The memo is input to the working group so that it can make a decision 19 on which type of design to pursue. It is expected that a routing- 20 protocol based assignment uses a minimal amount of prefixes. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 58 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 3 59 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 7 61 5.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 7 62 5.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 8 63 5.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 9 64 6. Manageability Considerations . . . . . . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 This memo describes a prefix assignment mechanism for home networks. 77 It is expected that home gateway routers are assigned an IPv6 prefix 78 through DHCPv6 Prefix Delegation (PD) [RFC3633], or in some cases 79 manually configured. This prefix needs to be divided among the 80 multiple subnets in a home network. This memo describes a mechanism 81 for such division via OSPFv3 [RFC5340]. 83 The OSPv3-based mechanism is an alternative design to using DHCPv6 PD 84 also for the prefix assignment in the internal network. This memo 85 has been written so that the working group can make a decision on 86 which type of design to pursue. The main benefit of using a routing 87 protocol to handle the prefix assignment is that it can provide a 88 more efficient allocation mechanism than hierarchical assignment 89 through DHCPv PD. This may be important for home networks that get 90 only a /60 allocation from their ISPs. 92 The rest of this memo is organized as follows. Section 2 defines the 93 usual keywords, Section 3 explains the main requirements for prefix 94 assignments, Section 4 describes how a home gateway router makes 95 assignments when it itself has multiple subnets, and Section 5 96 describes how the assignment can be performed in a distributed manner 97 via OSPFv3 in the entire home network. Finally, Section 6 explains 98 what administrative interfaces are useful for advanced users that 99 wish to manually interact with the mechanisms, Section 7 discusses 100 the security aspects of the design, and Section 8 explains the 101 necessary IANA actions. 103 2. Requirements language 105 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 106 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 107 described in [RFC2119]. 109 3. Role of Prefix Assignment 111 Given a prefix shorter than /64 for the entire home network, this 112 prefix needs to be subdivided so that every subnet is given its own 113 /64 prefix. In many cases there will be just one subnet, the 114 internal network interface attached to the router. But it is also 115 common to have two or more internal network interfaces with 116 intentionally separate networks. For instance, "private" and "guest" 117 SSIDs are automatically configured in many current home network 118 routers. When all the network interfaces that require a prefix are 119 attached to the same router, the prefix assignment problem is simple, 120 and procedures outlined in Section 4 can be employed. 122 In a more complex setting there are multiple routers in the internal 123 network. There are various possible reasons why this might be 124 necessary [I-D.chown-homenet-arch]. For instance, networks that 125 cannot be bridged together should be routed, speed differences 126 between wired and wireless interfaces make the use of the same 127 broadcast domain undesirable, or simply that router devices keep 128 being added. In any case, it then becomes necessary to assign 129 prefixes across the entire network, and this assignment can no longer 130 be done on a local basis as proposed in Section 4. A distributed 131 mechanism and a protocol is required. 133 The key requirements for this distributed mechanism are as follows. 135 o The short prefix assigned to the home gateway router must be used 136 to assign /64 prefixes on each subnet that requires one. 138 o The assignment mechanism should provide reasonable efficiency. As 139 a practical benchmark, some ISPs may employ /60 assignments to 140 individual subscribers. As a result, the assignment mechanism 141 should avoid wasting too many prefixes so that this set of 16 /64 142 prefixes does not run out in the foreseeable future for commonly 143 occuring network configurations. 145 o In particular, the assignment of multiple prefixes to the same 146 network from the same top-level prefix must be avoided. 148 Example: When a home network consists of a home gateway router 149 connected to another router which in turn is connected to 150 hosts, a minimum of two /64 prefixes are required in the 151 internal network: one between the two routers, and another one 152 for the host-side interface on the second router. But an 153 ineffective assignment mechanism in the two routers might have 154 both of them asking for an assignment for this shared 155 interface. 157 o The assignments must be stable across reboots, power cycling, 158 router software updates, and preferably, should be stable across 159 simple network changes. Simple network changes are in this case 160 defined as those that could be resolved through either deletion or 161 addition of a prefix assignment. For instance, the addition of a 162 new router without changing connections between existing routers 163 requires just the assigment of new prefixes for the new networks 164 that the router introduces. There are no stability requirements 165 across more complex types of network reconfiguration events. For 166 instance, if a network is separated into two networks connected by 167 a newly inserted router, this may lead into renumbering all 168 networks within the home. 170 In an even more complex setting there may be multiple home gateway 171 routers and multiple connections to ISP(s). These cases are 172 analogous to the case of a single gateway router. Each gateway will 173 simply distribute the prefix it has, and participating routers 174 throughout the network may assign themselves prefixes from several 175 gateways. 177 Similarly, it is also possible that it is necessary to assign both a 178 global prefix delegated from the ISP and a local, Unique Local 179 Address (ULA) prefix [RFC4193]. The mechanisms in this memo are 180 applicable to both types of prefixes. For ULA-based prefixes, it is 181 necessary to elect one or more router as the generator of such 182 prefixes, and have it perform the generation and employ the prefixes 183 for local interfaces and the entire router network. The generation 184 of ULAs in this manner -- and indeed even the question of whether 185 ULAs are needed -- is outside the scope of this memo, however. We 186 only note that if ULA prefixes are generated, then the mechanisms in 187 this memo can be used to subdivide that prefix for the rest of the 188 network. 190 Finally, the mechanisms in this memory can also be used in standalone 191 or ad hoc networks where no global prefixes or Internet connectivity 192 are available, by distributing ULA prefixes within the network. 194 4. Router Behavior 196 This section describes how a router assigns prefixes to its directly 197 connected interfaces. We assume that the router has prefix(es) that 198 it can use for this allocation. These prefix(es) can be manually 199 configured, acquired through DHCPv6 PD from the ISP, or learned 200 through the distributed prefix assignment protocols described in 201 Section 5. Each such prefix is called a usable prefix. Parts of the 202 usable prefix may already be assigned for some purpose; a coordinated 203 allocation from the prefix is necessary before it can actually be 204 assigned to an interface. 206 Even if the assignment process is local, it still needs to follow the 207 requirements from Section 3. This is achieved through the following 208 rules: 210 o The router MUST maintain a list of assigned prefixes on a per- 211 interface basis. The contents of this list consists of prefixes 212 that the router itself has assigned to the interface, as well as 213 prefixes assigned to the interface by other routers. The latter 214 are learned through the mechanisms described in Section 5, when 215 they are used. 217 o Whenever the router finds a combination of an interface and usable 218 prefix that is not used on the interface, it SHOULD make a new 219 assignment. That is, the router checks to see if there exists an 220 interface and usable prefix such that there are no assigned 221 prefixes within that interface that are more specific than the 222 usable prefix. In this situation the router makes an allocation 223 from the usable prefix (if possible) and adds the allocation to 224 the list of assigned prefixes on that interface. 226 o An allocation from a usable prefix MUST check for other 227 allocations from the same usable prefix. Allocations are made for 228 individual /64 prefixes. The choice of a /64 among multiple free 229 ones MUST be made randomly or based on an algorithm that takes 230 unique hardware characteristics of the router and the interface 231 into account. This helps avoid collisions when simultaneous 232 allocations are made within a network. 234 o In order to provide a stable assignment, the router MUST store 235 assignments affecting directly connected interfaces in non- 236 volatile memory and attempt to re-use them in the future when 237 possible. At least the 5 most recent assignments SHOULD be 238 stored. Note that this applies to both its own assignments as 239 well as assignments made by others. This ensures that the same 240 prefix assignments are made regardless of the order that different 241 devices are brought up. To avoid attacks on flash memory write 242 cycles, assignments made by others SHOULD be recorded only after 243 10 minutes have passed and the assignment is still valid. 245 o Re-using a memorized assignment is possible when there exists a 246 usable prefix that is less specific than the prefix in the 247 assignment (or it is the prefix itself in the assignment), and the 248 prefix in the assignment can be allocated for that purpose. 250 Once the router has assigned a prefix to an interface, it MUST act as 251 a router as defined in [RFC4861] and advertise the prefix in Router 252 Advertisements. The lifetime of the prefix SHOULD be advertised as a 253 reasonably long period, at least 48 hours or the lifetime of the 254 assigned prefixes, whichever is smaller. To support a variety of 255 IPv6-only hosts in these networks, the router needs to ensure that 256 sufficient DNS discovery mechanisms are enabled. It is RECOMMENDED 257 that both stateless DHCPv6 [RFC3736] and Router Advertisement options 258 [RFC6106] are supported and turned on by default. This requires, 259 however, that a working DNS server is known and addressable via IPv6. 260 The mechanism in [RFC3736] and [RFC3646] can be used for this. 262 5. Prefix Assignment in OSPFv3 264 This section describes how prefix assignment in a home network can be 265 performed in a distributed manner via OSPFv3. It is expected that 266 the router already support the auto-configuration extensions defined 267 in [I-D.acee-ospf-ospfv3-autoconfig]. 269 An overview to OSPFv3-based prefix assignment is as follows. OSPFv3 270 routers that are capable of auto-configuration advertise OSPFv3 Auto- 271 Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with 272 suitable TLVs. For prefix assignment, two TLVs are used. The Usable 273 Prefix TLV (Section 5.1) advertises a usable prefix, usually the 274 prefix that has been delegated to the home gateway router from the 275 ISP through DHCPv6 PD. These usable prefixes are necessary for 276 running the algorithm in Section 4 for determining whether prefix 277 assignments can and should be made. 279 The Assigned Prefix TLV (Section 5.2) is used to communicate 280 assignments that routers make out of the usable prefixes. 282 An assignment can be made when the algorithm in Section 4 indicates 283 that it can be made and no other router has claimed the same 284 assignment. The router emits an OSPFv3 advertisement with Assigned 285 Prefix TLV included to let other devices know that the prefix is now 286 in use. Unfortunately, collisions are still possible, when the 287 algorithms on different routers happen to choose the same free /64 288 prefix or when more /64 prefixes are needed than there are available. 289 This situation is detected through an advertisement where a different 290 router claims the allocation of the same prefix. In this situation 291 the router with numerically lower OSPFv3 Router ID has to select 292 another prefix. See also [I-D.acee-ospf-ospfv3-autoconfig] Section 293 5.2. 295 5.1. Usable Prefix TLV 297 The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration 298 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 299 BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with an 300 LSID of 0. It MAY occur once or multiple times and the information 301 from all TLV instances is retained. The length of the TLV is 302 variable. 304 The contents of the TLV include a usable prefix (Prefix) and prefix 305 length (PrefixLength). PrefixLength is the length in bits of the 306 prefix and is an 8-bit field. The PrefixLength MUST be greater than 307 or equal to 8 and less than or equal to 64. The prefix describes an 308 allocation of a global or ULA prefix for the entire auto-configured 309 home network. The Prefix is an encoding of the prefix itself as an 310 even multiple of 32-bit words, padding with zero bits as necessary. 311 This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 312 consistent with [RFC5340]. It MUST NOT be directly assigned to any 313 interface before following through the procedures defined above. 315 This TLV SHOULD be emitted by every home gateway router that has 316 either a manual or DHCPv6 PD based prefix that is shorter than /64. 318 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 319 and only in combination with the Router-Hardware-Fingerprint TLV 320 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | TBD-BY-IANA-1 | 20 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | PrefixLength | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | Prefix | 331 | (4-16 bytes) | 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Usable Prefix TLV Format 336 5.2. Assigned Prefix TLV 338 The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration 339 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 340 BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an 341 LSID of 0. It MAY occur once or multiple times and the information 342 from all TLV instances is retained. The length of the TLV is 343 variable. 345 The contents of the TLV include an Interface ID, assigned prefix 346 (Prefix), and prefix length (PrefixLength). The Interface ID is the 347 same OSPFv3 Interface ID that is described in section 4.2.1 or 348 [RFC5340]. PrefixLength is the length in bits of the prefix and is 349 an 8-bit field. The PrefixLength value MUST be 64 in this version of 350 the specification. The prefix describes an assignment of a global or 351 ULA prefix for a directly connected interface in the advertising 352 router. The Prefix is an encoding of the prefix itself as an even 353 multiple of 32-bit words, padding with zero bits as necessary. This 354 encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 355 consistent with xref target="RFC5340"/>. 357 This TLV MUST be emitted by every home router that has made 358 assignment from a usable prefix per Section 4. 360 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 361 and only in combination with the Router-Hardware-Fingerprint TLV 362 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 364 0 1 2 3 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | TBD-BY-IANA-2 | 20 | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Interface ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | PrefixLength | Reserved | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 | Prefix | 375 | (4-16 bytes) | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Assigned Prefix TLV Format 381 5.3. OSPFv3 Prefix Assignment 383 OSPFv3 Routers supporting the mechanisms in the memo will learn or 384 assign a global /64 IPv6 prefix for each IPv6 interface. Since the 385 mechanisms described herein are based on OSPFv3, Router ID assignment 386 as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed 387 successfully. 389 When an OSPFv3 Router receives a global prefix through DHCPv6 prefix 390 delegation, manual configuration, or other means, it will advertise 391 this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. 392 This will trigger prefix assignment for auto-configured OSPFv3 393 routers within the routing domain including the originating OSPFv3 394 router. 396 When an OSPFv3 Router receives an AC LSA containing a Usable Prefix 397 TLV, it will determine whether or not a new prefix needs to be 398 assigned for each of its attached IPv6 interfaces. For the purposes 399 of this discussion, the received prefix will be referred to as the 400 Current Usable Prefix. The following steps will be peformed for each 401 IPv6 interface: 403 1. The OSPFv3 Router will determine whether there are any other 404 OSPFv3 Routers connected to the same link by examining its list 405 of neighbors. 407 2. If no OSPFv3 neighbors have been discovered, the router will wait 408 TBD seconds before allocating a unique /64 IPv6 prefix for the 409 link as described in step 5. 411 3. If OSPFv3 neighbors are present on the link, the router needs to 412 determine whether any of them have already assigned an IPv6 413 prefix. This is done by examing the AC LSAs for neighbors on the 414 link and looking for any that include an Assigned Prefix TLV with 415 the same OSPFv3 Interface ID as the neighbor. If one is found 416 and is it a subnet of the IPv6 prefix advertised in the Usable 417 Prefix TLV, this global IPv6 prefix has been already been 418 assigned to the link. If more than one neighbor's Assigned 419 Prefix TLV is found with an IPv6 prefix matching the criteria 420 above, the Assigned Prefix advertised by the OSPFv3 router with 421 the numerically highest OSPFv3 Router ID takes precedence. 423 4. If there are OSPFv3 neighbors on the link but no IPv6 Prefix is 424 found, the task of prefix allocation is delegated to the OSPFv3 425 Router with the numerically highest OSPFv3 Router ID. Note that 426 this is different from OSPFv3 Desiginated Router (DR) election, 427 as described in [RFC5340], in that the router priority is not 428 taken into consideration and that the election will work for 429 networks types where no DR is elected, e.g., point-to-point 430 links. 432 5. If it is determined that the OSPFv3 Router is responsible for 433 prefix assignment on the link, it will: 435 * Examine all the AC LSA including Assigned Prefix TLVs that are 436 subnets of the Current Usable Prefix to determine which /64s 437 prefixes are already assigned. 439 * Examine former prefix assignments stored in non-volatile 440 storage for interface. Starting with the most recent 441 assignment, if the prefix is both a subnet of the Current 442 Usable Prefix and is currently unassigned, reuse the 443 assignment for the inteface. 445 * If no unused former prefix allocation is found, allocate a new 446 one from the subnets of the Current Usable Prefix which are 447 unallocated. 449 * Once a global IPv6 prefix is assigned, a new instance of the 450 AC LSA will be re-originated including the Assigned Prefix 451 TLV. 453 * In the rare event that no global /64 IPv6 prefixes are 454 available within the Current Usable Prefix, no IPv6 prefix is 455 assigned and an error condition must be raised. 457 There are two types of conflicts that may be detected: 459 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for 460 different networks. 462 2. Two of more OSPFv3 routers have assigned different IPv6 prefixes 463 for the same network. 465 In the case of the former, the OSPFv3 Router with the numerically 466 lower OSPFv3 Router ID must select a new prefix and advertise a new 467 instance of its AC LSA with an updated Assign Prefix TLV for the 468 link. In the latter case, the OSPFv3 Router with the numerically 469 lower OSPFv3 Router ID should accept the global IPv6 prefix from the 470 neighbor with the highest OSPFv3 Router ID and originate a new AC LSA 471 excluding the Assigned Prefix TLV for the link. 473 6. Manageability Considerations 475 Advanced users may wish to manage their networks without automation, 476 and there may also be situations where manual intervention may be 477 needed. For these purposes there MUST be a configuration mechanism 478 that allows users to turn off the automatic prefix assignment on a 479 given interface. This setting can be a part of disabling the entire 480 routing auto-configuration [I-D.acee-ospf-ospfv3-autoconfig]. 482 In addition, there SHOULD be a configuration mechanism that allows 483 users to specify the prefix that they would like the router to 484 request for a given interface. This can be useful, for instance, 485 when a router is replaced and there is a desire for the new router to 486 be configured to ask for the same prefix as the old one, in order to 487 avoid renumbering other devices on this network. 489 Finally, there SHOULD be mechanisms to display what prefixes the 490 router has been assigned, and where they came from (manual 491 configuration, DHCPv6 PD, OSPFv3). 493 7. Security Considerations 495 Security can be always added later. 497 8. IANA Considerations 499 This memo makes two allocations out of the OSPFv3 Auto- Configuration 500 (AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]: 502 o The Usable Prefix TLV in Section 5.1 takes the value TBD-BY-IANA-1 503 (suggested value is 2). 505 o The Assigned Prefix TLV in Section 5.2 takes the value TBD-BY- 506 IANA-2 (suggested value is 3). 508 9. Analysis 510 An analysis of a mechanism remiscent of the one described in this 511 specification has been published in the SIGCOMM IPv6 Workshop 512 [SIGCOMM.IPV6]. Further analysis is encouraged. 514 10. References 516 10.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 522 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 523 December 2003. 525 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 526 (DHCP) Service for IPv6", RFC 3736, April 2004. 528 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 529 Addresses", RFC 4193, October 2005. 531 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 532 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 533 September 2007. 535 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 536 for IPv6", RFC 5340, July 2008. 538 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 539 "IPv6 Router Advertisement Options for DNS Configuration", 540 RFC 6106, November 2010. 542 [I-D.acee-ospf-ospfv3-autoconfig] 543 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 544 draft-acee-ospf-ospv3-autoconfig-00 (work in progress), 545 October 2011. 547 10.2. Informative References 549 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 550 Host Configuration Protocol (DHCP) version 6", RFC 3633, 551 December 2003. 553 [I-D.chown-homenet-arch] 554 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 555 Networking Architecture for IPv6", 556 draft-chown-homenet-arch-00 (work in progress), 557 September 2011. 559 [I-D.chelius-router-autoconf] 560 Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for 561 IPv6 router autoconfiguration", 562 draft-chelius-router-autoconf-00 (work in progress), 563 June 2002. 565 [I-D.dimitri-zospf] 566 Dimitrelis, A. and A. Williams, "Autoconfiguration of 567 routers using a link state routing protocol", 568 draft-dimitri-zospf-00 (work in progress), October 2002. 570 [SIGCOMM.IPV6] 571 Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D. 572 Binet, "An evaluation of the NAP protocol for IPv6 router 573 auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto, 574 Japan, 2007. 576 Appendix A. Acknowledgments 578 The authors would like to thank to Tim Chown, Fred Baker, Mark 579 Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel 580 Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik 581 Nordmark, Laurent Toutain, and Ralph Droms for interesting 582 discussions in this problem space. The authors would also like to 583 point out some past work in this space, such as those in 584 [I-D.chelius-router-autoconf] or [I-D.dimitri-zospf]. 586 Authors' Addresses 588 Jari Arkko 589 Ericsson 590 Jorvas 02420 591 Finland 593 Email: jari.arkko@piuha.net 595 Acee Lindem 596 Ericsson 597 Cary, NC 27519 598 USA 600 Email: acee.lindem@ericsson.com