idnits 2.17.1 draft-ietf-homenet-prefix-assignment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If some host or non-Homenet router asks for Delegated Prefixes, a router MAY assign a set of prefixes and give them to the client. Such assignments MUST be advertised as either not assigned on any link, or assigned on a stub virtual link connected to the router, depending on the Flooding Protocol capabilities. By default assignments priorities MUST be between PRIORITY_AUTO_MIN and PRIORITY_AUTO_MAX, SHOULD be lower than PRIORITY_DEFAULT, and the authoritative bit MUST not be set. Whenever such an assignment becomes invalid, DHCPv6 Reconfigure SHOULD be used in order to remove the prefix from DHCPv6 DP client's lease. If DHCPv6 Reconfigure is not supported, leases lifetimes SHOULD be significantly small. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In the case of IPv4 prefixes, the network address (first address of the address pool) MUST not be used. -- The document date (October 24, 2014) is 3471 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 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-00 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-06 == Outdated reference: A later version (-08) exists of draft-ietf-6man-why64-06 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pfister 3 Internet-Draft B. Paterson 4 Intended status: Standards Track Cisco Systems 5 Expires: April 27, 2015 J. Arkko 6 Ericsson 7 October 24, 2014 9 Prefix and Address Assignment in a Home Network 10 draft-ietf-homenet-prefix-assignment-01 12 Abstract 14 This memo describes a home network prefix and address assignment 15 algorithm running on top of any 'flooding protocol' that fulfills the 16 specified requirements. It is expected that home border routers are 17 allocated one or multiple IPv6 prefixes through DHCPv6 Prefix 18 Delegation (PD) or that prefixes are made available through other 19 means. An IPv4 address can also be assigned and private addresses be 20 used with NAT to provide IPv4 connectivity. In both cases, provided 21 prefixes need to be efficiently divided among the multiple links, and 22 routers need to obtain addresses. This document describes a 23 distributed algorithm for IPv4 and IPv6 prefixes division, assignment 24 and router's address assignment, and specifies how hosts can be given 25 addresses and configuration options using DHCP or SLAAC. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 27, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 63 3. Prefix and Address Assignment Algorithms' Outline . . . . . . 4 64 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Data structures . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Routers' Interfaces . . . . . . . . . . . . . . . . . . . 7 67 4.3. Obtaining a Delegated Prefix . . . . . . . . . . . . . . 7 68 4.4. Network Leader . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. Designated Router . . . . . . . . . . . . . . . . . . . . 8 70 4.5.1. Sending Router Advertisement . . . . . . . . . . . . 9 71 4.5.2. DHCP Server Operations . . . . . . . . . . . . . . . 9 72 4.6. Applying an Assignment on an Interface . . . . . . . . . 10 73 4.7. DNS Support . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Flooding Protocol Requirements . . . . . . . . . . . . . . . 11 75 5.1. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.2. Propagation Delay . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Flooding Assigned Prefixes . . . . . . . . . . . . . . . 12 78 5.4. Flooding Delegated Prefixes . . . . . . . . . . . . . . . 12 79 5.5. Flooding Routers' Address Assignments . . . . . . . . . . 12 80 6. Prefix Assignment Algorithm . . . . . . . . . . . . . . . . . 13 81 6.1. When to execute the Prefix Assignment Algorithm . . . . . 13 82 6.2. Assignment Precedence . . . . . . . . . . . . . . . . . . 14 83 6.3. Testing Assignment's validity . . . . . . . . . . . . . . 14 84 6.4. Testing Assignment's availability . . . . . . . . . . . . 14 85 6.5. Accepting an Assigned Prefix . . . . . . . . . . . . . . 14 86 6.6. Making a New Assignment . . . . . . . . . . . . . . . . . 15 87 6.7. Using Authoritative Prefix Assignments . . . . . . . . . 16 88 6.8. Choosing the Assignment's Priority . . . . . . . . . . . 17 89 6.9. Prefix Assignment Algorithm steps . . . . . . . . . . . . 17 90 6.10. Downstream DHCPv6 Prefix Delegation support . . . . . . . 18 91 7. Address Assignment Algorithm . . . . . . . . . . . . . . . . 19 92 7.1. Router's address pools . . . . . . . . . . . . . . . . . 20 93 7.2. Address Assignment Algorithm . . . . . . . . . . . . . . 20 94 8. Hysteresis Principle . . . . . . . . . . . . . . . . . . . . 21 95 8.1. Prefix and Address assignments . . . . . . . . . . . . . 21 96 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . 21 97 8.2.1. Unreliable uplink . . . . . . . . . . . . . . . . . . 21 98 8.2.2. Unreliable in-home link . . . . . . . . . . . . . . . 22 99 9. ULA and IPv4 Prefixes Generation . . . . . . . . . . . . . . 22 100 9.1. ULA Prefix Generation . . . . . . . . . . . . . . . . . . 22 101 9.1.1. Choosing the ULA prefix . . . . . . . . . . . . . . . 23 102 9.1.2. Advertising a ULA prefix . . . . . . . . . . . . . . 23 103 9.1.3. Extending prefix lifetime . . . . . . . . . . . . . . 24 104 9.1.4. Authoritative ULAs . . . . . . . . . . . . . . . . . 24 105 9.2. IPv4 Private Prefix Generation . . . . . . . . . . . . . 24 106 10. Manageability Considerations . . . . . . . . . . . . . . . . 24 107 11. Documents Constants . . . . . . . . . . . . . . . . . . . . . 25 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 111 13.2. Informative References . . . . . . . . . . . . . . . . . 27 112 Appendix A. Scarcity Avoidance Mechanism . . . . . . . . . . . . 28 113 A.1. Prefix Wasts Avoidance . . . . . . . . . . . . . . . . . 29 114 A.2. Increasing Assigned Prefix Length . . . . . . . . . . . . 30 115 A.3. Foreseeing Prefixes Exaustion . . . . . . . . . . . . . . 30 116 A.4. Cutting an Existing Assignment . . . . . . . . . . . . . 31 117 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 31 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Introduction 122 This memo describes a fully distributed prefix and address assignment 123 algorithm for home networks, running on top of any 'flooding 124 protocol' that fulfills the specified requirements. It is expected 125 that home border routers are allocated one or multiple IPv6 prefixes 126 through DHCPv6 Prefix Delegation (PD) [RFC3633] or that prefixes are 127 made available through other means. When an IPv4 address is 128 assigned, a home private IPv4 prefix may be used with NAT to provide 129 IPv4 connectivity to the whole home, as well as Unique Local Address 130 prefixes [RFC4193] may be used in order to provide internal 131 connectivity whenever global IPv6 connectivity is not available. 133 Obtained IPv6 or IPv4 prefixes need to be efficiently divided among 134 the multiple links. For the purposes of this document, we refer to 135 this process as prefix assignment. This memo describes an algorithm 136 for such prefix division, assignment and router's address assignment, 137 as well as the way hosts can be given addresses and configuration 138 options using DHCPv4 [RFC2131], DHCPv6 [RFC3315] or SLAAC [RFC4862]. 139 In the rest of this document DHCP refers to both DHCPv4 and DHCPv6. 141 Although this document recommends the use of 64 bits long prefixes, 142 the algorithm do not require routers to assign prefixes of particular 143 lengths. When a delegated prefix is too small considered the number 144 of links in the home network, higher priority links may be privileged 145 or smaller prefixes can be assigned in order to avoid prefix 146 scarcity. 148 The rest of this memo is organized as follows. Section 2 defines the 149 usual keywords, Section 3 outlines the algorithms functioning and 150 features, Section 4 describes how a home router behaves when running 151 the prefix and address assignment algorithm. Requirements for the 152 underlying flooding protocol are detailed in Section 5. The prefix 153 assignment algorithm is detailed in Section 6 and Section 7 focuses 154 on the address assignment algorithm. Section 8 explains the 155 hysteresis principles applied to both prefix and address assignments, 156 Section 9 specifies the procedures for automatic generation of ULA 157 and IPv4 prefixes, Section 10 explains what administrative interfaces 158 are useful for advanced users that wish to manually interact with the 159 mechanisms, Section 11 gives values for the constants used in this 160 document, Section 12 discusses the security aspects and finally, 161 Appendix A provides implementation guidelines for the optional 162 scarcity avoidance mechanism. 164 The Prefix Assignment Algorithm was first detailed in 165 [I-D.arkko-homenet-prefix-assignment]. This document is a 166 continuation and generalization of that draft to any underlying 167 flooding protocol. It also adds support for arbitrary prefix length, 168 IPv4, scarcity avoidance mechanism or manual configuration. 170 2. Requirements language 172 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 173 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 174 described in [RFC2119]. 176 3. Prefix and Address Assignment Algorithms' Outline 178 Given one or multiple prefixes for the entire network, each prefix is 179 subdivided by the prefix assignment algorithm so that every link is 180 given one assignment per available prefix. Assignments are 181 advertised through the whole network using the underlying flooding 182 protocol, collisions are detected and valid assignments are chosen 183 and applied on every link. Once a prefix is applied, hosts and 184 routers may be given addresses. In summary, the algorithm works in 185 four steps: 187 1. The home is given IPv6 or IPv4 prefixes called Delegated Prefixes 188 (DPs). 190 2. Each link is provided an Assigned Prefix (AP) from each available 191 Delegated Prefix. 193 3. Routers internally check for AP's validity and select Chosen 194 Prefixes (CPs). 196 4. Once a link is given an assignment, routers may get addresses 197 from specified address pools and hosts may be configured using 198 SLAAC or by the per-link elected DHCP server. 200 This algorithm, which intends to fulfill requirements specified in 201 [I-D.ietf-homenet-arch], has the following features: 203 o Each delegated prefix is effectively divided so that each link is 204 assigned a reasonable part. If the delegated prefix is too small 205 given the size of the network, prefixes of arbitrary lengths may 206 be used. 208 o The algorithm is completely distributed. Routers may join or 209 leave and DPs may be added or removed at any time. 211 o IPv4 connectivity is provided when a home router acquires an IPv4 212 address and default route from an external source. In this case a 213 private IPv4 delegated prefix is generated and prefixes are 214 assigned similarly to IPv6. 216 o The network may spontaneously generate and use a Unique Local 217 Address (ULA) prefix. 219 o Assignments are stable across reboots and some network changes 220 (e.g. adding or removing routers). 222 o DHCP options like DNS servers, prefix colors 223 [I-D.bhandari-dhc-class-based-prefix], or any upcoming options may 224 be attached to each prefix and may be relayed down to the host 225 when it is given addresses. 227 o The user can manually assign prefixes to links. Such assignments 228 will take precedence over automatically assigned prefixes. 230 o Assignments and interfaces can be given priorities. When a 231 delegated prefix is too small, such values may be used to 232 prioritize prefix assignment to certain links. 234 4. Router Behavior 236 All home routers participating in the prefix assignment algorithm 237 MUST fulfill the requirements defined in this document and use a 238 common flooding protocol and routing protocol. Classic CPE routers 239 [RFC7084] are supported as downstream routers and dowstream DHCPv6-PD 240 enabled routers are supported as both downstream and uplink routers, 241 but problems may occur when such router is connected to the home 242 network on both WAN and LAN side. In the later case, finer external 243 interface detection algorithm or static configuration can be used to 244 solve the issue, but these are out of the scope of this document. 246 4.1. Data structures 248 Each router MUST maintain a list of all the Delegated Prefixes. 249 These prefixes may be locally generated, as described in Section 4.3, 250 or come from other routers as described in Section 5.4. 252 Each router MUST maintain a list of all the Assigned Prefixes 253 advertised by other routers. Each AP is learnt through the 254 mechanisms described in Section 5.3 and is defined as a tuple of: 256 Prefix: The assigned prefix. 258 Router ID: The identifier of the advertising router. 260 Link ID: If the assignment is made on a connected link, an interface 261 identifier of the interface connected to that link. 263 Authoritative bit: A boolean that tells whether the assignment comes 264 from a network authority (DHCPv6 PD, manual configuration, 265 etc...). 267 Assignment's Priority: A value between PRIORITY_MIN and 268 PRIORITY_MAX, specifying the assignment's priority. 270 The AP list is the result of the information provided by the flooding 271 protocol, as specified in Section 5.3. 273 The router MUST maintain a list of all prefixes currently chosen to 274 be applied on connected links. They are Chosen Prefixes (CPs) and 275 described by a tuple of: 277 Prefix: The assigned prefix. 279 Link ID: An interface identifier of the interface connected to the 280 link on which the assignment is made. 282 Authoritative bit: A boolean that tells whether the assignment comes 283 from a network authority (DHCPv6 PD, manual configuration, 284 etc...). 286 Assignment's Priority: A value between PRIORITY_MIN and 287 PRIORITY_MAX, specifying the assignment's priority. 289 Advertised: Whether that assignment is being advertised by the 290 flooding protocol (see Section 5.3). 292 Applied: Whether that assignment is applied on link's configuration 293 (see Section 4.6). 295 Chosen Prefixes that are marked as 'Advertised' are distributed to 296 other routers using the flooding protocol and are therefore 297 considered as Assigned Prefixes by other routers. The goal of the 298 Prefix Assignment Algorithm is to ensure that all routers have a 299 consistent view of Assigned Prefixes on each link. 301 The router MUST maintain a database of its own address assignments, 302 and address assignments made by other routers on connected links as 303 learnt through means described in Section 5.5. 305 4.2. Routers' Interfaces 307 Each interface MUST either be considered as internal or external. 308 Prefixes and addresses are only assigned to internal interfaces. The 309 criteria to make this distinction are out of the scope of this 310 document. 312 If an internal interface becomes external, all prefixes and addresses 313 assigned on the considered interface MUST be deleted and no longer 314 announced, and the prefix assignment algorithm MUST be run. 316 If an external interface becomes internal, the prefix assignment 317 algorithm MUST be run (see Section 6.1). 319 Whenever two or more interfaces are connected to the same link, all 320 but one of them SHOULD be ignored by the prefix assignment algorithm. 321 A mechanism to detect such situation SHOULD be provided by the 322 flooding algorithm. 324 4.3. Obtaining a Delegated Prefix 326 Delegated Prefixes (Of any kind: Global, ULA, IPv4...) can be 327 obtained or generated through different means: 329 o It can be delegated by a service provider (DHCPv6 PD, 6rd 330 [RFC5969], etc..). 332 o It can be provisioned by an administrative authority (user 333 configuration, netconf [RFC6241], etc... ). 335 o A ULA prefix may be spontaneously generated as defined in 336 Section 9.1. 338 o An IPv4 private prefix may be spontaneously generated as defined 339 in Section 9.2. 341 DHCP options MAY be attached to a delegated prefix by the router that 342 either generated the prefix or received it through DHCPv6 PD. IPv6 343 delegated prefix options MUST be encoded as DHCPv6 options. IPv4 344 delegated prefix options MUST be encoded as DHCPv4 options. 346 As DHCP options are numerous and new ones may be defined, specifying 347 routers' behavior regarding each option is out of the scope of this 348 document. In order to avoid misconfiguration, routers must follow 349 the two following general rules: 351 o A router MUST NOT advertise a prefix obtained through DHCPv6 PD if 352 it doesn't understand the all of the provided options. 354 o A router MUST NOT make or accept any assignment associated to a 355 delegated prefix if it doesn't understand the all of the DHCP 356 options advertised with the delegated prefix. 358 The mif working group may provide useful inputs concerning the way 359 the home network should handle different prefixes associated with 360 heterogeneous uplinks. 362 4.4. Network Leader 364 A router considers itself as the Network Leader if and only if its 365 router ID is greater than all other router IDs in received Prefix 366 Assignments and Delegated Prefixes. 368 4.5. Designated Router 370 On a link where custom host configuration must be provided, or 371 whenever SLAAC cannot be used, a DHCP server must be elected. That 372 router is called designated router and is dynamically chosen by the 373 prefix assignment algorithm. 375 A router MUST consider itself designated router on a given link if 376 either one of the following conditions holds: 378 o The link's Assigned Prefixes list is empty. i.e. no other router 379 is advertising assignments on the considered link. And, if such 380 information is provided by the flooding protocol, the router has 381 the highest id on the link. 383 o Considering all APs and advertised CPs on the given link, the 384 router is advertising the one with: 386 1. The lowest authoritative bit. 388 2. In case of tie, the lowest priority. 390 3. In case of tie, the highest router ID. 392 Note: That particular order (inverted compared to assignments' 393 priority) is motivated by the few cases where a router may 394 override an existing assignment by advertising an assignment of 395 higher priority. In such a case, the designated router should 396 remain the same. 398 Example: A new router is powered on and connected to another 399 router that was already there (doing DHCP). It sees the 400 assigned prefix for their common link, but also has, in its own 401 configuration, an authoritative assignment for the link. It 402 starts advertising the authoritative assignment, which causes 403 the second router to remove its previous assignment. Thanks to 404 the inverted order, the DHCP server will remain the same. 406 4.5.1. Sending Router Advertisement 408 On a given link, the designated router MUST send router 409 advertisements (RAs) including Prefix Information Options for all the 410 Chosen Prefixes associated to that link. SLAAC SHOULD be enabled 411 when possible, unless the configuration states otherwise. Prefixes 412 valid and preferred lifetimes MUST be set to values lower or equal to 413 the associated Delegated Prefix's valid and preferred lifetimes. 415 Whenever an IPv6 default route is present in the RIB, the designated 416 router MUST advertise itself as default router by specifying a 417 strictly positive valid lifetime. Whenever the last default route is 418 removed, the designated router MUST send an RA with the valid and 419 preferred lifetimes set to zero. 421 The designated router MUST advertise itself as a router for all IPv6 422 delegated prefixes using Route Information Options [RFC4191], 423 independently of whether there is a default route or not. 425 4.5.2. DHCP Server Operations 427 On a given link, whenever SLAAC can't be used for all assignments, or 428 DHCP configuration options must be provided to hosts, the designated 429 router MUST act as a DHCP server and serve addresses on the given 430 link. A router MUST stop behaving as a DHCP server whenever it is 431 not the link's designated router anymore. 433 Routers's addresses pool, specified in Section 7, MUST be excluded 434 from DHCP hosts pools. 436 The valid and preferred lifetimes MUST be set to values lower or 437 equal to the associated Delegated Prefix's valid and preferred 438 lifetimes. 440 4.6. Applying an Assignment on an Interface 442 Once a Chosen Prefix is created, a router first waits some time in 443 order to detect possible collisions (Section 8). Afterwards and if 444 no collision is detected, the prefix is applied as follows: 446 o The router updates its interface configuration so that the prefix 447 is assigned to the considered link. 449 o The router updates the routing protocol configuration so that it 450 starts advertising the prefix. Depending on the implementation, 451 this step may not be needed as the routing protocol directly gets 452 its configuration information from the interfaces configuration. 454 o If necessary, the router starts selecting an address for itself as 455 defined in Section 7. 457 o If the router is the designated router on the considered link, it 458 starts sending the Prefix Information Option with the considered 459 prefix, as specified in Section 4.5.1. 461 o If the router is the designated router on the considered link and 462 if the prefix requires DHCP configuration, it starts behaving as a 463 DHCP server, as defined in Section 4.5.2, for the considered 464 assigned prefix. 466 When a prefix assignment is removed, the previous steps MUST be 467 undone. The router MUST also deprecate the prefix, if it had been 468 advertised in Router Advertisements on an interface. The prefix is 469 deprecated by sending Router Advertisements with the PIO's preferred 470 lifetime set to 0 [RFC4861]. Hosts that support DHCP reconfigure 471 extension ([RFC3203], [RFC3315]) and that have been given leases MUST 472 be reconfigured as well. 474 4.7. DNS Support 476 DHCP options attached to each delegated prefixes and propagated 477 through the flooding protocol SHOULD contain the DHCP DNS options 478 provided by the ISP (when provided). 480 Whenever the router knows which DNS server to use, or is acting as a 481 DNS relay, it SHOULD include DNS DHCP options ([RFC3646]) within 482 host's configuration messages and include the Router Advertisement 483 DNS options ([RFC6106]) when sending RAs. 485 DNS server selection in multi-homed networks is a complex issue that 486 this document doesn't intend to solve. One should look at IETF's mif 487 working-group documents in order to obtain guidelines concerning DNS 488 server selection. It is RECOMMENDED that designated routers turns on 489 a local DNS relay that fetches information from provided DNS servers. 491 5. Flooding Protocol Requirements 493 In this document, the Flooding Protocol (FP) refers to a protocol 494 enabling information propagation to the whole network. It was not 495 specified in order to allow the working group to independently decide 496 which routing protocol, configuration protocol, and prefix assignment 497 method to use within the home network. Routing protocol, like OSPFv3 498 [RFC5340] (With its autoconf extension 499 [I-D.ietf-ospf-ospfv3-autoconfig]) or IS-IS [RFC5308], could be 500 extended in order to fulfill the requirements. An independent 501 protocol, for instance HNCP [I-D.ietf-homenet-hncp], could be used as 502 well. 504 The specified algorithm can use any protocol that fulfills the 505 requirements specified in this section. 507 5.1. Router ID 509 The FP MUST provide a router ID. ID collisions within the network 510 MUST be rare and any conflicts MUST be resolved by the flooding 511 protocol. When the router ID is changed, the FP MUST immediately 512 provide the new ID to the Prefix Assignment Algorithm, which will in 513 turn be run again, without requiring the current state to be flushed. 515 In the absence of collisions, the router ID MUST NOT be changed, and 516 it SHOULD be stable across reboots, power cycling and router software 517 updates. 519 5.2. Propagation Delay 521 The FP MUST provide an approximate upper bound of the time it takes 522 for an update to be propagated to the whole network. This value is 523 referred to as the FLOODING_DELAY. The algorithm ensures that, as 524 long as the upper bound is respected, two identical prefixes will 525 never be applied to different links, and two different prefixes will 526 never be applied to the same link. The algorithm and the network 527 will recover when the upper bound is exceeded, but collisions may 528 appear in the routing protocol and errors may be propagated to upper 529 layers. 531 If the FP supports link-local flooding, which is used for router's 532 address assignments, it SHOULD provide an approximate upper bound of 533 the time it takes for an update to be propagated to a single link. 534 This value is referred to as the FLOODING_DELAY_LL. If link-local 535 flooding is not available, or the value is not provided, the 536 assignment algorithm MUST use the FLOODING_DELAY value instead. 538 5.3. Flooding Assigned Prefixes 540 The FP MUST provide a way to flood Chosen Prefixes marked as 541 advertised and retrieve prefixes assigned by other routers (APs). 542 Retrieved APs MUST contain all the information specified in 543 Section 4.1. 545 5.4. Flooding Delegated Prefixes 547 The FP must provide a way to flood Delegated Prefixes and retrieve 548 prefixes delegated to other routers. Retrieved entries must contain 549 the following information. 551 Prefix: The delegated prefix. 553 Router ID: The router ID of the router that is advertising the 554 delegated prefix. 556 Valid until: A time value, in absolute local time, specifying the 557 prefix validity time. 559 Preferred until: A time value, in absolute local time, specifying 560 the prefix preferred time. 562 DHCP information: DHCP options attached to the delegated prefix. 564 The FP MUST make sure time values are consistent throughout the 565 network (i.e. differences are small compared to Delegated Prefixes 566 lifetimes). If no time synchronization protocol is used, the FP MUST 567 keep track of prefix age across the network and within its database. 569 5.5. Flooding Routers' Address Assignments 571 Routers addresses are dynamically allocated, picked from a defined 572 pool, and collisions must be detected using the FP. The FP MUST 573 provide a way to flood routers' addresses. The flooding scope of 574 those values SHOULD be link-local, but as addresses are unique within 575 the home network, this is not mandatory. For each address 576 assignment, the FP SHOULD provide the identifier of the interface 577 connected to the link the address assignment was advertised on. 579 6. Prefix Assignment Algorithm 581 The Prefix Assignment Algorithm is a distributed algorithm that 582 assigns one prefix from each available Delegated Prefix on every link 583 that is considered to be internal by at least one connected router. 584 The algorithm itself does not distinguish between global IPv6, ULA or 585 IPv4 prefixes. IPv4 prefixes are encoded as their IPv4-mapped IPv6 586 form, as defined in [RFC4291] (i.e. ::ffff:A.B.C.D/X with X >= 96). 588 When the Prefix Assignment Algorithm is executed, combinations of 589 Delegated Prefixes and internal interfaces are being considered. For 590 the purpose of this discussion, the Delegated Prefix will be referred 591 to as the current Delegated Prefix, and the interface will be 592 referred to as the current Interface. If a delegated prefix is 593 included inside another delegated prefix, it is ignored. This rule 594 intends to ignore prefixes delegated from non-Homenet routers that 595 previously obtained their larger prefix from one of Homenet's 596 routers. 598 The algorithm is specified here for the sake of clarity. It can be 599 optimized in some cases. For instance Prefix Assignment deletion 600 might not need to trigger algorithm's execution if all internal 601 interfaces already have assignements associated to the same Delegated 602 Prefix. Similarly, when an ignored Delegated Prefix is deleted, it 603 is not necessary to run the algorithm. An implementation may work 604 differently than specified here as long as the resulting behavior is 605 identical to the behavior a router implementing this exact algorithm 606 would have. 608 6.1. When to execute the Prefix Assignment Algorithm 610 The algorithm MUST be run whenever one of the following event occurs: 612 o A Delegated Prefix is created or deleted (A DP must be deleted 613 when its lifetime is exceeded). 615 o A Prefix Assignment is created, deleted or modified. 617 o The router ID is modified. 619 o An external link becomes internal, or an internal link becomes 620 external. 622 It is not required that the algorithm is synchronously run each time 623 such an event occurs. But the delay between the event and the 624 algorithm execution MUST be small compared to FLOODING_DELAY. 626 6.2. Assignment Precedence 628 An assignment is said to take precedence over another assignment 629 when: 631 o The authoritative bit value is higher. 633 o In case of tie, the priority value is higher. 635 o In case of tie, the advertising router's ID is higher. 637 6.3. Testing Assignment's validity 639 An Assigned Prefix or a Chosen Prefix is said to be valid if all the 640 following conditions are met: 642 1. Its prefix is included in an advertised Delegated Prefix. 644 2. The prefix is not included or does not include any other Assigned 645 Prefix with a higher precedence. 647 3. No other assignment which prefix is included in the same 648 Delegated Prefix, and with a higher precedence, is being 649 advertised on the same link. 651 6.4. Testing Assignment's availability 653 A prefix is said to be available if it does not overlap with any 654 other assignment by any other router in the network. 656 6.5. Accepting an Assigned Prefix 658 An AP is said to be accepted when the AP is currently being 659 advertised by a different router on a directly connected link, and 660 will be used by the accepting router as a new Chosen Prefix. When a 661 router accepts a neighbor's assignment, it starts a timer as 662 specified in Section 8. A new CP is created from the AP, with: 664 o The same prefix. 666 o The same link ID. 668 o The authoritative bit set to false. 670 o The same priority. 672 o The advertised bit value set as specified by the algorithm. 674 o The applied bit is unset. It is set when the timer elapsed if the 675 entry still exists. 677 6.6. Making a New Assignment 679 In situations where a router can make an assignment (see 680 Section 6.9), the following rules are used in the following order: 682 1. If the configuration specifies a custom behavior (e.g. always 683 ignore/accept a particular delegated prefix), use the 684 configuration entry. 686 2. If the Delegated Prefix Preferred Lifetime is strictly greater 687 than zero, an assignment MUST be made. 689 3. If no other prefix has a non-zero Preferred Lifetime, and no 690 assignment is made on the link, an assignment SHOULD be made. 692 4. Otherwise, a new assignment SHOULD NOT be made. 694 When the algorithm decides to make a new assignment, it first needs 695 to specify the desired size of the assigned prefix. Although this 696 algorithm intends to remain generic, the use of 64 bits long prefixes 697 is RECOMMENDED (See [I-D.ietf-6man-why64]). The following table MAY 698 be used as default values, where X is the length of the delegated 699 prefix. 701 If X <= 64: Prefix length = 64 703 If X >= 64 and X < 104: Prefix length = X + 16 (up to 2^16 links) 705 If X >= 104 and X < 112: Prefix length = 120 (2^8 addresses per link 706 and more than 2^8 links) 708 If X >= 112 and X <= 128: Prefix length = 120 + (X - 112)/2 (Link Vs 709 Addresses tradeoff) 711 When the algorithm decides to make a new assignment, it SHOULD first 712 checks its stable storage for an available assignment that was 713 previously applied on the current interface and is part of the 714 current delegated prefix. If no available assignment can be found 715 that way, the new prefix MUST be randomly selected among a subset of 716 available prefixes (if possible, large enough to avoid collisions). 718 Hardware specific identifiers may be used to seed a pseudo-random 719 generator. 721 If no available prefix is found, the assignment fails. 723 The algorithm leaves much room for implementation specific policies. 724 For instance, static prefixes may be configured as specified in 725 Section 10. If implemented, the router MAY also decide to execute 726 the Prefix Scarcity Avoidance mechanisms, as proposed in Appendix A. 728 If an available prefix is found, a new assignment is made and a new 729 Chosen Prefix entry is created. 731 o The prefix value is set to the chosen prefix. 733 o The link ID is the ID of the link on which the assignment is made. 735 o The authoritative bit is set to false. 737 o The priority is set to a value between PRIORITY_AUTO_MIN and 738 PRIORITY_AUTO_MAX (Section 6.8). 740 o The advertised bit is set. 742 o The applied bit is unset. It is set when the timer elapsed if the 743 entry still exists. 745 A new assignment is always marked as advertised when created and 746 therefore immediately provided to the flooding protocol. 748 6.7. Using Authoritative Prefix Assignments 750 When some authority (Delegating router, system admin, etc...) wants 751 to manually enforce some behavior, it may ask some router to make an 752 Authoritative Prefix Assignment. Such assignments have their 753 Authoritative bit set, SHALL NOT be overridden, and will appear in 754 other router's database as Assigned Prefixes with the Authoritative 755 bit set. 757 There are two kinds of Authoritative Prefix Assignments. 759 o When an authority wants to assign some particular prefix to some 760 interface, an Authoritative Prefix Assignment MAY be created and 761 consists in a Chosen Prefix which have its Authoritative bit set 762 and which is advertised. Just like normal assignments, it MUST 763 NOT be applied before the delay specified in Section 8 elapsed. 765 o When an authority wants to prevent some prefix from being used, an 766 Authoritative Assignment MAY be advertised. Such assignments MUST 767 NOT be applied and MUST be advertised through the flooding 768 protocol as assigned to either no-interface, or a fake interface 769 (Depending on the flooding protocol's capabilities). 771 When a delegated prefix is obtained through DHCPv6 PD with a non- 772 empty excluded prefix, as specified in [RFC6603], an Authoritative 773 Prefix Assignment MUST be created with the excluded prefix. 775 Note: If the router doesn't understand the excluded prefix DHCPv6 776 option, the delegated prefix is ignored, as specified in 777 Section 4.3. 779 6.8. Choosing the Assignment's Priority 781 When either a new Prefix Assignment is made, or an Authoritative 782 Prefix Assignment is created, the creating router needs to choose 783 which priority value to use. The assignment priority is kept by the 784 designated router when it starts advertising the assignment, and is 785 useful when not enough prefixes are available. 787 o PRIORITY_DEFAULT SHOULD be used as default. 789 o Other values between PRIORITY_AUTO_MIN and PRIORITY_AUTO_MAX MAY 790 be dynamically chosen by the implementation. 792 o Other values between PRIORITY_AUTHORITY_MIN and 793 PRIORITY_AUTHORITY_MAX MUST NOT be used if not specified by an 794 authority (by static or dynamic configuration). 796 o Other values are reserved. 798 6.9. Prefix Assignment Algorithm steps 800 At the beginning of the algorithm, all assignments that do not have 801 their Authoritative bit set are marked as 'invalid', and the router 802 computes for each connected link whether it is the designated router, 803 as specified in Section 4.5. 805 The following steps are then executed for every combination of 806 delegated prefixes and interfaces. 808 o If the current interface is external, ignore that interface. 810 o If the Delegated Prefix is strictly included in another Delegated 811 Prefix, ignore that delegated prefix. 813 o If the Delegated Prefix is equal to another Delegated Prefix, 814 advertised by some router with an higher router ID than the 815 considered delegated prefix, ignore that delegated prefix. 817 o Look for a valid Assigned Prefix, advertised by another router on 818 the current interface and included in the current Delegated 819 Prefix. 821 o Look for a Chosen Prefix associated to the current interface and 822 included in the current Delegated Prefix. 824 o There are four possibilities at this stage. 826 1. If no AP is found, and no CP is found, a new assignment can be 827 made if and only if the router considers itself as the 828 designated router. Whether to create an assignment or not, 829 and which prefix to use, is specified in Section 6.6. 831 2. If an AP is found, and no CP is found, the AP MUST be 832 accepted. The new CP's advertised bit MUST be set if and only 833 if the router considers itself as the designated router. 835 3. If no AP is found, and a CP is found, the router MUST check if 836 the CP's assignment is valid. If it is, the local assignment 837 is marked as valid and advertised. If it isn't, it is 838 destroyed and the algorithm applies case 1. 840 4. If both an AP and a CP are found, the router must check if the 841 prefixes are the same. If they are different and if the CP's 842 Authoritative bit is not set, the CP MUST be deleted and the 843 algorithm applies case 2. If the prefixes are the same, the 844 CP must be updated with the AP's priority value, marked as 845 valid, and advertised if and only if the router considers 846 itself as designated on the link. 848 In the end all the assignments that are marked as invalid are 849 deleted. 851 6.10. Downstream DHCPv6 Prefix Delegation support 853 If some host or non-Homenet router asks for Delegated Prefixes, a 854 router MAY assign a set of prefixes and give them to the client. 855 Such assignments MUST be advertised as either not assigned on any 856 link, or assigned on a stub virtual link connected to the router, 857 depending on the Flooding Protocol capabilities. By default 858 assignments priorities MUST be between PRIORITY_AUTO_MIN and 859 PRIORITY_AUTO_MAX, SHOULD be lower than PRIORITY_DEFAULT, and the 860 authoritative bit MUST not be set. Whenever such an assignment 861 becomes invalid, DHCPv6 Reconfigure SHOULD be used in order to remove 862 the prefix from DHCPv6 DP client's lease. If DHCPv6 Reconfigure is 863 not supported, leases lifetimes SHOULD be significantly small. 865 Provided DPs' valid and preferred lifetimes MUST be lower or equal to 866 their associated Delegated Prefix's lifetimes, and associated DHCPv6 867 data SHOULD be provided to the DHCPv6 PD client. 869 By default, an assigned prefix SHOULD NOT be provided to a DHCPv6 PD 870 client before the apply timeout has elapsed. But in order to allow 871 faster response delay, a lease MAY first be provided with a lifetime 872 of 2*FLOODING_DELAY seconds, even if the private assignments' apply 873 timeout has not elapsed yet. 875 7. Address Assignment Algorithm 877 IPv6 routers always get at least one link-local address per link. 878 Routing protocols and link DHCP servers are able to run with these 879 addresses. In some cases though, a router may need to take one or 880 multiple addresses among one or multiple available Delegated 881 Prefixes. For example: 883 o The router needs connectivity to the internet (For management, NTP 884 synchronization, etc...). 886 o The router needs connectivity within the home network (For 887 management, DNS communications, etc...). 889 o IPv4 addresses are needed (DHCPv4, v4 link-local connectivity, 890 etc...). 892 When possible, SLAAC MUST be used. In other cases a different 893 mechanism is necessary for routers to get addresses. This document 894 proposes an Address Assignment Algorithm that extends the Prefix 895 Assignment Algorithm and works as follows. Each prefix assignment is 896 associated with a fixed address pool, reserved for router's addresses 897 assignment. The address pool is a prefix which value is 898 deterministically function of the assigned prefix. A router MAY, at 899 any time, decide to assign itself an address from any of its Chosen 900 Prefixes. Just like prefix assignments, address assignments are 901 advertised to other routers and collisions are detected. Routers 902 MUST keep track of Address Assignments made by other routers on 903 connected links by using information provided by the flooding 904 algorithm, as defined in Section 5.5. 906 7.1. Router's address pools 908 Given an assigned prefix A/X (where all A's latest '128 - X'th bits 909 are set to 0), the routers reserved address pool is defined as 910 follows: 912 If X <= 64: SLAAC MUST be used 914 If X > 64 and X <= 110: The pool is A/112 (2^16 addresses) 916 If X >= 110 and X <= 126: The pool is A/(X + 2) (One quarter of the 917 available addresses) 919 If X >= 126: Only the designated router MAY use A/128. Other 920 routers MUST NOT get an address. 922 In the case of IPv4 prefixes, the network address (first address of 923 the address pool) MUST not be used. 925 7.2. Address Assignment Algorithm 927 In this section, we say an address assignment is made by some router 928 when it intends to use, or is using the address specified by this 929 assignment. An assignment, made by some router, MUST be advertised 930 on the link on which the assignment is made. Similarly, an address 931 assignment is said to be applied when the address is pushed to the 932 router's interface configuration. It is unapplied otherwise. 934 Routers MUST store applied address assignments in their stable 935 storage and reuse the same addresses whenever possible. At least the 936 five previously applied addresses SHOULD be stored for each 937 interface. 939 For a given prefix assignment, an address is said to be available if 940 it is within the router's address pool associated to the prefix 941 assignment, and it is not being advertised by any other router. If 942 the flooding protocol provides interface identifier in the address 943 assignments, looking for collisions on considered link is enough. 945 A new address assignment MUST be chosen randomly among available 946 addresses. An address assignment MUST NOT be applied when one of the 947 following condition is true. 949 o The associated Chosen Prefix is not applied. 951 o The timer specified in Section 8 has not elapsed yet. 953 An address assignment must be deleted whenever one of the following 954 condition becomes true. 956 o The associated Chosen Prefix is deleted or moved to another link. 958 o Some other router with a higher router ID is advertising the same 959 address on the same link. 961 8. Hysteresis Principle 963 The IPv6 Stateless Address Autoconfiguration [RFC4862] states that 964 host addresses can be kept up to 2 hours after a Router Advertisement 965 wit zero lifetime is received. Therefore, routers must be carefull 966 before assigning or deprecating a prefix. 968 8.1. Prefix and Address assignments 970 When the flooding protocol is started, the router MUST wait 971 FLOODING_DELAY before executing the prefix assignment algorithm for 972 the first time. 974 Prefix and address assignment algorithms are distributed. Collisions 975 may occur, but network configuration, routing protocols or upper 976 layers should not suffer from these collisions. For this reason, all 977 assignments that could imply collisions are not immediately applied. 979 o A router MUST NOT apply a Chosen Prefix before it has waited 980 2*FLOODING_DELAY. If the entry is valid during the whole waiting 981 time, it MUST be applied to the link it is assigned. 983 o A router MUST NOT apply an Assigned Address before it has waited 984 2*FLOODING_DELAY_LL. If the assignment is valid during the whole 985 waiting time, it MUST be applied to the interface it is assigned. 987 8.2. Delegated Prefixes 989 Some links may be unreliable, causing repetitive connectivity loss. 990 Such links shouldn't cause IP reconfiguration. 992 8.2.1. Unreliable uplink 994 When a router detects uplink connectivity loss, Delegated Prefixes' 995 lifetimes from prefixes obtained through the uplink MUST be modified 996 in the following way. 998 o The Preferred Lifetime is set to 0. 1000 o The Valid Lifetime is set to the minimum between the current Valid 1001 Lifetime and two hours. 1003 o The default route associated with the prefix is not advertised 1004 anymore. 1006 This behavior is similar to [RFC7084] specifications and provides 1007 stable host configuration in case of unreliable uplink. 1009 8.2.2. Unreliable in-home link 1011 When a router stops advertising a Delegated Prefix, it MUST first 1012 deprecate that Delegated Prefix by advertising it for 1013 DP_DEPRECATE_FACTOR*FLOODING_DELAY seconds with zero valid and 1014 preferred lifetimes. 1016 When a router receives a deprecated Delegated Prefix advertisement 1017 from the Flooding Protocol, it MUST remove the Delegated Prefix from 1018 its Delegated Prefixes list. 1020 When a router stops receiving a Delegated Prefix from the Flooding 1021 Protocol, it SHOULD keep using that delegating prefix up to a period 1022 of min(remaining Valid Lifetime, DP_KEEP_ALIVE_TIME) seconds. 1024 9. ULA and IPv4 Prefixes Generation 1026 Although DHCPv6 PD and static configuration are regular means of 1027 obtaining IPv6 prefixes, routers MAY, in some cases, autonomously 1028 decide to generate a delegated prefix. In this section are specified 1029 when and how IPv6 ULA prefixes and IPv4 private prefixes may be 1030 autonomously generated. 1032 9.1. ULA Prefix Generation 1034 ULA prefixes can be randomly generated as specified in [RFC4193], 1035 enabling stable in-home IPv6 connectivity. 1037 In this section, we say a ULA delegated prefix is 'stable' if it has 1038 been the only advertised ULA delegated prefix for at least 1039 2*FLOODING_DELAY seconds. The behaviour specified in the following 1040 sections tend to reuse a stable ULA prefix as long as its preferred 1041 lifetime is not null. 1043 Additionaly, we say a router is the owner of a spontaneously 1044 generated ULA prefix if it randomly created the prefix in the first 1045 place. A router SHOULD NOT create more than one prefix this way, and 1046 MUST remember all the prefixes they own. As stated in the following 1047 sections, only the owner of a prefix can extend its lifetimes. 1049 9.1.1. Choosing the ULA prefix 1051 When a stable ULA prefix is advertised, all routers SHOULD remember 1052 that prefix alongwith its associated valid and preferred lifetime. 1053 If this prefix stops being advertised (e.g. due to a network split) 1054 while its preferred lifetime is not null, the same ULA prefix SHOULD 1055 be selected using the same valid and preferred lifetimes. 1057 If there was no stable ULA prefix advertised, or if the preferred 1058 lifetime of the prefix was null, a prefix generated as specified in 1059 [RFC4193] SHOULD be used. In case the stable storage can't be used 1060 or the current date cannot be determined, the prefix MAY be pseudo- 1061 randomly generated based on hardware specific values. 1063 9.1.2. Advertising a ULA prefix 1065 A router MAY start advertising a ULA prefix whenever the two 1066 following conditions are met: 1068 o It is the network leader. 1070 o There is no other advertised ULA prefix. 1072 If no IPv6 prefix is available at all, the network leader SHOULD 1073 start advertising a ULA delegated prefix. 1075 Additionaly, a router SHOULD start advertising its own ULA prefix 1076 whenever the three following conditions are met: 1078 o A stable ULA prefix is advertised by another router. 1080 o The router owns the advertised stable ULA prefix. 1082 o The preferred lifetime of the advertised ULA prefix is below 10 1083 minutes. 1085 This allows a router to restart advertising a owned prefix whenever 1086 the preferred lifetime is approaching zero. Which later allows him 1087 to extend the lifetime of the prefix. 1089 A router MUST stop advertising a spontaenously generated ULA prefix 1090 whenever one of the two following condition is met: 1092 o A different ULA prefix is being advertised. 1094 o The same prefix is advertised by another router, and the router 1095 doesn't own that prefix. 1097 9.1.3. Extending prefix lifetime 1099 Routers MUST regularly extend the valid and preferred lifetimes of 1100 the ULA delegated prefix they advertise and own, so that they never 1101 drop to zero. 1103 When a router advertises a prefix it doesn't own, lifetimes are never 1104 extended. When the preferred lifetime of the prefix approaches zero, 1105 either the owner of the prefix will start advertising the prefix with 1106 a non-zero preferred lifetime, or a new prefix will be generated. 1108 9.1.4. Authoritative ULAs 1110 This section doesn't prevent multiple ULA prefixes from existing 1111 simultaneously. ULA prefixes may be provided by different means, as 1112 specified in Section 4.3. Delegated prefixes that are delegated by a 1113 service provider or provisioned by an authority differ from 1114 'spontaneously' generated prefixes. They MUST NOT be withdrawn if 1115 another ULA delegated prefix is observed. 1117 When at least one of such ULA prefixes is used, spontaneously 1118 generated ULA prefixes are withdrawned. 1120 9.2. IPv4 Private Prefix Generation 1122 A router MAY generate an IPv4 prefix when the two following 1123 conditions are met. 1125 o It has an IPv4 address with global connectivity. 1127 o No other IPv4 delegated prefix is advertised by any other router. 1129 A router MUST stop advertising an IPv4 prefix whenever another router 1130 with an higher router ID is advertising an IPv4 Delegated Prefix. 1132 The IPv4 private prefix must be included in one of the private 1133 prefixes defined in [RFC1918]. The prefix 10/8 SHOULD be used by 1134 default but it SHOULD be configurable. In the case the address 1135 provided by the ISP is already a private address, a different private 1136 prefix SHOULD be used. For instance, if the ISP is giving the 1137 address 10.1.2.3, 10/8 or any sub-prefix included in 10/8 SHOULD NOT 1138 be used. (For instance, 172.16/12 or 192.168/16 can be selected). 1140 10. Manageability Considerations 1142 The algorithm leaves much room for implementation specific features. 1143 For instance, ULA prefix as well IPv4 prefix generation may be 1144 disabled whenever a global IPv6 is made available. This section 1145 details a few other possible configuration options. 1147 The implementation MAY allow each internal interface to be configured 1148 with a custom priority value. The specified priority SHOULD then be 1149 used when creating new assignments on the given interface. If not 1150 specified, the default priority SHOULD be used. 1152 The implementation SHOULD allow manual assignments on given links. 1153 When specified, and whenever such an assignment is valid, it MUST be 1154 advertised as Authoritative Assignments on the given interface. 1156 11. Documents Constants 1158 PRIORITY_MIN 0 1159 PRIORITY_AUTHORITY_MIN 4 1160 PRIORITY_AUTO_MIN 6 1161 PRIORITY_DEFAULT 8 1162 PRIORITY_AUTO_MAX 10 1163 PRIORITY_AUTHORITY_MAX 12 1164 PRIORITY_MAX 15 1166 DP_DEPRECATE_FACTOR 3 1167 DP_KEEP_ALIVE_TIME 60 seconds 1169 12. Security Considerations 1171 Prefix assignment algorithm security entirely relies on flooding 1172 protocol security features. The flooding protocol SHOULD therefore 1173 check for the authenticity of advertised information. Security modes 1174 may be classified in three categories. 1176 1. The flooding protocol is not protected. 1178 2. The flooding protocol's protection is binary: An allowed router 1179 may send any type of packets in the name of other routers. 1181 3. All advertised messages are individually signed by the sender. 1183 Whenever a malicious router attacks an unprotected network, or 1184 whenever a malicious router is able to authenticate itself to a 1185 network as stated in the second case, it may for example: 1187 o Prevent other routers to get a stable router ID. 1189 o Prevent other routers from making assignments by claiming the 1190 whole available address space. 1192 o Redirect traffic to some router on the network. 1194 If a malicious router is able to authenticate itself in a network 1195 protected as in the third case, most of the previously listed attacks 1196 may still be performed, but traffic could only be redirected toward 1197 the origination of the attack, and the source of the attack could be 1198 identified. 1200 In any case, in order to protect the network, the routing protocol as 1201 well as the way hosts are configured also needs to be protected, 1202 hence requiring other link (e.g. WPA) or IP layer (e.g. IPSec-Auth 1203 [RFC4302] or SeND [RFC3971]) security solutions. 1205 13. References 1207 13.1. Normative References 1209 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1210 E. Lear, "Address Allocation for Private Internets", BCP 1211 5, RFC 1918, February 1996. 1213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", BCP 14, RFC 2119, March 1997. 1216 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1217 2131, March 1997. 1219 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 1220 reconfigure extension", RFC 3203, December 2001. 1222 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1223 and M. Carney, "Dynamic Host Configuration Protocol for 1224 IPv6 (DHCPv6)", RFC 3315, July 2003. 1226 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1227 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1228 December 2003. 1230 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1231 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1232 December 2003. 1234 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1235 More-Specific Routes", RFC 4191, November 2005. 1237 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1238 Addresses", RFC 4193, October 2005. 1240 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1241 Architecture", RFC 4291, February 2006. 1243 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1244 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1245 September 2007. 1247 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1248 Address Autoconfiguration", RFC 4862, September 2007. 1250 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1251 "IPv6 Router Advertisement Options for DNS Configuration", 1252 RFC 6106, November 2010. 1254 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1255 "Prefix Exclude Option for DHCPv6-based Prefix 1256 Delegation", RFC 6603, May 2012. 1258 13.2. Informative References 1260 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1261 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1263 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 1264 2005. 1266 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1267 2008. 1269 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1270 for IPv6", RFC 5340, July 2008. 1272 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1273 Infrastructures (6rd) -- Protocol Specification", RFC 1274 5969, August 2010. 1276 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1277 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1278 6241, June 2011. 1280 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1281 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1282 November 2013. 1284 [I-D.ietf-homenet-arch] 1285 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1286 "IPv6 Home Networking Architecture Principles", draft- 1287 ietf-homenet-arch-11 (work in progress), October 2013. 1289 [I-D.ietf-homenet-hncp] 1290 Stenberg, M. and S. Barth, "Home Networking Control 1291 Protocol", draft-ietf-homenet-hncp-00 (work in progress), 1292 April 2014. 1294 [I-D.ietf-ospf-ospfv3-autoconfig] 1295 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1296 draft-ietf-ospf-ospfv3-autoconfig-06 (work in progress), 1297 February 2014. 1299 [I-D.ietf-6man-why64] 1300 Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 1301 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 1302 in IPv6 Addressing", draft-ietf-6man-why64-06 (work in 1303 progress), October 2014. 1305 [I-D.arkko-homenet-prefix-assignment] 1306 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1307 in a Home Network", draft-arkko-homenet-prefix- 1308 assignment-04 (work in progress), May 2013. 1310 [I-D.bhandari-dhc-class-based-prefix] 1311 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1312 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 1313 based prefix", draft-bhandari-dhc-class-based-prefix-05 1314 (work in progress), July 2013. 1316 [I-D.chelius-router-autoconf] 1317 Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for 1318 IPv6 router autoconfiguration", draft-chelius-router- 1319 autoconf-00 (work in progress), June 2002. 1321 [I-D.dimitri-zospf] 1322 Dimitrelis, A. and A. Williams, "Autoconfiguration of 1323 routers using a link state routing protocol", draft- 1324 dimitri-zospf-00 (work in progress), October 2002. 1326 Appendix A. Scarcity Avoidance Mechanism 1328 Although an ISP should provide enough addresses, an implementation 1329 must carefully manage the provided address space. First, when a new 1330 assignment is made, the prefix should be selected amongst a set of 1331 prefixes so that prefix waste is minimized. Then, a router may 1332 decide to execute procedures intended to avoid prefix scarcity. 1333 Different approaches are possible. This section intends to provide 1334 guidelines for such procedures. They are optional and are compatible 1335 with routers that only support basic requirements defined in this 1336 document. 1338 A.1. Prefix Wasts Avoidance 1340 Given a Delegated Prefix, different routers may try to assign 1341 prefixes of different lengths. Particularly, a non-homenet 1342 downstream router may ask for a delegated prefix of significant size, 1343 as specified in Section 8.2. Some other routers, like sensors, may 1344 also require small prefixes. When randomly selected, a few /80s may 1345 easily prevent the assignment of bigger prefixes. Small prefixes 1346 should therefore be selected in neighboring areas. 1348 For instance, given a delegated prefix 2001::/56 and an assigned 1349 prefix 2001::/64, the best prefix choice in order to reduce prefix 1350 space waste is 2001:0:0:1::/64. Other choices are then to be taken 1351 in 2001:0:0:2::/63, 2001:0:0:4::/62, 2001:0:0:8::/61, etc... 1353 Creating an efficient prefix selection algorithm may be challenging 1354 as it needs to fullfill somehow contradictory requirements: 1356 1. The prefix MUST be chosen amongst available prefixes, which 1357 implies that other routers may interfere with the process. 1359 2. The prefix MUST be chosen randomly in a subset of available 1360 prefixes. When possible, the subset must be big enough to avoid 1361 collisions. 1363 3. The prefix SHOULD be selected amongst prefixes that reduces the 1364 prefix space waste. 1366 4. The prefix SHOULD be selected pseudo-randomly. 1368 The following algorithm offers a satisfying tradeoff. Given a 1369 Delegated Prefix and the desired prefix length: 1371 1. Compute the minimal subset of available prefixes included in the 1372 Delegated Prefix. In the example given previously, the minimal 1373 subset was {2001:0:0:1::/64, 2001:0:0:2::/63, ..., 2001:0:0:80::/ 1374 57}. 1376 2. Compute the set of prefixes of desired length so that: 1378 * It contains exactly RANDOM_SUBSET_SIZE prefixes, or all the 1379 available prefixes if there are less than RANDOM_SUBSET_SIZE 1380 available prefixes. 1382 * Prefixes are picked in the prefixes from the minimal subset of 1383 available prefixes which lengths are the highest. 1385 * When multiple subsets are possible, privelege lexicographicaly 1386 lowest prefixes. 1388 If RANDOM_SUBSET_SIZE equals 10, the subset would be 1389 {2001:0:0:1::/64, 2 /64s in 2001:0:0:2::/63, 4 /64s in 1390 2001:0:0:4::/62, the 3 first /64s in 2001:0:0:8::/61}. 1392 3. First try PSEUDO_RANDOM_TENTATIVE pseudo-random prefixes, 1393 computed from the DP, with the given length, based on interface 1394 specific hardware values (For instance using values generated 1395 like HASH(MAC Address : Counter). The hash function doesn't need 1396 to be cryptographic). The first prefix amongst this set that 1397 also is in the set computed at step 2 is chosen. If no prefix is 1398 found, try next step. 1400 4. Choose a prefix randomly among prefixes in the subset computed at 1401 step 2. 1403 This algorithm, defined as a sequence of prefix sets computation, may 1404 seem algorithmicaly complex, but it can be efficiently implemented. 1405 The key element in order to do so is the ability to iterate 1406 efficiently over all the available prefixes. 1408 RANDOM_SUBSET_SIZE should provide sufficiently low collision 1409 probability. A value of 256 should be enough in most cases. 1410 PSEUDO_RANDOM_TENTATIVE is purely implementation dependent, but 1411 shouldn't be too high as the probability of finding an available 1412 prefix that way quickly decreases with the number of used prefixes. 1413 A value of 10 should be sufficient. 1415 A.2. Increasing Assigned Prefix Length 1417 When a new assignment can't be created, and if not forbidden by the 1418 router's configuration, the router MAY increase the size of the 1419 desired prefix. For instance, if an available /64 can't be found, 1420 the router may look for a /80. Nevertheless, this implies using 1421 DHCPv6 instead of SLAAC, which SHOULD be avoided. 1423 A.3. Foreseeing Prefixes Exaustion 1425 The previously proposed solution may be useful in some particular 1426 cases, but won't work when no more prefixes are available. A router 1427 MAY try to detect when default length prefixes are becoming rare. In 1428 such a situation, it MAY decide to allocate a longer prefix, part of 1429 an available shorter prefix. For instance, if A/64 is available, but 1430 there are not many other available /64, the router can try to 1431 allocate A/80. If the allocation doesn't raise any collision, this 1432 procedure will prevent A/64 from being used by other hosts, hence 1433 creating a large set of smaller available prefixes to be used. 1435 Such an allocation is considered dynamic. The Authoritative bit MUST 1436 NOT be set and the priority MUST be among values authorized as 1437 dynamically chosen in Section 6.8. 1439 When different prefixes lengths are being used, the random prefix 1440 selection MUST NOT be uniform among all possibilities. Instead, it 1441 SHOULD privilege prefixes contained in bigger prefixes that cannot be 1442 allocated. For instance, if 2001::/56 is the DP, and 2001:0:0:0:1::/ 1443 80 is an assigned prefix, other /80 should be randomly chosen in 1444 2001:0:0:0:1::/64 before being chosen in other /64s. 1446 A.4. Cutting an Existing Assignment 1448 When specifically required by an authority (configuration or DHCP), a 1449 router MAY decide to un-assign one of its own assignment, in order to 1450 cut it in smaller prefixes, or to send an overriding assignment in 1451 order to force the network to stop using a particular prefix. 1452 Because such a procedure may imply links reconfiguration, it SHOULD 1453 be avoided whenever possible. 1455 Such allocation are considered as required by an authority. The 1456 Authoritative bit MAY be set and the priority MUST be among values 1457 authorized as specified by an authority in Section 6.8. 1459 As an example, if a router can't find a /64 for a link that, with a 1460 high priority, must be given a /64, it chooses a prefix assigned by 1461 some other router, to another link, with a lower priority, and 1462 creates a new Chosen Prefix with a higher priority. The other router 1463 will be forced to remove its own assignment, hence making the new 1464 assignment valid. 1466 Appendix B. Acknowledgments 1468 This document is the continuation of the work being done in 1469 [I-D.arkko-homenet-prefix-assignment]. The authors would like to 1470 thank all the people that participated in the previous document's 1471 development as well as the present one. In particular, the authors 1472 would like to thank to Tim Chown, Fred Baker, Mark Townsley, Lorenzo 1473 Colitti, Ole Troan, Ray Bellis, Markus Stenberg, Wassim Haddad, Joel 1474 Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik 1475 Nordmark, Laurent Toutain, Ralph Droms, Acee Lindem and Steven Barth 1476 for interesting discussions in this problem space. The authors would 1477 also like to point out some past work in this space, such as those in 1478 [I-D.chelius-router-autoconf] or [I-D.dimitri-zospf]. 1480 Authors' Addresses 1482 Pierre Pfister 1483 Cisco Systems 1484 Paris 1485 France 1487 Email: pierre.pfister@darou.fr 1489 Benjamin Paterson 1490 Cisco Systems 1491 Paris 1492 France 1494 Email: benjamin@paterson.fr 1496 Jari Arkko 1497 Ericsson 1498 Jorvas 02420 1499 Finland 1501 Email: jari.arkko@piuha.net