idnits 2.17.1 draft-ietf-homenet-prefix-assignment-06.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 (May 28, 2015) is 3256 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: November 29, 2015 J. Arkko 6 Ericsson 7 May 28, 2015 9 Distributed Prefix Assignment Algorithm 10 draft-ietf-homenet-prefix-assignment-06 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 November 29, 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 2.1. Subroutine Specific Terminology . . . . . . . . . . . . . 5 59 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 60 4. Algorithm Specification . . . . . . . . . . . . . . . . . . . 7 61 4.1. Prefix Assignment Algorithm Subroutine . . . . . . . . . 7 62 4.2. Overriding and Destroying Existing Assignments . . . . . 10 63 4.3. Other Events . . . . . . . . . . . . . . . . . . . . . . 12 64 5. Prefix Selection Considerations . . . . . . . . . . . . . . . 12 65 6. Implementation Capabilities and Node Behavior . . . . . . . . 14 66 7. Algorithm Parameters . . . . . . . . . . . . . . . . . . . . 15 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 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 satisfied after a finite convergence period: 84 1. At most one prefix from each delegated prefix is assigned to each 85 link. 87 2. Assigned prefixes are non-overlapping (i.e., an assigned prefix 88 never includes another assigned prefix). 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 custom assignment policies. When multiple 99 Nodes assign different prefixes from the same delegated prefix to the 100 same link, or when multiple Nodes assign overlapping prefixes (to the 101 same link or to different links), the assignment with the greatest 102 priority is kept and other 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 within a given time window, the algorithm also ensures that all 108 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. The terms 119 defined here are ordered in such a way as to avoid forward 120 references, and therefore are not sorted alphabetically. 122 Node: An entity executing the algorithm specified in this document 123 and able to communicate with other Nodes using the Flooding 124 Mechanism. 126 Flooding Mechanism: A mechanism allowing participating Nodes to 127 reliably share information with all other participating Nodes. 129 Link: An object the distributed algorithm will assign prefixes to. 130 A Node may only assign prefixes to Links it is directly connected 131 to. A Link is either Shared or Private. 133 Shared Link: A Link multiple Nodes may be connected to. Most of 134 the time, a Shared Link is a multi-access link or point-to-point 135 link, virtual or physical, requiring prefixes to be assigned to 136 it. 138 Private Link: A Private Link is an abstract concept defined for the 139 sake of this document. It allows Nodes to make assignments for 140 their private use or delegation. For instance, every DHCPv6-PD 141 [RFC3633] requesting router MAY be considered as a different 142 Private Link. 144 Delegated Prefix: A prefix provided to the algorithm and used as a 145 prefix pool for Assigned Prefixes. 147 Node ID: A value identifying a given participating Node. The set 148 of identifiers MUST be strictly and totally ordered (e.g., using 149 the alphanumeric order). 151 Flooding Delay: A value which MUST be provided by the Flooding 152 Mechanism and SHOULD be a deterministic or likely upper bound on 153 the information propagation delay among participating Nodes. 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 that 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 (i.e., overlapping or from the same Delegated 164 Prefix and assigned to the same link), all Advertised Prefixes but 165 the one with the greatest priority will eventually be removed. In 166 case of a tie, the assignment advertised by the Node with the 167 greatest Node ID is kept and others are removed. In order to 168 ensure convergence, the range of priority values MUST have an 169 upper bound. 171 Assigned Prefix: A prefix included in a Delegated Prefix and 172 assigned to a Shared or Private Link. It represents a local 173 decision to assign a given prefix from a given Delegated Prefix to 174 a given Link. The algorithm ensures that there is never more than 175 one Assigned Prefix per Delegated Prefix and Link pair. When 176 destroyed, an Assigned Prefix is set as not applied, ceases to be 177 advertised, and is removed from the set of Assigned Prefixes. 179 Applied (Assigned Prefix): When an Assigned Prefix is applied, it 180 MAY be used (e.g., for host configuration, routing protocol 181 configuration, prefix delegation). When not applied, it MUST NOT 182 be used for any purpose outside of the prefix assignment 183 algorithm. Each Assigned Prefix is associated with a timer (Apply 184 Timer) used to apply the Assigned Prefix. An Assigned Prefix is 185 unapplied when destroyed. 187 Published (Assigned Prefix): The Assigned Prefix is advertised 188 through the Flooding Mechanism as assigned to its associated Link. 189 A published Assigned Prefix MUST have an Advertised Prefix 190 Priority. It will appear as an Advertised Prefix to other Nodes, 191 once received through the Flooding Mechanism. 193 Prefix Adoption: When an Advertised Prefix which does not conflict 194 with any other Advertised Prefix or published Assigned Prefix 195 stops being advertised, any other Node connected to the same Link 196 MAY, after some random delay, start advertising the same prefix. 197 This procedure is called adoption and provides seamless assignment 198 transfer from a Node to another, e.g., in case of Node failure. 200 Backoff Timer: Every Delegated Prefix and Link pair is associated 201 with a timer counting down to zero. It is used to reduce the 202 probability of colliding assignments made by multiple Nodes by 203 delaying the creation of new Assigned Prefixes or the 204 advertisement of adopted Assigned Prefixes by a random amount of 205 time. 207 Renumbering: Event occurring when an Assigned Prefix which was 208 applied is destroyed. Renumbering is undesirable as it usually 209 implies reconfiguring routers or hosts. 211 2.1. Subroutine Specific Terminology 213 In addition to the terms defined in Section 2, the subroutine 214 specified in Section 4 makes use of the following terms. 216 Current Assignment: For a given Delegated Prefix and Link, the 217 Current Assignment is the Assigned Prefix (if any) included in the 218 Delegated Prefix and assigned to the given Link by the Node 219 executing the algorithm. At some point in time, the Current 220 Assignment from different Nodes may differ, but the algorithm 221 ensures that eventually, all Nodes directly connected to a Shared 222 Link have the same Current Assignment for any given Delegated 223 Prefix. 225 Precedence: An Advertised Prefix takes precedence over an Assigned 226 Prefix if and only if one of the following conditions is met: 228 * The Assigned Prefix is not published. 230 * The Assigned Prefix is published and the Advertised Prefix 231 Priority from the Advertised Prefix is strictly greater than 232 the Advertised Prefix Priority from the Assigned Prefix. 234 * The Assigned Prefix is published, the priorities are identical, 235 and the Node ID from the Node advertising the Advertised Prefix 236 is strictly greater than the local Node ID. 238 Best Assignment: For a given Delegated Prefix and Link, the Best 239 Assignment is the unique Advertised Prefix (if any) that: 241 * Includes or is included in the Delegated Prefix (i.e., the 242 Advertised Prefix is a sub-prefix of the Delegated Prefix, or 243 the Delegated Prefix is a sub-prefix of the Advertised Prefix). 245 * Is assigned on the given Link. 247 * Has the greatest Advertised Prefix Priority among Advertised 248 Prefixes fulfilling the two preceding conditions (and, in case 249 of a tie, the prefix advertised by the Node with the greatest 250 Node ID among all prefixes with greatest priority). 252 * Takes precedence over the Current Assignment associated with 253 the same Link and Delegated Prefix (if any). 255 Valid (Assigned Prefix): An Assigned Prefix is valid if and only if 256 the following two conditions are met: 258 * No Advertised Prefix including or included in the Assigned 259 Prefix takes precedence over the Assigned Prefix. 261 * No Advertised Prefix including or included in the same 262 Delegated Prefix as the Assigned Prefix and assigned to the 263 same Link takes precedence over the Assigned Prefix. 265 3. Applicability Statement 267 Each Node MUST have a set of non-overlapping Delegated Prefixes 268 (i.e., which do not include each other). This set MAY change over 269 time and be different from one Node to another at some point, but 270 Nodes MUST eventually have the same set of disjoint Delegated 271 Prefixes. 273 Given this set of disjoint Delegated Prefixes, Nodes may assign 274 available prefixes from each Delegated Prefix to the Links they are 275 directly connected to. The algorithm ensures that at most one prefix 276 from a given Delegated Prefix is assigned to any given Link. 278 The algorithm can be applied to any address space and can be used to 279 manage multiple address spaces simultaneously. For instance, an 280 implementation can make use of IPv4-mapped IPv6 addresses [RFC4291] 281 in order to manage both IPv4 and IPv6 prefix assignment using a 282 single prefix space. 284 The algorithm supports dynamically changing topologies: 286 o Nodes may join or leave the set of participating Nodes. 288 o Nodes may join or leave Links. 290 o Links may be joined or split. 292 All Nodes MUST run a common Flooding Mechanism in order to share 293 published Assigned Prefixes. The set of participating Nodes is 294 defined as the set of Nodes participating in the Flooding Mechanism. 296 The Flooding Mechanism MUST: 298 o Provide a way to flood Assigned Prefixes assigned to a directly 299 connected Link along with their respective Advertised Prefix 300 Priority and the Node ID of the Node which is advertising them. 302 o Specify whether an Advertised Prefix was assigned to a directly 303 connected Shared Link, and if so, on which one. 305 o Provide a Flooding Delay value, which SHOULD represent a 306 deterministic or likely upper bound on the information propagation 307 delay among participating Nodes. Whenever the Flooding Mechanism 308 is unable to adhere to the provided Flooding Delay, renumbering 309 may happen. As such a delay often depends on the size of the 310 network, it MAY change over time and MAY be different from one 311 Node to another. Furthermore, the process of selecting this value 312 is subject to a tradeoff between convergence speed and lower 313 renumbering probability (e.g., the value 0 may be used when 314 renumbering is harmless), and is therefore out of scope of this 315 document. 317 The algorithm ensures that whenever the Flooding Delay is provided 318 and respected, and in the absence of any topology change or Delegated 319 Prefix removal, renumbering only happens when a Node deliberately 320 overrides an existing assignment. 322 Each Node MUST have a Node ID. Node IDs MAY change over time and be 323 the same on multiple Nodes at some point, but each Node MUST 324 eventually have a Node ID which is unique among the set of 325 participating Nodes. 327 4. Algorithm Specification 329 This section specifies the behavior of Nodes implementing the prefix 330 assignment algorithm. The terms 'Current Assignment', 'Precedence', 331 'Best Assignment' and 'Valid' are used as defined in Section 2.1. 333 4.1. Prefix Assignment Algorithm Subroutine 335 This section specifies the prefix assignment algorithm subroutine. 336 It is defined for a given Delegated Prefix and Link pair and takes a 337 BackoffTriggered boolean as parameter (indicating whether the 338 subroutine execution was triggered by the Backoff Timer or by another 339 event). 341 For a given Delegated Prefix and Link pair, the subroutine MUST be 342 run with the BackoffTriggered boolean set to false whenever: 344 o An Advertised Prefix including or included in the considered 345 Delegated Prefix is added or removed. 347 o An Assigned Prefix included in the considered Delegated Prefix and 348 associated with a different Link than the considered Link was 349 destroyed, while there is no Current Assignment associated with 350 the given pair. This case MAY be ignored if the creation of a new 351 Assigned Prefix associated with the considered pair is not 352 desired. 354 o The considered Delegated Prefix is added. 356 o The considered Link is added. 358 o The Node ID is modified. 360 Furthermore, for a given Delegated Prefix and Link pair, the 361 subroutine MUST be run with the BackoffTriggered boolean set to true 362 whenever: 364 o The Backoff Timer associated with the considered Delegated Prefix 365 and Link pair fires while there is no Current Assignment 366 associated with the given pair. 368 When such an event occurs, a Node MAY delay the execution of the 369 subroutine instead of executing it immediately, e.g., while receiving 370 an update from the Flooding Mechanism, or for security reasons (see 371 Section 8). Even if other events occur in the meantime, the 372 subroutine MUST be run only once. It is also assumed that, whenever 373 one of these events is the Backoff Timer firing, the subroutine is 374 executed with the BackoffTriggered boolean set to true. 376 In order to execute the subroutine for a given Delegated Prefix and 377 Link pair, first look for the Best Assignment and Current Assignment 378 associated with the Delegated Prefix and Link pair, then execute the 379 corresponding case: 381 1. If there is no Best Assignment and no Current Assignment: Decide 382 whether the creation of a new assignment for the given Delegated 383 Prefix and Link pair is desired (As any result would be valid, 384 the process of making this decision is out of the scope of this 385 document) and do the following: 387 * If it is not desired, stop the execution of the subroutine. 389 * Else if the Backoff Timer is running, stop the execution of 390 the subroutine. 392 * Else if the BackoffTriggered boolean is set to false, set the 393 Backoff Timer to some random delay between ADOPT_MAX_DELAY and 394 BACKOFF_MAX_DELAY (see Section 7) and stop the execution of 395 the subroutine. 397 * Else, continue the execution of the subroutine. 399 Select a prefix for the new assignment (see Section 5 for 400 guidance regarding prefix selection). This prefix MUST be 401 included in or be equal to the considered Delegated Prefix and 402 MUST NOT include or be included in any Advertised Prefix. If a 403 suitable prefix is found, use it to create a new Assigned Prefix: 405 * Assigned to the considered Link. 407 * Set as not applied. 409 * The Apply Timer set to '2 * Flooding Delay'. 411 * Published with some selected Advertised Prefix Priority. 413 2. If there is a Best Assignment but no Current Assignment: Cancel 414 the Backoff Timer and use the prefix from the Best Assignment to 415 create a new Assigned Prefix: 417 * Assigned to the considered Link. 419 * Set as not applied. 421 * The Apply Timer set to '2 * Flooding Delay'. 423 * Set as not published. 425 3. If there is a Current Assignment but no Best Assignment: 427 * If the Current Assignment is not valid, destroy it, and 428 execute the subroutine again with the BackoffTriggered boolean 429 set to false. 431 * If the Current Assignment is valid and published, stop the 432 execution of the subroutine. 434 * If the Current Assignment is valid and not published, the Node 435 MUST either: 437 + Adopt the prefix by canceling the Apply Timer and set the 438 Backoff Timer to some random delay between 0 and 439 ADOPT_MAX_DELAY (see Section 7). This procedure is used to 440 avoid renumbering when the Node advertising the prefix left 441 the Shared Link. 443 + Destroy it and go to case 1. 445 4. If there is a Current Assignment and a Best Assignment: 447 * Cancel the Backoff Timer. 449 * If the two prefixes are identical, set the Current Assignment 450 as not published. If the Current Assignment is not applied 451 and the Apply Timer is not set, set the Apply Timer to '2 * 452 Flooding Delay'. 454 * If the two prefixes are not identical, destroy the Current 455 Assignment and go to case 2. 457 When the prefix assignment algorithm subroutine requires an 458 assignment to be created or adopted, any Advertised Prefix Priority 459 value can be used. Other documents MAY provide restrictions over 460 this value depending on the context the algorithm is operating in, or 461 leave it as implementation-specific. 463 4.2. Overriding and Destroying Existing Assignments 465 In addition to the behaviors specified in Section 4.1, the following 466 procedures MAY be used in order to provide additional behavior 467 options (Section 6): 469 Overriding Existing Assignments: For any given Link and Delegated 470 Prefix, a Node MAY create a new Assigned Prefix using a chosen 471 prefix and Advertised Prefix Priority such that: 473 * The chosen prefix is included in or is equal to the considered 474 Delegated Prefix. 476 * The Current Assignment, if any, as well as all existing 477 Assigned Prefixes which include or are included inside the 478 chosen prefix, are destroyed. 480 * It is not applied. 482 * The Apply Timer is set to '2 * Flooding Delay'. 484 * It is published. 486 * The Advertised Prefix Priority is greater than the Advertised 487 Prefix Priority from all Advertised Prefixes which include or 488 are included in the chosen prefix. 490 * The Advertised Prefix Priority is greater than the Advertised 491 Prefix Priority from all Advertised Prefixes which include or 492 are included in the considered Delegated Prefix and are 493 assigned to the considered Link. 495 In order to ensure algorithm convergence: 497 * Such overriding assignments MUST NOT be created unless there 498 was a change in the Node configuration, a Link was added, or an 499 Advertised Prefix was added or removed. 501 * The chosen Advertised Prefix Priority for the new Assigned 502 Prefix SHOULD be greater than all priorities from the destroyed 503 Assigned Prefixes. If not, simple topologies with only two 504 Nodes may not converge. Nodes which do not adhere to this rule 505 MUST implement a mechanism which detects whether the 506 distributed algorithm does not converge and, whenever this 507 would happen, stop creating overriding Assigned Prefixes which 508 do not adhere to this rule. The specifications for such safety 509 procedures are out of the scope of this document. 511 Removing an Assigned Prefix: A Node MAY destroy any Assigned Prefix 512 which is published. Such an event reflects the desire of a Node 513 to not assign a prefix from a given Delegated Prefix to a given 514 Link anymore. In order to ensure algorithm convergence, such a 515 procedure MUST NOT be executed unless there was a change in the 516 Node configuration. Furthermore, whenever an Assigned Prefix is 517 destroyed in this way, the prefix assignment algorithm subroutine 518 MUST be run for the Delegated Prefix and Link pair associated with 519 the destroyed Assigned Prefix. 521 The two procedures specified in this section are OPTIONAL. They 522 could be used for various purposes, e.g., for providing custom prefix 523 assignment configuration or reacting to prefix space exhaustion (by 524 overriding short Assigned Prefixes and assigning longer ones). 526 4.3. Other Events 528 When the Apply Timer fires, the associated Assigned Prefix MUST be 529 applied. 531 When the Backoff Timer associated with a given Delegated Prefix and 532 Link pair fires while there is a Current Assignment associated with 533 the same pair, the Current Assignment MUST be published with some 534 associated Advertised Prefix Priority and, if the prefix is not 535 applied, the Apply Timer MUST be set to '2 * Flooding Delay'. 537 When a Delegated Prefix is removed from the set of Delegated Prefixes 538 (e.g., when the Delegated Prefix expires), all Assigned Prefixes 539 included in the removed Delegated Prefix MUST be destroyed. 541 When one Delegated Prefix is replaced by another one that includes or 542 is included in the deleted Delegated Prefix, all Assigned Prefixes 543 which were included in the deleted Delegated Prefix but are not 544 included in the added Delegated Prefix MUST be destroyed. Others MAY 545 be kept. 547 When a Link is removed, all Assigned Prefixes assigned to that Link 548 MUST be destroyed. 550 5. Prefix Selection Considerations 552 When the prefix assignment algorithm subroutine specified in 553 Section 4.1 requires a new prefix to be selected, the prefix MUST be 554 selected either: 556 o Among prefixes included in the considered Delegated Prefix which 557 were previously assigned and applied on the considered Link. For 558 that purpose, Applied Prefixes may be stored in stable storage 559 along with their associated Link. 561 o Randomly, picked in a set of at least RANDOM_SET_SIZE (see 562 Section 7) prefixes included in the considered Delegated Prefix 563 and not including or included in any Assigned or Advertised 564 Prefix. If less than RANDOM_SET_SIZE candidates are found, the 565 prefix MUST be picked among all candidates. 567 o Based on some custom selection process specified in the 568 configuration. 570 A simple implementation MAY randomly pick the prefix among all 571 available prefixes, but this strategy is inefficient in terms of 572 address space use as a few long prefixes may exhaust the pool of 573 available short prefixes. 575 The rest of this section describes a more efficient approach which 576 MAY be applied any time a Node needs to pick a prefix for a new 577 assignment. The two following definitions are used: 579 Available prefix: The prefix of the form Prefix/PrefixLength is 580 available if and only if it satisfies the three following 581 conditions: 583 * It is included in the considered Delegated Prefix. 585 * It does not include and is not included in any Assigned or 586 Advertised Prefix. 588 * It is equal to the considered Delegated Prefix or Prefix/ 589 (PrefixLength-1) includes an Assigned or Advertised Prefix. 591 Candidate prefix: A prefix of desired length which is included in 592 or is equal to an available prefix. 594 The procedure described in this section takes the three following 595 criteria into account: 597 Prefix Stability: In some cases, it is desirable that the selected 598 prefix should remain the same across executions and reboots. For 599 this purpose, prefixes previously applied on the Link or pseudo- 600 random prefixes generated based on Node- and Link-specific values 601 may be considered. 603 Randomness: When no stored or pseudo-random prefix is chosen, a 604 prefix may be randomly picked among RANDOM_SET_SIZE candidates of 605 desired length. If less than RANDOM_SET_SIZE candidates can be 606 found, the prefix is picked among all candidates. 608 Addressing-space usage efficiency: In the process of assigning 609 prefixes, a small set of badly chosen long prefixes may prevent 610 any shorter prefix from being assigned. For this reason, the set 611 of RANDOM_SET_SIZE candidates is created from available prefixes 612 with longest prefix lengths and, in case of a tie, preferring 613 numerically small prefix values. 615 When executing the procedure, do as follows: 617 1. For each prefix stored in stable storage, check if the prefix is 618 included in or equal to an available prefix. If so, pick that 619 prefix and stop. 621 2. For each prefix length, count the number of available prefixes of 622 the given length. 624 3. If the desired prefix length was not specified, select one. The 625 available prefixes count computed previously may be used to help 626 pick a prefix length such that: 628 * There is at least one candidate prefix. 630 * The prefix length is chosen large enough to not exhaust the 631 address space. 633 Let N be the chosen prefix length. 635 4. Iterate over available prefixes starting with prefixes of length 636 N down to length 0 and create a set of RANDOM_SET_SIZE candidate 637 prefixes of length exactly N included in or equal to available 638 prefixes. The end goal here is to create a set of 639 RANDOM_SET_SIZE candidate prefixes of length N included in a set 640 of available prefixes of maximized prefix length. In case of a 641 tie, smaller prefix values (as defined by the bit-wise 642 lexicographical order) are preferred. 644 5. Generate a set of prefixes of desired length, which are pseudo- 645 randomly chosen based on Node- and Link-specific values. For 646 each pseudo-random prefix, check if the prefix is equal to a 647 candidate prefix. If so, pick that prefix and stop. 649 6. Choose a random prefix from the set of selected candidates. 651 The complexity of this procedure is equivalent to the complexity of 652 iterating over available prefixes. Such operation may be 653 accomplished in linear time, e.g., by storing Advertised and Assigned 654 Prefixes in a binary trie. 656 6. Implementation Capabilities and Node Behavior 658 Implementations of the prefix assignment algorithm may vary from very 659 basic to highly customizable, enabling different types of fully 660 interoperable behaviors. The three following behaviors are given as 661 examples: 663 Listener: The Node only acts upon assignments made by other Nodes, 664 i.e, it never creates new assignments nor adopts existing ones. 665 Such behavior does not require the implementation of the 666 considerations specified in Section 5 or Section 4.2. The Node 667 never checks the validity of existing assignments, which makes 668 this behavior particularly suited to lightweight devices which can 669 rely on more capable neighbors to make assignments on directly 670 connected Shared Links. 672 Basic: The Node is capable of assigning new prefixes or adopting 673 prefixes which do not conflict with any other existing assignment. 674 Such behavior does not require the implementation of the 675 considerations specified in Section 4.2. It is suited to 676 situations where there is no preference over which prefix should 677 be assigned to which Link, and there is no priority between 678 different Links. 680 Advanced: The Node is capable of assigning new prefixes, adopting 681 existing ones, making overriding assignments and destroying 682 existing ones. Such behavior requires the implementation of the 683 considerations specified in Section 5 and Section 4.2. It is 684 suited when the administrator desires some particular prefix to be 685 assigned on a given Link, or some Link to be assigned prefixes 686 with a greater priority when there are not enough prefixes 687 available for all Links. 689 Note that if all Nodes directly connected to some Link are listener 690 Nodes or none of these Nodes are willing to make an assignment from a 691 given Delegated Prefix to the given Link, no prefix from the given 692 Delegated Prefix will ever be assigned to the Link (and such existing 693 prefixes will be removed). This situation may be detected by 694 watching whether no prefix from a given Delegated Prefix has been 695 assigned to the Link for longer than BACKOFF_MAX_DELAY plus the 696 Flooding Delay. 698 7. Algorithm Parameters 700 This document does not provide values for ADOPT_MAX_DELAY, 701 BACKOFF_MAX_DELAY and RANDOM_SET_SIZE. The algorithm ensures 702 convergence and correctness for any chosen values, even when these 703 are different from Node to Node. They MAY be adjusted depending on 704 the context, providing a tradeoff between convergence time, efficient 705 addressing, reduced control traffic (generated by the Flooding 706 Mechanism), and low collision probability. 708 ADOPT_MAX_DELAY (respectively BACKOFF_MAX_DELAY) represents the 709 maximum backoff time a Node may wait before adopting an assignment 710 (respectively making a new assignment). BACKOFF_MAX_DELAY MUST be 711 greater than or equal to ADOPT_MAX_DELAY. The greater 712 ADOPT_MAX_DELAY and (BACKOFF_MAX_DELAY - ADOPT_MAX_DELAY), the lower 713 the collision probability and the lesser the amount of control 714 traffic, but the greater the convergence time. 716 RANDOM_SET_SIZE represents the desired size of the set a random 717 prefix will be picked from. The greater RANDOM_SET_SIZE, the better 718 the convergence time and the lower the collision probability, but the 719 worse the addressing-space usage efficiency. 721 8. Security Considerations 723 The prefix assignment algorithm functions on top of two distinct 724 mechanisms, the Flooding Mechanism and the Node ID assignment 725 mechanism. 727 An attacker able to publish Advertised Prefixes through the 728 Flooding Mechanism may perform the following attacks: 730 * Publish a single overriding assignment for a whole Delegated 731 Prefix or for the whole address space, thus preventing any Node 732 from assigning prefixes to Links. 734 * Quickly publish and remove Advertised Prefixes, generating 735 traffic at the Flooding Mechanism layer and causing multiple 736 executions of the prefix assignment algorithm in all 737 participating Nodes. 739 * Publish and remove Advertised Prefixes in order to prevent the 740 convergence of the algorithm. 742 An attacker able to prevent other Nodes from accessing a portion 743 or the whole set of Advertised Prefixes may compromise the 744 correctness of the algorithm. 746 An attacker able to cause repetitive Node ID changes may cause 747 traffic to be generated in the Flooding Mechanism and multiple 748 executions of the prefix assignment algorithm in all participating 749 Nodes. 751 An attacker able to publish Advertised Prefixes using a Node ID 752 used by another Node may prevent the correctness and convergence 753 of the algorithm or cause the result to violate the correctness 754 conditions. 756 Whenever the security of the Flooding Mechanism and Node ID 757 assignment mechanism cannot be ensured, the convergence of the 758 algorithm may be prevented. In environments where such attacks may 759 be performed, the execution of the prefix assignment algorithm 760 subroutine SHOULD be rate limited, as specified in Section 4.1. 762 9. IANA Considerations 764 This document has no actions for IANA. 766 10. Acknowledgments 768 The authors would like to thank those who participated in the 769 previous document's version development as well as the present one. 770 In particular, the authors would like to thank Tim Chown, Fred Baker, 771 Mark Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus 772 Stenberg, Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael 773 Richardson, Anders Brandt, Erik Nordmark, Laurent Toutain, Ralph 774 Droms, Acee Lindem and Steven Barth for interesting discussions and 775 document review. 777 11. References 779 11.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 11.2. Informative References 786 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 787 Architecture", RFC 4291, February 2006. 789 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 790 Host Configuration Protocol (DHCP) version 6", RFC 3633, 791 December 2003. 793 Appendix A. Static Configuration Example 795 This section describes an example of how custom configuration of the 796 prefix assignment algorithm may be implemented. 798 The Node configuration is specified as a finite set of rules. A rule 799 is defined as: 801 o A prefix to be used. 803 o A Link on which the prefix may be assigned. 805 o An Assigned Prefix Priority (smallest possible Assigned Prefix 806 Priority if the rule may not override other Assigned Prefixes). 808 o A rule priority (0 if the rule may not override existing 809 Advertised Prefixes). 811 In order to ensure the convergence of the algorithm, the Assigned 812 Prefix Priority MUST be an increasing function (not necessarily 813 strictly) of the configuration rule priority (i.e., the greater is 814 the configuration rule priority, the greater the Assigned Prefix 815 Priority must be). 817 Each Assigned Prefix is associated with a rule priority. Assigned 818 Prefixes which are created as specified in Section 4.1 are given a 819 rule priority of 0. 821 Whenever the configuration is changed or the prefix assignment 822 algorithm subroutine is run: For each Link/Delegated Prefix pair, 823 look for the configuration rule with the greatest configuration rule 824 priority such that: 826 o The prefix specified in the configuration rule is included in the 827 considered Delegated Prefix. 829 o The Link specified in the configuration rule is the considered 830 Link. 832 o All the Assigned Prefixes which would need to be destroyed in case 833 a new Assigned Prefix is created from that configuration rule (as 834 specified in Section 4.2) have an associated rule priority which 835 is strictly lower than the one of the considered configuration 836 rule. 838 o The assignment would be valid when published with an Advertised 839 Prefix Priority equal to the one specified in the configuration 840 rule. 842 If a rule is found, a new Assigned Prefix is created based on that 843 rule as specified in Section 4.2. The new Assigned Prefix is 844 associated with the Advertised Prefix Priority and the rule priority 845 specified in the considered configuration rule. 847 Note that the use of rule priorities ensures the convergence of the 848 algorithm. 850 Authors' Addresses 852 Pierre Pfister 853 Cisco Systems 854 Paris 855 France 857 Email: pierre.pfister@darou.fr 858 Benjamin Paterson 859 Cisco Systems 860 Paris 861 France 863 Email: paterson.b@gmail.com 865 Jari Arkko 866 Ericsson 867 Jorvas 02420 868 Finland 870 Email: jari.arkko@piuha.net