Prefix Assignment in a Home NetworkEricssonJorvas02420Finlandjari.arkko@piuha.netEricssonCary, NC27519USAacee.lindem@ericsson.comIPv6HomenetPrefix AssignmentThis memo describes a prefix assignment mechanism for home
networks. It is expected that home gateway routers are assigned an
IPv6 prefix through DHCPv6 Prefix Delegation (PD). This prefix needs
to be divided among the multiple subnets in a home network. This memo
describes a mechanism for such division via OSPFv3. This is an
alternative design to using DHCPv6 PD also for the prefix
assignment. The memo is input to the working group so that it can make
a decision on which type of design to pursue. It is expected that a
routing-protocol based assignment uses a minimal amount of
prefixes.This memo describes a prefix assignment mechanism for home
networks. It is expected that home gateway routers are assigned an
IPv6 prefix through DHCPv6 Prefix Delegation (PD) , or in some cases manually configured. This prefix
needs to be divided among the multiple subnets in a home network. This
memo describes a mechanism for such division via OSPFv3 .The OSPv3-based mechanism is an alternative design to using DHCPv6
PD also for the prefix assignment in the internal network. This memo
has been written so that the working group can make a decision on
which type of design to pursue. The main benefit of using a routing
protocol to handle the prefix assignment is that it can provide a more
efficient allocation mechanism than hierarchical assignment through
DHCPv PD. This may be important for home networks that get only a /60
allocation from their ISPs.The rest of this memo is organized as follows.
defines the usual keywords, explains the main
requirements for prefix assignments, describes
how a home gateway router makes assignments when it itself has
multiple subnets, and describes how the
assignment can be performed in a distributed manner via OSPFv3 in the
entire home network. Finally, explains what
administrative interfaces are useful for advanced users that wish to
manually interact with the mechanisms, discusses
the security aspects of the design, and
explains the necessary IANA actions.In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .Given a prefix shorter than /64 for the entire home network, this
prefix needs to be subdivided so that every subnet is given its own
/64 prefix. In many cases there will be just one subnet, the internal
network interface attached to the router. But it is also common to
have two or more internal network interfaces with intentionally separate
networks. For instance, "private" and "guest" SSIDs are automatically
configured in many current home network routers. When all the network
interfaces that require a prefix are attached to the same router, the
prefix assignment problem is simple, and procedures outlined in can be employed.In a more complex setting there are multiple routers in the
internal network. There are various possible reasons why this might be
necessary . For instance,
networks that cannot be bridged together should be routed, speed
differences between wired and wireless interfaces make the use of the
same broadcast domain undesirable, or simply that router devices keep
being added. In any case, it then becomes necessary to assign prefixes
across the entire network, and this assignment can no longer be done
on a local basis as proposed in . A distributed
mechanism and a protocol is required.The key requirements for this distributed mechanism are as follows.
The short prefix assigned to the home gateway router must be
used to assign /64 prefixes on each subnet that requires one.The assignment mechanism should provide reasonable efficiency.
As a practical benchmark, some ISPs may employ /60 assignments to individual
subscribers. As a result, the assignment mechanism should avoid
wasting too many prefixes so that this set of 16 /64 prefixes does
not run out in the foreseeable future for commonly occuring network
configurations.In particular, the assignment of multiple prefixes to the same
network from the same top-level prefix must be avoided.
Example: When a home network consists of a home gateway router
connected to another router which in turn is connected to hosts, a
minimum of two /64 prefixes are required in the internal network: one
between the two routers, and another one for the host-side interface
on the second router. But an ineffective assignment mechanism in the
two routers might have both of them asking for an assignment for this
shared interface.The assignments must be stable across reboots, power cycling,
router software updates, and preferably, should be stable across
simple network changes such as adding a new device on the stub network
segments. However, stability across more complex types of network
reconfiguration events is not a requirement.In an even more complex setting there may be multiple home gateway
routers and multiple connections to ISP(s). These cases are analogous
to the case of a single gateway router. Each gateway will simply
distribute the prefix it has, and participating routers throughout the
network may assign themselves prefixes from several gateways.Similarly, it is also possible that it is necessary to assign both
a global prefix delegated from the ISP and a local, Unique Local
Address (ULA) prefix . The mechanisms in this
memo are applicable to both types of prefixes. For ULA-based prefixes,
it is necessary to elect one or more router as the generator of such
prefixes, and have it perform the generation and employ the prefixes
for local interfaces and the entire router network. The generation of
ULAs in this manner -- and indeed even the question of whether ULAs
are needed -- is outside the scope of this memo, however. We only note
that if ULA prefixes are generated, then the mechanisms in this memo
can be used to subdivide that prefix for the rest of the network.This section describes how a router assigns prefixes to its
directly connected interfaces. We assume that the router has
prefix(es) that it can use for this allocation. These prefix(es) can
be manually configured, acquired through DHCPv6 PD from the ISP, or
learned through the distributed prefix assignment protocols described
in . Each such prefix is called a usable
prefix. Parts of the usable prefix may already be assigned for some
purpose; a coordinated allocation from the prefix is necessary before
it can actually be assigned to an interface.Even if the assignment process is local, it still needs to follow
the requirements from . This is achieved through the
following rules:
The router MUST maintain a list of assigned prefixes on a
per-interface basis. The contents of this list consists of prefixes
that the router itself has assigned to the interface, as well as
prefixes assigned to the interface by other routers. The latter are
learned through the mechanisms described in ,
when they are used.Whenever the router finds a combination of an interface and usable
prefix that is not used on the interface, it SHOULD make a new
assignment. That is, the router checks to see if there exists an
interface and usable prefix such that there are no assigned prefixes
within that interface that are more specific than the usable
prefix. In this situation the router makes an allocation from the
usable prefix (if possible) and adds the allocation to the list of
assigned prefixes on that interface.An allocation from a usable prefix MUST check for other allocations
from the same usable prefix. Allocations are made for individual /64
prefixes. The choice of a /64 among multiple free ones MUST be made
randomly or based on an algorithm that takes unique hardware
characteristics of the router and the interface into account. This
helps avoid collisions when simultaneous allocations are made within a
network.In order to provide a stable assignment, the router MUST store
assignments affecting directly connected interfaces in non-volatile
memory and attempt to re-use them in the future when possible. At
least the 5 most recent assignments SHOULD be stored. Note that this
applies to both its own assignments as well as assignments made by
others. This ensures that the same prefix assignments are made
regardless of the order that different devices are brought up. To
avoid attacks on flash memory write cycles, assignments made by others
SHOULD be recorded only after 10 minutes have passed and the assignment
is still valid.Re-using a memorized assignment is possible when there exists a
usable prefix that is less specific than the prefix in the assignment
(or it is the prefix itself in the assignment), and the prefix in the
assignment can be allocated for that purpose.Once the router has assigned a prefix to an interface, it MUST act
as a router as defined in and advertise the
prefix in Router Advertisements. The lifetime of the prefix SHOULD be
advertised as a reasonably long period, at least 48 hours or the
lifetime of the assigned prefixes, whichever is smaller. To support a
variety of IPv6-only hosts in these networks, the router needs to
ensure that sufficient DNS discovery mechanisms are enabled. It is
RECOMMENDED that both stateless DHCPv6 and
Router Advertisement options are supported
and turned on by default. This requires, however, that a working DNS
server is known and addressable via IPv6. The mechanism in and can be used for this.This section describes how prefix assignment in a home network can
be performed in a distributed manner via OSPFv3. It is expected that
the router already support the auto-configuration extensions defined
in .An overview to OSPFv3-based prefix assignment is as follows.
OSPFv3 routers that are capable of auto-configuration advertise OSPFv3
Auto-Configuration (AC) LSA with suitable TLVs. For
prefix assignment, two TLVs are used. The Usable Prefix TLV () advertises a usable prefix, usually the
prefix that has been delegated to the home gateway router from the ISP
through DHCPv6 PD. These usable prefixes are necessary for running
the algorithm in for determining whether prefix
assignments can and should be made.The Assigned Prefix TLV ()
is used to communicate assignments that routers make out of the
usable prefixes.An assignment can be made when the algorithm in indicates that it can be made and no other router
has claimed the same assignment. The router emits an OSPFv3
advertisement with Assigned Prefix TLV included to let other devices
know that the prefix is now in use. Unfortunately, collisions are
still possible, when the algorithms on different routers happen to
choose the same free /64 prefix or when more /64 prefixes are needed
than there are available. This situation is detected through an
advertisement where a different router claims the allocation of the
same prefix. In this situation the router with numerically lower
OSPFv3 Router ID has to select another prefix. See also Section 5.2.The Usable Prefix TLV is defined for the OSPFv3
Auto-Configuration (AC) LSA . It will have type
TBD-BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with
an LSID of 0. It MAY occur once or multiple times and the
information from all TLV instances is retained. The length of the
TLV is variable.The contents of the TLV include a usable prefix (Prefix) and
prefix length (PrefixLength). PrefixLength is the length in bits of the prefix
and is an 8-bit field. The PrefixLength MUST be greater than or equal
to 8 and less than or equal to 64. The prefix describes an
allocation of a global or ULA prefix for the entire auto-configured
home network. The Prefix is
an encoding of the prefix itself as an even multiple of 32-bit words,
padding with zero bits as necessary. This encoding consumes
(PrefixLength + 31) / 32) 32-bit words and is consistent with
. It MUST NOT be directly assigned to any
interface before
following through the procedures defined above.This TLV SHOULD be emitted by every home gateway router that has
either a manual or DHCPv6 PD based prefix that is shorter than
/64.This TLV MUST appear inside an OSPFv3 Router Auto-Configuration
LSA, and only in combination with the Router-Hardware-Fingerprint
TLV Section 5.2.2
in the same LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-1 | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| (4-16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Usable Prefix TLV Format
The Assigned Prefix TLV is defined for the OSPFv3
Auto-Configuration (AC) LSA . It will have type
TBD-BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with
an LSID of 0. It MAY occur once or multiple times and the
information from all TLV instances is retained. The length of the
TLV is variable.The contents of the TLV include an Interface ID, assigned prefix (Prefix),
and prefix length (PrefixLength). The Interface ID is the same OSPFv3
Interface ID that is described in section 4.2.1 or .
PrefixLength is the length in bits of the prefix
and is an 8-bit field. The PrefixLength value MUST be 64 in
this version of
the specification. The prefix describes an assignment of a global
or ULA prefix for a directly connected interface in the advertising
router. The Prefix is
an encoding of the prefix itself as an even multiple of 32-bit words,
padding with zero bits as necessary. This encoding consumes
(PrefixLength + 31) / 32) 32-bit words and is consistent with
xref target="RFC5340"/>.This TLV MUST be emitted by every home router that has made
assignment from a usable prefix per .This TLV MUST appear inside an OSPFv3 Router Auto-Configuration
LSA, and only in combination with the Router-Hardware-Fingerprint
TLV Section 5.2.2
in the same LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-2 | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| (4-16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Prefix TLV Format
OSPFv3 Routers supporting the mechanisms in the memo will learn or
assign a global /64 IPv6 prefix for each IPv6 interface.
Since the mechanisms described herein are based on OSPFv3, Router ID assignment
as described in MUST have
completed successfully.When an OSPFv3 Router receives a global prefix through DHCPv6 prefix
delegation, manual configuration, or other means, it will advertise this
prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. This will
trigger prefix assignment for auto-configured OSPFv3 routers within
the routing domain including the originating OSPFv3 router.When an OSPFv3 Router receives an AC LSA containing a Usable Prefix TLV,
it will determine whether or not a new prefix needs to be assigned for
each of its attached IPv6 interfaces. For the purposes of this discussion, the
received prefix will be referred to as the Current Usable Prefix.
The following steps will be peformed for
each IPv6 interface:
The OSPFv3 Router will determine whether there are any other OSPFv3 Routers connected
to the same link by examining its list of neighbors.If no OSPFv3 neighbors have been discovered, the router will wait TBD seconds
before allocating a unique /64 IPv6 prefix for the link as described in step 5.If OSPFv3 neighbors are present on the link, the router needs to determine whether any of them
have already assigned an IPv6 prefix. This is done by examing the AC LSAs for neighbors on the
link and looking for any that include an Assigned Prefix TLV with the same OSPFv3 Interface ID
as the neighbor. If one is found and is it a subnet of the IPv6 prefix advertised in the
Usable Prefix TLV, this global IPv6 prefix has been already been assigned to the link.
If more than one neighbor's Assigned Prefix TLV is found with an IPv6 prefix matching the
criteria above, the Assigned Prefix advertised by the OSPFv3 router with the
numerically highest OSPFv3 Router ID takes precedence.If there are OSPFv3 neighbors on the link but no IPv6 Prefix is found, the task of prefix
allocation is delegated to the OSPFv3 Router with the numerically highest OSPFv3 Router ID. Note
that this is different from OSPFv3 Desiginated Router (DR) election, as described in
, in that the router priority is not taken into consideration and that
the election will work for networks types where no DR is elected, e.g., point-to-point links.If it is determined that the OSPFv3 Router is responsible for prefix assignment on the link,
it will:
Examine all the AC LSA including Assigned Prefix TLVs that are subnets of the Current Usable Prefix
to determine which /64s prefixes are already assigned.Examine former prefix assignments stored in non-volatile storage for interface. Starting with the
most recent assignment, if the prefix is both a subnet of the Current Usable Prefix and is
currently unassigned, reuse the assignment for the inteface.If no unused former prefix allocation is found, allocate a new one from the subnets of the
Current Usable Prefix which are unallocated.Once a global IPv6 prefix is assigned, a new instance of the AC LSA will be re-originated
including the Assigned Prefix TLV.In the rare event that no global /64 IPv6 prefixes are available within the Current Usable Prefix,
no IPv6 prefix is assigned and an error condition must be raised.There are two types of conflicts that may be detected:
Two or more OSPFv3 routers have assigned the same IPv6 prefix for different networks.Two of more OSPFv3 routers have assigned different IPv6 prefixes for the same network.
In the case of the former, the OSPFv3 Router with the numerically lower OSPFv3 Router ID must
select a new prefix and advertise a new instance of its AC LSA with an updated Assign Prefix TLV
for the link. In the latter case, the OSPFv3 Router
with the numerically lower OSPFv3 Router ID should accept the global IPv6 prefix from the
neighbor with the highest OSPFv3 Router ID and originate a new AC LSA excluding the Assigned Prefix
TLV for the link.Advanced users may wish to manage their networks without
automation, and there may also be situations where manual intervention
may be needed. For these purposes there MUST be a configuration
mechanism that allows users to turn off the automatic prefix
assignment on a given interface. This setting can be a part of
disabling the entire routing auto-configuration .In addition, there SHOULD be a configuration mechanism that allows
users to specify the prefix that they would like the router to request
for a given interface. This can be useful, for instance, when a
router is replaced and there is a desire for the new router to be
configured to ask for the same prefix as the old one, in order to
avoid renumbering other devices on this network.Finally, there SHOULD be mechanisms to display what prefixes the
router has been assigned, and where they came from (manual
configuration, DHCPv6 PD, OSPFv3).Security can be always added later.This memo makes two allocations out of the OSPFv3 Auto-
Configuration (AC) LSA TLV namespace :
The Usable Prefix TLV in takes the value TBD-BY-IANA-1 (suggested value is 2).The Assigned Prefix TLV in takes the value TBD-BY-IANA-2 (suggested value is 3).The authors would like to thank to Tim Chown, Fred Baker, Mark
Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel
Halpern, Samita Chakrabarti, Michael Richardson, and Ralph Droms for
interesting discussions in this problem space.