| Network Working Group | P. Pfister |
| Internet-Draft | B. Paterson |
| Intended status: Standards Track | Cisco Systems |
| J. Arkko | |
| Ericsson | |
| Feb 2014 |
Prefix and Address Assignment in a Home Network
draft-pfister-homenet-prefix-assignment-00
This memo describes a home network prefix and address assignment algorithm running on top of any 'flooding protocol' that fulfills the specified requirements. It is expected that home border routers are allocated one or multiple IPv6 prefixes through DHCPv6 Prefix Delegation (PD) or that prefixes are made available through other means. An IPv4 address can also be assigned and private addresses be used with NAT to provide IPv4 connectivity. In both cases, provided prefixes need to be efficiently divided among the multiple links and routers need to obtain addresses. This document describes a distributed algorithm for IPv4 and IPv6 prefixes division, assignment and router's address assignment, and specifies how hosts can be given addresses and configuration options using DHCP or SLAAC.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This memo describes a fully distributed prefix and address assignment algorithm for home networks, running on top of any 'flooding protocol' that fulfills the specified requirements. It is expected that home border routers are allocated one or multiple IPv6 prefixes through DHCPv6 Prefix Delegation (PD) [RFC3633] or that prefixes are made available through other means. When an IPv4 address is assigned, a home private IPv4 prefix may be used with NAT to provide IPv4 connectivity to the whole home, as well as Unique Local Address prefixes [RFC4193] may be used in order to provide internal connectivity whenever global IPv6 connectivity is lost.
Obtained IPv6 or IPv4 prefixes need to be efficiently divided among the multiple links. For the purposes of this document, we refer to this process as prefix assignment. This memo describes an algorithm for such prefix division, assignment and router's address assignment, as well as the way hosts can be given addresses and configuration options using DHCP or SLAAC.
Although this document recommends the use of 64 bits long prefixes, the algorithm do not require routers to assign prefixes of particular lengths. When a delegated prefix is too small considered the number of links in the home network, higher priority links may be privileged or smaller prefixes can be assigned in order to avoid prefix scarcity.
The rest of this memo is organized as follows. Section 2 defines the usual keywords, Section 3 outlines the algorithms functioning and features, Section 4 describes how a home router behaves when running the prefix and address assignment algorithm. Requirements for the underlying flooding protocol are detailed in Section 5. The prefix assignment algorithm is detailed in Section 6 and Section 7 focuses on the address assignment algorithm. Section 8 explains the hysteresis principles applied to both prefix and address assignments, Section 9 specifies the procedures for automatic generation of ULA and IPv4 prefixes, Section 10 explains what administrative interfaces are useful for advanced users that wish to manually interact with the mechanisms, Section 12 discusses the security aspects and finally, Appendix A provides implementation guidelines for the optional scarcity avoidance mechanism.
The Prefix Assignment Algorithm functioning was first detailed in [I-D.arkko-homenet-prefix-assignment]. This document is a continuation and generalization of that draft to any underlying flooding protocol. It also adds a some features like arbitrary lengths prefixes support, IPv4 support, scarcity avoidance mechanism support or manual configuration support.
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
Given one or multiple prefixes for the entire network, each prefix is subdivided by the prefix assignment algorithm so that every link is given one assignment per available prefix. Assignments are advertised through the whole network using the underlying flooding protocol, collisions are detected and valid assignments are chosen and applied on every link. Once a prefix is applied, hosts and routers may start to be given addresses. In summary, the algorithm works in four steps:
This algorithm, which intends to fulfill requirements specified in [I-D.ietf-homenet-arch], have the following features:
In a home network, all routers that want to participate in the prefix assignment algorithm MUST fulfill the requirements defined in this document. They MUST also use the same flooding protocol and routing protocol. The presence of an internal router that do not implement the flooding protocol and prefix assignment algorithm will not prevent the network from working as long as:
The router MUST maintain a list of all the Delegated Prefixes. These prefixes may be locally generated, as described in Section 4.3, or come from other routers as described in Section 5.4.
The router MUST maintain a list of all the Assigned Prefixes advertised by other routers. They are learnt through the mechanisms described in Section 5.3 and MUST contain the following information:
The AP list is the result of the information provided by the flooding protocol, as specified in Section 5.3.
The router MUST maintain a list of all prefixes currently chosen to be applied on connected links. They are called Chosen Prefixes (CPs) and MUST contain the following information:
Chosen Prefixes that are marked as 'Advertised' are sent to other routers through the flooding protocol, and are therefore considered as Assigned Prefixes by other routers. The Prefix Assignment Algorithm goal is to make sure that all routers, on each link, select the same set of Chosen Prefixes.
The router MUST maintain a database of all its own address assignments, and address assignments made by other routers on connected links. The latter are learned through the mechanisms described in Section 5.5.
Each router's interface MUST either be considered as internal or external. Prefixes or addresses are only assigned to internal interfaces. The way an interface is selected as internal or external is out of the scope of this document.
If an internal interface's state is changed to external, all prefixes and addresses assigned on the considered interface MUST be deleted, and the prefix assignment algorithm MUST be run.
If an external interface's state is changed to internal, the prefix assignment algorithm MUST be run.
A Delegated Prefix can be obtained or generated through different means:
DHCP options MAY be attached to a delegated prefix by the router that either generated the prefix or received it through DHCPv6 PD. When the delegated prefix is IPv6, the options MUST be encoded as DHCPv6 options. When the delegated prefix is IPv4, the options MUST be encoded as DHCPv4 options.
As DHCP options are numerous and new one may be defined, specifying routers' behavior regarding each option is out of the scope of this document. In order to avoid misconfiguration, routers must follow the two following general rules:
On a link where custom host configuration must be provided, or whenever SLAAC cannot be used, a DHCP server must be elected. That router is called designated router and is dynamically chosen by the prefix assignment algorithm.
A router MUST consider itself as a designated router on a given link if one of the two following conditions is true:
On a given link, the designated router MUST send router advertisements including Prefix Information Options for all the Chosen Prefixes associated to that link. SLAAC MAY be enabled depending on the router's configuration and assignments prefix length. The valid and preferred lifetimes MUST be set to values lower or equal to the associated Delegated Prefix's valid and preferred lifetimes.
On a given link, whenever SLAAC can't be used for all assignments, or DHCP configuration options must be provided to hosts, the designated router MUST act as a DHCP server on the given link and serve addresses for all assignments on the given link. A router MUST stop behaving as a DHCP server whenever it is not the link's designated router anymore.
Routers's addresses pool, specified in Section 7, MUST be excluded from DHCP hosts pools.
The valid and preferred lifetimes MUST be set to values lower or equal to the associated Delegated Prefix's valid and preferred lifetimes.
Once a Chosen Prefix is created, a router first waits some time in order to detect possible collisions (Section 8). Once the timeout is elapsed and no collision is detected, the prefix is applied by executing the following steps:
When a prefix assignment is removed, the previous steps MUST be undone in the reverse order. The router MUST also deprecate the prefix, if it had been advertised in Router Advertisements on an interface. The prefix is deprecated by sending Router Advertisements with the lifetime set to 0 [RFC4861] for the considered prefix. Hosts that support DHCP reconfigure extension and that have been given leases MUST be reconfigured as well [RFC3203].
DHCP options attached to each delegated prefixes and propagated through the flooding protocol SHOULD contain the DHCP DNS option provided by the ISP (when provided).
Whenever the router knows which DNS server to use, or is acting as a DNS relay, it SHOULD include DNS DHCPv6 option ([RFC3646]) along-with host's configuration messages and include the Router Advertisement DNS options ([RFC6106]) when sending RAs.
DNS server selection in multi-homed networks is a complex issue that this document doesn't intend to solve. One should look at IETF's mif working-group documents in order to obtain guidelines concerning DNS server selection. It is RECOMMENDED that designated routers turns on a local DNS relay that fetches information from provided DNS servers.
In this document, the Flooding Protocol (FP) refers to a protocol enabling information propagation to the whole network. It was not specified in order to allow the working group to independently decide which routing protocol, configuration protocol, and prefix assignment method to use within the home network. Routing protocol, like OSPF or ISIS, could be extended in order to fulfill the requirements, as well as new dedicated and optimized protocols could be proposed.
The specified algorithm can use any protocol that fulfills the requirements specified in this section.
The FP MUST provide a router ID. IDs collisions within the network MUST be rare and, when a collision occurs, the conflict MUST be resolved by the flooding protocol. When the router ID is changed, the FP MUST immediately provide the new ID to the Prefix Assignment Algorithm, which will in turn be run again, without requiring the current state to be flushed.
In the absence of collisions, the router ID MUST NOT be changed, and it SHOULD be stable across reboots, power cycling and router software updates.
The FP MUST provide an approximate upper bound of the time it takes for an update to be propagated to the whole network. This value is referred to as the FLOODING_DELAY. The algorithm ensures that, as long as the upper bound is respected, two identical prefixes will never be applied to different links, and two different prefixes will never be applied to the same link. The algorithm and the network will recover when the upper bound is exceeded, but collisions may appear in the routing protocol and errors may be propagated to upper layers.
If the FP supports link-local flooding, which is used for router's address assignments, it SHOULD provide an approximate upper bound of the time it takes for an update to be propagated to a single link. This value is referred to as the FLOODING_DELAY_LL. If link-local flooding is not available, or the value is not provided, the assignment algorithm MUST use the FLOODING_DELAY value instead.
The FP MUST provide a way to flood Chosen Prefixes marked as advertised and retrieve prefixes assigned by other routers (APs). Retrieved APs MUST contain all the information specified in Section 4.1.
The FP must provide a way to flood Delegated Prefixes and retrieve prefixes delegated to other routers. Retrieved entries must contain the following information.
The FP MUST make sure time values are consistent throughout the network (i.e. differences are small compared to Delegated Prefixes lifetimes). If no time synchronization protocol is used, the FP MUST keep track of prefix age across the network and within its database.
Routers addresses are dynamically allocated, picked in defined pools, and collisions must be detected using the FP. The FP MUST provide a way to flood routers' addresses. The flooding scope of those values SHOULD be link-local, but as addresses are unique within the home network, this is not mandatory. For each address assignment, the FP SHOULD provide the identifier of the interface connected to the link the address assignment was advertised on.
The Prefix Assignment Algorithm is a distributed algorithm that assigns one prefix from each available Delegated Prefix on every link that is considered as internal by at least one connected router. The algorithm itself makes no difference whether the delegated prefix is global IPv6, ULA or IPv4. IPv4 prefixes are written in their IPv4-mapped IPv6 form, as defined in [RFC4291] (i.e. ::ffff:A.B.C.D/X with X >= 96).
When the Prefix Assignment Algorithm is executed, combinations of Delegated Prefixes and internal interfaces are being considered. If a delegated prefix contains another delegated prefix, it is ignored. For the purpose of this discussion, the Aggregated Prefix will be referred to as the current Aggregated Prefix, and the interface will be referred to as the current Interface.
The algorithm MUST be run whenever one of the following event occurs:
It is not required that the algorithm is synchronously run each time such an event occurs. But the delay between the event and the algorithm execution MUST be small compared to FLOODING_DELAY.
An assignment is said to take precedence over another assignment when:
An Assigned Prefix or a Chosen Prefix is said to be valid if all the following conditions are met:
A prefix is said to be available if it is not included and does not include any other assignment made by any router in the network.
An AP is said to be accepted when the AP is currently being advertised by a different router, and will be used by the accepting router as a new Chosen Prefix. When a router accepts a neighbor's assignment, it starts a timer as specified in Section 8. A new CP is created from the AP, with:
When the algorithm decides to make a new assignment, it first needs to specify the desired size of the assigned prefix. Although that choice is completely implementation specific, prefixes of size 64 are RECOMMENDED. The following table MAY be used as default values, where X is the length of the delegated prefix.
When the algorithm decides to make a new assignment, it looks in the stable storage for an available assignment that was previously applied on the current interface and that is included in the current delegated prefix. If no available assignment can be found this way, the new prefix MUST be randomly selected among prefixes in the current Delegated Prefix that are still available. Implementing a uniform selection among all available prefixes may be challenging, but an implementation SHOULD at least be able to make an exhaustive search when the address space is small, and make multiple tentatives when the address space is too big.
If no available prefix is found, the assignment fails. If implemented, the router MAY decide to execute the Prefix Scarcity Avoidance mechanisms, as proposed in Appendix A.
When a new assignment is made, a new Chosen Prefix entry is created.
A new assignment is always marked as advertised when created and therefore immediately provided to the flooding protocol.
When some authority (Delegating router, system admin, etc...) wants to manually enforce some behavior, it may ask some router to make an Authoritative Prefix Assignment. Such assignments have their Authoritative bit set, CAN NOT be overridden, and will appear in other router's database as Assigned Prefixes with the Authoritative bit set.
There are two kinds of Authoritative Prefix Assignments.
When a delegated prefix is obtained through DHCP PD with a non-null excluded prefix, as specified in [RFC6603], an Authoritative Prefix Assignment MUST be created with the excluded prefix.
When either a new Prefix Assignment is made, or an Authoritative Prefix Assignment is created, the creating router needs to choose which priority value to use. The assignment priority is kept by the designated router when it starts advertising the assignment, and is an interesting feature when not enough prefixes are available.
In this section are detailed the steps of the Prefix Assignment Algorithm.
At the beginning of the algorithm, all assignments that do not have their Authoritative bit set are marked as 'invalid', and the router computes for each link whether it is the designated router.
The following steps are then executed for every combination of delegated prefix and interface.
In the end of the algorithm, all the assignments that are marked as invalid are deleted.
IPv6 routers always get at least one link-local address per link. Routing protocols and link DHCP servers are able to run with these addresses. In some cases though, a router may need to take one or multiple addresses among one or multiple available Delegated Prefixes. For example:
When possible, SLAAC MUST be used. In other cases a different mechanism is necessary for routers to get addresses. This document proposes an Address Assignment Algorithm that extends the Prefix Assignment Algorithm and works as follows. Each prefix assignment is associated a fixed address pool, reserved for router's addresses assignment. The address pool is a prefix whose value is deterministically function of the assigned prefix. A router CAN, at any time, decide to assign itself an address from any of its Chosen Prefixes. Just like prefix assignments, address assignments are advertised to other routers and collisions are detected. Routers MUST keep track of Address Assignments made by other routers on connected links by using information provided by the flooding algorithm, as defined in Section 5.5.
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 following:
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 assignment. An assignment, made by some router, MUST be advertised on the link on which the assignment is made. Similarly, an address assignment is said to be applied when the address is pushed to the router's interface configuration. It is unapplied otherwise.
Routers MUST store applied address assignments in stable storage and reuse the same addresses whenever possible. At least the five previously applied addresses should be stored.
For a given prefix assignment, an address is said to be available if it is within the router's address pool associated to the prefix assignment, and it is not being advertised by any other router. If the flooding protocol provides interface identifier along-with address assignments, looking for collisions on considered link is enough.
A new address assignment MUST be chosen randomly among available addresses. An address assignment MUST NOT be applied when one of the following condition is true.
An address assignment must be deleted whenever one of the following condition becomes true.
When the flooding protocol is started, the router MUST wait FLOODING_DELAY before executing the prefix assignment algorithm for the first time.
Prefix and address assignment algorithms are distributed. Collisions may occur, but network configuration, routing protocols or upper layers should not suffer from these collisions. For this reason, all assignments that could imply collisions are not immediately applied.
Although DHCPv6 PD and static configuration are regular means of obtaining IPv6 prefixes, routers MAY, in some cases, autonomously decide to generate a delegated prefix. In this section are specified when and how IPv6 ULA prefixes and IPv4 private prefixes may be autonomously generated.
A router MAY generate a ULA prefix when the two following conditions are met.
A router MUST stop advertising a spontaneously generated ULA prefix whenever another router is advertising a ULA delegated prefix.
The more recently used ULA prefix SHOULD be stored in stable storage by all routers and reused whenever choosing a new ULA delegated prefix. If no ULA prefix can be found in stable storage, it MUST be randomly generated, or generated from hardware specific values.
A router MAY generate an IPv4 prefix when the two following conditions are met.
A router MUST stop advertising an IPv4 prefix whenever another router with an higher router ID is advertising an IPv4 Delegated Prefix.
The IPv4 private prefix must be included in one of the private prefixes defined in [RFC1918]. The prefix 10/8 SHOULD be used by default but it SHOULD be configurable. In the case the address provided by the ISP is already a private address, a different private prefix SHOULD be used. For instance, if the ISP is giving the address 10.1.2.3, 10/8 or any sub-prefix included in 10/8 SHOULD NOT be used. 172.16/12 MAY be selected instead.
The algorithm leaves much place to implementation specific features. For instance, ULA prefix as well IPv4 prefix generation may be disabled whenever a global IPv6 is made available. This section details a few other possible configuration options.
The implementation MAY allow each internal interface to be configured with a custom priority value. The specified priority SHOULD then be used when creating new assignments on the given interface. If not specified, the default priority SHOULD be used.
The implementation SHOULD allow manual assignments on given links. When specified, and whenever such an assignment is valid, it MUST be advertised as Authoritative Assignments on the given interface.
PRIORITY_MIN 0 PRIORITY_AUTHORITY_MIN 4 PRIORITY_AUTO_MIN 6 PRIORITY_DEFAULT 8 PRIORITY_AUTO_MAX 10 PRIORITY_AUTHORITY_MAX 12 PRIORITY_MAX 15
Prefix assignment algorithm security entirely relies on flooding protocol security features. The flooding protocol SHOULD therefore check for advertised information's authenticity. Security modes may be classified in three categories.
Whenever a malicious router attacks an unprotected network, or whenever a malicious router is able to authenticate itself to a network as stated in the second case, it may for example:
If a malicious router is able to authenticate itself in a network protected as in the third case, most of the previously listed attacks may still be performed, but traffic could only be redirected toward the origination of the attack, and the source of the attack could identified.
In any case, in order to protect the network, the routing protocol as well as the way hosts are configured also needs to be protected, hence requiring other link (e.g. WPA) or IP layer (e.g. IPSec or SeND) security solutions.
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. |
| [I-D.ietf-homenet-arch] | Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, "IPv6 Home Networking Architecture Principles", Internet-Draft draft-ietf-homenet-arch-11, October 2013. |
| [I-D.dimitri-zospf] | Dimitrelis, A. and A. Williams, "Autoconfiguration of routers using a link state routing protocol", Internet-Draft draft-dimitri-zospf-00, October 2002. |
| [I-D.chelius-router-autoconf] | Chelius, G., Fleury, E. and L. Toutain, "Using OSPFv3 for IPv6 router autoconfiguration", Internet-Draft draft-chelius-router-autoconf-00, June 2002. |
| [I-D.arkko-homenet-prefix-assignment] | Arkko, J., Lindem, A. and B. Paterson, "Prefix Assignment in a Home Network", Internet-Draft draft-arkko-homenet-prefix-assignment-04, May 2013. |
When not enough addresses are available, a router may decide to execute procedures intended to avoid prefix scarcity. Different approaches are possible. This section intends to provide guidelines for such procedures implementation. They are optional and are compatible with routers that only support basic requirements defined in this document.
When a new assignment can't be created, and if not forbidden by the router's configuration, the router MAY increase the size of the desired prefix. For instance, if an available /64 can't be found, the router may look for a /80. Nevertheless, this imply using DHCPv6 instead of SLAAC, which SHOULD be avoided.
The previously proposed solution may be useful in some particular cases, but won't work when no more prefixes are available. A router MAY try to detect when default length prefixes are becoming rare. In such a situation, it MAY decide to allocate a longer prefix, part of an available shorter prefix. For instance, if A/64 is available, but there are not many other available /64, the router can try to allocate A/80. If the allocation doesn't raise any collision, this procedure will prevent A/64 from being used by other hosts, hence creating a large set of smaller available prefixes to be used.
Such an allocation is considered as dynamic. The Authoritative bit MUST NOT be set and the priority MUST be among values authorized as dynamically chosen in Section 6.8.
When different prefixes lengths are being used, the random prefix selection MUST NOT be uniform among all possibilities. Instead, it SHOULD privilege prefixes contained in bigger prefixes that cannot be allocated. For instance, if 2001::/56 is the DP, and 2001:0:0:0:1::/80 is an assigned prefix, other /80 should be randomly chosen in 2001:0:0:0:1::/64 before being chosen in other /64s.
When specifically required by an authority (configuration or DHCP), a router MAY decide to un-assign one of its own assignment, in order to cut it in smaller prefixes, or to send an overriding assignment in order to force the network to stop using a particular prefix. Because such a procedure may imply links reconfiguration, it SHOULD be avoided as much as possible.
Such allocation are considered as required by an authority. The Authoritative bit MAY be set and the priority MUST be among values authorized as specified by an authority in Section 6.8.
As an example, if a router can't find a /64 for a link that, with a high priority, must be given a /64, it chooses a prefix assigned by some other router, to another link, with a lower priority, and creates a new Chosen Prefix with an higher priority. The other router will be forced to remove its own assignment, hence making the new assignment valid.
This document is the continuation of the work being done in [I-D.arkko-homenet-prefix-assignment]. The authors would like to thank all the people that participated in the previous document's development as well as the present one. In particular, the authors would like to thank to Tim Chown, Fred Baker, Mark Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Markus Stenberg, Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik Nordmark, Laurent Toutain, Ralph Droms, Acee Lindem and Steven Barth for interesting discussions in this problem space. The authors would also like to point out some past work in this space, such as those in [I-D.chelius-router-autoconf] or [I-D.dimitri-zospf].