draft-ietf-homenet-prefix-assignment-07.txt   draft-ietf-homenet-prefix-assignment-08.txt 
Network Working Group P. Pfister Network Working Group P. Pfister
Internet-Draft B. Paterson Internet-Draft B. Paterson
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 17, 2015 J. Arkko Expires: February 25, 2016 J. Arkko
Ericsson Ericsson
June 15, 2015 August 24, 2015
Distributed Prefix Assignment Algorithm Distributed Prefix Assignment Algorithm
draft-ietf-homenet-prefix-assignment-07 draft-ietf-homenet-prefix-assignment-08
Abstract Abstract
This document specifies a distributed algorithm for automatic prefix This document specifies a distributed algorithm for dividing a set of
assignment. Thus it provides an alternative to manual or centralized prefixes in a manner that allows for automatic assignment of sub-
prefix and address assignment techniques. Given a set of delegated prefixes that are unique and non-overlapping. Used in conjunction
prefixes, it ensures that at most one prefix is assigned from each with a protocol that provides flooding of information among a set of
delegated prefix to each link. Nodes may assign available prefixes participating nodes, prefix configuration within a network may be
to the links they are directly connected to, or for other private automated.
purposes. The algorithm eventually converges and ensures that all
assigned prefixes do not overlap.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2015. This Internet-Draft will expire on February 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Subroutine Specific Terminology . . . . . . . . . . . . . 5 2.1. Subroutine Specific Terminology . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Algorithm Specification . . . . . . . . . . . . . . . . . . . 8 4. Algorithm Specification . . . . . . . . . . . . . . . . . . . 8
4.1. Prefix Assignment Algorithm Subroutine . . . . . . . . . 8 4.1. Prefix Assignment Algorithm Subroutine . . . . . . . . . 9
4.2. Overriding and Destroying Existing Assignments . . . . . 10 4.2. Overriding and Destroying Existing Assignments . . . . . 12
4.3. Other Events . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Other Events . . . . . . . . . . . . . . . . . . . . . . 13
5. Prefix Selection Considerations . . . . . . . . . . . . . . . 12 5. Prefix Selection Considerations . . . . . . . . . . . . . . . 13
6. Implementation Capabilities and Node Behavior . . . . . . . . 14 6. Implementation Capabilities and Node Behavior . . . . . . . . 16
7. Algorithm Parameters . . . . . . . . . . . . . . . . . . . . 15 7. Algorithm Parameters . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Static Configuration Example . . . . . . . . . . . . 17 Appendix A. Static Configuration Example . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document specifies a distributed algorithm for automatic prefix This document specifies a distributed algorithm for automatic prefix
assignment. The algorithm provides a generic alternative to assignment. The algorithm provides a generic alternative to
centralized (human or software based) approaches for network prefixes centralized (human or software based) approaches for network prefix
and addresses assignment. Although it does not require to be and address assignment. Although it does not require to be
configured to operate properly, it supports custom configuration by configured to operate properly, it supports custom configuration by
means of variable priority assignments, and can therefore be used in means of variable priority assignments, and can therefore be used in
fully autonomic as well as professionally managed networks. fully autonomic as well as configured networks. This document
focuses on the algorithm itself and therefore leaves as out of scope
context-specific considerations, such as the process of selecting a
prefix value and length when making a new assignment.
Given a set of delegated prefixes, Nodes may assign available The algorithm makes use of a flooding mechanism allowing
prefixes to links they are directly connected to, or for their participating Nodes to advertise prefixes assigned to the links they
private use. The algorithm ensures that the following assertions are are directly connected to or for other purposes, e.g., for private
satisfied after a finite convergence period: assignment or prefix delegation. Advertising a prefix therefore
serves two purposes. It is a claim that a prefix is in use, meaning
that no other Node may advertise an overlapping prefix (unless it has
a greater priority). And it is a way for other Nodes to know which
prefixes have been assigned to the links they are directly connected
to.
The algorithm is given a set of delegated prefixes, and ensures that
the following assertions are satisfied after a finite convergence
period:
1. At most one prefix from each delegated prefix is assigned to each 1. At most one prefix from each delegated prefix is assigned to each
link. link.
2. Assigned prefixes are non-overlapping (i.e., an assigned prefix 2. Assigned prefixes are non-overlapping (i.e., an assigned prefix
never includes another assigned prefix). never includes another assigned prefix).
3. Assigned prefixes do not change in the absence of topology or 3. Assigned prefixes do not change in the absence of topology or
configuration changes. configuration changes.
skipping to change at page 3, line 28 skipping to change at page 3, line 38
The prefix assignment algorithm requires that participating Nodes The prefix assignment algorithm requires that participating Nodes
share information through a flooding mechanism. If the flooding share information through a flooding mechanism. If the flooding
mechanism ensures that all messages are propagated to all Nodes mechanism ensures that all messages are propagated to all Nodes
within a given time window, the algorithm also ensures that all within a given time window, the algorithm also ensures that all
assigned prefixes used for networking operations (e.g., host assigned prefixes used for networking operations (e.g., host
configuration) remain unchanged, unless another Node assigns an configuration) remain unchanged, unless another Node assigns an
overlapping prefix with a higher assignment priority, or the topology overlapping prefix with a higher assignment priority, or the topology
changes and renumbering cannot be avoided. changes and renumbering cannot be avoided.
2. Terminology 2. Definitions
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
and "SHOULD", are to be interpreted as described in [RFC2119]. "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in [RFC2119].
This document makes use of the following terminology. The terms This document makes use of the following terminology. The terms
defined here are ordered in such a way as to avoid forward defined here are ordered in such a way as to try to avoid forward
references, and therefore are not sorted alphabetically. references, and therefore are not sorted alphabetically.
Node: An entity executing the algorithm specified in this document Node: An entity executing the algorithm specified in this document
and able to communicate with other Nodes using the Flooding and able to communicate with other Nodes using the Flooding
Mechanism. Mechanism.
Flooding Mechanism: A mechanism allowing participating Nodes to Flooding Mechanism: A mechanism allowing participating Nodes to
reliably share information with all other participating Nodes. reliably share information with all other participating Nodes.
Link: An object the distributed algorithm will assign prefixes to. Link: An object the distributed algorithm will assign prefixes to.
skipping to change at page 4, line 8 skipping to change at page 4, line 20
to. A Link is either Shared or Private. to. A Link is either Shared or Private.
Shared Link: A Link multiple Nodes may be connected to. Most of Shared Link: A Link multiple Nodes may be connected to. Most of
the time, a Shared Link is a multi-access link or point-to-point the time, a Shared Link is a multi-access link or point-to-point
link, virtual or physical, requiring prefixes to be assigned to link, virtual or physical, requiring prefixes to be assigned to
it. it.
Private Link: A Private Link is an abstract concept defined for the Private Link: A Private Link is an abstract concept defined for the
sake of this document. It allows Nodes to make assignments for sake of this document. It allows Nodes to make assignments for
their private use or delegation. For instance, every DHCPv6-PD their private use or delegation. For instance, every DHCPv6-PD
[RFC3633] requesting router MAY be considered as a different [RFC3633] requesting router may be considered as a different
Private Link. Private Link.
Delegated Prefix: A prefix provided to the algorithm and used as a Delegated Prefix: A prefix provided to the algorithm and used as a
prefix pool for Assigned Prefixes. prefix pool for Assigned Prefixes.
Node ID: A value identifying a given participating Node. The set Node ID: A value identifying a given participating Node. The set
of identifiers MUST be strictly and totally ordered (e.g., using of identifiers MUST be strictly and totally ordered (e.g., using
the alphanumeric order). the alphanumeric order). The mechanism used to assign Node IDs,
whether manual or automated, is out of the scope of this document.
Flooding Delay: A value which MUST be provided by the Flooding Flooding Delay: A value which MUST be provided by the Flooding
Mechanism and SHOULD be a deterministic or likely upper bound on Mechanism and SHOULD be a deterministic or likely upper bound on
the information propagation delay among participating Nodes. the information propagation delay among participating Nodes.
Advertised Prefix: A prefix advertised by another Node and Advertised Prefix: A prefix advertised by another Node and
delivered to the local Node by the Flooding Mechanism. It has an delivered to the local Node by the Flooding Mechanism. It has an
Advertised Prefix Priority and, when assigned to a directly Advertised Prefix Priority and, when assigned to a directly
connected Shared Link, is associated with that Shared Link. connected Shared Link, is associated with that Shared Link.
skipping to change at page 5, line 9 skipping to change at page 5, line 22
configuration, prefix delegation). When not applied, it MUST NOT configuration, prefix delegation). When not applied, it MUST NOT
be used for any purpose outside of the prefix assignment be used for any purpose outside of the prefix assignment
algorithm. Each Assigned Prefix is associated with a timer (Apply algorithm. Each Assigned Prefix is associated with a timer (Apply
Timer) used to apply the Assigned Prefix. An Assigned Prefix is Timer) used to apply the Assigned Prefix. An Assigned Prefix is
unapplied when destroyed. unapplied when destroyed.
Published (Assigned Prefix): The Assigned Prefix is advertised Published (Assigned Prefix): The Assigned Prefix is advertised
through the Flooding Mechanism as assigned to its associated Link. through the Flooding Mechanism as assigned to its associated Link.
A published Assigned Prefix MUST have an Advertised Prefix A published Assigned Prefix MUST have an Advertised Prefix
Priority. It will appear as an Advertised Prefix to other Nodes, Priority. It will appear as an Advertised Prefix to other Nodes,
once received through the Flooding Mechanism. once received from the Flooding Mechanism.
Destroy (an Assigned Prefix): Local action of removing an Assigned
Prefix from the set of Assigned Prefixes. If applied, the prefix
is unapplied. If published, the prefix stops being advertised
through the Flooding Mechanism.
Prefix Adoption: When an Advertised Prefix which does not conflict Prefix Adoption: When an Advertised Prefix which does not conflict
with any other Advertised Prefix or published Assigned Prefix with any other Advertised Prefix or published Assigned Prefix
stops being advertised, any other Node connected to the same Link stops being advertised, any other Node connected to the same Link
MAY, after some random delay, start advertising the same prefix. may, after some random delay, start advertising the same prefix.
This procedure is called adoption and provides seamless assignment This procedure is called adoption and provides seamless assignment
transfer from a Node to another, e.g., in case of Node failure. transfer from a Node to another, e.g., in case of Node failure.
Backoff Timer: Every Delegated Prefix and Link pair is associated Backoff Timer: Every Delegated Prefix and Link pair is associated
with a timer counting down to zero. It is used to reduce the with a timer counting down to zero. It is used to reduce the
probability of colliding assignments made by multiple Nodes by probability of colliding assignments made by multiple Nodes by
delaying the creation of new Assigned Prefixes or the delaying the creation of new Assigned Prefixes or the
advertisement of adopted Assigned Prefixes by a random amount of advertisement of adopted Assigned Prefixes by a random amount of
time. time.
skipping to change at page 6, line 10 skipping to change at page 6, line 28
* The Assigned Prefix is published and the Advertised Prefix * The Assigned Prefix is published and the Advertised Prefix
Priority from the Advertised Prefix is strictly greater than Priority from the Advertised Prefix is strictly greater than
the Advertised Prefix Priority from the Assigned Prefix. the Advertised Prefix Priority from the Assigned Prefix.
* The Assigned Prefix is published, the priorities are identical, * The Assigned Prefix is published, the priorities are identical,
and the Node ID from the Node advertising the Advertised Prefix and the Node ID from the Node advertising the Advertised Prefix
is strictly greater than the local Node ID. is strictly greater than the local Node ID.
Best Assignment: For a given Delegated Prefix and Link, the Best Best Assignment: For a given Delegated Prefix and Link, the Best
Assignment is the unique Advertised Prefix (if any) that: Assignment is computed as the unique Advertised Prefix (if any)
that:
* Includes or is included in the Delegated Prefix (i.e., the * Includes or is included in the Delegated Prefix (i.e., the
Advertised Prefix is a sub-prefix of the Delegated Prefix, or Advertised Prefix is a sub-prefix of the Delegated Prefix, or
the Delegated Prefix is a sub-prefix of the Advertised Prefix). the Delegated Prefix is a sub-prefix of the Advertised Prefix).
* Is assigned on the given Link. * Is assigned on the given Link.
* Has the greatest Advertised Prefix Priority among Advertised * Has the greatest Advertised Prefix Priority among Advertised
Prefixes fulfilling the two preceding conditions (and, in case Prefixes fulfilling the two preceding conditions (and, in case
of a tie, the prefix advertised by the Node with the greatest of a tie, the prefix advertised by the Node with the greatest
skipping to change at page 6, line 38 skipping to change at page 7, line 11
* No Advertised Prefix including or included in the Assigned * No Advertised Prefix including or included in the Assigned
Prefix takes precedence over the Assigned Prefix. Prefix takes precedence over the Assigned Prefix.
* No Advertised Prefix including or included in the same * No Advertised Prefix including or included in the same
Delegated Prefix as the Assigned Prefix and assigned to the Delegated Prefix as the Assigned Prefix and assigned to the
same Link takes precedence over the Assigned Prefix. same Link takes precedence over the Assigned Prefix.
3. Applicability Statement 3. Applicability Statement
Although the algorithm was primarily designed as an autonomic prefix
assignment tool for home networks, it is applicable to other areas.
In particular, it can operate without any kind of configuration as
well as using advanced prefix assignment rules. Additionally, it can
be applied to any address space and can be used to manage multiple
address spaces simultaneously. For instance, an implementation can
make use of IPv4-mapped IPv6 addresses [RFC4291] in order to manage
both IPv4 and IPv6 prefix assignment using a single prefix space.
Each Node MUST have a set of non-overlapping Delegated Prefixes Each Node MUST have a set of non-overlapping Delegated Prefixes
(i.e., which do not include each other). This set MAY change over (i.e., which do not include each other). This set MAY change over
time and be different from one Node to another at some point, but time and be different from one Node to another at some point, but
Nodes MUST eventually have the same set of disjoint Delegated Nodes MUST eventually have the same set of non-overlapping Delegated
Prefixes. Prefixes.
Given this set of disjoint Delegated Prefixes, Nodes may assign Given this set of non-overlapping Delegated Prefixes, Nodes may
available prefixes from each Delegated Prefix to the Links they are assign available prefixes from each Delegated Prefix to the Links
directly connected to. The algorithm ensures that at most one prefix they are directly connected to. The algorithm ensures that at most
from a given Delegated Prefix is assigned to any given Link. one prefix from a given Delegated Prefix is assigned to any given
Link. Prefixes may also be assigned for private use. For example,
The algorithm can be applied to any address space and can be used to an assigned prefix may be delegated to some other entity that does
manage multiple address spaces simultaneously. For instance, an not implement this algorithm [RFC3633], or associated with a high
implementation can make use of IPv4-mapped IPv6 addresses [RFC4291] priority in order to prevent other nodes from assigning any
in order to manage both IPv4 and IPv6 prefix assignment using a overlapping prefix [RFC6603].
single prefix space.
The algorithm supports dynamically changing topologies:
o Nodes may join or leave the set of participating Nodes.
o Nodes may join or leave Links.
o Links may be joined or split. The algorithm supports dynamically changing topologies and therefore
will converge if the topology remains unmodified for a long enough
period of time (That time depends on the Flooding Mechanism
properties). Nevertheless, some topology changes may induce
renumbering, while others do not. In particular, Nodes joining the
set of participating Nodes do not cause renumbering. Similarly,
Nodes leaving the network may be dealt with without renumbering by
using the prefix adoption procedure. On the other hand, Links
junction or split may break correctness conditions, and therefore
cause renumbering.
All Nodes MUST run a common Flooding Mechanism in order to share All Nodes MUST run a common Flooding Mechanism in order to share
published Assigned Prefixes. The set of participating Nodes is published Assigned Prefixes. The set of participating Nodes is
defined as the set of Nodes participating in the Flooding Mechanism. defined as the set of Nodes participating in the Flooding Mechanism.
The Flooding Mechanism MUST: The Flooding Mechanism MUST:
o Provide a way to flood Assigned Prefixes assigned to a directly o Provide a way to flood Assigned Prefixes assigned to a directly
connected Link along with their respective Advertised Prefix connected Link along with their respective Advertised Prefix
Priority and the Node ID of the Node which is advertising them. Priority and the Node ID of the Node which is advertising them.
o Specify whether an Advertised Prefix was assigned to a directly o Specify whether an Advertised Prefix is assigned to a directly
connected Shared Link, and if so, on which one. connected Shared Link, and if so, on which one. This information
also needs to be updated in case of links junction or split.
o Provide a Flooding Delay value, which SHOULD represent a o Provide a Flooding Delay value, which SHOULD represent a
deterministic or likely upper bound on the information propagation deterministic or likely upper bound on the information propagation
delay among participating Nodes. Whenever the Flooding Mechanism delay among participating Nodes. Whenever the Flooding Mechanism
is unable to adhere to the provided Flooding Delay, renumbering is unable to adhere to the provided Flooding Delay, renumbering
may happen. As such a delay often depends on the size of the may happen. As such a delay often depends on the size of the
network, it MAY change over time and MAY be different from one network, it MAY change over time and MAY be different from one
Node to another. Furthermore, the process of selecting this value Node to another. Furthermore, the process of selecting this value
is subject to a tradeoff between convergence speed and lower is subject to a tradeoff between convergence speed and lower
renumbering probability (e.g., the value 0 may be used when renumbering probability (e.g., the value 0 may be used when
renumbering is harmless), and is therefore out of scope of this renumbering is harmless), and is therefore out of scope of this
document. document.
The algorithm ensures that whenever the Flooding Delay is provided The algorithm ensures that whenever the Flooding Delay is provided
and respected, and in the absence of any topology change or Delegated and held, and in the absence of any topology change or Delegated
Prefix removal, renumbering only happens when a Node deliberately Prefix removal, renumbering only happens when a Node deliberately
overrides an existing assignment. overrides an existing assignment. In the absence of such deliberate
override, the algorithm converges within an absolute worst case
timespan of '2 * Flooding Delay * L' seconds, where L in the number
of links.
Each Node MUST have a Node ID. Node IDs MAY change over time and be Each Node MUST have a Node ID. In the absence of colliding
the same on multiple Nodes at some point, but each Node MUST assignments, the algorithm will not suffer from multiple nodes having
eventually have a Node ID which is unique among the set of the same Node ID, but in order for collisions to be resolved, such
participating Nodes. situation MUST be transient.
Finally, leaving the Flooding Mechanism or Node ID assignment process
unsecured makes the network vulnerable to deny of service attacks, as
detailed in Section 8. Additionally, as this algorithm requires all
Nodes to know which Node has made which assignment, it may be
unsuitable depending on privacy requirements among participating
Nodes.
4. Algorithm Specification 4. Algorithm Specification
This section specifies the behavior of Nodes implementing the prefix This section specifies the behavior of Nodes implementing the prefix
assignment algorithm. The terms 'Current Assignment', 'Precedence', assignment algorithm. The terms 'Current Assignment', 'Precedence',
'Best Assignment' and 'Valid' are used as defined in Section 2.1. 'Best Assignment' and 'Valid' are used as defined in Section 2.1.
4.1. Prefix Assignment Algorithm Subroutine 4.1. Prefix Assignment Algorithm Subroutine
This section specifies the prefix assignment algorithm subroutine. This section specifies the prefix assignment algorithm subroutine.
It is defined for a given Delegated Prefix and Link pair and takes a It is defined for a given Delegated Prefix and Link pair and takes a
BackoffTriggered boolean as parameter (indicating whether the BackoffTriggered boolean as parameter (indicating whether the
subroutine execution was triggered by the Backoff Timer or by another subroutine execution was triggered by the Backoff Timer or by another
event). event). The subroutine also makes use of the two following
configuration parameters: ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY,
which meanings are detailed in Section 7.
For a given Delegated Prefix and Link pair, the subroutine MUST be For a given Delegated Prefix and Link pair, the subroutine MUST be
run with the BackoffTriggered boolean set to false whenever: run with the BackoffTriggered boolean set to false whenever:
o An Advertised Prefix including or included in the considered o An Advertised Prefix including or included in the considered
Delegated Prefix is added or removed. Delegated Prefix is added or removed.
o An Assigned Prefix included in the considered Delegated Prefix and o An Assigned Prefix included in the considered Delegated Prefix and
associated with a different Link than the considered Link was associated with a different Link than the considered Link was
destroyed, while there is no Current Assignment associated with destroyed, while there is no Current Assignment associated with
the given pair. This case MAY be ignored if the creation of a new the given pair. This case MAY be ignored if the creation of a new
Assigned Prefix associated with the considered pair is not Assigned Prefix associated with the considered pair is not
desired. desired.
o The considered Delegated Prefix is added. o The considered Delegated Prefix is added.
o The considered Link is added. o The considered Link is added.
o The Node ID is modified. o The Node ID is modified.
o An Assigned Prefix included in the considered Delegated Prefix and
associated with the considered Link is destroyed outside of the
context of the subroutine, as specified in Section 4.2.
Furthermore, for a given Delegated Prefix and Link pair, the Furthermore, for a given Delegated Prefix and Link pair, the
subroutine MUST be run with the BackoffTriggered boolean set to true subroutine MUST be run with the BackoffTriggered boolean set to true
whenever: whenever:
o The Backoff Timer associated with the considered Delegated Prefix o The Backoff Timer associated with the considered Delegated Prefix
and Link pair fires while there is no Current Assignment and Link pair fires while there is no Current Assignment
associated with the given pair. associated with the given pair.
When such an event occurs, a Node MAY delay the execution of the When such an event occurs, a Node MAY delay the execution of the
subroutine instead of executing it immediately, e.g., while receiving subroutine instead of executing it immediately, e.g., while receiving
an update from the Flooding Mechanism, or for security reasons (see an update from the Flooding Mechanism, or for security reasons (see
Section 8). Even if other events occur in the meantime, the Section 8). Even if other events occur in the meantime, the
subroutine MUST be run only once. It is also assumed that, whenever subroutine MUST be run only once. It is also assumed that, whenever
one of these events is the Backoff Timer firing, the subroutine is one of these events is the Backoff Timer firing while there is no
Current Assignment associated with the given pair, the subroutine is
executed with the BackoffTriggered boolean set to true. executed with the BackoffTriggered boolean set to true.
In order to execute the subroutine for a given Delegated Prefix and In order to execute the subroutine for a given Delegated Prefix and
Link pair, first look for the Best Assignment and Current Assignment Link pair, first get the Current Assignment and compute the Best
associated with the Delegated Prefix and Link pair, then execute the Assignment associated with the Delegated Prefix and Link pair, then
corresponding case: execute the corresponding case:
1. If there is no Best Assignment and no Current Assignment: Decide 1. If there is no Best Assignment and no Current Assignment: Decide
whether the creation of a new assignment for the given Delegated whether the creation of a new assignment for the given Delegated
Prefix and Link pair is desired (As any result would be valid, Prefix and Link pair is desired (As any result would be valid,
the process of making this decision is out of the scope of this the process of making this decision is out of the scope of this
document) and do the following: document) and do the following:
* If it is not desired, stop the execution of the subroutine. * If it is not desired, stop the execution of the subroutine.
* Else if the Backoff Timer is running, stop the execution of * Else if the Backoff Timer is running, stop the execution of
skipping to change at page 9, line 42 skipping to change at page 10, line 44
suitable prefix is found, use it to create a new Assigned Prefix: suitable prefix is found, use it to create a new Assigned Prefix:
* Assigned to the considered Link. * Assigned to the considered Link.
* Set as not applied. * Set as not applied.
* The Apply Timer set to '2 * Flooding Delay'. * The Apply Timer set to '2 * Flooding Delay'.
* Published with some selected Advertised Prefix Priority. * Published with some selected Advertised Prefix Priority.
2. If there is a Best Assignment but no Current Assignment: Cancel 2. If there is a Best Assignment but no Current Assignment: First
the Backoff Timer and use the prefix from the Best Assignment to check if the Best Assignment is equal to or included in the
create a new Assigned Prefix: Delegated Prefix. If not, stop the execution of the subroutine.
Otherwise, cancel the Backoff Timer and use the prefix from the
Best Assignment to create a new Assigned Prefix:
* Assigned to the considered Link. * Assigned to the considered Link.
* Set as not applied. * Set as not applied.
* The Apply Timer set to '2 * Flooding Delay'. * The Apply Timer set to '2 * Flooding Delay'.
* Set as not published. * Set as not published.
3. If there is a Current Assignment but no Best Assignment: 3. If there is a Current Assignment but no Best Assignment:
skipping to change at page 10, line 21 skipping to change at page 11, line 27
* If the Current Assignment is valid and published, stop the * If the Current Assignment is valid and published, stop the
execution of the subroutine. execution of the subroutine.
* If the Current Assignment is valid and not published, the Node * If the Current Assignment is valid and not published, the Node
MUST either: MUST either:
+ Adopt the prefix by canceling the Apply Timer and set the + Adopt the prefix by canceling the Apply Timer and set the
Backoff Timer to some random delay between 0 and Backoff Timer to some random delay between 0 and
ADOPT_MAX_DELAY (see Section 7). This procedure is used to ADOPT_MAX_DELAY (see Section 7). This procedure is used to
avoid renumbering when the Node advertising the prefix left avoid renumbering when the Node advertising the prefix left
the Shared Link. the Shared Link, and SHOULD therefore be preferred.
+ Destroy it and go to case 1. + Destroy it and go to case 1, allowing a different prefix to
be assigned, or the prefix to be removed. When the Current
Assignment is applied, this causes renumbering.
4. If there is a Current Assignment and a Best Assignment: 4. If there is a Current Assignment and a Best Assignment:
* Cancel the Backoff Timer. * Cancel the Backoff Timer.
* If the two prefixes are identical, set the Current Assignment * If the two prefixes are identical, set the Current Assignment
as not published. If the Current Assignment is not applied as not published. If the Current Assignment is not applied
and the Apply Timer is not set, set the Apply Timer to '2 * and the Apply Timer is not set, set the Apply Timer to '2 *
Flooding Delay'. Flooding Delay'.
skipping to change at page 15, line 32 skipping to change at page 16, line 43
existing ones. Such behavior requires the implementation of the existing ones. Such behavior requires the implementation of the
considerations specified in Section 5 and Section 4.2. It is considerations specified in Section 5 and Section 4.2. It is
suited when the administrator desires some particular prefix to be suited when the administrator desires some particular prefix to be
assigned on a given Link, or some Link to be assigned prefixes assigned on a given Link, or some Link to be assigned prefixes
with a greater priority when there are not enough prefixes with a greater priority when there are not enough prefixes
available for all Links. available for all Links.
Note that if all Nodes directly connected to some Link are listener Note that if all Nodes directly connected to some Link are listener
Nodes or none of these Nodes are willing to make an assignment from a Nodes or none of these Nodes are willing to make an assignment from a
given Delegated Prefix to the given Link, no prefix from the given given Delegated Prefix to the given Link, no prefix from the given
Delegated Prefix will ever be assigned to the Link (and such existing Delegated Prefix will ever be assigned to the Link. This situation
prefixes will be removed). This situation may be detected by may be detected by watching whether no prefix from a given Delegated
watching whether no prefix from a given Delegated Prefix has been Prefix has been assigned to the Link for longer than
assigned to the Link for longer than BACKOFF_MAX_DELAY plus the BACKOFF_MAX_DELAY plus the Flooding Delay.
Flooding Delay.
7. Algorithm Parameters 7. Algorithm Parameters
This document does not provide values for ADOPT_MAX_DELAY, This document does not provide values for ADOPT_MAX_DELAY,
BACKOFF_MAX_DELAY and RANDOM_SET_SIZE. The algorithm ensures BACKOFF_MAX_DELAY and RANDOM_SET_SIZE. The algorithm ensures
convergence and correctness for any chosen values, even when these convergence and correctness for any chosen values, even when these
are different from Node to Node. They MAY be adjusted depending on are different from Node to Node. They MAY be adjusted depending on
the context, providing a tradeoff between convergence time, efficient the context, providing a tradeoff between convergence time, efficient
addressing, reduced control traffic (generated by the Flooding addressing, reduced control traffic (generated by the Flooding
Mechanism), and low collision probability. Mechanism), and low collision probability.
skipping to change at page 16, line 43 skipping to change at page 18, line 11
An attacker able to prevent other Nodes from accessing a portion An attacker able to prevent other Nodes from accessing a portion
or the whole set of Advertised Prefixes may compromise the or the whole set of Advertised Prefixes may compromise the
correctness of the algorithm. correctness of the algorithm.
An attacker able to cause repetitive Node ID changes may cause An attacker able to cause repetitive Node ID changes may cause
traffic to be generated in the Flooding Mechanism and multiple traffic to be generated in the Flooding Mechanism and multiple
executions of the prefix assignment algorithm in all participating executions of the prefix assignment algorithm in all participating
Nodes. Nodes.
An attacker able to publish Advertised Prefixes using a Node ID An attacker able to publish Advertised Prefixes using a Node ID
used by another Node may prevent the correctness and convergence used by another Node may impede the ability to resolve prefix
of the algorithm or cause the result to violate the correctness assignment collisions.
conditions.
Whenever the security of the Flooding Mechanism and Node ID Whenever the security of the Flooding Mechanism and Node ID
assignment mechanism cannot be ensured, the convergence of the assignment mechanism cannot be ensured, the convergence of the
algorithm may be prevented. In environments where such attacks may algorithm may be prevented. In environments where such attacks may
be performed, the execution of the prefix assignment algorithm be performed, the execution of the prefix assignment algorithm
subroutine SHOULD be rate limited, as specified in Section 4.1. subroutine SHOULD be rate limited, as specified in Section 4.1.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank those who participated in the The authors would like to thank those who participated in the
previous document's version development as well as the present one. previous document's version development as well as the present one.
In particular, the authors would like to thank Tim Chown, Fred Baker, In particular, the authors would like to thank Tim Chown, Fred Baker,
Mark Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus Mark Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus
Stenberg, Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael Stenberg, Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael
Richardson, Anders Brandt, Erik Nordmark, Laurent Toutain, Ralph Richardson, Anders Brandt, Erik Nordmark, Laurent Toutain, Ralph
Droms, Acee Lindem and Steven Barth for interesting discussions and Droms, Acee Lindem, Steven Barth and Juliusz Chroboczek for
document review. interesting discussions and document review.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
Appendix A. Static Configuration Example Appendix A. Static Configuration Example
This section describes an example of how custom configuration of the This section describes an example of how custom configuration of the
prefix assignment algorithm may be implemented. prefix assignment algorithm may be implemented.
The Node configuration is specified as a finite set of rules. A rule The Node configuration is specified as a finite set of rules. A rule
is defined as: is defined as:
o A prefix to be used. o A prefix to be used.
 End of changes. 39 change blocks. 
93 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/