idnits 2.17.00 (12 Aug 2021) /tmp/idnits49752/draft-arkko-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 : ---------------------------------------------------------------------------- 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 24, 2011) is 3862 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: April 26, 2012 October 24, 2011 7 Prefix Assignment in a Home Network 8 draft-arkko-homenet-prefix-assignment-00 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 April 26, 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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 11 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 This memo describes a prefix assignment mechanism for home networks. 76 It is expected that home gateway routers are assigned an IPv6 prefix 77 through DHCPv6 Prefix Delegation (PD) [RFC3633], or in some cases 78 manually configured. This prefix needs to be divided among the 79 multiple subnets in a home network. This memo describes a mechanism 80 for such division via OSPFv3 [RFC5340]. 82 The OSPv3-based mechanism is an alternative design to using DHCPv6 PD 83 also for the prefix assignment in the internal network. This memo 84 has been written so that the working group can make a decision on 85 which type of design to pursue. The main benefit of using a routing 86 protocol to handle the prefix assignment is that it can provide a 87 more efficient allocation mechanism than hierarchical assignment 88 through DHCPv PD. This may be important for home networks that get 89 only a /60 allocation from their ISPs. 91 The rest of this memo is organized as follows. Section 2 defines the 92 usual keywords, Section 3 explains the main requirements for prefix 93 assignments, Section 4 describes how a home gateway router makes 94 assignments when it itself has multiple subnets, and Section 5 95 describes how the assignment can be performed in a distributed manner 96 via OSPFv3 in the entire home network. Finally, Section 6 explains 97 what administrative interfaces are useful for advanced users that 98 wish to manually interact with the mechanisms, Section 7 discusses 99 the security aspects of the design, and Section 8 explains the 100 necessary IANA actions. 102 2. Requirements language 104 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 105 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 106 described in [RFC2119]. 108 3. Role of Prefix Assignment 110 Given a prefix shorter than /64 for the entire home network, this 111 prefix needs to be subdivided so that every subnet is given its own 112 /64 prefix. In many cases there will be just one subnet, the 113 internal network interface attached to the router. But it is also 114 common to have two or more internal network interfaces with 115 intentionally separate networks. For instance, "private" and "guest" 116 SSIDs are automatically configured in many current home network 117 routers. When all the network interfaces that require a prefix are 118 attached to the same router, the prefix assignment problem is simple, 119 and procedures outlined in Section 4 can be employed. 121 In a more complex setting there are multiple routers in the internal 122 network. There are various possible reasons why this might be 123 necessary [I-D.chown-homenet-arch]. For instance, networks that 124 cannot be bridged together should be routed, speed differences 125 between wired and wireless interfaces make the use of the same 126 broadcast domain undesirable, or simply that router devices keep 127 being added. In any case, it then becomes necessary to assign 128 prefixes across the entire network, and this assignment can no longer 129 be done on a local basis as proposed in Section 4. A distributed 130 mechanism and a protocol is required. 132 The key requirements for this distributed mechanism are as follows. 134 o The short prefix assigned to the home gateway router must be used 135 to assign /64 prefixes on each subnet that requires one. 137 o The assignment mechanism should provide reasonable efficiency. As 138 a practical benchmark, some ISPs may employ /60 assignments to 139 individual subscribers. As a result, the assignment mechanism 140 should avoid wasting too many prefixes so that this set of 16 /64 141 prefixes does not run out in the foreseeable future for commonly 142 occuring network configurations. 144 o In particular, the assignment of multiple prefixes to the same 145 network from the same top-level prefix must be avoided. 147 Example: When a home network consists of a home gateway router 148 connected to another router which in turn is connected to 149 hosts, a minimum of two /64 prefixes are required in the 150 internal network: one between the two routers, and another one 151 for the host-side interface on the second router. But an 152 ineffective assignment mechanism in the two routers might have 153 both of them asking for an assignment for this shared 154 interface. 156 o The assignments must be stable across reboots, power cycling, 157 router software updates, and preferably, should be stable across 158 simple network changes such as adding a new device on the stub 159 network segments. However, stability across more complex types of 160 network reconfiguration events is not a requirement. 162 In an even more complex setting there may be multiple home gateway 163 routers and multiple connections to ISP(s). These cases are 164 analogous to the case of a single gateway router. Each gateway will 165 simply distribute the prefix it has, and participating routers 166 throughout the network may assign themselves prefixes from several 167 gateways. 169 Similarly, it is also possible that it is necessary to assign both a 170 global prefix delegated from the ISP and a local, Unique Local 171 Address (ULA) prefix [RFC4193]. The mechanisms in this memo are 172 applicable to both types of prefixes. For ULA-based prefixes, it is 173 necessary to elect one or more router as the generator of such 174 prefixes, and have it perform the generation and employ the prefixes 175 for local interfaces and the entire router network. The generation 176 of ULAs in this manner -- and indeed even the question of whether 177 ULAs are needed -- is outside the scope of this memo, however. We 178 only note that if ULA prefixes are generated, then the mechanisms in 179 this memo can be used to subdivide that prefix for the rest of the 180 network. 182 4. Router Behavior 184 This section describes how a router assigns prefixes to its directly 185 connected interfaces. We assume that the router has prefix(es) that 186 it can use for this allocation. These prefix(es) can be manually 187 configured, acquired through DHCPv6 PD from the ISP, or learned 188 through the distributed prefix assignment protocols described in 189 Section 5. Each such prefix is called a usable prefix. Parts of the 190 usable prefix may already be assigned for some purpose; a coordinated 191 allocation from the prefix is necessary before it can actually be 192 assigned to an interface. 194 Even if the assignment process is local, it still needs to follow the 195 requirements from Section 3. This is achieved through the following 196 rules: 198 o The router MUST maintain a list of assigned prefixes on a per- 199 interface basis. The contents of this list consists of prefixes 200 that the router itself has assigned to the interface, as well as 201 prefixes assigned to the interface by other routers. The latter 202 are learned through the mechanisms described in Section 5, when 203 they are used. 205 o Whenever the router finds a combination of an interface and usable 206 prefix that is not used on the interface, it SHOULD make a new 207 assignment. That is, the router checks to see if there exists an 208 interface and usable prefix such that there are no assigned 209 prefixes within that interface that are more specific than the 210 usable prefix. In this situation the router makes an allocation 211 from the usable prefix (if possible) and adds the allocation to 212 the list of assigned prefixes on that interface. 214 o An allocation from a usable prefix MUST check for other 215 allocations from the same usable prefix. Allocations are made for 216 individual /64 prefixes. The choice of a /64 among multiple free 217 ones MUST be made randomly or based on an algorithm that takes 218 unique hardware characteristics of the router and the interface 219 into account. This helps avoid collisions when simultaneous 220 allocations are made within a network. 222 o In order to provide a stable assignment, the router MUST store 223 assignments affecting directly connected interfaces in non- 224 volatile memory and attempt to re-use them in the future when 225 possible. At least the 5 most recent assignments SHOULD be 226 stored. Note that this applies to both its own assignments as 227 well as assignments made by others. This ensures that the same 228 prefix assignments are made regardless of the order that different 229 devices are brought up. To avoid attacks on flash memory write 230 cycles, assignments made by others SHOULD be recorded only after 231 10 minutes have passed and the assignment is still valid. 233 o Re-using a memorized assignment is possible when there exists a 234 usable prefix that is less specific than the prefix in the 235 assignment (or it is the prefix itself in the assignment), and the 236 prefix in the assignment can be allocated for that purpose. 238 Once the router has assigned a prefix to an interface, it MUST act as 239 a router as defined in [RFC4861] and advertise the prefix in Router 240 Advertisements. The lifetime of the prefix SHOULD be advertised as a 241 reasonably long period, at least 48 hours or the lifetime of the 242 assigned prefixes, whichever is smaller. To support a variety of 243 IPv6-only hosts in these networks, the router needs to ensure that 244 sufficient DNS discovery mechanisms are enabled. It is RECOMMENDED 245 that both stateless DHCPv6 [RFC3736] and Router Advertisement options 246 [RFC6106] are supported and turned on by default. This requires, 247 however, that a working DNS server is known and addressable via IPv6. 248 The mechanism in [RFC3736] and [RFC3646] can be used for this. 250 5. Prefix Assignment in OSPFv3 252 This section describes how prefix assignment in a home network can be 253 performed in a distributed manner via OSPFv3. It is expected that 254 the router already support the auto-configuration extensions defined 255 in [I-D.acee-ospf-ospfv3-autoconfig]. 257 An overview to OSPFv3-based prefix assignment is as follows. OSPFv3 258 routers that are capable of auto-configuration advertise OSPFv3 Auto- 259 Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with 260 suitable TLVs. For prefix assignment, two TLVs are used. The Usable 261 Prefix TLV (Section 5.1) advertises a usable prefix, usually the 262 prefix that has been delegated to the home gateway router from the 263 ISP through DHCPv6 PD. These usable prefixes are necessary for 264 running the algorithm in Section 4 for determining whether prefix 265 assignments can and should be made. 267 The Assigned Prefix TLV (Section 5.2) is used to communicate 268 assignments that routers make out of the usable prefixes. 270 An assignment can be made when the algorithm in Section 4 indicates 271 that it can be made and no other router has claimed the same 272 assignment. The router emits an OSPFv3 advertisement with Assigned 273 Prefix TLV included to let other devices know that the prefix is now 274 in use. Unfortunately, collisions are still possible, when the 275 algorithms on different routers happen to choose the same free /64 276 prefix or when more /64 prefixes are needed than there are available. 277 This situation is detected through an advertisement where a different 278 router claims the allocation of the same prefix. In this situation 279 the router with numerically lower OSPFv3 Router ID has to select 280 another prefix. See also [I-D.acee-ospf-ospfv3-autoconfig] Section 281 5.2. 283 5.1. Usable Prefix TLV 285 The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration 286 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 287 BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with an 288 LSID of 0. It MAY occur once or multiple times and the information 289 from all TLV instances is retained. The length of the TLV is 290 variable. 292 The contents of the TLV include a usable prefix (Prefix) and prefix 293 length (PrefixLength). PrefixLength is the length in bits of the 294 prefix and is an 8-bit field. The PrefixLength MUST be greater than 295 or equal to 8 and less than or equal to 64. The prefix describes an 296 allocation of a global or ULA prefix for the entire auto-configured 297 home network. The Prefix is an encoding of the prefix itself as an 298 even multiple of 32-bit words, padding with zero bits as necessary. 299 This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 300 consistent with [RFC5340]. It MUST NOT be directly assigned to any 301 interface before following through the procedures defined above. 303 This TLV SHOULD be emitted by every home gateway router that has 304 either a manual or DHCPv6 PD based prefix that is shorter than /64. 306 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 307 and only in combination with the Router-Hardware-Fingerprint TLV 308 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | TBD-BY-IANA-1 | 20 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | PrefixLength | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 | Prefix | 319 | (4-16 bytes) | 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Usable Prefix TLV Format 324 5.2. Assigned Prefix TLV 326 The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration 327 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 328 BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an 329 LSID of 0. It MAY occur once or multiple times and the information 330 from all TLV instances is retained. The length of the TLV is 331 variable. 333 The contents of the TLV include an Interface ID, assigned prefix 334 (Prefix), and prefix length (PrefixLength). The Interface ID is the 335 same OSPFv3 Interface ID that is described in section 4.2.1 or 336 [RFC5340]. PrefixLength is the length in bits of the prefix and is 337 an 8-bit field. The PrefixLength value MUST be 64 in this version of 338 the specification. The prefix describes an assignment of a global or 339 ULA prefix for a directly connected interface in the advertising 340 router. The Prefix is an encoding of the prefix itself as an even 341 multiple of 32-bit words, padding with zero bits as necessary. This 342 encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 343 consistent with xref target="RFC5340"/>. 345 This TLV MUST be emitted by every home router that has made 346 assignment from a usable prefix per Section 4. 348 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 349 and only in combination with the Router-Hardware-Fingerprint TLV 350 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | TBD-BY-IANA-2 | 20 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Interface ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | PrefixLength | Reserved | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 | Prefix | 363 | (4-16 bytes) | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Assigned Prefix TLV Format 369 5.3. OSPFv3 Prefix Assignment 371 OSPFv3 Routers supporting the mechanisms in the memo will learn or 372 assign a global /64 IPv6 prefix for each IPv6 interface. Since the 373 mechanisms described herein are based on OSPFv3, Router ID assignment 374 as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed 375 successfully. 377 When an OSPFv3 Router receives a global prefix through DHCPv6 prefix 378 delegation, manual configuration, or other means, it will advertise 379 this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. 380 This will trigger prefix assignment for auto-configured OSPFv3 381 routers within the routing domain including the originating OSPFv3 382 router. 384 When an OSPFv3 Router receives an AC LSA containing a Usable Prefix 385 TLV, it will determine whether or not a new prefix needs to be 386 assigned for each of its attached IPv6 interfaces. For the purposes 387 of this discussion, the received prefix will be referred to as the 388 Current Usable Prefix. The following steps will be peformed for each 389 IPv6 interface: 391 1. The OSPFv3 Router will determine whether there are any other 392 OSPFv3 Routers connected to the same link by examining its list 393 of neighbors. 395 2. If no OSPFv3 neighbors have been discovered, the router will wait 396 TBD seconds before allocating a unique /64 IPv6 prefix for the 397 link as described in step 5. 399 3. If OSPFv3 neighbors are present on the link, the router needs to 400 determine whether any of them have already assigned an IPv6 401 prefix. This is done by examing the AC LSAs for neighbors on the 402 link and looking for any that include an Assigned Prefix TLV with 403 the same OSPFv3 Interface ID as the neighbor. If one is found 404 and is it a subnet of the IPv6 prefix advertised in the Usable 405 Prefix TLV, this global IPv6 prefix has been already been 406 assigned to the link. If more than one neighbor's Assigned 407 Prefix TLV is found with an IPv6 prefix matching the criteria 408 above, the Assigned Prefix advertised by the OSPFv3 router with 409 the numerically highest OSPFv3 Router ID takes precedence. 411 4. If there are OSPFv3 neighbors on the link but no IPv6 Prefix is 412 found, the task of prefix allocation is delegated to the OSPFv3 413 Router with the numerically highest OSPFv3 Router ID. Note that 414 this is different from OSPFv3 Desiginated Router (DR) election, 415 as described in [RFC5340], in that the router priority is not 416 taken into consideration and that the election will work for 417 networks types where no DR is elected, e.g., point-to-point 418 links. 420 5. If it is determined that the OSPFv3 Router is responsible for 421 prefix assignment on the link, it will: 423 * Examine all the AC LSA including Assigned Prefix TLVs that are 424 subnets of the Current Usable Prefix to determine which /64s 425 prefixes are already assigned. 427 * Examine former prefix assignments stored in non-volatile 428 storage for interface. Starting with the most recent 429 assignment, if the prefix is both a subnet of the Current 430 Usable Prefix and is currently unassigned, reuse the 431 assignment for the inteface. 433 * If no unused former prefix allocation is found, allocate a new 434 one from the subnets of the Current Usable Prefix which are 435 unallocated. 437 * Once a global IPv6 prefix is assigned, a new instance of the 438 AC LSA will be re-originated including the Assigned Prefix 439 TLV. 441 * In the rare event that no global /64 IPv6 prefixes are 442 available within the Current Usable Prefix, no IPv6 prefix is 443 assigned and an error condition must be raised. 445 There are two types of conflicts that may be detected: 447 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for 448 different networks. 450 2. Two of more OSPFv3 routers have assigned different IPv6 prefixes 451 for the same network. 453 In the case of the former, the OSPFv3 Router with the numerically 454 lower OSPFv3 Router ID must select a new prefix and advertise a new 455 instance of its AC LSA with an updated Assign Prefix TLV for the 456 link. In the latter case, the OSPFv3 Router with the numerically 457 lower OSPFv3 Router ID should accept the global IPv6 prefix from the 458 neighbor with the highest OSPFv3 Router ID and originate a new AC LSA 459 excluding the Assigned Prefix TLV for the link. 461 6. Manageability Considerations 463 Advanced users may wish to manage their networks without automation, 464 and there may also be situations where manual intervention may be 465 needed. For these purposes there MUST be a configuration mechanism 466 that allows users to turn off the automatic prefix assignment on a 467 given interface. This setting can be a part of disabling the entire 468 routing auto-configuration [I-D.acee-ospf-ospfv3-autoconfig]. 470 In addition, there SHOULD be a configuration mechanism that allows 471 users to specify the prefix that they would like the router to 472 request for a given interface. This can be useful, for instance, 473 when a router is replaced and there is a desire for the new router to 474 be configured to ask for the same prefix as the old one, in order to 475 avoid renumbering other devices on this network. 477 Finally, there SHOULD be mechanisms to display what prefixes the 478 router has been assigned, and where they came from (manual 479 configuration, DHCPv6 PD, OSPFv3). 481 7. Security Considerations 483 Security can be always added later. 485 8. IANA Considerations 487 This memo makes two allocations out of the OSPFv3 Auto- Configuration 488 (AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]: 490 o The Usable Prefix TLV in Section 5.1 takes the value TBD-BY-IANA-1 491 (suggested value is 2). 493 o The Assigned Prefix TLV in Section 5.2 takes the value TBD-BY- 494 IANA-2 (suggested value is 3). 496 9. References 498 9.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 504 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 505 December 2003. 507 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 508 (DHCP) Service for IPv6", RFC 3736, April 2004. 510 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 511 Addresses", RFC 4193, October 2005. 513 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 514 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 515 September 2007. 517 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 518 for IPv6", RFC 5340, July 2008. 520 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 521 "IPv6 Router Advertisement Options for DNS Configuration", 522 RFC 6106, November 2010. 524 [I-D.acee-ospf-ospfv3-autoconfig] 525 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 526 draft-acee-ospf-ospv3-autoconfig-00 (work in progress), 527 October 2011. 529 9.2. Informative References 531 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 532 Host Configuration Protocol (DHCP) version 6", RFC 3633, 533 December 2003. 535 [I-D.chown-homenet-arch] 536 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 537 Networking Architecture for IPv6", 538 draft-chown-homenet-arch-00 (work in progress), 539 September 2011. 541 Appendix A. Acknowledgments 543 The authors would like to thank to Tim Chown, Fred Baker, Mark 544 Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel 545 Halpern, Samita Chakrabarti, Michael Richardson, and Ralph Droms for 546 interesting discussions in this problem space. 548 Authors' Addresses 550 Jari Arkko 551 Ericsson 552 Jorvas 02420 553 Finland 555 Email: jari.arkko@piuha.net 557 Acee Lindem 558 Ericsson 559 Cary, NC 27519 560 USA 562 Email: acee.lindem@ericsson.com