idnits 2.17.1 draft-arkko-homenet-prefix-assignment-02.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 (July 9, 2012) is 4299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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? -- Possible downref: Normative reference to a draft: ref. 'I-D.acee-ospf-ospfv3-autoconfig' -- 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 (==), 4 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: Standards Track Ericsson 5 Expires: January 10, 2013 B. Paterson 6 Cisco Systems 7 July 9, 2012 9 Prefix Assignment in a Home Network 10 draft-arkko-homenet-prefix-assignment-02 12 Abstract 14 This memo describes a prefix assignment mechanism for home networks. 15 It is expected that home gateway routers are allocated an IPv6 prefix 16 through DHCPv6 Prefix Delegation (PD) or that a prefix is made 17 available through other means. This prefix needs to be divided among 18 the multiple subnets in a home network. This memo describes a 19 mechanism for such division, or assignment, via OSPFv3. This is an 20 alternative design to also using DHCPv6 PD for the assignment. The 21 memo is input to the working group so that it can make a decision on 22 which type of design to pursue. It is expected that a routing- 23 protocol based assignment uses a minimal amount of prefixes. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 10, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 61 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 4 62 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Sending Router Advertisements . . . . . . . . . . . . . . 7 64 4.2. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 9 67 6.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 10 69 6.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 11 70 6.3.1. Making a New Assignment . . . . . . . . . . . . . . . 14 71 6.3.2. Checking for Conflicts Across the Entire Network . . . 15 72 6.3.3. Deprecating an Assigned Prefix . . . . . . . . . . . . 15 73 6.3.4. Verifying and Making a Local Assignment . . . . . . . 16 74 7. ULA Generation . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 9. Manageability Considerations . . . . . . . . . . . . . . . . . 18 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 12. Timer Constants . . . . . . . . . . . . . . . . . . . . . . . 19 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 82 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 This memo describes a prefix assignment mechanism for home networks. 89 It is expected that home gateway routers are allocated an IPv6 prefix 90 through DHCPv6 Prefix Delegation (PD) [RFC3633], or that a prefix is 91 made available by some other means. Manual configuration may be 92 needed in some networks, for instance when the ISP does not support 93 DHCPv6-based prefix delegation. In other cases, such as networks 94 that have do not yet have an Internet connection, Unique Local 95 Address (ULA) [RFC4193] prefixes can be automatically generated. For 96 the purposes of this document, we refer to the prefix reserved for a 97 home network as a prefix allocation. 99 A prefix allocation needs to be divided among the multiple subnets in 100 a home network. For the purposes of this document, we refer to this 101 process as prefix assignment. This memo describes a mechanism for 102 prefix assignment via OSPFv3 [RFC5340]. 104 The OSPv3-based mechanism is an alternative design to also using 105 DHCPv6 PD for the prefix assignment in the internal network. This 106 memo has been written so that the working group can make a decision 107 on which type of design to pursue. The main benefit of using a 108 routing protocol to handle the prefix assignment is that it can 109 provide a more efficient use of address space than hierarchical 110 assignment through DHCPv PD. This may be important for home networks 111 that only get a /60 prefix allocation from their ISPs. 113 The rest of this memo is organized as follows. Section 2 defines the 114 usual keywords, Section 3 explains the main requirements for prefix 115 assignments, Section 4 describes how a home gateway router makes 116 assignments when it itself has multiple subnets, and Section 5 and 117 Section 6 describe how the assignment can be performed in a 118 distributed manner via OSPFv3 in the entire home network. Finally, 119 Section 7 specifies the procedures for automatic generation of ULA 120 prefixes, Section 8 explains the hysteresis principles applied to 121 prefix assignment and de-assignment, Section 9 explains what 122 administrative interfaces are useful for advanced users that wish to 123 manually interact with the mechanisms, Section 10 discusses the 124 security aspects of the design, Section 11 explains the necessary 125 IANA actions, and Section 12 defines the necessary timer constants. 127 An analysis of a mechanism reminiscent of the one described in this 128 specification has been published in the SIGCOMM IPv6 Workshop 129 [SIGCOMM.IPV6]. Further analysis is encouraged. 131 2. Requirements language 133 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 134 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 135 described in [RFC2119]. 137 3. Role of Prefix Assignment 139 Given a prefix shorter than /64 for the entire home network, this 140 prefix needs to be subdivided so that every subnet is given its own 141 /64 prefix. In many cases there will be just one subnet, the 142 internal network interface attached to the router. But it is also 143 common to have two or more internal network interfaces with 144 intentionally separate networks. For instance, "private" and "guest" 145 SSIDs are automatically configured in many current home network 146 routers. When all the network interfaces that require a prefix are 147 attached to the same router, the prefix assignment problem is simple, 148 and procedures outlined in Section 4 can be employed. 150 In a more complex setting there are multiple routers in the internal 151 network. There are various possible reasons why this might be 152 necessary [I-D.chown-homenet-arch]. For instance, networks that 153 cannot be bridged together should be routed, speed differences 154 between wired and wireless interfaces make the use of the same 155 broadcast domain undesirable, or simply that router devices keep 156 being added. In any case, it then becomes necessary to assign 157 prefixes across the entire network, and this assignment can no longer 158 be done on a local basis as proposed in Section 4. A distributed 159 mechanism and a protocol are required. 161 The key requirements for this distributed mechanism are as follows. 163 o A prefix allocated to a home gateway router within the home 164 network is used to assign /64 prefixes on each subnet that 165 requires one. 167 Note that several methods may be used to allocate such a usable 168 prefix. 170 o The assignment mechanism should provide reasonable efficiency. As 171 a practical benchmark, some ISPs may employ /60 allocations to 172 individual subscribers. As a result, the assignment mechanism 173 should avoid wasting too many prefixes so that this set of 16 /64 174 prefixes is not exhausted in the foreseeable future for commonly 175 occurring network configurations. 177 o In particular, the assignment of multiple prefixes to the same 178 network from the same top-level prefix must be avoided. 180 Example: When a home network consists of a home gateway router 181 connected to another router which in turn is connected to 182 hosts, a minimum of two /64 prefixes are required in the 183 internal network: one between the two routers, and another one 184 for the host-side interface on the second router. But an 185 ineffective assignment mechanism in the two routers might have 186 both of them asking for separate assignments for this shared 187 interface. 189 o The assignments must be stable across reboots, power cycling, 190 router software updates, and preferably, should be stable across 191 simple network changes. Simple network changes are in this case 192 defined as those that could be resolved through either deletion or 193 addition of a prefix assignment. For instance, the addition of a 194 new router without changing connections between existing routers 195 requires just the assignment of new prefixes for the new networks 196 that the router introduces. There are no stability requirements 197 across more complex types of network reconfiguration events. For 198 instance, if a network is separated into two networks connected by 199 a newly inserted router, this may lead to renumbering all networks 200 within the home. 202 In an even more complex setting there may be multiple home gateway 203 routers and multiple connections to ISP(s). These cases are 204 analogous to the case of a single gateway router. Each gateway will 205 simply distribute the prefix it has, and participating routers 206 throughout the network may assign themselves prefixes from several 207 gateways. Multiple assignments can be made for the same interface. 208 For example, this can be useful in a multi-homing setting. 210 Similarly, it is also possible that it is necessary to assign either 211 a global prefix delegated from the ISP or a local, Unique Local 212 Address (ULA) prefix [RFC4193]. The mechanisms in this memo are 213 applicable to both types of prefixes. The details of the generation 214 of ULA-based prefixes is covered in Section 7. 216 The mechanisms in this memory can also be used in standalone or ad 217 hoc networks where no global prefixes or Internet connectivity are 218 available, by distributing ULA prefixes within the network. 220 4. Router Behavior 222 This section describes how a router assigns prefixes to its directly 223 connected interfaces. We assume that the router has prefix 224 allocation(s) that it can use for this assignment. Each such prefix 225 allocation is called a usable prefix. Parts of the usable prefix may 226 already be assigned for some purpose; a coordinated assignment from 227 the prefix is necessary before it can actually be assigned to an 228 interface. 230 Even if the assignment process is local, it still needs to follow the 231 requirements from Section 3. This is achieved through the following 232 rules: 234 o The router MUST maintain a list of assigned prefixes on a per- 235 interface basis. The contents of this list consists of prefixes 236 that the router itself has assigned to the interface, as well as 237 prefixes assigned to the interface by other routers. The latter 238 are learned through the mechanisms described in Section 6, when 239 they are used. Each prefix is associated with the Router ID of 240 the router that assigned it. 242 o Whenever the router finds a combination of an interface and usable 243 prefix that is not used on the interface, it SHOULD make a new 244 prefix assignment. That is, the router checks to see if an 245 interface and usable prefix exists such that there are no assigned 246 prefixes within that interface that are more specific than the 247 usable prefix. In this situation the router makes an allocation 248 from the usable prefix (if possible) and adds the assignment to 249 the list of assigned prefixes on that interface. 251 Note: The above implies that when there are multiple usable 252 prefixes, each network will be assigned multiple prefixes. 254 o An assignment from a usable prefix MUST be checked against 255 possible other assignments from the same usable prefix on the same 256 link by neighboring routers, to avoid unnecessary assignments. 257 Assignments MUST also be examined against all existing assignments 258 from the same usable prefix across the network, to avoid 259 collisions. Assignments are made for individual /64 prefixes. 260 The choice of a /64 prefix among multiple free ones MUST be made 261 randomly or based on an algorithm that takes unique hardware 262 characteristics of the router and the interface into account. 263 This helps avoid collisions when simultaneous assignments are made 264 within a network. 266 o In order to provide a stable assignment, the router MUST store 267 assignments affecting directly connected interfaces and 268 automatically generated ULA prefixes in non-volatile memory and 269 attempt to re-use them in the future when possible. At least the 270 5 most recent assignments SHOULD be stored. Note that this 271 applies to both its own assignments as well as assignments made by 272 others. This ensures that the same prefix assignments are made 273 regardless of the order that different devices are brought up. To 274 avoid attacks on flash memory write cycles, assignments made by 275 others SHOULD be recorded only after 10 minutes have passed and 276 the assignment is still valid. 278 o Re-using a memorized assignment is possible when a usable prefix 279 exists that is less specific than the prefix in the assignment (or 280 it is the prefix itself in the assignment), and the prefix is 281 currently unassigned. 283 4.1. Sending Router Advertisements 285 Once the router has assigned a prefix to an interface, it MUST act as 286 a router as defined in [RFC4861] and advertise the prefix in Router 287 Advertisements. The lifetime of the prefix SHOULD be advertised as a 288 reasonably long period, at least 48 hours or the lifetime of the 289 assigned prefixes, whichever is smaller. 291 4.2. DNS Discovery 293 To support a variety of IPv6-only hosts in these networks, the router 294 needs to ensure that sufficient DNS discovery mechanisms are enabled. 295 It is RECOMMENDED that both stateless DHCPv6 [RFC3736] and Router 296 Advertisement options [RFC6106] are supported and turned on by 297 default. 299 The above requires, however, that a working DNS server is known and 300 addressable via IPv6. The mechanism in [RFC3736] and [RFC3646] can 301 be used for this. It is RECOMMENDED that each router attempts to 302 discover an existing DNS server. Typically, such a server will be 303 provided by an ISP. However, in some cases no such server can be 304 found. For instance, an ISP may provide only IPv4 DNS server 305 addresses, or a router deep within the home network is unaware of the 306 IPv6 DNS servers that a home gateway router has discovered. In these 307 situations it is RECOMMENDED that each router turns on a local DNS 308 relay that fetches information from the IPv4 Internet (if a working 309 IPv4 DNS server is available) or a full DNS server that fetches 310 information from the DNS root. 312 5. Design Choices 314 The DNS discovery recommendations in Section 4.2 ensure that an IPv6- 315 only home network can resolve names. However, these recommendations 316 are suboptimal in the sense that different routers in the home may 317 provide different DNS servers, or multiple local DNS servers have to 318 be run where it would have been possible to point to one, or even 319 point to the one provided by the ISP. However, better coordination 320 for the DNS server selection would require some form of additional 321 communication between the routers in the home network. The authors 322 solicit opinions from the Working Group on whether this is something 323 that should be specified. 325 The OSPFv3-based prefix assignment protocol needs to detect two types 326 of conflicts: 328 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for 329 different networks. 331 2. Two or more OSPFv3 routers have assigned different IPv6 prefixes 332 for the same network. 334 Several design decisions were needed to construct the protocol: 336 1. How to determine the winner in case of a conflict? 338 The algorithm in Section 6 ensures that the OSPFv3 Router with 339 the numerically lower OSPFv3 Router ID removes its assignment and 340 schedules an advertisement of LSAs that no longer describe such 341 an assignment. That is, the router with the highest Router ID 342 wins in a conflict situation. 344 2. How to ensure that a network-wide conflict can be detected? 346 We chose to define new LSA extensions -- TLVs within the new 347 Autoconfiguration LSA -- that are flooded throughout the network. 348 Another possible design would have been to re-use existing OSPFv3 349 LSAs, and by assuming that if a router advertises a prefix then 350 it has made an assignment. The advantage of the design that we 351 chose is that we get to specify what information is needed in the 352 new TLVs. This is particularly important, as not all existing 353 OSPFv3 LSAs are extensible. A downside is that assignments will 354 not be visible, unless the router using an assignment implements 355 this specification and advertises the new LSAs. Had we reused 356 existing LSAs, a manual assignment for a legacy router could have 357 been handled, as the legacy router would have advertised the 358 prefix assigned to it. 360 3. How to ensure that both local and network-wide conflicts can be 361 detected? 363 We chose to employ the same new Autoconfiguration LSA TLVs for 364 this purpose, and correlate neighbors through the Router IDs and 365 Interface IDs that they advertise in these TLVs. The OSPFv3 366 Router with a numerically lower OSPFv3 Router ID should accept 367 the global IPv6 prefix from the neighbor with the highest OSPFv3 368 Router ID. 370 6. Prefix Assignment in OSPFv3 372 This section describes how prefix assignment in a home network can be 373 performed in a distributed manner via OSPFv3. It is expected that 374 the router already support the auto-configuration extensions defined 375 in [I-D.acee-ospf-ospfv3-autoconfig]. 377 An overview of OSPFv3-based prefix assignment is as follows. OSPFv3 378 routers that are capable of auto-configuration advertise an OSPFv3 379 Auto-Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with 380 suitable TLVs. For prefix assignment, two TLVs are used. The Usable 381 Prefix TLV (Section 6.1) advertises a usable prefix, usually the 382 prefix that has been delegated to the home gateway router from the 383 ISP through DHCPv6 PD. These usable prefixes are necessary for 384 running the algorithm in Section 4 for determining whether prefix 385 assignments can and should be made. 387 The Assigned Prefix TLV (Section 6.2) is used to communicate 388 assignments that routers make out of the usable prefixes. 390 An assignment can be made when the algorithm in Section 4 indicates 391 that it can be made and no other router has claimed the same 392 assignment. The router makes an OSPFv3 advertisement with the 393 Assigned Prefix TLV included to let other devices know that the 394 prefix is now in use. Unfortunately, collisions are still possible, 395 when the algorithms on different routers happen to choose the same 396 free /64 prefix or when more /64 prefixes are needed than are 397 available. This situation is detected through an advertisement where 398 a different router claims the assignment of the same prefix. In this 399 situation the router with the numerically lower OSPFv3 Router ID has 400 to select another prefix and immediately withdraw any assignments and 401 advertisements that may have been advertised in OSPFv3. See also 402 Section 5.2 in [I-D.acee-ospf-ospfv3-autoconfig]. 404 6.1. Usable Prefix TLV 406 The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration 407 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 408 BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with an 409 LSID of 0. It MAY occur once or multiple times and the information 410 from all TLV instances is retained. The length of the TLV is 411 variable. 413 The contents of the TLV include a usable prefix (Prefix) and prefix 414 length (PrefixLength). PrefixLength is the length in bits of the 415 prefix and is an 8-bit field. The PrefixLength MUST be greater than 416 or equal to 8 and less than or equal to 64. The prefix describes an 417 allocation of a global or ULA prefix for the entire auto-configured 418 home network. The Prefix is an encoding of the prefix itself as an 419 even multiple of 32-bit words, padding with zero bits as necessary. 420 This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 421 consistent with [RFC5340]. It MUST NOT be directly assigned to any 422 interface before following the procedures defined in this memo. 424 This TLV SHOULD be advertised by every home gateway router that has 425 either a manual, DHCPv6 PD-based, or generated ULA prefix that is 426 shorter than /64. 428 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 429 and only in combination with the Router-Hardware-Fingerprint TLV 430 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | TBD-BY-IANA-1 | Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | PrefixLength | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 | Prefix | 441 | (4-16 bytes) | 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Usable Prefix TLV Format 446 6.2. Assigned Prefix TLV 448 The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration 449 (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- 450 BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an 451 LSID of 0. It MAY occur once or multiple times and the information 452 from all TLV instances is retained. The length of the TLV is 453 variable. 455 The contents of the TLV include an Interface ID, assigned prefix 456 (Prefix), and prefix length (PrefixLength). The Interface ID is the 457 same OSPFv3 Interface ID that is described in section 4.2.1 or 458 [RFC5340]. PrefixLength is the length in bits of the prefix and is 459 an 8-bit field. The PrefixLength value MUST be 64 in this version of 460 the specification. The prefix describes an assignment of a global or 461 ULA prefix for a directly connected interface in the advertising 462 router. The Prefix is an encoding of the prefix itself as an even 463 multiple of 32-bit words, padding with zero bits as necessary. This 464 encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 465 consistent with [RFC5340]. 467 This TLV MUST be advertised by the router that has made assignment 468 from a usable prefix per Section 4. 470 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 471 and only in combination with the Router-Hardware-Fingerprint TLV 472 [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | TBD-BY-IANA-2 | Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Interface ID | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | PrefixLength | Reserved | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 | Prefix | 485 | (4-16 bytes) | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Assigned Prefix TLV Format 491 6.3. OSPFv3 Prefix Assignment 493 OSPFv3 Routers supporting the mechanisms in the memo will learn or 494 assign a global /64 IPv6 prefix for each IPv6 interface. Since the 495 mechanisms described herein are based on OSPFv3, Router ID assignment 496 as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed 497 successfully. 499 When an OSPFv3 Router receives a global prefix through DHCPv6 prefix 500 delegation, manual configuration, or other means, it SHOULD advertise 501 this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. 502 This will trigger prefix assignment for auto-configured OSPFv3 503 routers within the routing domain including the originating OSPFv3 504 router. 506 Discussion: Note that while having multiple routers advertise the 507 same usable address space (or address space that covers another 508 router's usable address space) is a configuration error, it should 509 not result in any adverse effects, as long as assignments from 510 such space are still checked for collisions against all other 511 assignments from the same address space. 513 When an OSPFv3 Router detects a change in the set of AC LSAs in its 514 LSA database, it will run the prefix assignment algorithm. The 515 purpose of this algorithm is to determine, for each Usable Prefix in 516 the database, whether or not a new prefix needs to be assigned for 517 each of its attached IPv6 interfaces and whether or not existing 518 assignments need to be deprecated. The algorithm also detects and 519 removes assignments for which there is no longer a corresponding 520 Usable Prefix. Before the algorithm is run, all existing assignments 521 in assigned prefix lists for directly connected interfaces must be 522 marked as "invalid" and will be deleted at the end of the algorithm 523 if they are still in this state. An assigned prefix is considered to 524 be "valid" if all the following conditions are met: 526 o A containing Usable Prefix TLV exists in reachable AC LSA(s). 528 o An Assigned Prefix TLV that matches this assignment exactly (same 529 prefix, same router and interface ID associated with the 530 assignment) exist in reachable AC LSA(s). 532 o Any router advertising an assignment for the same link and Usable 533 Prefix has a lower Router ID than the source of this assignment. 535 o If this router is the source of the assignment, any router in the 536 network that has assigned the same prefix on a different link has 537 a lower Router ID than this router. 539 Note that this definition of a "valid assignment" depends on the 540 router running the algorithm: in particular, a router is not expected 541 to detect prefix collisions or duplicate prefix assignments that do 542 not concern assignments for which it is the responsible router. It 543 is the role of the responsible router to detect these cases and 544 update its AC LSAs accordingly. A router is, however, expected to 545 react to these updates from other routers which translate into 546 additions or removals of Usable Prefix or Assigned Prefix TLVs. 548 The router is expected to have made a snapshot of the LSA database 549 before running this algorithm. The prefix assignment algorithm 550 consists of the following steps run once per combination of Usable 551 Prefix in the LSA database and directly connected OSPFv3 interface. 552 For the purposes of this discussion, the Usable Prefix will be 553 referred to as the Current Usable Prefix, and the interface will be 554 referred to as the Current Interface. The following steps will be 555 performed for each tuple (Usable Prefix, OSPFv3 interface): 557 1. The OSPFv3 Router will search all AC LSAs for a Usable Prefix TLV 558 describing a prefix which contains but is not equal to the 559 Current Usable Prefix. If such a prefix is found, the algorithm 560 is skipped for the Current Usable Prefix as it either has or will 561 be run for the shorter prefix. 563 2. The OSPFv3 router will examine its list of neighbors to find all 564 neighbors in state greater than Init (these neighbors will be 565 referred to as active neighbors). 567 3. The following three steps will serve to determine whether an 568 assignment needs to be made on the link: 570 i. 572 The OSPFv3 router will determine whether or not it has the 573 highest Router ID of all active OSPFv3 routers on the link. 575 ii. 577 If OSPFv3 active neighbors are present on the link, the router 578 will determine whether any of them have already assigned an 579 IPv6 prefix. This is done by examining the AC LSAs of all the 580 active neighbors on the link and looking for any that include 581 an Assigned Prefix TLV with the same OSPFv3 Router ID and 582 Interface ID as the neighbor has. If one is found and it is a 583 subnet of the IPv6 prefix advertised in the Usable Prefix TLV, 584 the router stores this prefix and the Router ID of the router 585 advertising it for reference in the next step. If several 586 such prefixes are found, only the prefix and Router ID with 587 the numerically highest Router ID are stored. 589 iii. 591 The router will compare its Router ID with the highest Router 592 ID among neighbors which have made an assignment on the link. 593 If it is higher (or if no assignments have been made by any 594 neighbors), it will determine whether or not it is already the 595 source of an assignment for the Current Interface from the 596 Current Usable Prefix. 598 4. There are four possibilities at this stage: 600 * The router has already made an assignment on the link and has 601 a higher Router ID than all eventual neighbors which have also 602 made an assignment. In this case, the router's existing 603 assignment takes precedence over all other eventual existing 604 assignments on the link, but the router must determine whether 605 its assignment is still valid throughout the whole network. 606 This is described in Section 6.3.2. 608 * An assignment has been made by a neighbor on the link, and the 609 router either has not made an assignment on the link, or has a 610 lower Router ID than the neighbor. In this case, the 611 neighbor's assignment takes precedence over all eventual 612 existing assignments on the link (including assignments made 613 by the router), and the router must update the assigned prefix 614 list of the Current Interface as well as check assignments on 615 other interfaces for potential collisions. This is described 616 in Section 6.3.4. 618 * No assignment has been made by anyone on the link, and the 619 router has the highest Router ID on the link. In this case, 620 it must make an assignment from the Current Usable Prefix. 621 This is described in Section 6.3.1. 623 * No assignment has been made by anyone on the link, and the 624 router does not have the highest Router ID on the link. In 625 this case, the algorithm exits as the router is not 626 responsible for prefix assignment on the link. 628 Once the algorithm has been run for each Usable Prefix and each 629 interface, the router must delete all assignments that are not marked 630 as valid on all assigned prefix lists and deprecate the corresponding 631 addresses. If this leads to deleting an assignment that this router 632 was responsible for, or if AC LSA origination was scheduled during 633 the algorithm, it must originate a new AC LSA advertising the 634 changes. The router MUST also deprecate deleted prefixes as 635 specified in Section 6.3.3. 637 6.3.1. Making a New Assignment 639 This procedure is executed when no assignment exists on the link and 640 the router is responsible for making an assignment. The router MUST: 642 1. Examine all the AC LSAs not advertised by this router that 643 include Assigned Prefix TLVs that are subnets of the Current 644 Usable Prefix, as well as all assignments made by this router, to 645 determine which prefixes are already assigned. 647 2. Examine former prefix assignments stored in non-volatile storage 648 for the interface. Starting with the most recent assignment, if 649 the prefix is both a subnet of the Current Usable Prefix and is 650 currently unassigned, reuse the assignment for the interface. 652 3. If no unused former prefix assignment is found, and an unassigned 653 /64 subnet of the Current Usable Prefix exists, assign that 654 prefix to the interface. 656 4. If no OSPFv3 neighbors have been discovered and previous prefix 657 assignments exist, the router can make the assignments 658 immediately. Otherwise, the hysteresis periods specified in 659 Section 8 are applied before making an assignment. 661 5. In the event that no assignment could be made to the interface, a 662 warning must be raised. However, the router MUST remain in a 663 state where it continues to assign prefixes through OSPFv3, as 664 prefixes may later become available. 666 6. Once a global IPv6 prefix is assigned, the router will mark it as 667 valid and schedule re-origination of the AC LSA including the 668 Assigned Prefix TLV once all Usable Prefixes and interfaces have 669 been examined. 671 6.3.2. Checking for Conflicts Across the Entire Network 673 This procedure is executed for every assignment that the router 674 intends to make or retain as the router responsible for an 675 assignment. 677 The router MUST verify that this assignment is still valid across the 678 whole network. This assigned prefix will be referred to as the 679 Current Assigned Prefix. The router will search for a reachable AC 680 LSA in the LSA database that is advertised by a router with a higher 681 Router ID and contains an Assigned Prefix equal to the Current 682 Assigned Prefix. If such an LSA is found, it needs to be deprecated 683 as described in Section 6.3.3. Otherwise, the router will mark its 684 assignment as valid. 686 6.3.3. Deprecating an Assigned Prefix 688 This procedure is executed when the router's earlier assignment of a 689 prefix can no longer be used. The following steps MUST be followed: 691 1. If the the prefix was in an interface's assigned prefix list, it 692 is removed. 694 2. If this router was the source of the prefix assignment, schedule 695 re-origination of the modified AC LSA once the algorithm has 696 finished. 698 3. The router MUST also deprecate the prefix, if it had been 699 advertised in Router Advertisements on an interface. The prefix 700 is deprecated by sending Router Advertisements with the lifetime 701 set to 0 [RFC4861] for the prefix in question. 703 6.3.4. Verifying and Making a Local Assignment 705 This procedure is executed when an assignment by a neighbor already 706 exists, and takes precedence over all other assignments on the link. 707 The router must check whether or not it is already aware of this 708 assignment. It will search for the assigned prefix matching the 709 neighbor's assignment and Router ID in the Current Interface's 710 assigned prefix list. If it is already present, the router will mark 711 it as valid. Otherwise, the router will check that no assignment on 712 any directly connected interface collides with the neighbor's 713 assignment. If a collision is found and the colliding prefix takes 714 priority over the neighbor's assignment (higher Router ID), the 715 router will silently ignore the neighbor's assignment. If a 716 collision is found but the neighbor's assignment takes priority, the 717 old assignment is removed as described in Section 6.3.3. If the 718 neighbor's assignment takes priority, or if no collision was found, 719 the router will provision the interface with the prefix, add it to 720 the list of assigned prefixes using the neighbor's Router ID and mark 721 it as valid. 723 7. ULA Generation 725 For ULA-based prefixes, it is necessary to elect a router as the 726 generator of such prefixes, have it perform the generation, and then 727 employ the prefixes for local interfaces and the entire router 728 network. This section specifies these procedures, and recommends the 729 generation of ULAs when no connectivity can be established otherwise. 730 However, the use of ULAs in parallel with global IPv6 prefixes is 731 outside the scope of this memo. The mechanisms in this memo could be 732 used for that as well. 734 When an OSPFv3 Router detects a change in the set of AC LSAs in its 735 LSA database, it will run the ULA generation algorithm. The purpose 736 of this algorithm is to determine whether a new ULA prefix needs to 737 be generated. There is no need for this router to generate a new ULA 738 prefix when any of the following conditions are met: 740 i. 742 A Usable Prefix TLV exists in an AC LSA advertised by a reachable 743 router in the LSA database, with either global or ULA address 744 space. 746 ii. 748 A reachable router in the OSPFv3 topology with a higher Router ID 749 than this OSPFv3 router exists. 751 iii. 753 This router has assignments from either IPv4 or IPv6 global 754 address space on any interface, or there is connectivity to the 755 global Internet. 757 Discussion: This rule is necessary in order to prevent 758 autoconfiguration-capable routers from unnecessarily creating 759 ULA address space in networks where autoconfiguration is not in 760 use. Similarly, from an IPv6 "happy eyeballs" perspective it 761 is desirable to not create local islands of IPv6 connectivity 762 when there is IPv4 connectivity (even through a NAT). 764 If none of the above conditions are met after applying the hysteresis 765 principles from Section 8, the router SHOULD perform the following 766 actions: 768 1. Generate a new 48-bit ULA prefix as specified in [RFC4193], 769 Section 3.2. 771 2. Record the new prefix in stable storage, per rules in Section 4. 773 3. Advertise the new prefix allocation in OSPFv3 as specified in 774 Section 6.3. 776 4. Assign /64 prefixes from the new prefix for its own use, as a 777 part of the general algorithm for making prefix assignments (also 778 in Section 6.3). 780 If the router has made such an allocation, it SHOULD continue to 781 advertise the prefix in OSPFv3 for as long as conditions i) through 782 iii) do not apply, with the exception of the generated ULA prefix 783 that this router is advertising. 785 If the router has made such an allocation, and any of the conditions 786 become true (except for the case of the ULA prefix that the router is 787 advertising) even after applying the hysteresis principles from 788 Section 8, then the OSPFv3 router SHOULD withdraw the advertisement 789 for the usable prefix. This is done by scheduling the re-origination 790 of an AC LSA that does not include the Usable Prefix TLV with the 791 ULA. Note that as a result of the general algorithm for making 792 prefix assignments, any /64 prefix assignments from the ULA prefix 793 will eventually be deprecated. 795 8. Hysteresis 797 A network may experience temporary connectivity problems, routing 798 protocol convergence may take time, and a set of devices may be 799 coming up at the same time due to power being turned on in a 800 synchronous manner. Due to these reasons it is important that the 801 prefix allocation and assignment mechanisms do not react before the 802 situation is allowed to stabilize. To allow for this, a hysteresis 803 principle is applied to new or withdrawn automatically generated 804 prefixes and prefix assignments. 806 A new automatically generated ULA prefix SHOULD NOT be allocated 807 before the router has waited NEW_ULA_PREFIX seconds for another 808 prefix or reachable OSPFv3 router to appear. See Section 12 for the 809 specific time value. 811 A previously automatically generated ULA prefix SHOULD NOT be taken 812 out of use before the router has waited TERMINATE_ULA_PREFIX seconds. 814 A new prefix assignment within a usable prefix SHOULD NOT be 815 committed before the router has waited NEW_PREFIX_ASSIGNMENT seconds 816 for another prefix or reachable OSPFv3 router to appear. Note the 817 exceptions to this rule in Section 6.3.1, item 4. 819 A previously assigned prefix SHOULD NOT be taken out of use before 820 the router has waited TERMINATE_PREFIX_ASSIGNMENT seconds. 822 9. Manageability Considerations 824 Advanced users may wish to manage their networks without automation, 825 and there may also be situations where manual intervention may be 826 needed. For these purposes there MUST be a configuration mechanism 827 that allows users to turn off the automatic prefix allocation and 828 assignment on a given interface. This setting can be a part of 829 disabling the entire routing auto-configuration 830 [I-D.acee-ospf-ospfv3-autoconfig]. 832 In addition, there SHOULD be a configuration mechanism that allows 833 users to specify the prefix that they would like the router to 834 request for a given interface. This can be useful, for instance, 835 when a router is replaced and there is a desire for the new router to 836 be configured to ask for the same prefix as the old one, in order to 837 avoid renumbering other devices on this network. 839 Finally, there SHOULD be mechanisms to display the prefixes assigned 840 on each interface, and where they came from (manual configuration, 841 DHCPv6 PD, OSPFv3). 843 10. Security Considerations 845 Security can be always added later. 847 11. IANA Considerations 849 This memo makes two allocations out of the OSPFv3 Auto- Configuration 850 (AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]: 852 o The Usable Prefix TLV in Section 6.1 takes the value TBD-BY-IANA-1 853 (suggested value is 2). 855 o The Assigned Prefix TLV in Section 6.2 takes the value TBD-BY- 856 IANA-2 (suggested value is 3). 858 12. Timer Constants 860 NEW_ULA_PREFIX 20 seconds 861 TERMINATE_ULA_PREFIX 120 seconds 862 NEW_PREFIX_ASSIGNMENT 20 seconds 863 TERMINATE_PREFIX_ASSIGNMENT 240 seconds 865 13. References 867 13.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 873 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 874 December 2003. 876 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 877 (DHCP) Service for IPv6", RFC 3736, April 2004. 879 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 880 Addresses", RFC 4193, October 2005. 882 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 883 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 884 September 2007. 886 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 887 for IPv6", RFC 5340, July 2008. 889 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 890 "IPv6 Router Advertisement Options for DNS Configuration", 891 RFC 6106, November 2010. 893 [I-D.acee-ospf-ospfv3-autoconfig] 894 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 895 draft-acee-ospf-ospv3-autoconfig-00 (work in progress), 896 October 2011. 898 13.2. Informative References 900 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 901 Host Configuration Protocol (DHCP) version 6", RFC 3633, 902 December 2003. 904 [I-D.chown-homenet-arch] 905 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 906 Networking Architecture for IPv6", 907 draft-chown-homenet-arch-00 (work in progress), 908 September 2011. 910 [I-D.chelius-router-autoconf] 911 Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for 912 IPv6 router autoconfiguration", 913 draft-chelius-router-autoconf-00 (work in progress), 914 June 2002. 916 [I-D.dimitri-zospf] 917 Dimitrelis, A. and A. Williams, "Autoconfiguration of 918 routers using a link state routing protocol", 919 draft-dimitri-zospf-00 (work in progress), October 2002. 921 [SIGCOMM.IPV6] 922 Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D. 923 Binet, "An evaluation of the NAP protocol for IPv6 router 924 auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto, 925 Japan, 2007. 927 Appendix A. Acknowledgments 929 The authors would like to thank to Tim Chown, Fred Baker, Mark 930 Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel 931 Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik 932 Nordmark, Laurent Toutain, and Ralph Droms for interesting 933 discussions in this problem space. The authors would also like to 934 point out some past work in this space, such as those in 935 [I-D.chelius-router-autoconf] or [I-D.dimitri-zospf]. 937 Authors' Addresses 939 Jari Arkko 940 Ericsson 941 Jorvas 02420 942 Finland 944 Email: jari.arkko@piuha.net 946 Acee Lindem 947 Ericsson 948 Cary, NC 27519 949 USA 951 Email: acee.lindem@ericsson.com 953 Benjamin Paterson 954 Cisco Systems 955 Paris 956 France 958 Email: benjamin@paterson.fr