idnits 2.17.1 draft-arkko-homenet-prefix-assignment-03.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 23, 2012) is 4193 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) == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-00 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-06 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: April 26, 2013 B. Paterson 6 Cisco Systems 7 October 23, 2012 9 Prefix Assignment in a Home Network 10 draft-arkko-homenet-prefix-assignment-03 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 April 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 8 68 6. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 9 69 6.1. Aggregated Prefix TLV . . . . . . . . . . . . . . . . . . 10 70 6.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 11 71 6.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 12 72 6.3.1. Making a New Assignment . . . . . . . . . . . . . . . 15 73 6.3.2. Checking for Conflicts Across the Entire Network . . . 15 74 6.3.3. Deprecating an Assigned Prefix . . . . . . . . . . . . 16 75 6.3.4. Verifying and Making a Local Assignment . . . . . . . 16 76 7. ULA Generation . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 9. Manageability Considerations . . . . . . . . . . . . . . . . . 19 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 12. Timer Constants . . . . . . . . . . . . . . . . . . . . . . . 19 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Appendix A. Changes in Version -02 . . . . . . . . . . . . . . . 21 86 Appendix B. Changes in Version -03 . . . . . . . . . . . . . . . 21 87 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 This memo describes a prefix assignment mechanism for home networks. 93 It is expected that home gateway routers are allocated an IPv6 prefix 94 through DHCPv6 Prefix Delegation (PD) [RFC3633], or that a prefix is 95 made available by some other means. Manual configuration may be 96 needed in some networks, for instance when the ISP does not support 97 DHCPv6-based prefix delegation. In other cases, such as networks 98 that have do not yet have an Internet connection, Unique Local 99 Address (ULA) [RFC4193] prefixes can be automatically generated. For 100 the purposes of this document, we refer to the prefix reserved for a 101 home network as a prefix allocation. 103 A prefix allocation needs to be divided among the multiple subnets in 104 a home network. For the purposes of this document, we refer to this 105 process as prefix assignment. This memo describes a mechanism for 106 prefix assignment via OSPFv3 [RFC5340]. 108 The OSPv3-based mechanism is an alternative design to also using 109 DHCPv6 PD for the prefix assignment in the internal network. This 110 memo has been written so that the working group can make a decision 111 on which type of design to pursue. The main benefit of using a 112 routing protocol to handle the prefix assignment is that it can 113 provide a more efficient use of address space than hierarchical 114 assignment through DHCPv PD. This may be important for home networks 115 that only get a /60 prefix allocation from their ISPs. 117 The rest of this memo is organized as follows. Section 2 defines the 118 usual keywords, Section 3 explains the main requirements for prefix 119 assignments, Section 4 describes how a home gateway router makes 120 assignments when it itself has multiple subnets, and Section 5 and 121 Section 6 describe how the assignment can be performed in a 122 distributed manner via OSPFv3 in the entire home network. Finally, 123 Section 7 specifies the procedures for automatic generation of ULA 124 prefixes, Section 8 explains the hysteresis principles applied to 125 prefix assignment and de-assignment, Section 9 explains what 126 administrative interfaces are useful for advanced users that wish to 127 manually interact with the mechanisms, Section 10 discusses the 128 security aspects of the design, Section 11 explains the necessary 129 IANA actions, and Section 12 defines the necessary timer constants. 131 An analysis of a mechanism reminiscent of the one described in this 132 specification has been published in the SIGCOMM IPv6 Workshop 133 [SIGCOMM.IPV6]. Further analysis is encouraged. 135 2. Requirements language 137 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 138 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 139 described in [RFC2119]. 141 3. Role of Prefix Assignment 143 Given a prefix shorter than /64 for the entire home network, this 144 prefix needs to be subdivided so that every subnet is given its own 145 /64 prefix. In many cases there will be just one subnet, the 146 internal network interface attached to the router. But it is also 147 common to have two or more internal network interfaces with 148 intentionally separate networks. For instance, "private" and "guest" 149 SSIDs are automatically configured in many current home network 150 routers. When all the network interfaces that require a prefix are 151 attached to the same router, the prefix assignment problem is simple, 152 and procedures outlined in Section 4 can be employed. 154 In a more complex setting there are multiple routers in the internal 155 network. There are various possible reasons why this might be 156 necessary [I-D.ietf-homenet-arch]. For instance, networks that 157 cannot be bridged together should be routed, speed differences 158 between wired and wireless interfaces make the use of the same 159 broadcast domain undesirable, or simply that router devices keep 160 being added. In any case, it then becomes necessary to assign 161 prefixes across the entire network, and this assignment can no longer 162 be done on a local basis as proposed in Section 4. A distributed 163 mechanism and a protocol are required. 165 The key requirements for this distributed mechanism are as follows. 167 o A prefix allocated to a home gateway router within the home 168 network is used to assign /64 prefixes on each subnet that 169 requires one. 171 Note that several methods may be used to allocate such an 172 aggregated prefix. 174 o The assignment mechanism should provide reasonable efficiency. As 175 a practical benchmark, some ISPs may employ /60 allocations to 176 individual subscribers. As a result, the assignment mechanism 177 should avoid wasting too many prefixes so that this set of 16 /64 178 prefixes is not exhausted in the foreseeable future for commonly 179 occurring network configurations. 181 o In particular, the assignment of multiple prefixes to the same 182 network from the same top-level prefix must be avoided. 184 Example: When a home network consists of a home gateway router 185 connected to another router which in turn is connected to 186 hosts, a minimum of two /64 prefixes are required in the 187 internal network: one between the two routers, and another one 188 for the host-side interface on the second router. But an 189 ineffective assignment mechanism in the two routers might have 190 both of them asking for separate assignments for this shared 191 interface. 193 o The assignments must be stable across reboots, power cycling, 194 router software updates, and preferably, should be stable across 195 simple network changes. Simple network changes are in this case 196 defined as those that could be resolved through either deletion or 197 addition of a prefix assignment. For instance, the addition of a 198 new router without changing connections between existing routers 199 requires just the assignment of new prefixes for the new networks 200 that the router introduces. There are no stability requirements 201 across more complex types of network reconfiguration events. For 202 instance, if a network is separated into two networks connected by 203 a newly inserted router, this may lead to renumbering all networks 204 within the home. 206 In an even more complex setting there may be multiple home gateway 207 routers and multiple connections to ISP(s). These cases are 208 analogous to the case of a single gateway router. Each gateway will 209 simply distribute the prefix it has, and participating routers 210 throughout the network may assign themselves prefixes from several 211 gateways. Multiple assignments can be made for the same interface. 212 For example, this can be useful in a multi-homing setting. 214 Similarly, it is also possible that it is necessary to assign either 215 a global prefix delegated from the ISP or a local, Unique Local 216 Address (ULA) prefix [RFC4193]. The mechanisms in this memo are 217 applicable to both types of prefixes. The details of the generation 218 of ULA-based prefixes is covered in Section 7. 220 The mechanisms in this memory can also be used in standalone or ad 221 hoc networks where no global prefixes or Internet connectivity are 222 available, by distributing ULA prefixes within the network. 224 4. Router Behavior 226 This section describes how a router assigns prefixes to its directly 227 connected interfaces. We assume that the router has prefix 228 allocation(s) that it can use for this assignment. Each such prefix 229 allocation is called an aggregated prefix. Parts of the aggregated 230 prefix may already be assigned for some purpose; a coordinated 231 assignment from the prefix is necessary before it can actually be 232 assigned to an interface. 234 Even if the assignment process is local, it still needs to follow the 235 requirements from Section 3. This is achieved through the following 236 rules: 238 o The router MUST maintain a list of assigned prefixes on a per- 239 interface basis. The contents of this list consists of prefixes 240 that the router itself has assigned to the interface, as well as 241 prefixes assigned to the interface by other routers. The latter 242 are learned through the mechanisms described in Section 6, when 243 they are used. Each prefix is associated with the Router ID of 244 the router that assigned it. 246 o Whenever the router finds a combination of an interface and 247 aggregated prefix that is not used on the interface, it SHOULD 248 make a new prefix assignment. That is, the router checks to see 249 if an interface and aggregated prefix exists such that there are 250 no assigned prefixes within that interface that are more specific 251 than the aggregated prefix. In this situation the router makes an 252 allocation from the aggregated prefix (if possible) and adds the 253 assignment to the list of assigned prefixes on that interface. 255 Note: The above implies that when there are multiple aggregated 256 prefixes, each network will be assigned multiple prefixes. 258 o An assignment from an aggregated prefix MUST be checked against 259 possible other assignments from the same aggregated prefix on the 260 same link by neighboring routers, to avoid unnecessary 261 assignments. Assignments MUST also be examined against all 262 existing assignments from the same aggregated prefix across the 263 network, to avoid collisions. Assignments are made for individual 264 /64 prefixes. The choice of a /64 prefix among multiple free ones 265 MUST be made randomly or based on an algorithm that takes unique 266 hardware characteristics of the router and the interface into 267 account. This helps avoid collisions when simultaneous 268 assignments are made within a network. 270 o In order to provide a stable assignment, the router MUST store 271 assignments affecting directly connected interfaces and 272 automatically generated ULA prefixes in non-volatile memory and 273 attempt to re-use them in the future when possible. At least the 274 5 most recent assignments SHOULD be stored. Note that this 275 applies to both its own assignments as well as assignments made by 276 others. This ensures that the same prefix assignments are made 277 regardless of the order that different devices are brought up. To 278 avoid attacks on flash memory write cycles, assignments made by 279 others SHOULD be recorded only after 10 minutes have passed and 280 the assignment is still valid. 282 o Re-using a memorized assignment is possible when a aggregated 283 prefix exists that is less specific than the prefix in the 284 assignment (or it is the prefix itself in the assignment), and the 285 prefix is currently unassigned. 287 4.1. Sending Router Advertisements 289 Once the router has assigned a prefix to an interface, it MUST act as 290 a router as defined in [RFC4861] and advertise the prefix in Router 291 Advertisements. The lifetime of the prefix SHOULD be advertised as a 292 reasonably long period, at least 48 hours or the lifetime of the 293 assigned prefixes, whichever is smaller. 295 4.2. DNS Discovery 297 To support a variety of IPv6-only hosts in these networks, the router 298 needs to ensure that sufficient DNS discovery mechanisms are enabled. 299 It is RECOMMENDED that both stateless DHCPv6 [RFC3736] and Router 300 Advertisement options [RFC6106] are supported and turned on by 301 default in routers. 303 The above requires, however, that a working DNS server is known and 304 addressable via IPv6. The mechanism in [RFC3736] and [RFC3646] can 305 be used for this. It is RECOMMENDED that each router attempts to 306 discover an existing DNS server. Typically, such a server will be 307 provided by an ISP. However, in some cases no such server can be 308 found. For instance, an ISP may provide only IPv4 DNS server 309 addresses, or a router deep within the home network is unaware of the 310 IPv6 DNS servers that a home gateway router has discovered. In these 311 situations it is RECOMMENDED that each router turns on a local DNS 312 relay that fetches information from the IPv4 Internet (if a working 313 IPv4 DNS server is available) or a full DNS server that fetches 314 information from the DNS root. 316 As a result of these recommendations, as long as there is 317 reachability to at least the Internet, every router within the home 318 network will either know the IPv6 address of a DNS server or it 319 itself runs a server that can fetch information from the Internet. 320 As a result, the router can provide information about the server 321 address to hosts in directly connected networks. 323 5. Design Choices 325 5.1. DNS Discovery 327 The DNS discovery recommendations in Section 4.2 ensure that an IPv6- 328 only home network can resolve names. However, these recommendations 329 are suboptimal in the sense that different routers in the home may 330 provide different DNS servers, or multiple local DNS servers have to 331 be run where it would have been possible to point to one, or even 332 point to the one provided by the ISP. However, better coordination 333 for the DNS server selection would require some form of additional 334 communication between the routers in the home network. The authors 335 solicit opinions from the Working Group on whether this is something 336 that should be specified. However, the current design is easy to 337 deploy even when not all routers within the network support Homenet 338 specifications yet; the mechanism provides an incremental improvement 339 to IPv6 DNS reachability even when the first Homenet router is 340 deployed. 342 5.2. Prefix Assignment 344 The OSPFv3-based prefix assignment protocol needs to detect two types 345 of conflicts: 347 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for 348 different networks. 350 2. Two or more OSPFv3 routers have assigned different IPv6 prefixes 351 for the same network. 353 Several design decisions were needed to construct the protocol: 355 1. How to determine the winner in case of a conflict? 357 The algorithm in Section 6 ensures that the OSPFv3 Router with 358 the numerically lower OSPFv3 Router ID removes its assignment and 359 schedules an advertisement of LSAs that no longer describe such 360 an assignment. That is, the router with the highest Router ID 361 wins in a conflict situation. 363 2. How to ensure that a network-wide conflict can be detected? 365 We chose to define new LSA extensions -- TLVs within the new 366 Autoconfiguration LSA -- that are flooded throughout the network. 367 Another possible design would have been to re-use existing OSPFv3 368 LSAs, and by assuming that if a router advertises a prefix then 369 it has made an assignment. The advantage of the design that we 370 chose is that we get to specify what information is needed in the 371 new TLVs. This is particularly important, as not all existing 372 OSPFv3 LSAs are extensible. A downside is that assignments will 373 not be visible, unless the router using an assignment implements 374 this specification and advertises the new LSAs. Had we reused 375 existing LSAs, a manual assignment for a legacy router could have 376 been handled, as the legacy router would have advertised the 377 prefix assigned to it. 379 3. How to ensure that both local and network-wide conflicts can be 380 detected? 382 We chose to employ the same new Autoconfiguration LSA TLVs for 383 this purpose, and correlate neighbors through the Router IDs and 384 Interface IDs that they advertise in these TLVs. The OSPFv3 385 Router with a numerically lower OSPFv3 Router ID should accept 386 the global IPv6 prefix from the neighbor with the highest OSPFv3 387 Router ID. 389 6. Prefix Assignment in OSPFv3 391 This section describes how prefix assignment in a home network can be 392 performed in a distributed manner via OSPFv3. It is expected that 393 the router already support the auto-configuration extensions defined 394 in [I-D.ietf-ospf-ospfv3-autoconfig]. 396 An overview of OSPFv3-based prefix assignment is as follows. OSPFv3 397 routers that are capable of auto-configuration advertise an OSPFv3 398 Auto-Configuration (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig] with 399 suitable TLVs. For prefix assignment, two TLVs are used. The 400 Aggregated Prefix TLV (Section 6.1) advertises an aggregated prefix, 401 usually the prefix that has been delegated to the home gateway router 402 from the ISP through DHCPv6 PD. These aggregated prefixes are 403 necessary for running the algorithm in Section 4 for determining 404 whether prefix assignments can and should be made. 406 The Assigned Prefix TLV (Section 6.2) is used to communicate 407 assignments that routers make out of the aggregated prefixes. 409 An assignment can be made when the algorithm in Section 4 indicates 410 that it can be made and no other router has claimed the same 411 assignment. The router makes an OSPFv3 advertisement with the 412 Assigned Prefix TLV included to let other devices know that the 413 prefix is now in use. Unfortunately, collisions are still possible, 414 when the algorithms on different routers happen to choose the same 415 free /64 prefix or when more /64 prefixes are needed than are 416 available. This situation is detected through an advertisement where 417 a different router claims the assignment of the same prefix. In this 418 situation the router with the numerically lower OSPFv3 Router ID has 419 to select another prefix and immediately withdraw any assignments and 420 advertisements that may have been advertised in OSPFv3. See also 421 Section 5.2 in [I-D.ietf-ospf-ospfv3-autoconfig]. 423 6.1. Aggregated Prefix TLV 425 The Aggregated Prefix TLV is defined for the OSPFv3 Auto- 426 Configuration (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig]. It will 427 have type TBD-BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC 428 LSA with an LSID of 0. It MAY occur once or multiple times and the 429 information from all TLV instances is retained. The length of the 430 TLV is variable. 432 The contents of the TLV include an aggregated prefix (Prefix) and 433 prefix length (PrefixLength). PrefixLength is the length in bits of 434 the prefix and is an 8-bit field. The PrefixLength MUST be greater 435 than or equal to 8 and less than or equal to 64. The prefix 436 describes an allocation of a global or ULA prefix for the entire 437 auto-configured home network. The Prefix is an encoding of the 438 prefix itself as an even multiple of 32-bit words, padding with zero 439 bits as necessary. This encoding consumes (PrefixLength + 31) / 32) 440 32-bit words and is consistent with [RFC5340]. It MUST NOT be 441 directly assigned to any interface before following the procedures 442 defined in this memo. 444 This TLV SHOULD be advertised by every home gateway router that has 445 either a manual, DHCPv6 PD-based, or generated ULA prefix that is 446 shorter than /64. 448 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 449 and only in combination with the Router-Hardware-Fingerprint TLV 450 [I-D.ietf-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | TBD-BY-IANA-1 | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | PrefixLength | Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 | Prefix | 461 | (4-16 bytes) | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Aggregated Prefix TLV Format 466 6.2. Assigned Prefix TLV 468 The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration 469 (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig]. It will have type TBD- 470 BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an 471 LSID of 0. It MAY occur once or multiple times and the information 472 from all TLV instances is retained. The length of the TLV is 473 variable. 475 The contents of the TLV include an Interface ID, assigned prefix 476 (Prefix), and prefix length (PrefixLength). The Interface ID is the 477 same OSPFv3 Interface ID that is described in section 4.2.1 or 478 [RFC5340]. PrefixLength is the length in bits of the prefix and is 479 an 8-bit field. The PrefixLength value MUST be 64 in this version of 480 the specification. The prefix describes an assignment of a global or 481 ULA prefix for a directly connected interface in the advertising 482 router. The Prefix is an encoding of the prefix itself as an even 483 multiple of 32-bit words, padding with zero bits as necessary. This 484 encoding consumes (PrefixLength + 31) / 32) 32-bit words and is 485 consistent with [RFC5340]. 487 This TLV MUST be advertised by the router that has made assignment 488 from an aggregated prefix per Section 4. 490 This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, 491 and only in combination with the Router-Hardware-Fingerprint TLV 492 [I-D.ietf-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | TBD-BY-IANA-2 | Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Interface ID | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | PrefixLength | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 | Prefix | 505 | (4-16 bytes) | 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Assigned Prefix TLV Format 511 6.3. OSPFv3 Prefix Assignment 513 OSPFv3 Routers supporting the mechanisms in the memo will learn or 514 assign a global /64 IPv6 prefix for each IPv6 interface. Since the 515 mechanisms described herein are based on OSPFv3, Router ID assignment 516 as described in [I-D.ietf-ospf-ospfv3-autoconfig] MUST have completed 517 successfully. 519 When an OSPFv3 Router receives a global prefix through DHCPv6 prefix 520 delegation, manual configuration, or other means, it SHOULD advertise 521 this prefix by including the Aggregated Prefix TLV in its OSPFv3 AC 522 LSA. This will trigger prefix assignment for auto-configured OSPFv3 523 routers within the routing domain including the originating OSPFv3 524 router. 526 Discussion: Note that while having multiple routers advertise the 527 same aggregated address space (or address space that covers 528 another router's aggregated address space) is a configuration 529 error, it should not result in any adverse effects, as long as 530 assignments from such space are still checked for collisions 531 against all other assignments from the same address space. 533 When an OSPFv3 Router detects a change in the set of AC LSAs in its 534 LSA database, it will run the prefix assignment algorithm. The 535 purpose of this algorithm is to determine, for each Aggregated Prefix 536 in the database, whether or not a new prefix needs to be assigned for 537 each of its attached IPv6 interfaces and whether or not existing 538 assignments need to be deprecated. The algorithm also detects and 539 removes assignments for which there is no longer a corresponding 540 Aggregated Prefix. Before the algorithm is run, all existing 541 assignments in assigned prefix lists for directly connected 542 interfaces must be marked as "invalid" and will be deleted at the end 543 of the algorithm if they are still in this state. An assigned prefix 544 is considered to be "valid" if all the following conditions are met: 546 o A containing Aggregated Prefix TLV exists in reachable AC LSA(s). 548 o An Assigned Prefix TLV that matches this assignment exactly (same 549 prefix, same router and interface ID associated with the 550 assignment) exist in reachable AC LSA(s). 552 o Any router advertising an assignment for the same link and 553 Aggregated Prefix has a lower Router ID than the source of this 554 assignment. 556 o If this router is the source of the assignment, any router in the 557 network that has assigned the same prefix on a different link has 558 a lower Router ID than this router. 560 Note that this definition of a "valid assignment" depends on the 561 router running the algorithm: in particular, a router is not expected 562 to detect prefix collisions or duplicate prefix assignments that do 563 not concern assignments for which it is the responsible router. It 564 is the role of the responsible router to detect these cases and 565 update its AC LSAs accordingly. A router is, however, expected to 566 react to these updates from other routers which translate into 567 additions or removals of Aggregated Prefix or Assigned Prefix TLVs. 569 The router is expected to have made a snapshot of the LSA database 570 before running this algorithm. The prefix assignment algorithm 571 consists of the following steps run once per combination of 572 Aggregated Prefix in the LSA database and directly connected OSPFv3 573 interface. For the purposes of this discussion, the Aggregated 574 Prefix will be referred to as the Current Aggregated Prefix, and the 575 interface will be referred to as the Current Interface. The 576 following steps will be performed for each tuple (Aggregated Prefix, 577 OSPFv3 interface): 579 1. The OSPFv3 Router will search all AC LSAs for an Aggregated 580 Prefix TLV describing a prefix which contains but is not equal to 581 the Current Aggregated Prefix. If such a prefix is found, the 582 algorithm is skipped for the Current Aggregated Prefix as it 583 either has or will be run for the shorter prefix. 585 2. The OSPFv3 router will examine its list of neighbors to find all 586 neighbors in state greater than Init (these neighbors will be 587 referred to as active neighbors). 589 3. The following three steps will serve to determine whether an 590 assignment needs to be made on the link: 592 i. 594 The OSPFv3 router will determine whether or not it has the 595 highest Router ID of all active OSPFv3 routers on the link. 597 ii. 599 If OSPFv3 active neighbors are present on the link, the router 600 will determine whether any of them have already assigned an 601 IPv6 prefix. This is done by examining the AC LSAs of all the 602 active neighbors on the link and looking for any that include 603 an Assigned Prefix TLV with the same OSPFv3 Router ID and 604 Interface ID as the neighbor has. If one is found and it is a 605 subnet of the IPv6 prefix advertised in the Aggregated Prefix 606 TLV, the router stores this prefix and the Router ID of the 607 router advertising it for reference in the next step. If 608 several such prefixes are found, only the prefix and Router ID 609 with the numerically highest Router ID are stored. 611 iii. 613 The router will compare its Router ID with the highest Router 614 ID among neighbors which have made an assignment on the link. 615 If it is higher (or if no assignments have been made by any 616 neighbors), it will determine whether or not it is already the 617 source of an assignment for the Current Interface from the 618 Current Aggregated Prefix. 620 4. There are four possibilities at this stage: 622 * The router has already made an assignment on the link and has 623 a higher Router ID than all eventual neighbors which have also 624 made an assignment. In this case, the router's existing 625 assignment takes precedence over all other eventual existing 626 assignments on the link, but the router must determine whether 627 its assignment is still valid throughout the whole network. 628 This is described in Section 6.3.2. 630 * An assignment has been made by a neighbor on the link, and the 631 router either has not made an assignment on the link, or has a 632 lower Router ID than the neighbor. In this case, the 633 neighbor's assignment takes precedence over all eventual 634 existing assignments on the link (including assignments made 635 by the router), and the router must update the assigned prefix 636 list of the Current Interface as well as check assignments on 637 other interfaces for potential collisions. This is described 638 in Section 6.3.4. 640 * No assignment has been made by anyone on the link, and the 641 router has the highest Router ID on the link. In this case, 642 it must make an assignment from the Current Aggregated Prefix. 643 This is described in Section 6.3.1. 645 * No assignment has been made by anyone on the link, and the 646 router does not have the highest Router ID on the link. In 647 this case, the algorithm exits as the router is not 648 responsible for prefix assignment on the link. 650 Once the algorithm has been run for each Aggregated Prefix and each 651 interface, the router must delete all assignments that are not marked 652 as valid on all assigned prefix lists and deprecate the corresponding 653 addresses. If this leads to deleting an assignment that this router 654 was responsible for, or if AC LSA origination was scheduled during 655 the algorithm, it must originate a new AC LSA advertising the 656 changes. The router MUST also deprecate deleted prefixes as 657 specified in Section 6.3.3. 659 6.3.1. Making a New Assignment 661 This procedure is executed when no assignment exists on the link and 662 the router is responsible for making an assignment. The router MUST: 664 1. Examine all the AC LSAs not advertised by this router that 665 include Assigned Prefix TLVs that are subnets of the Current 666 Aggregated Prefix, as well as all assignments made by this 667 router, to determine which prefixes are already assigned. 669 2. Examine former prefix assignments stored in non-volatile storage 670 for the interface. Starting with the most recent assignment, if 671 the prefix is both a subnet of the Current Aggregated Prefix and 672 is currently unassigned, reuse the assignment for the interface. 674 3. If no unused former prefix assignment is found, and an unassigned 675 /64 subnet of the Current Aggregated Prefix exists, assign that 676 prefix to the interface. 678 4. If no OSPFv3 neighbors have been discovered and previous prefix 679 assignments exist, the router can make the assignments 680 immediately. Otherwise, the hysteresis periods specified in 681 Section 8 are applied before making an assignment. 683 5. In the event that no assignment could be made to the interface, a 684 warning must be raised. However, the router MUST remain in a 685 state where it continues to assign prefixes through OSPFv3, as 686 prefixes may later become available. 688 6. Once a global IPv6 prefix is assigned, the router will mark it as 689 valid and schedule re-origination of the AC LSA including the 690 Assigned Prefix TLV once all Aggregated Prefixes and interfaces 691 have been examined. 693 6.3.2. Checking for Conflicts Across the Entire Network 695 This procedure is executed for every assignment that the router 696 intends to make or retain as the router responsible for an 697 assignment. 699 The router MUST verify that this assignment is still valid across the 700 whole network. This assigned prefix will be referred to as the 701 Current Assigned Prefix. The router will search for a reachable AC 702 LSA in the LSA database that is advertised by a router with a higher 703 Router ID and contains an Assigned Prefix equal to the Current 704 Assigned Prefix. If such an LSA is found, it needs to be deprecated 705 as described in Section 6.3.3. Otherwise, the router will mark its 706 assignment as valid. 708 6.3.3. Deprecating an Assigned Prefix 710 This procedure is executed when the router's earlier assignment of a 711 prefix can no longer be used. The following steps MUST be followed: 713 1. If the the prefix was in an interface's assigned prefix list, it 714 is removed. 716 2. If this router was the source of the prefix assignment, schedule 717 re-origination of the modified AC LSA once the algorithm has 718 finished. 720 3. The router MUST also deprecate the prefix, if it had been 721 advertised in Router Advertisements on an interface. The prefix 722 is deprecated by sending Router Advertisements with the lifetime 723 set to 0 [RFC4861] for the prefix in question. 725 6.3.4. Verifying and Making a Local Assignment 727 This procedure is executed when an assignment by a neighbor already 728 exists, and takes precedence over all other assignments on the link. 729 The router must check whether or not it is already aware of this 730 assignment. It will search for the assigned prefix matching the 731 neighbor's assignment and Router ID in the Current Interface's 732 assigned prefix list. If it is already present, the router will mark 733 it as valid. Otherwise, the router will check that no assignment on 734 any directly connected interface collides with the neighbor's 735 assignment. If a collision is found and the colliding prefix takes 736 priority over the neighbor's assignment (higher Router ID), the 737 router will silently ignore the neighbor's assignment. If a 738 collision is found but the neighbor's assignment takes priority, the 739 old assignment is removed as described in Section 6.3.3. If the 740 neighbor's assignment takes priority, or if no collision was found, 741 the router will provision the interface with the prefix, add it to 742 the list of assigned prefixes using the neighbor's Router ID and mark 743 it as valid. 745 7. ULA Generation 747 For ULA-based prefixes, it is necessary to elect a router as the 748 generator of such prefixes, have it perform the generation, and then 749 employ the prefixes for local interfaces and the entire router 750 network. This section specifies these procedures, and recommends the 751 generation of ULAs when no connectivity can be established otherwise. 752 However, the use of ULAs in parallel with global IPv6 prefixes is 753 outside the scope of this memo. The mechanisms in this memo could be 754 used for that as well. 756 When an OSPFv3 Router detects a change in the set of AC LSAs in its 757 LSA database, it will run the ULA generation algorithm. The purpose 758 of this algorithm is to determine whether a new ULA prefix needs to 759 be generated. There is no need for this router to generate a new ULA 760 prefix when any of the following conditions are met: 762 i. 764 An Aggregated Prefix TLV exists in an AC LSA advertised by a 765 reachable router in the LSA database, with either global or ULA 766 address space. 768 ii. 770 A reachable router in the OSPFv3 topology with a higher Router ID 771 than this OSPFv3 router exists. 773 iii. 775 This router has assignments from either IPv4 or IPv6 global 776 address space on any interface, or there is connectivity to the 777 global Internet. 779 Discussion: This rule is necessary in order to prevent 780 autoconfiguration-capable routers from unnecessarily creating 781 ULA address space in networks where autoconfiguration is not in 782 use. Similarly, from an IPv6 "happy eyeballs" perspective it 783 is desirable to not create local islands of IPv6 connectivity 784 when there is IPv4 connectivity (even through a NAT). 786 If none of the above conditions are met after applying the hysteresis 787 principles from Section 8, the router SHOULD perform the following 788 actions: 790 1. Generate a new 48-bit ULA prefix as specified in [RFC4193], 791 Section 3.2. 793 2. Record the new prefix in stable storage, per rules in Section 4. 795 3. Advertise the new prefix allocation in OSPFv3 as specified in 796 Section 6.3. 798 4. Assign /64 prefixes from the new prefix for its own use, as a 799 part of the general algorithm for making prefix assignments (also 800 in Section 6.3). 802 If the router has made such an allocation, it SHOULD continue to 803 advertise the prefix in OSPFv3 for as long as conditions i) through 804 iii) do not apply, with the exception of the generated ULA prefix 805 that this router is advertising. 807 If the router has made such an allocation, and any of the conditions 808 become true (except for the case of the ULA prefix that the router is 809 advertising) even after applying the hysteresis principles from 810 Section 8, then the OSPFv3 router SHOULD withdraw the advertisement 811 for the aggregated prefix. This is done by scheduling the re- 812 origination of an AC LSA that does not include the Aggregated Prefix 813 TLV with the ULA. Note that as a result of the general algorithm for 814 making prefix assignments, any /64 prefix assignments from the ULA 815 prefix will eventually be deprecated. 817 8. Hysteresis 819 A network may experience temporary connectivity problems, routing 820 protocol convergence may take time, and a set of devices may be 821 coming up at the same time due to power being turned on in a 822 synchronous manner. Due to these reasons it is important that the 823 prefix allocation and assignment mechanisms do not react before the 824 situation is allowed to stabilize. To allow for this, a hysteresis 825 principle is applied to new or withdrawn automatically generated 826 prefixes and prefix assignments. 828 A new automatically generated ULA prefix SHOULD NOT be allocated 829 before the router has waited NEW_ULA_PREFIX seconds for another 830 prefix or reachable OSPFv3 router to appear. See Section 12 for the 831 specific time value. 833 A previously automatically generated ULA prefix SHOULD NOT be taken 834 out of use before the router has waited TERMINATE_ULA_PREFIX seconds. 836 A new prefix assignment within an aggregated prefix SHOULD NOT be 837 committed before the router has waited NEW_PREFIX_ASSIGNMENT seconds 838 for another prefix or reachable OSPFv3 router to appear. Note the 839 exceptions to this rule in Section 6.3.1, item 4. 841 A previously assigned prefix SHOULD NOT be taken out of use before 842 the router has waited TERMINATE_PREFIX_ASSIGNMENT seconds. 844 9. Manageability Considerations 846 Advanced users may wish to manage their networks without automation, 847 and there may also be situations where manual intervention may be 848 needed. For these purposes there MUST be a configuration mechanism 849 that allows users to turn off the automatic prefix allocation and 850 assignment on a given interface. This setting can be a part of 851 disabling the entire routing auto-configuration 852 [I-D.ietf-ospf-ospfv3-autoconfig]. 854 In addition, there SHOULD be a configuration mechanism that allows 855 users to specify the prefix that they would like the router to 856 request for a given interface. This can be useful, for instance, 857 when a router is replaced and there is a desire for the new router to 858 be configured to ask for the same prefix as the old one, in order to 859 avoid renumbering other devices on this network. 861 Finally, there SHOULD be mechanisms to display the prefixes assigned 862 on each interface, and where they came from (manual configuration, 863 DHCPv6 PD, OSPFv3). 865 10. Security Considerations 867 Security can be always added later. 869 11. IANA Considerations 871 This memo makes two allocations out of the OSPFv3 Auto- Configuration 872 (AC) LSA TLV namespace [I-D.ietf-ospf-ospfv3-autoconfig]: 874 o The Aggregated Prefix TLV in Section 6.1 takes the value TBD-BY- 875 IANA-1 (suggested value is 2). 877 o The Assigned Prefix TLV in Section 6.2 takes the value TBD-BY- 878 IANA-2 (suggested value is 3). 880 12. Timer Constants 882 NEW_ULA_PREFIX 20 seconds 883 TERMINATE_ULA_PREFIX 120 seconds 884 NEW_PREFIX_ASSIGNMENT 20 seconds 885 TERMINATE_PREFIX_ASSIGNMENT 240 seconds 887 13. References 888 13.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, March 1997. 893 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 894 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 895 December 2003. 897 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 898 (DHCP) Service for IPv6", RFC 3736, April 2004. 900 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 901 Addresses", RFC 4193, October 2005. 903 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 904 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 905 September 2007. 907 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 908 for IPv6", RFC 5340, July 2008. 910 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 911 "IPv6 Router Advertisement Options for DNS Configuration", 912 RFC 6106, November 2010. 914 [I-D.ietf-ospf-ospfv3-autoconfig] 915 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 916 draft-ietf-ospf-ospfv3-autoconfig-00 (work in progress), 917 October 2012. 919 13.2. Informative References 921 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 922 Host Configuration Protocol (DHCP) version 6", RFC 3633, 923 December 2003. 925 [I-D.ietf-homenet-arch] 926 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 927 "Home Networking Architecture for IPv6", 928 draft-ietf-homenet-arch-06 (work in progress), 929 October 2012. 931 [I-D.chelius-router-autoconf] 932 Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for 933 IPv6 router autoconfiguration", 934 draft-chelius-router-autoconf-00 (work in progress), 935 June 2002. 937 [I-D.dimitri-zospf] 938 Dimitrelis, A. and A. Williams, "Autoconfiguration of 939 routers using a link state routing protocol", 940 draft-dimitri-zospf-00 (work in progress), October 2002. 942 [SIGCOMM.IPV6] 943 Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D. 944 Binet, "An evaluation of the NAP protocol for IPv6 router 945 auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto, 946 Japan, 2007. 948 Appendix A. Changes in Version -02 950 These changes were extensive, including the definition of a new 951 algorithm for making allocations, adding support for DNS server 952 discovery, adding support for ULA-based address space generation, and 953 adding specifications for a hysteresis mechanism. 955 Appendix B. Changes in Version -03 957 This version updated references to the most current ones, and changed 958 the "usable prefix" terminology to "aggregated prefix". The 959 requirements for turning on DNS relays or servers were also 960 clarified. 962 Appendix C. Acknowledgments 964 The authors would like to thank to Tim Chown, Fred Baker, Mark 965 Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus Stenberg, 966 Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael Richardson, 967 Anders Brandt, Erik Nordmark, Laurent Toutain, and Ralph Droms for 968 interesting discussions in this problem space. The authors would 969 also like to point out some past work in this space, such as those in 970 [I-D.chelius-router-autoconf] or [I-D.dimitri-zospf]. 972 Authors' Addresses 974 Jari Arkko 975 Ericsson 976 Jorvas 02420 977 Finland 979 Email: jari.arkko@piuha.net 980 Acee Lindem 981 Ericsson 982 Cary, NC 27519 983 USA 985 Email: acee.lindem@ericsson.com 987 Benjamin Paterson 988 Cisco Systems 989 Paris 990 France 992 Email: benjamin@paterson.fr