idnits 2.17.1 draft-ietf-homenet-prefix-assignment-05.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 (April 8, 2015) is 3298 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 informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: October 10, 2015 J. Arkko 6 Ericsson 7 April 8, 2015 9 Distributed Prefix Assignment Algorithm 10 draft-ietf-homenet-prefix-assignment-05 12 Abstract 14 This document specifies a distributed algorithm for automatic prefix 15 assignment. Given a set of delegated prefixes, it ensures that at 16 most one prefix is assigned from each delegated prefix to each link. 17 Nodes may assign available prefixes to the links they are directly 18 connected to, or for other private purposes. The algorithm 19 eventually converges and ensures that all assigned prefixes do not 20 overlap. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Applicability statement . . . . . . . . . . . . . . . . . . . 5 59 4. Algorithm Specification . . . . . . . . . . . . . . . . . . . 6 60 4.1. Algorithm Terminology . . . . . . . . . . . . . . . . . . 6 61 4.2. Prefix Assignment Algorithm Routine . . . . . . . . . . . 7 62 4.3. Overriding and Destroying Existing Assignments . . . . . 10 63 4.4. Other Events . . . . . . . . . . . . . . . . . . . . . . 11 64 5. Prefix Selection Considerations . . . . . . . . . . . . . . . 12 65 6. Implementation Capabilities and Node Behavior . . . . . . . . 14 66 7. Algorithm Parameters . . . . . . . . . . . . . . . . . . . . 15 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 72 11.2. Informative References . . . . . . . . . . . . . . . . . 17 73 Appendix A. Static Configuration Example . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 This document specifies a distributed algorithm for automatic prefix 79 assignment. Given a set of delegated prefixes, nodes may assign 80 available prefixes to links they are directly connected to, or for 81 their private use. The algorithm ensures that the following 82 assertions are eventually true: 84 1. At most one prefix from each delegated prefix is assigned to each 85 link. 87 2. Assigned prefixes are not included in and do not include other 88 assigned prefixes. 90 3. Assigned prefixes do not change in the absence of topology or 91 configuration changes. 93 In the rest of this document the two first conditions are referred to 94 as the correctness conditions of the algorithm while the third 95 condition is referred to as its convergence condition. 97 Each assignment has a priority specified by the node making the 98 assignment, allowing for more advanced assignment policies. When 99 multiple nodes assign different prefixes from the same delegated 100 prefix to the same link, or when multiple nodes assign overlapping 101 prefixes, the assignment with the highest priority is kept and other 102 assignments are removed. 104 The prefix assignment algorithm requires that participating nodes 105 share information through a flooding mechanism. If the flooding 106 mechanism ensures that all messages are propagated to all nodes 107 faster than a given timing upper bound, the algorithm also ensures 108 that all assigned prefixes used for networking operations (e.g., host 109 configuration) remain unchanged, unless another node assigns an 110 overlapping prefix with a higher assignment priority, or the topology 111 changes and renumbering cannot be avoided. 113 2. Terminology 115 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 116 and "SHOULD", are to be interpreted as described in [RFC2119]. 118 This document makes use of the following terminology: 120 Node: An entity executing the algorithm specified in this document 121 and able to communicate with other nodes using the Flooding 122 Mechanism. 124 Link: An object the distributed algorithm will assign prefixes to. 125 A Node may only assign prefixes to Links it is directly connected 126 to. A Link is either Shared or Private. 128 Private Link: A Private Link is an abstract concept defined for the 129 sake of this document. It allows nodes to make assignments for 130 their private use or delegation. For instance, every DHCPv6-PD 131 [RFC3633] requesting router MAY be considered as a different 132 Private Link. 134 Shared Link: A Link multiple nodes may be connected to. Most of 135 the time, a Shared Link is a multi-access link or point-to-point 136 link, virtual or physical, requiring prefixes to be assigned to 137 it. 139 Delegated Prefix: A prefix provided to the algorithm and used as a 140 prefix pool for Assigned Prefixes. 142 Node ID: A value identifying a given participating node. The set 143 of identifiers MUST be strictly and totally ordered (e.g., using 144 the alphanumeric order). 146 Flooding Mechanism: A mechanism allowing participating nodes to 147 reliably share information with all other participating nodes. 149 Flooding Delay: Value which SHOULD be provided by the Flooding 150 Mechanism indicating a deterministic or likely upper bound of the 151 information propagation delay. When the Flooding Mechanism does 152 not provide a value, it is set to DEFAULT_FLOODING_DELAY 153 (Section 7). 155 Advertised Prefix: A prefix advertised by another node and 156 delivered to the local node by the Flooding Mechanism. It has an 157 Advertised Prefix Priority and, when assigned to a directly 158 connected Shared Link, is associated with a Shared Link. 160 Advertised Prefix Priority: A value that defines the priority of an 161 Advertised Prefix received from the Flooding Mechanism or a 162 published Assigned Prefix. Whenever multiple Advertised Prefixes 163 are conflicting, all Advertised Prefixes but the one with the 164 greatest priority will eventually be removed. In case of tie, the 165 assignment advertised by the node with the greatest Node ID is 166 kept and others are removed. In order to ensure convergence, the 167 range of priority values MUST have an upper bound. 169 Assigned Prefix: A prefix included in a Delegated Prefix and 170 assigned to a Shared or Private Link. It represents a local 171 decision to assign a given prefix from a given Delegated Prefix to 172 a given Link. The algorithm ensures that there never is more than 173 one Assigned Prefix per Delegated Prefix and Link pair. When 174 destroyed, an Assigned Prefix is set as not applied, ceases to be 175 advertised, and is removed from the set of Assigned Prefixes. 177 Applied (Assigned Prefix): When an Assigned Prefix is applied, it 178 MAY be used (e.g., for host configuration, routing protocol 179 configuration, prefix delegation). When not applied, it MUST NOT 180 be used for any other purposes than the prefix assignment 181 algorithm. Each Assigned Prefix is associated with a timer (Apply 182 Timer) used to apply the Assigned Prefix. An Assigned Prefix is 183 unapplied when destroyed. 185 Published (Assigned Prefix): The Assigned Prefix is advertised 186 through the Flooding Mechanism as assigned to its associated Link. 187 A published Assigned Prefix MUST have an Advertised Prefix 188 Priority. It will appear as an Advertised Prefix to other nodes, 189 once received through the Flooding Mechanism. 191 Prefix Adoption: When an Advertised Prefix which does not conflict 192 with any other Advertised Prefix or published Assigned Prefix 193 stops being advertised, any other node connected to the same Link 194 MAY, after some random delay, start advertising the same prefix. 195 This procedure is called adoption and provides seamless assignment 196 transfer from a node to another, e.g., in case of node failure. 198 Backoff Timer: Every Delegated Prefix and Link pair is associated 199 with a timer counting down to zero. It is used to avoid multiple 200 nodes from making colliding assignments by delaying the creation 201 of new Assigned Prefixes or the advertisement of adopted Assigned 202 Prefixes by a random amount of time. 204 Renumbering: Event occurring when an Assigned Prefix which was 205 applied is destroyed. It is undesirable as it usually implies 206 reconfiguring routers or hosts. 208 3. Applicability statement 210 Each node MUST have a set of disjoint Delegated Prefixes (i.e., which 211 do not include each other). This set MAY change over time and be 212 different from one node to another at some point, but nodes MUST 213 eventually have the same set of disjoint Delegated Prefixes. 215 Given this set of disjoint Delegated Prefixes, nodes may assign 216 available prefixes from each Delegated Prefix to the Links they are 217 directly connected to. The algorithm ensures that at most one prefix 218 from a given Delegated Prefix is assigned to a given Link. 220 The algorithm can be applied to any address space and can be used to 221 manage multiple address spaces simultaneously. For instance, an 222 implementation can make use of IPv4-mapped IPv6 addresses [RFC4291] 223 in order to manage both IPv4 and IPv6 prefix assignment using a 224 single prefix space. 226 The algorithm supports dynamically changing topologies: 228 o Nodes may join or leave the set of participating nodes. 230 o Nodes may join or leave Links. 232 o Links may be joined or split. 234 All nodes MUST run a common Flooding Mechanism in order to share 235 published Assigned Prefixes. The set of participating nodes is 236 defined as the set of nodes participating in the Flooding Mechanism. 238 The Flooding Mechanism MUST: 240 o Provide a way to flood Assigned Prefixes assigned to a directly 241 connected Link along with their respective Advertised Prefix 242 Priority and the Node ID of the node which advertises it. 244 o Specify whether an Advertised Prefix was assigned to a directly 245 connected Shared Link, and if so, on which one. 247 In addition, a Flooding Delay SHOULD be specified and respected in 248 order to avoid renumbering. If not specified, or whenever the 249 Flooding Mechanism is unable to respect the provided delay, 250 renumbering may happen. As such delay often depends on the size of 251 the network, it MAY change over time and MAY be different from one 252 node to another. 254 The algorithm ensures that whenever the Flooding Delay is provided 255 and respected, and in the absence of topology change or Delegated 256 Prefix removal, renumbering only happens when a node deliberately 257 overrides an existing assignment. 259 Each node MUST have a Node ID. Node IDs MAY change over time and be 260 the same on multiple nodes at some point, but each node MUST 261 eventually have a Node ID which is unique among the set of 262 participating nodes. 264 4. Algorithm Specification 266 This section specifies the behavior of nodes implementing the prefix 267 assignment algorithm. 269 4.1. Algorithm Terminology 271 The algorithm makes use of the following terms: 273 Current Assignment: For a given Delegated Prefix and Link, the 274 Current Assignment is the Assigned Prefix (if any) included in the 275 Delegated Prefix and assigned to the given Link by the node 276 executing the algorithm. At some point in time, Current 277 Assignment from different nodes may differ, but the algorithm 278 ensures that eventually, all nodes directly connected to a Shared 279 Link have the same Current Assignment for any given Delegated 280 Prefix. 282 Precedence: An Advertised Prefix takes precedence over an Assigned 283 Prefix if and only if one of the following conditions is met: 285 * The Assigned Prefix is not published. 287 * The Assigned Prefix is published and the Advertised Prefix 288 Priority from the Advertised Prefix is strictly greater than 289 the Advertised Prefix Priority from the Assigned Prefix. 291 * The Assigned Prefix is published, the priorities are identical, 292 and the Node ID from the node advertising the Advertised Prefix 293 is strictly greater than the local Node ID. 295 Best Assignment: For a given Delegated Prefix and Link, the Best 296 Assignment is the Advertised Prefix (if any): 298 * Including or included in the Delegated Prefix. 300 * Assigned on the given Link. 302 * Having the greatest Advertised Prefix Priority among Advertised 303 Prefixes fulfilling the two preceding conditions (and, in case 304 of tie, the prefix advertised by the node with the greatest 305 Node ID among all prefixes with greatest priority). 307 * Taking precedence over the Current Assignment associated with 308 the same Link and Delegated Prefix (if any). 310 Valid (Assigned Prefix): An Assigned Prefix is valid if and only if 311 the two following conditions are met: 313 * No Advertised Prefix including or included in the Assigned 314 Prefix takes precedence over the Assigned Prefix. 316 * No Advertised Prefix including or included in the same 317 Delegated Prefix as the Assigned Prefix and assigned to the 318 same Link takes precedence over the Assigned Prefix. 320 4.2. Prefix Assignment Algorithm Routine 322 This section specifies the prefix assignment algorithm routine. It 323 is defined for a given Delegated Prefix and Link pair and may be run 324 either as triggered by the Backoff Timer or as triggered by another 325 event. 327 For a given Delegated Prefix and Link pair, the routine MUST be run 328 as not triggered by the Backoff Timer whenever: 330 o An Advertised Prefix including or included in the considered 331 Delegated Prefix is added or removed. 333 o An Assigned Prefix included in the considered Delegated Prefix and 334 associated with a different Link than the considered Link was 335 destroyed, while there is no Current Assignment associated with 336 the given pair. This case MAY be ignored if the creation of a new 337 Assigned Prefix associated with the considered pair is not 338 desired. 340 o The considered Delegated Prefix is added. 342 o The considered Link is added. 344 o The Node ID is modified. 346 Additionally, for a given Delegated Prefix and Link pair, the routine 347 MUST be run as triggered by the Backoff Timer whenever: 349 o The Backoff Timer associated with the considered Delegated Prefix 350 and Link pair fires while there is no Current Assignment 351 associated with the given pair. 353 When such an event occurs, a node MAY delay the execution of the 354 routine instead of executing it immediately, e.g. while receiving an 355 update from the Flooding Mechanism, or for security reasons (see 356 Section 8). Even though other events occur in the meantime, the 357 routine MUST be run only once. It is also assumed that, whenever one 358 of these events is the Backoff Timer firing, the routine is executed 359 as triggered by the Backoff Timer. 361 In order to execute the routine for a given Delegated Prefix and Link 362 pair, first look for the Best Assignment and Current Assignment 363 associated with the Delegated Prefix and Link pair, then execute the 364 corresponding case: 366 1. If there is no Best Assignment and no Current Assignment: Decide 367 whether the creation of a new assignment for the given Delegated 368 Prefix and Link pair is desired (As any result would be valid, 369 the way the decision is made is out of the scope of this 370 document) and do the following: 372 * If it is not desired, stop the execution of the routine. 374 * Else if the Backoff Timer is running, stop the execution of 375 the routine. 377 * Else if the routine was not executed as triggered by the 378 Backoff Timer, set the Backoff Timer to some random delay 379 between ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY (see Section 7) 380 and stop the execution of the routine. 382 * Else, continue the execution of the routine. 384 Select a prefix for the new assignment (see Section 5 for 385 guidance regarding prefix selection). This prefix MUST be 386 included in or be equal to the considered Delegated Prefix and 387 MUST NOT include or be included in any Advertised Prefix. If a 388 suitable prefix is found, use it to create a new Assigned Prefix: 390 * Assigned to the considered Link. 392 * Not applied. 394 * The Apply Timer set to '2 * Flooding Delay'. 396 * Published with some selected Advertised Prefix Priority. 398 2. If there is a Best Assignment but no Current Assignment: Cancel 399 the Backoff Timer and use the prefix from the Best Assignment to 400 create a new Assigned Prefix: 402 * Assigned to the considered Link. 404 * Not applied. 406 * The Apply Timer set to '2 * Flooding Delay'. 408 * Not published. 410 3. If there is a Current Assignment but no Best Assignment: 412 * If the Current Assignment is not valid, destroy it, and 413 execute the routine again, as not triggered by the Backoff 414 Timer. 416 * If the Current Assignment is valid and published, stop the 417 execution of the routine. 419 * If the Current Assignment is valid and not published, the node 420 MUST either: 422 + Adopt the prefix by cancelling the Apply Timer and set the 423 Backoff Timer to some random delay between 0 and 424 ADOPT_MAX_DELAY (see Section 7). This procedure is used to 425 avoid renumbering when the node advertising the prefix left 426 the Shared Link. 428 + Destroy it and go to case 1. 430 4. If there is a Current Assignment and a Best Assignment: 432 * Cancel the Backoff Timer. 434 * If the two prefixes are identical, set the Current Assignment 435 as not published. If the Current Assignment is not applied 436 and the Apply Timer is not set, set the Apply Timer to '2 * 437 Flooding Delay'. 439 * If the two prefixes are not identical, destroy the Current 440 Assignment and go to case 2. 442 When the prefix assignment algorithm routine requires an assignment 443 to be created or adopted, any Advertised Prefix Priority value can be 444 used. Other documents MAY provide restrictions over this value 445 depending on the context the algorithm is operating in, or leave it 446 as implementation-specific. 448 When the prefix assignment algorithm routine requires an assignment 449 to be created or adopted, the chosen Advertised Prefix Priority is 450 unspecified (any value would be valid). The values to be used in 451 such situations MAY be specified by other documents making use of the 452 prefix assignment algorithm or be left as an implementation specific 453 choice. 455 4.3. Overriding and Destroying Existing Assignments 457 In addition to the behaviors specified in Section 4.2, the following 458 procedures MAY be used in order to provide more advanced behavior 459 (Section 6): 461 Overriding Existing Assignments: For any given Link and Delegated 462 Prefix, a node MAY create a new Assigned Prefix using a chosen 463 prefix and Advertised Prefix Priority such that: 465 * The chosen prefix is included in or is equal to the considered 466 Delegated Prefix. 468 * The Current Assignment, if any, as well as all existing 469 Assigned Prefixes which include or are included inside the 470 chosen prefix, are destroyed. 472 * It is not applied. 474 * The Apply Timer set to '2 * Flooding Delay'. 476 * It is published. 478 * The Advertised Prefix Priority is greater than the Advertised 479 Prefix Priority from all Advertised Prefixes which include or 480 are included in the chosen prefix. 482 * The Advertised Prefix Priority is greater than the Advertised 483 Prefix Priority from all Advertised Prefixes which include or 484 are included in the considered Delegated Prefix and are 485 assigned to the considered Link. 487 In order to ensure algorithm convergence: 489 * Such overriding assignments MUST NOT be created unless there 490 was a change in the node configuration, a Link was added, or an 491 Advertised Prefix was added or removed. 493 * The chosen Advertised Prefix Priority for the new Assigned 494 Prefix SHOULD be greater than all priorities from the destroyed 495 Assigned Prefixes. If not, simple topologies with only two 496 nodes may not converge. Nodes which do not respect this rule 497 MUST implement a mechanism which detects whether the 498 distributed algorithm do not converge and, whenever this would 499 happen, stop creating overriding Assigned Prefixes which do not 500 hold this rule. The specifications for such safety procedures 501 are out of the scope of this document. 503 Removing an Assigned Prefix: A node MAY destroy any Assigned Prefix 504 which is published. Such an event reflects the desire from a node 505 to not assign a prefix from a given Delegated Prefix to a given 506 Link anymore. In order to ensure algorithm convergence, such 507 procedure MUST NOT be executed unless there was a change in the 508 node configuration. Additionally, whenever an Assigned Prefix is 509 destroyed this way, the prefix assignment algorithm routine MUST 510 be run for the Delegated Prefix and Link pair associated with the 511 deleted Assigned Prefix. 513 These procedures are OPTIONAL. They could be used for various 514 purposes, e.g., for providing custom prefix assignment configuration 515 or reacting to prefix space exhaustion (by overriding short Assigned 516 Prefixes and assigning longer ones). 518 4.4. Other Events 520 When the Apply Timer fires, the associated Assigned Prefix MUST be 521 applied. 523 When the Backoff Timer associated with a given Delegated Prefix and 524 Link pair fires while there is a Current Assignment associated with 525 the same pair, the Current Assignment MUST be published with some 526 associated Advertised Prefix Priority and, if the prefix is not 527 applied, the Apply Timer MUST be set to '2 * Flooding Delay'. 529 When a Delegated Prefix is removed from the set of Delegated 530 Prefixes, all Assigned Prefixes included in the removed Delegated 531 Prefix MUST be destroyed. 533 When one Delegated Prefix is replaced by another one that includes or 534 is included in the deleted Delegated Prefix, all Assigned Prefixes 535 which were included in the deleted Delegated Prefix but are not 536 included in the added Delegated Prefix MUST be destroyed. Others MAY 537 be kept. 539 When a Link is removed, all Assigned Prefixes assigned to that Link 540 MUST be destroyed. 542 5. Prefix Selection Considerations 544 When the prefix assignment algorithm routine specified in Section 4.2 545 requires a new prefix to be selected, the prefix MUST be selected 546 either: 548 o Among prefixes included in the considered Delegated Prefix which 549 were previously assigned and applied on the considered Link. For 550 that purpose, Applied Prefixes may be stored in stable storage 551 along with their associated Link. 553 o Randomly, picked in a set of at least RANDOM_SET_SIZE (see 554 Section 7) prefixes included in the considered Delegated Prefix 555 and not including or included in any Assigned or Advertised 556 Prefix. If less than RANDOM_SET_SIZE candidates are found, the 557 prefix MUST be picked among all candidates. 559 o Based on some custom selection process specified in the 560 configuration. 562 A simple implementation MAY randomly pick the prefix among all 563 available prefixes, but this strategy is inefficient in terms of 564 address space use as a few long prefixes may exhaust the pool of 565 available short prefixes. 567 The rest of this section describes a more efficient approach which 568 MAY be applied any time a node needs to pick a prefix for a new 569 assignment. The two following definitions are used: 571 Available prefix: The prefix A/N is available if and only if it 572 holds the three following conditions: 574 * It is included in the considered Delegated Prefix. 576 * It does not include and is not included in any Assigned or 577 Advertised Prefix but 579 * It is equal to the considered Delegated Prefix or A/(N-1) 580 includes an Assigned or Advertised Prefix. 582 Candidate prefix: A prefix of desired length which is included in 583 or is equal to an available prefix. 585 The procedure described in this section takes the three following 586 criteria into account: 588 Stability: In some cases, it is desirable that the selected prefix 589 remains the same across executions and reboots. For this purpose, 590 prefixes previously applied on the Link or pseudo-random prefixes 591 generated based on node and Link specific values may be 592 considered. 594 Randomness: When no stored or pseudo-random prefix is chosen, a 595 prefix may be randomly picked among RANDOM_SET_SIZE candidates of 596 desired length. If less than RANDOM_SET_SIZE candidates can be 597 found, the prefix is picked among all candidates. 599 Addressing-space usage efficiency: In the process of assigning 600 prefixes, a small set of badly chosen long prefixes may prevent 601 any shorter prefix from being assigned. For this reason, the set 602 of RANDOM_SET_SIZE candidates is created from available prefixes 603 with longest prefix lengths and, in case of tie, preferring small 604 prefix values. 606 When executing the procedure, do as follows: 608 1. For each prefix stored in stable storage, check if the prefix is 609 included in or equal to an available prefix. If so, pick that 610 prefix and stop. 612 2. For each prefix length, count the number of available prefixes of 613 the given length. 615 3. If the desired prefix length was not specified, select one. The 616 available prefixes count computed previously may be used to help 617 picking a prefix length such that: 619 * There is at least one candidate prefix. 621 * The prefix length is chosen great enough to not exhaust the 622 address space. 624 Let N be the chosen prefix length. 626 4. Iterate over available prefixes starting with prefixes of length 627 N down to length 0 and create a set of RANDOM_SET_SIZE candidate 628 prefixes of length exactly N included in or equal to available 629 prefixes. The end goal here is to create a set of 630 RANDOM_SET_SIZE candidate prefixes of length N included in a set 631 of available prefixes of maximized prefix length. In case of a 632 tie, smaller prefix values (as defined by the bit-wise 633 lexicographical order) are preferred. 635 5. Generate a set of prefixes of desired length, which are pseudo- 636 randomly chosen based on Node and Link specific values. For each 637 pseudo-random prefix, check if the prefix is equal to a candidate 638 prefix. If so, pick that prefix and stop. 640 6. Choose a random prefix from the set of selected candidates. 642 The complexity of this procedure is equivalent to the complexity of 643 iterating over available prefixes. Such operation may be 644 accomplished in linear time, e.g., by storing Advertised and Assigned 645 Prefixes in a binary trie. 647 6. Implementation Capabilities and Node Behavior 649 Implementations of the prefix assignment algorithm may vary from very 650 basic to highly customizable, enabling different types of fully 651 interoperable behaviors. The three following behaviors are given as 652 examples: 654 Listener: The node only acts upon assignments made by other nodes, 655 i.e, it never creates new assignments nor adopts existing ones. 656 Such behavior does not require the implementation of the 657 considerations specified in Section 5 or Section 4.3. The node 658 never checks existing assignments validity, which makes this 659 behavior particularly suited to lightweight devices which can rely 660 on more capable neighbors to make assignments on directly 661 connected Shared Links. 663 Basic: The node is capable of assigning new prefixes or adopting 664 prefixes which do not conflict with any other existing assignment. 665 Such behavior does not require the implementation of the 666 considerations specified in Section 4.3. It is suited to 667 situations where there is no preference over which prefix should 668 be assigned to which Link, and there is no priority between 669 different Links. 671 Advanced: The node is capable of assigning new prefixes, adopting 672 existing ones, making overriding assignments and destroying 673 existing ones. Such behavior requires the implementation of the 674 considerations specified in Section 5 and Section 4.3. It is 675 suited when the administrator desires some particular prefix to be 676 assigned on a given Link, or some Links to be assigned prefixes 677 with a greater priority. 679 7. Algorithm Parameters 681 This document does not provide values for ADOPT_MAX_DELAY, 682 BACKOFF_MAX_DELAY and RANDOM_SET_SIZE. The algorithm ensures 683 convergence and correctness for any chosen values, even when these 684 are different from node to node. They MAY be adjusted depending on 685 the context, providing a tradeoff between convergence time, efficient 686 addressing, low verbosity (less traffic is generated by the Flooding 687 Mechanism), and low collision probability. 689 ADOPT_MAX_DELAY (respectively BACKOFF_MAX_DELAY) represents the 690 maximum backoff time a node may wait before adopting an assignment 691 (respectively making a new assignment). BACKOFF_MAX_DELAY MUST be 692 greater than or equal to ADOPT_MAX_DELAY. The greater 693 ADOPT_MAX_DELAY and (BACKOFF_MAX_DELAY - ADOPT_MAX_DELAY), the lower 694 the collision probability and the verbosity, but the greater the 695 convergence time. 697 RANDOM_SET_SIZE represents the desired size of the set a random 698 prefix will be picked from. The greater RANDOM_SET_SIZE, the better 699 the convergence time and the lower the collision probability, but the 700 worse the addressing-space usage efficiency. 702 When the Flooding Mechanism does not provide a Flooding Delay, it is 703 set to DEFAULT_FLOODING_DELAY. As participating nodes do not need to 704 agree on a common Flooding Delay value, this default value MAY be 705 different from one node to another. If the context in which the 706 algorithm is used does not suffer from renumbering, the value 0 MAY 707 be used. Otherwise it depends on the Flooding Mechanism properties 708 and the desired renumbering probability, and is therefore out of 709 scope of this document. 711 8. Security Considerations 713 The prefix assignment algorithm functions on top of two distinct 714 mechanisms, the Flooding Mechanism and the Node ID assignment 715 mechanism. 717 An attacker able to publish Advertised Prefixes through the 718 Flooding Mechanism may perform the following attacks: 720 * Publish a single overriding assignment for a whole Delegated 721 Prefix or for the whole address space, thus preventing any node 722 from assigning prefixes to Links. 724 * Quickly publish and remove Advertised Prefixes, generating 725 traffic at the Flooding Mechanism layer and causing multiple 726 executions of the prefix assignment algorithm in all 727 participating nodes. 729 * Publish and remove Advertised Prefixes in order to prevent the 730 convergence of the execution. 732 An attacker able to prevent other nodes from accessing a portion 733 or the whole set of Advertised Prefixes may compromise the 734 correctness of the execution. 736 An attacker able to cause repetitive Node ID changes may induce 737 traffic generation from the Flooding Mechanism and multiple 738 executions of the prefix assignment algorithm in all participating 739 nodes. 741 An attacker able to publish Advertised Prefixes using a Node ID 742 used by another node may prevent the correctness and convergence 743 of the execution. 745 Whenever the security of the Flooding Mechanism and Node ID 746 assignment mechanism could not be ensured, the convergence of the 747 execution may be prevented. In environments where such attacks may 748 be performed, the execution of the prefix assignment algorithm 749 routine SHOULD be rate limited, as specified in Section 4.2. 751 9. IANA Considerations 753 This document has no actions for IANA. 755 10. Acknowledgments 757 The authors would like to thank those who participated in the 758 previous document's version development as well as the present one. 759 In particular, the authors would like to thank Tim Chown, Fred Baker, 760 Mark Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus 761 Stenberg, Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael 762 Richardson, Anders Brandt, Erik Nordmark, Laurent Toutain, Ralph 763 Droms, Acee Lindem and Steven Barth for interesting discussions and 764 document review. 766 11. References 768 11.1. Normative References 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, March 1997. 773 11.2. Informative References 775 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 776 Architecture", RFC 4291, February 2006. 778 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 779 Host Configuration Protocol (DHCP) version 6", RFC 3633, 780 December 2003. 782 Appendix A. Static Configuration Example 784 This section describes an example of how custom configuration of the 785 prefix assignment algorithm may be implemented. 787 The node configuration is specified as a finite set of rules. A rule 788 is defined as: 790 o A prefix to be used. 792 o A Link on which the prefix may be assigned. 794 o An Assigned Prefix Priority (smallest possible Assigned Prefix 795 Priority if the rule may not override other Assigned Prefixes). 797 o A rule priority (0 if the rule may not override existing 798 Advertised Prefixes). 800 In order to ensure the convergence of the execution, the Assigned 801 Prefix Priority MUST be an increasing function (not necessarily 802 strictly) of the configuration rule priority (i.e. the greater is the 803 configuration rule priority, the greater the Assigned Prefix Priority 804 must be). 806 Each Assigned Prefix is associated with a rule priority. Assigned 807 Prefixes which are created as specified in Section 4.2 are given a 808 rule priority of 0. 810 Whenever the configuration is changed or the prefix assignment 811 algorithm routine is run: For each Link/Delegated Prefix pair, look 812 for the configuration rule with the highest configuration rule 813 priority such that: 815 o The prefix specified in the configuration rule is included in the 816 considered Delegated Prefix. 818 o The Link specified in the configuration rule is the considered 819 Link. 821 o All the Assigned Prefixes which would need to be destroyed in case 822 a new Assigned Prefix is created from that configuration rule (as 823 specified in Section 4.3) have an associated rule priority which 824 is strictly lower than the one of the considered configuration 825 rule. 827 o The assignment would be valid when published with an Advertised 828 Prefix Priority equal to the one specified in the configuration 829 rule. 831 If a rule is found, a new Assigned Prefix is created based on that 832 rule in conformance with Section 4.3. The new Assigned Prefix is 833 associated with the Advertised Prefix Priority and the rule priority 834 specified in the considered configuration rule. 836 Note that the use of rule priorities ensures the convergence of the 837 execution. 839 Authors' Addresses 841 Pierre Pfister 842 Cisco Systems 843 Paris 844 France 846 Email: pierre.pfister@darou.fr 848 Benjamin Paterson 849 Cisco Systems 850 Paris 851 France 853 Email: benjamin@paterson.fr 855 Jari Arkko 856 Ericsson 857 Jorvas 02420 858 Finland 860 Email: jari.arkko@piuha.net