draft-ietf-homenet-prefix-assignment-00.txt   draft-ietf-homenet-prefix-assignment-01.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: March 23, 2015 J. Arkko Expires: April 27, 2015 J. Arkko
Ericsson Ericsson
September 19, 2014 October 24, 2014
Prefix and Address Assignment in a Home Network Prefix and Address Assignment in a Home Network
draft-ietf-homenet-prefix-assignment-00 draft-ietf-homenet-prefix-assignment-01
Abstract Abstract
This memo describes a home network prefix and address assignment This memo describes a home network prefix and address assignment
algorithm running on top of any 'flooding protocol' that fulfills the algorithm running on top of any 'flooding protocol' that fulfills the
specified requirements. It is expected that home border routers are specified requirements. It is expected that home border routers are
allocated one or multiple IPv6 prefixes through DHCPv6 Prefix allocated one or multiple IPv6 prefixes through DHCPv6 Prefix
Delegation (PD) or that prefixes are made available through other Delegation (PD) or that prefixes are made available through other
means. An IPv4 address can also be assigned and private addresses be means. An IPv4 address can also be assigned and private addresses be
used with NAT to provide IPv4 connectivity. In both cases, provided used with NAT to provide IPv4 connectivity. In both cases, provided
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 23, 2015. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Prefix and Address Assignment Algorithms' Outline . . . . . . 4 3. Prefix and Address Assignment Algorithms' Outline . . . . . . 4
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Data structures . . . . . . . . . . . . . . . . . . . . . 6 4.1. Data structures . . . . . . . . . . . . . . . . . . . . . 6
4.2. Routers' Interfaces . . . . . . . . . . . . . . . . . . . 7 4.2. Routers' Interfaces . . . . . . . . . . . . . . . . . . . 7
4.3. Obtaining a Delegated Prefix . . . . . . . . . . . . . . 7 4.3. Obtaining a Delegated Prefix . . . . . . . . . . . . . . 7
4.4. Network Leader . . . . . . . . . . . . . . . . . . . . . 8 4.4. Network Leader . . . . . . . . . . . . . . . . . . . . . 8
4.5. Designated Router . . . . . . . . . . . . . . . . . . . . 8 4.5. Designated Router . . . . . . . . . . . . . . . . . . . . 8
4.5.1. Sending Router Advertisement . . . . . . . . . . . . 9 4.5.1. Sending Router Advertisement . . . . . . . . . . . . 9
4.5.2. DHCP Server Operations . . . . . . . . . . . . . . . 9 4.5.2. DHCP Server Operations . . . . . . . . . . . . . . . 9
4.6. Applying an Assignment on an Interface . . . . . . . . . 9 4.6. Applying an Assignment on an Interface . . . . . . . . . 10
4.7. DNS Support . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. DNS Support . . . . . . . . . . . . . . . . . . . . . . . 10
5. Flooding Protocol Requirements . . . . . . . . . . . . . . . 10 5. Flooding Protocol Requirements . . . . . . . . . . . . . . . 11
5.1. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Propagation Delay . . . . . . . . . . . . . . . . . . . . 11 5.2. Propagation Delay . . . . . . . . . . . . . . . . . . . . 11
5.3. Flooding Assigned Prefixes . . . . . . . . . . . . . . . 11 5.3. Flooding Assigned Prefixes . . . . . . . . . . . . . . . 12
5.4. Flooding Delegated Prefixes . . . . . . . . . . . . . . . 12 5.4. Flooding Delegated Prefixes . . . . . . . . . . . . . . . 12
5.5. Flooding Routers' Address Assignments . . . . . . . . . . 12 5.5. Flooding Routers' Address Assignments . . . . . . . . . . 12
6. Prefix Assignment Algorithm . . . . . . . . . . . . . . . . . 12 6. Prefix Assignment Algorithm . . . . . . . . . . . . . . . . . 13
6.1. When to execute the Prefix Assignment Algorithm . . . . . 13 6.1. When to execute the Prefix Assignment Algorithm . . . . . 13
6.2. Assignment Precedence . . . . . . . . . . . . . . . . . . 13 6.2. Assignment Precedence . . . . . . . . . . . . . . . . . . 14
6.3. Testing Assignment's validity . . . . . . . . . . . . . . 14 6.3. Testing Assignment's validity . . . . . . . . . . . . . . 14
6.4. Testing Assignment's availability . . . . . . . . . . . . 14 6.4. Testing Assignment's availability . . . . . . . . . . . . 14
6.5. Accepting an Assigned Prefix . . . . . . . . . . . . . . 14 6.5. Accepting an Assigned Prefix . . . . . . . . . . . . . . 14
6.6. Making a New Assignment . . . . . . . . . . . . . . . . . 14 6.6. Making a New Assignment . . . . . . . . . . . . . . . . . 15
6.7. Using Authoritative Prefix Assignments . . . . . . . . . 16 6.7. Using Authoritative Prefix Assignments . . . . . . . . . 16
6.8. Choosing the Assignment's Priority . . . . . . . . . . . 16 6.8. Choosing the Assignment's Priority . . . . . . . . . . . 17
6.9. Prefix Assignment Algorithm steps . . . . . . . . . . . . 17 6.9. Prefix Assignment Algorithm steps . . . . . . . . . . . . 17
6.10. Downstream DHCPv6 Prefix Delegation support . . . . . . . 18 6.10. Downstream DHCPv6 Prefix Delegation support . . . . . . . 18
7. Address Assignment Algorithm . . . . . . . . . . . . . . . . 18 7. Address Assignment Algorithm . . . . . . . . . . . . . . . . 19
7.1. Router's address pools . . . . . . . . . . . . . . . . . 19 7.1. Router's address pools . . . . . . . . . . . . . . . . . 20
7.2. Address Assignment Algorithm . . . . . . . . . . . . . . 19 7.2. Address Assignment Algorithm . . . . . . . . . . . . . . 20
8. Hysteresis Principle . . . . . . . . . . . . . . . . . . . . 20 8. Hysteresis Principle . . . . . . . . . . . . . . . . . . . . 21
8.1. Prefix and Address assignments . . . . . . . . . . . . . 20 8.1. Prefix and Address assignments . . . . . . . . . . . . . 21
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . 20 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . 21
8.2.1. Unreliable uplink . . . . . . . . . . . . . . . . . . 21
9. ULA and IPv4 Prefixes Generation . . . . . . . . . . . . . . 21 8.2.2. Unreliable in-home link . . . . . . . . . . . . . . . 22
9.1. ULA Prefix Generation . . . . . . . . . . . . . . . . . . 21 9. ULA and IPv4 Prefixes Generation . . . . . . . . . . . . . . 22
9.2. IPv4 Private Prefix Generation . . . . . . . . . . . . . 21 9.1. ULA Prefix Generation . . . . . . . . . . . . . . . . . . 22
10. Manageability Considerations . . . . . . . . . . . . . . . . 22 9.1.1. Choosing the ULA prefix . . . . . . . . . . . . . . . 23
11. Documents Constants . . . . . . . . . . . . . . . . . . . . . 22 9.1.2. Advertising a ULA prefix . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.1.3. Extending prefix lifetime . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1.4. Authoritative ULAs . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. IPv4 Private Prefix Generation . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 24 10. Manageability Considerations . . . . . . . . . . . . . . . . 24
Appendix A. Scarcity Avoidance Mechanism . . . . . . . . . . . . 25 11. Documents Constants . . . . . . . . . . . . . . . . . . . . . 25
A.1. Prefix Wasts Avoidance . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
A.2. Increasing Assigned Prefix Length . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3. Foreseeing Prefixes Exaustion . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
A.4. Cutting an Existing Assignment . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 28 Appendix A. Scarcity Avoidance Mechanism . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 A.1. Prefix Wasts Avoidance . . . . . . . . . . . . . . . . . 29
A.2. Increasing Assigned Prefix Length . . . . . . . . . . . . 30
A.3. Foreseeing Prefixes Exaustion . . . . . . . . . . . . . . 30
A.4. Cutting an Existing Assignment . . . . . . . . . . . . . 31
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This memo describes a fully distributed prefix and address assignment This memo describes a fully distributed prefix and address assignment
algorithm for home networks, running on top of any 'flooding algorithm for home networks, running on top of any 'flooding
protocol' that fulfills the specified requirements. It is expected protocol' that fulfills the specified requirements. It is expected
that home border routers are allocated one or multiple IPv6 prefixes that home border routers are allocated one or multiple IPv6 prefixes
through DHCPv6 Prefix Delegation (PD) [RFC3633] or that prefixes are through DHCPv6 Prefix Delegation (PD) [RFC3633] or that prefixes are
made available through other means. When an IPv4 address is made available through other means. When an IPv4 address is
assigned, a home private IPv4 prefix may be used with NAT to provide assigned, a home private IPv4 prefix may be used with NAT to provide
skipping to change at page 7, line 36 skipping to change at page 7, line 42
If an external interface becomes internal, the prefix assignment If an external interface becomes internal, the prefix assignment
algorithm MUST be run (see Section 6.1). algorithm MUST be run (see Section 6.1).
Whenever two or more interfaces are connected to the same link, all Whenever two or more interfaces are connected to the same link, all
but one of them SHOULD be ignored by the prefix assignment algorithm. but one of them SHOULD be ignored by the prefix assignment algorithm.
A mechanism to detect such situation SHOULD be provided by the A mechanism to detect such situation SHOULD be provided by the
flooding algorithm. flooding algorithm.
4.3. Obtaining a Delegated Prefix 4.3. Obtaining a Delegated Prefix
A Delegated Prefix can be obtained or generated through different Delegated Prefixes (Of any kind: Global, ULA, IPv4...) can be
means: obtained or generated through different means:
o It can be dynamically delegated, for instance using DHCPv6 PD. o It can be delegated by a service provider (DHCPv6 PD, 6rd
[RFC5969], etc..).
o It can be created statically, specified in router's configuration. o It can be provisioned by an administrative authority (user
configuration, netconf [RFC6241], etc... ).
o A ULA prefix may be spontaneously generated as defined in o A ULA prefix may be spontaneously generated as defined in
Section 9.1. Section 9.1.
o An IPv4 private prefix may be spontaneously generated as defined o An IPv4 private prefix may be spontaneously generated as defined
in Section 9.2. in Section 9.2.
DHCP options MAY be attached to a delegated prefix by the router that DHCP options MAY be attached to a delegated prefix by the router that
either generated the prefix or received it through DHCPv6 PD. IPv6 either generated the prefix or received it through DHCPv6 PD. IPv6
delegated prefix options MUST be encoded as DHCPv6 options. IPv4 delegated prefix options MUST be encoded as DHCPv6 options. IPv4
skipping to change at page 9, line 19 skipping to change at page 9, line 28
router that was already there (doing DHCP). It sees the router that was already there (doing DHCP). It sees the
assigned prefix for their common link, but also has, in its own assigned prefix for their common link, but also has, in its own
configuration, an authoritative assignment for the link. It configuration, an authoritative assignment for the link. It
starts advertising the authoritative assignment, which causes starts advertising the authoritative assignment, which causes
the second router to remove its previous assignment. Thanks to the second router to remove its previous assignment. Thanks to
the inverted order, the DHCP server will remain the same. the inverted order, the DHCP server will remain the same.
4.5.1. Sending Router Advertisement 4.5.1. Sending Router Advertisement
On a given link, the designated router MUST send router On a given link, the designated router MUST send router
advertisements including Prefix Information Options for all the advertisements (RAs) including Prefix Information Options for all the
Chosen Prefixes associated to that link. SLAAC SHOULD be enabled Chosen Prefixes associated to that link. SLAAC SHOULD be enabled
when possible, unless the configuration states otherwise. The valid when possible, unless the configuration states otherwise. Prefixes
and preferred lifetimes MUST be set to values lower or equal to the valid and preferred lifetimes MUST be set to values lower or equal to
associated Delegated Prefix's valid and preferred lifetimes. the associated Delegated Prefix's valid and preferred lifetimes.
Whenever an IPv6 default route is present in the RIB, the designated
router MUST advertise itself as default router by specifying a
strictly positive valid lifetime. Whenever the last default route is
removed, the designated router MUST send an RA with the valid and
preferred lifetimes set to zero.
The designated router MUST advertise itself as a router for all IPv6
delegated prefixes using Route Information Options [RFC4191],
independently of whether there is a default route or not.
4.5.2. DHCP Server Operations 4.5.2. DHCP Server Operations
On a given link, whenever SLAAC can't be used for all assignments, or On a given link, whenever SLAAC can't be used for all assignments, or
DHCP configuration options must be provided to hosts, the designated DHCP configuration options must be provided to hosts, the designated
router MUST act as a DHCP server and serve addresses on the given router MUST act as a DHCP server and serve addresses on the given
link. A router MUST stop behaving as a DHCP server whenever it is link. A router MUST stop behaving as a DHCP server whenever it is
not the link's designated router anymore. not the link's designated router anymore.
Routers's addresses pool, specified in Section 7, MUST be excluded Routers's addresses pool, specified in Section 7, MUST be excluded
skipping to change at page 14, line 47 skipping to change at page 15, line 14
o The same priority. o The same priority.
o The advertised bit value set as specified by the algorithm. o The advertised bit value set as specified by the algorithm.
o The applied bit is unset. It is set when the timer elapsed if the o The applied bit is unset. It is set when the timer elapsed if the
entry still exists. entry still exists.
6.6. Making a New Assignment 6.6. Making a New Assignment
In situations where a router can make an assignment (see
Section 6.9), the following rules are used in the following order:
1. If the configuration specifies a custom behavior (e.g. always
ignore/accept a particular delegated prefix), use the
configuration entry.
2. If the Delegated Prefix Preferred Lifetime is strictly greater
than zero, an assignment MUST be made.
3. If no other prefix has a non-zero Preferred Lifetime, and no
assignment is made on the link, an assignment SHOULD be made.
4. Otherwise, a new assignment SHOULD NOT be made.
When the algorithm decides to make a new assignment, it first needs When the algorithm decides to make a new assignment, it first needs
to specify the desired size of the assigned prefix. Although that to specify the desired size of the assigned prefix. Although this
choice is completely implementation specific, prefixes of size 64 are algorithm intends to remain generic, the use of 64 bits long prefixes
RECOMMENDED. The following table MAY be used as default values, is RECOMMENDED (See [I-D.ietf-6man-why64]). The following table MAY
where X is the length of the delegated prefix. be used as default values, where X is the length of the delegated
prefix.
If X < 64: Prefix length = 64 If X <= 64: Prefix length = 64
If X >= 64 and X < 104: Prefix length = X + 16 (up to 2^16 links) If X >= 64 and X < 104: Prefix length = X + 16 (up to 2^16 links)
If X >= 104 and X < 112: Prefix length = 120 (2^8 addresses per link If X >= 104 and X < 112: Prefix length = 120 (2^8 addresses per link
and more than 2^8 links) and more than 2^8 links)
If X >= 112 and X <= 128: Prefix length = 120 + (X - 112)/2 (Link Vs If X >= 112 and X <= 128: Prefix length = 120 + (X - 112)/2 (Link Vs
Addresses tradeoff) Addresses tradeoff)
When the algorithm decides to make a new assignment, it SHOULD first When the algorithm decides to make a new assignment, it SHOULD first
skipping to change at page 16, line 10 skipping to change at page 16, line 40
entry still exists. entry still exists.
A new assignment is always marked as advertised when created and A new assignment is always marked as advertised when created and
therefore immediately provided to the flooding protocol. therefore immediately provided to the flooding protocol.
6.7. Using Authoritative Prefix Assignments 6.7. Using Authoritative Prefix Assignments
When some authority (Delegating router, system admin, etc...) wants When some authority (Delegating router, system admin, etc...) wants
to manually enforce some behavior, it may ask some router to make an to manually enforce some behavior, it may ask some router to make an
Authoritative Prefix Assignment. Such assignments have their Authoritative Prefix Assignment. Such assignments have their
Authoritative bit set, CAN NOT be overridden, and will appear in Authoritative bit set, SHALL NOT be overridden, and will appear in
other router's database as Assigned Prefixes with the Authoritative other router's database as Assigned Prefixes with the Authoritative
bit set. bit set.
There are two kinds of Authoritative Prefix Assignments. There are two kinds of Authoritative Prefix Assignments.
o When an authority wants to assign some particular prefix to some o When an authority wants to assign some particular prefix to some
interface, an Authoritative Prefix Assignment CAN be created and interface, an Authoritative Prefix Assignment MAY be created and
consists in a Chosen Prefix which have its Authoritative bit set consists in a Chosen Prefix which have its Authoritative bit set
and which is advertised. Just like normal assignments, it MUST and which is advertised. Just like normal assignments, it MUST
NOT be applied before the delay specified in Section 8 elapsed. NOT be applied before the delay specified in Section 8 elapsed.
o When an authority wants to prevent some prefix from being used, an o When an authority wants to prevent some prefix from being used, an
Authoritative Assignment CAN be advertised. Such assignments MUST Authoritative Assignment MAY be advertised. Such assignments MUST
NOT be applied and MUST be advertised through the flooding NOT be applied and MUST be advertised through the flooding
protocol as assigned to either no-interface, or a fake interface protocol as assigned to either no-interface, or a fake interface
(Depending on the flooding protocol's capabilities). (Depending on the flooding protocol's capabilities).
When a delegated prefix is obtained through DHCPv6 PD with a non- When a delegated prefix is obtained through DHCPv6 PD with a non-
empty excluded prefix, as specified in [RFC6603], an Authoritative empty excluded prefix, as specified in [RFC6603], an Authoritative
Prefix Assignment MUST be created with the excluded prefix. Prefix Assignment MUST be created with the excluded prefix.
Note: If the router doesn't understand the excluded prefix DHCPv6 Note: If the router doesn't understand the excluded prefix DHCPv6
option, the delegated prefix is ignored, as specified in option, the delegated prefix is ignored, as specified in
skipping to change at page 17, line 35 skipping to change at page 18, line 18
o Look for a valid Assigned Prefix, advertised by another router on o Look for a valid Assigned Prefix, advertised by another router on
the current interface and included in the current Delegated the current interface and included in the current Delegated
Prefix. Prefix.
o Look for a Chosen Prefix associated to the current interface and o Look for a Chosen Prefix associated to the current interface and
included in the current Delegated Prefix. included in the current Delegated Prefix.
o There are four possibilities at this stage. o There are four possibilities at this stage.
1. If no AP is found, and no CP is found, a new assignment MUST 1. If no AP is found, and no CP is found, a new assignment can be
be made if and only if the router considers itself as the made if and only if the router considers itself as the
designated router. See Section 6.6. designated router. Whether to create an assignment or not,
and which prefix to use, is specified in Section 6.6.
2. If an AP is found, and no CP is found, the AP MUST be 2. If an AP is found, and no CP is found, the AP MUST be
accepted. The new CP's advertised bit MUST be set if and only accepted. The new CP's advertised bit MUST be set if and only
if the router considers itself as the designated router. if the router considers itself as the designated router.
3. If no AP is found, and a CP is found, the router MUST check if 3. If no AP is found, and a CP is found, the router MUST check if
the CP's assignment is valid. If it is, the local assignment the CP's assignment is valid. If it is, the local assignment
is marked as valid and advertised. If it isn't, it is is marked as valid and advertised. If it isn't, it is
destroyed and the algorithm applies case 1. destroyed and the algorithm applies case 1.
skipping to change at page 19, line 11 skipping to change at page 19, line 41
o IPv4 addresses are needed (DHCPv4, v4 link-local connectivity, o IPv4 addresses are needed (DHCPv4, v4 link-local connectivity,
etc...). etc...).
When possible, SLAAC MUST be used. In other cases a different When possible, SLAAC MUST be used. In other cases a different
mechanism is necessary for routers to get addresses. This document mechanism is necessary for routers to get addresses. This document
proposes an Address Assignment Algorithm that extends the Prefix proposes an Address Assignment Algorithm that extends the Prefix
Assignment Algorithm and works as follows. Each prefix assignment is Assignment Algorithm and works as follows. Each prefix assignment is
associated with a fixed address pool, reserved for router's addresses associated with a fixed address pool, reserved for router's addresses
assignment. The address pool is a prefix which value is assignment. The address pool is a prefix which value is
deterministically function of the assigned prefix. A router CAN, at deterministically function of the assigned prefix. A router MAY, at
any time, decide to assign itself an address from any of its Chosen any time, decide to assign itself an address from any of its Chosen
Prefixes. Just like prefix assignments, address assignments are Prefixes. Just like prefix assignments, address assignments are
advertised to other routers and collisions are detected. Routers advertised to other routers and collisions are detected. Routers
MUST keep track of Address Assignments made by other routers on MUST keep track of Address Assignments made by other routers on
connected links by using information provided by the flooding connected links by using information provided by the flooding
algorithm, as defined in Section 5.5. algorithm, as defined in Section 5.5.
7.1. Router's address pools 7.1. Router's address pools
Given an assigned prefix A/X (where all A's latest '128 - X'th bits Given an assigned prefix A/X (where all A's latest '128 - X'th bits
are set to 0), the routers reserved address pool is defined as are set to 0), the routers reserved address pool is defined as
follows: follows:
If X <= 64: SLAAC MUST be used If X <= 64: SLAAC MUST be used
If X > 64 and X <= 110: The pool is A/112 (2^16 addresses) If X > 64 and X <= 110: The pool is A/112 (2^16 addresses)
If X >= 110 and X <= 126: The pool is A/(X + 2) (One quarter of the If X >= 110 and X <= 126: The pool is A/(X + 2) (One quarter of the
available addresses) available addresses)
If X >= 126: Only the designated router CAN use A/128. Other If X >= 126: Only the designated router MAY use A/128. Other
routers MUST NOT get an address. routers MUST NOT get an address.
In the case of IPv4 prefixes, the network address (first address of In the case of IPv4 prefixes, the network address (first address of
the address pool) MUST not be used. the address pool) MUST not be used.
7.2. Address Assignment Algorithm 7.2. Address Assignment Algorithm
In this section, we say an address assignment is made by some router In this section, we say an address assignment is made by some router
when it intends to use, or is using the address specified by this when it intends to use, or is using the address specified by this
assignment. An assignment, made by some router, MUST be advertised assignment. An assignment, made by some router, MUST be advertised
skipping to change at page 20, line 29 skipping to change at page 21, line 15
An address assignment must be deleted whenever one of the following An address assignment must be deleted whenever one of the following
condition becomes true. condition becomes true.
o The associated Chosen Prefix is deleted or moved to another link. o The associated Chosen Prefix is deleted or moved to another link.
o Some other router with a higher router ID is advertising the same o Some other router with a higher router ID is advertising the same
address on the same link. address on the same link.
8. Hysteresis Principle 8. Hysteresis Principle
The IPv6 Stateless Address Autoconfiguration [RFC4862] states that
host addresses can be kept up to 2 hours after a Router Advertisement
wit zero lifetime is received. Therefore, routers must be carefull
before assigning or deprecating a prefix.
8.1. Prefix and Address assignments 8.1. Prefix and Address assignments
When the flooding protocol is started, the router MUST wait When the flooding protocol is started, the router MUST wait
FLOODING_DELAY before executing the prefix assignment algorithm for FLOODING_DELAY before executing the prefix assignment algorithm for
the first time. the first time.
Prefix and address assignment algorithms are distributed. Collisions Prefix and address assignment algorithms are distributed. Collisions
may occur, but network configuration, routing protocols or upper may occur, but network configuration, routing protocols or upper
layers should not suffer from these collisions. For this reason, all layers should not suffer from these collisions. For this reason, all
assignments that could imply collisions are not immediately applied. assignments that could imply collisions are not immediately applied.
skipping to change at page 20, line 50 skipping to change at page 21, line 41
o A router MUST NOT apply a Chosen Prefix before it has waited o A router MUST NOT apply a Chosen Prefix before it has waited
2*FLOODING_DELAY. If the entry is valid during the whole waiting 2*FLOODING_DELAY. If the entry is valid during the whole waiting
time, it MUST be applied to the link it is assigned. time, it MUST be applied to the link it is assigned.
o A router MUST NOT apply an Assigned Address before it has waited o A router MUST NOT apply an Assigned Address before it has waited
2*FLOODING_DELAY_LL. If the assignment is valid during the whole 2*FLOODING_DELAY_LL. If the assignment is valid during the whole
waiting time, it MUST be applied to the interface it is assigned. waiting time, it MUST be applied to the interface it is assigned.
8.2. Delegated Prefixes 8.2. Delegated Prefixes
Some links may be unreliable, causing repetitive connectivity loss.
Such links shouldn't cause IP reconfiguration.
8.2.1. Unreliable uplink
When a router detects uplink connectivity loss, Delegated Prefixes'
lifetimes from prefixes obtained through the uplink MUST be modified
in the following way.
o The Preferred Lifetime is set to 0.
o The Valid Lifetime is set to the minimum between the current Valid
Lifetime and two hours.
o The default route associated with the prefix is not advertised
anymore.
This behavior is similar to [RFC7084] specifications and provides
stable host configuration in case of unreliable uplink.
8.2.2. Unreliable in-home link
When a router stops advertising a Delegated Prefix, it MUST first When a router stops advertising a Delegated Prefix, it MUST first
deprecate that Delegated Prefix by advertising it for deprecate that Delegated Prefix by advertising it for
DP_DEPRECATE_FACTOR*FLOODING_DELAY seconds with zero valid and DP_DEPRECATE_FACTOR*FLOODING_DELAY seconds with zero valid and
preferred lifetimes. preferred lifetimes.
When a router receives a deprecated Delegated Prefix advertisement, When a router receives a deprecated Delegated Prefix advertisement
it must remove the Delegated Prefix from its Delegated Prefixes list. from the Flooding Protocol, it MUST remove the Delegated Prefix from
its Delegated Prefixes list.
When a router stops receiving a Delegated Prefix from the Flooding When a router stops receiving a Delegated Prefix from the Flooding
Protocol, it SHOULD keep using that delegating prefix up to a period Protocol, it SHOULD keep using that delegating prefix up to a period
of min(remaining lifetime, DP_KEEP_ALIVE_TIME) seconds. of min(remaining Valid Lifetime, DP_KEEP_ALIVE_TIME) seconds.
9. ULA and IPv4 Prefixes Generation 9. ULA and IPv4 Prefixes Generation
Although DHCPv6 PD and static configuration are regular means of Although DHCPv6 PD and static configuration are regular means of
obtaining IPv6 prefixes, routers MAY, in some cases, autonomously obtaining IPv6 prefixes, routers MAY, in some cases, autonomously
decide to generate a delegated prefix. In this section are specified decide to generate a delegated prefix. In this section are specified
when and how IPv6 ULA prefixes and IPv4 private prefixes may be when and how IPv6 ULA prefixes and IPv4 private prefixes may be
autonomously generated. autonomously generated.
9.1. ULA Prefix Generation 9.1. ULA Prefix Generation
A router MAY generate a ULA prefix when the two following conditions ULA prefixes can be randomly generated as specified in [RFC4193],
are met. enabling stable in-home IPv6 connectivity.
o It is the Network Leader (Section 4.4). In this section, we say a ULA delegated prefix is 'stable' if it has
been the only advertised ULA delegated prefix for at least
2*FLOODING_DELAY seconds. The behaviour specified in the following
sections tend to reuse a stable ULA prefix as long as its preferred
lifetime is not null.
o No other ULA delegated prefix is advertised by any other router. Additionaly, we say a router is the owner of a spontaneously
generated ULA prefix if it randomly created the prefix in the first
place. A router SHOULD NOT create more than one prefix this way, and
MUST remember all the prefixes they own. As stated in the following
sections, only the owner of a prefix can extend its lifetimes.
A router MUST stop advertising a spontaneously generated ULA prefix 9.1.1. Choosing the ULA prefix
whenever another router is advertising a ULA delegated prefix.
The most recently used ULA prefix SHOULD be stored in stable storage When a stable ULA prefix is advertised, all routers SHOULD remember
by all routers and reused whenever choosing a new ULA delegated that prefix alongwith its associated valid and preferred lifetime.
prefix. If no ULA prefix can be found in stable storage, it MUST be If this prefix stops being advertised (e.g. due to a network split)
randomly generated, or generated from hardware specific values. while its preferred lifetime is not null, the same ULA prefix SHOULD
be selected using the same valid and preferred lifetimes.
If there was no stable ULA prefix advertised, or if the preferred
lifetime of the prefix was null, a prefix generated as specified in
[RFC4193] SHOULD be used. In case the stable storage can't be used
or the current date cannot be determined, the prefix MAY be pseudo-
randomly generated based on hardware specific values.
9.1.2. Advertising a ULA prefix
A router MAY start advertising a ULA prefix whenever the two
following conditions are met:
o It is the network leader.
o There is no other advertised ULA prefix.
If no IPv6 prefix is available at all, the network leader SHOULD
start advertising a ULA delegated prefix.
Additionaly, a router SHOULD start advertising its own ULA prefix
whenever the three following conditions are met:
o A stable ULA prefix is advertised by another router.
o The router owns the advertised stable ULA prefix.
o The preferred lifetime of the advertised ULA prefix is below 10
minutes.
This allows a router to restart advertising a owned prefix whenever
the preferred lifetime is approaching zero. Which later allows him
to extend the lifetime of the prefix.
A router MUST stop advertising a spontaenously generated ULA prefix
whenever one of the two following condition is met:
o A different ULA prefix is being advertised.
o The same prefix is advertised by another router, and the router
doesn't own that prefix.
9.1.3. Extending prefix lifetime
Routers MUST regularly extend the valid and preferred lifetimes of
the ULA delegated prefix they advertise and own, so that they never
drop to zero.
When a router advertises a prefix it doesn't own, lifetimes are never
extended. When the preferred lifetime of the prefix approaches zero,
either the owner of the prefix will start advertising the prefix with
a non-zero preferred lifetime, or a new prefix will be generated.
9.1.4. Authoritative ULAs
This section doesn't prevent multiple ULA prefixes from existing
simultaneously. ULA prefixes may be provided by different means, as
specified in Section 4.3. Delegated prefixes that are delegated by a
service provider or provisioned by an authority differ from
'spontaneously' generated prefixes. They MUST NOT be withdrawn if
another ULA delegated prefix is observed.
When at least one of such ULA prefixes is used, spontaneously
generated ULA prefixes are withdrawned.
9.2. IPv4 Private Prefix Generation 9.2. IPv4 Private Prefix Generation
A router MAY generate an IPv4 prefix when the two following A router MAY generate an IPv4 prefix when the two following
conditions are met. conditions are met.
o It has an IPv4 address with global connectivity. o It has an IPv4 address with global connectivity.
o No other IPv4 delegated prefix is advertised by any other router. o No other IPv4 delegated prefix is advertised by any other router.
skipping to change at page 24, line 9 skipping to change at page 26, line 47
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[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.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
skipping to change at page 24, line 44 skipping to change at page 27, line 37
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008. 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", RFC
5969, August 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[I-D.ietf-homenet-arch] [I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-11 (work in progress), October 2013. ietf-homenet-arch-11 (work in progress), October 2013.
[I-D.ietf-homenet-hncp] [I-D.ietf-homenet-hncp]
Stenberg, M. and S. Barth, "Home Networking Control Stenberg, M. and S. Barth, "Home Networking Control
Protocol", draft-ietf-homenet-hncp-00 (work in progress), Protocol", draft-ietf-homenet-hncp-00 (work in progress),
April 2014. April 2014.
[I-D.ietf-ospf-ospfv3-autoconfig] [I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-06 (work in progress), draft-ietf-ospf-ospfv3-autoconfig-06 (work in progress),
February 2014. February 2014.
[I-D.ietf-6man-why64]
Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", draft-ietf-6man-why64-06 (work in
progress), October 2014.
[I-D.arkko-homenet-prefix-assignment] [I-D.arkko-homenet-prefix-assignment]
Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment
in a Home Network", draft-arkko-homenet-prefix- in a Home Network", draft-arkko-homenet-prefix-
assignment-04 (work in progress), May 2013. assignment-04 (work in progress), May 2013.
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05 based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013. (work in progress), July 2013.
 End of changes. 38 change blocks. 
68 lines changed or deleted 218 lines changed or added

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