< draft-arkko-homenet-prefix-assignment-01.txt   draft-arkko-homenet-prefix-assignment-02.txt >
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft A. Lindem Internet-Draft A. Lindem
Intended status: Informational Ericsson Intended status: Standards Track Ericsson
Expires: May 3, 2012 October 31, 2011 Expires: January 10, 2013 B. Paterson
Cisco Systems
July 9, 2012
Prefix Assignment in a Home Network Prefix Assignment in a Home Network
draft-arkko-homenet-prefix-assignment-01 draft-arkko-homenet-prefix-assignment-02
Abstract Abstract
This memo describes a prefix assignment mechanism for home networks. This memo describes a prefix assignment mechanism for home networks.
It is expected that home gateway routers are assigned an IPv6 prefix It is expected that home gateway routers are allocated an IPv6 prefix
through DHCPv6 Prefix Delegation (PD). This prefix needs to be through DHCPv6 Prefix Delegation (PD) or that a prefix is made
divided among the multiple subnets in a home network. This memo available through other means. This prefix needs to be divided among
describes a mechanism for such division via OSPFv3. This is an the multiple subnets in a home network. This memo describes a
alternative design to using DHCPv6 PD also for the prefix assignment. mechanism for such division, or assignment, via OSPFv3. This is an
The memo is input to the working group so that it can make a decision alternative design to also using DHCPv6 PD for the assignment. The
on which type of design to pursue. It is expected that a routing- 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. protocol based assignment uses a minimal amount of prefixes.
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 May 3, 2012. This Internet-Draft will expire on January 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 3 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 4
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
5. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 7 4.1. Sending Router Advertisements . . . . . . . . . . . . . . 7
5.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 7 4.2. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 8 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 9 6. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 9
6. Manageability Considerations . . . . . . . . . . . . . . . . . 11 6.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 11
9. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.1. Making a New Assignment . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.2. Checking for Conflicts Across the Entire Network . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.3.3. Deprecating an Assigned Prefix . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 6.3.4. Verifying and Making a Local Assignment . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 7. ULA Generation . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Manageability Considerations . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Timer Constants . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This memo describes a prefix assignment mechanism for home networks. This memo describes a prefix assignment mechanism for home networks.
It is expected that home gateway routers are assigned an IPv6 prefix It is expected that home gateway routers are allocated an IPv6 prefix
through DHCPv6 Prefix Delegation (PD) [RFC3633], or in some cases through DHCPv6 Prefix Delegation (PD) [RFC3633], or that a prefix is
manually configured. This prefix needs to be divided among the made available by some other means. Manual configuration may be
multiple subnets in a home network. This memo describes a mechanism needed in some networks, for instance when the ISP does not support
for such division via OSPFv3 [RFC5340]. DHCPv6-based prefix delegation. In other cases, such as networks
that have do not yet have an Internet connection, Unique Local
Address (ULA) [RFC4193] prefixes can be automatically generated. For
the purposes of this document, we refer to the prefix reserved for a
home network as a prefix allocation.
The OSPv3-based mechanism is an alternative design to using DHCPv6 PD A prefix allocation needs to be divided among the multiple subnets in
also for the prefix assignment in the internal network. This memo a home network. For the purposes of this document, we refer to this
has been written so that the working group can make a decision on process as prefix assignment. This memo describes a mechanism for
which type of design to pursue. The main benefit of using a routing prefix assignment via OSPFv3 [RFC5340].
protocol to handle the prefix assignment is that it can provide a
more efficient allocation mechanism than hierarchical assignment The OSPv3-based mechanism is an alternative design to also using
through DHCPv PD. This may be important for home networks that get DHCPv6 PD for the prefix assignment in the internal network. This
only a /60 allocation from their ISPs. 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 use of address space than hierarchical
assignment through DHCPv PD. This may be important for home networks
that only get a /60 prefix allocation from their ISPs.
The rest of this memo is organized as follows. Section 2 defines the The rest of this memo is organized as follows. Section 2 defines the
usual keywords, Section 3 explains the main requirements for prefix usual keywords, Section 3 explains the main requirements for prefix
assignments, Section 4 describes how a home gateway router makes assignments, Section 4 describes how a home gateway router makes
assignments when it itself has multiple subnets, and Section 5 assignments when it itself has multiple subnets, and Section 5 and
describes how the assignment can be performed in a distributed manner Section 6 describe how the assignment can be performed in a
via OSPFv3 in the entire home network. Finally, Section 6 explains distributed manner via OSPFv3 in the entire home network. Finally,
what administrative interfaces are useful for advanced users that Section 7 specifies the procedures for automatic generation of ULA
wish to manually interact with the mechanisms, Section 7 discusses prefixes, Section 8 explains the hysteresis principles applied to
the security aspects of the design, and Section 8 explains the prefix assignment and de-assignment, Section 9 explains what
necessary IANA actions. administrative interfaces are useful for advanced users that wish to
manually interact with the mechanisms, Section 10 discusses the
security aspects of the design, Section 11 explains the necessary
IANA actions, and Section 12 defines the necessary timer constants.
An analysis of a mechanism reminiscent of the one described in this
specification has been published in the SIGCOMM IPv6 Workshop
[SIGCOMM.IPV6]. Further analysis is encouraged.
2. Requirements language 2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119]. described in [RFC2119].
3. Role of Prefix Assignment 3. Role of Prefix Assignment
Given a prefix shorter than /64 for the entire home network, this Given a prefix shorter than /64 for the entire home network, this
skipping to change at page 4, line 15 skipping to change at page 4, line 33
In a more complex setting there are multiple routers in the internal In a more complex setting there are multiple routers in the internal
network. There are various possible reasons why this might be network. There are various possible reasons why this might be
necessary [I-D.chown-homenet-arch]. For instance, networks that necessary [I-D.chown-homenet-arch]. For instance, networks that
cannot be bridged together should be routed, speed differences cannot be bridged together should be routed, speed differences
between wired and wireless interfaces make the use of the same between wired and wireless interfaces make the use of the same
broadcast domain undesirable, or simply that router devices keep broadcast domain undesirable, or simply that router devices keep
being added. In any case, it then becomes necessary to assign being added. In any case, it then becomes necessary to assign
prefixes across the entire network, and this assignment can no longer prefixes across the entire network, and this assignment can no longer
be done on a local basis as proposed in Section 4. A distributed be done on a local basis as proposed in Section 4. A distributed
mechanism and a protocol is required. mechanism and a protocol are required.
The key requirements for this distributed mechanism are as follows. The key requirements for this distributed mechanism are as follows.
o The short prefix assigned to the home gateway router must be used o A prefix allocated to a home gateway router within the home
to assign /64 prefixes on each subnet that requires one. network is used to assign /64 prefixes on each subnet that
requires one.
Note that several methods may be used to allocate such a usable
prefix.
o The assignment mechanism should provide reasonable efficiency. As o The assignment mechanism should provide reasonable efficiency. As
a practical benchmark, some ISPs may employ /60 assignments to a practical benchmark, some ISPs may employ /60 allocations to
individual subscribers. As a result, the assignment mechanism individual subscribers. As a result, the assignment mechanism
should avoid wasting too many prefixes so that this set of 16 /64 should avoid wasting too many prefixes so that this set of 16 /64
prefixes does not run out in the foreseeable future for commonly prefixes is not exhausted in the foreseeable future for commonly
occuring network configurations. occurring network configurations.
o In particular, the assignment of multiple prefixes to the same o In particular, the assignment of multiple prefixes to the same
network from the same top-level prefix must be avoided. network from the same top-level prefix must be avoided.
Example: When a home network consists of a home gateway router Example: When a home network consists of a home gateway router
connected to another router which in turn is connected to connected to another router which in turn is connected to
hosts, a minimum of two /64 prefixes are required in the hosts, a minimum of two /64 prefixes are required in the
internal network: one between the two routers, and another one internal network: one between the two routers, and another one
for the host-side interface on the second router. But an for the host-side interface on the second router. But an
ineffective assignment mechanism in the two routers might have ineffective assignment mechanism in the two routers might have
both of them asking for an assignment for this shared both of them asking for separate assignments for this shared
interface. interface.
o The assignments must be stable across reboots, power cycling, o The assignments must be stable across reboots, power cycling,
router software updates, and preferably, should be stable across router software updates, and preferably, should be stable across
simple network changes. Simple network changes are in this case simple network changes. Simple network changes are in this case
defined as those that could be resolved through either deletion or defined as those that could be resolved through either deletion or
addition of a prefix assignment. For instance, the addition of a addition of a prefix assignment. For instance, the addition of a
new router without changing connections between existing routers new router without changing connections between existing routers
requires just the assigment of new prefixes for the new networks requires just the assignment of new prefixes for the new networks
that the router introduces. There are no stability requirements that the router introduces. There are no stability requirements
across more complex types of network reconfiguration events. For across more complex types of network reconfiguration events. For
instance, if a network is separated into two networks connected by instance, if a network is separated into two networks connected by
a newly inserted router, this may lead into renumbering all a newly inserted router, this may lead to renumbering all networks
networks within the home. within the home.
In an even more complex setting there may be multiple home gateway In an even more complex setting there may be multiple home gateway
routers and multiple connections to ISP(s). These cases are routers and multiple connections to ISP(s). These cases are
analogous to the case of a single gateway router. Each gateway will analogous to the case of a single gateway router. Each gateway will
simply distribute the prefix it has, and participating routers simply distribute the prefix it has, and participating routers
throughout the network may assign themselves prefixes from several throughout the network may assign themselves prefixes from several
gateways. gateways. Multiple assignments can be made for the same interface.
For example, this can be useful in a multi-homing setting.
Similarly, it is also possible that it is necessary to assign both a Similarly, it is also possible that it is necessary to assign either
global prefix delegated from the ISP and a local, Unique Local a global prefix delegated from the ISP or a local, Unique Local
Address (ULA) prefix [RFC4193]. The mechanisms in this memo are Address (ULA) prefix [RFC4193]. The mechanisms in this memo are
applicable to both types of prefixes. For ULA-based prefixes, it is applicable to both types of prefixes. The details of the generation
necessary to elect one or more router as the generator of such of ULA-based prefixes is covered in Section 7.
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.
Finally, the mechanisms in this memory can also be used in standalone The mechanisms in this memory can also be used in standalone or ad
or ad hoc networks where no global prefixes or Internet connectivity hoc networks where no global prefixes or Internet connectivity are
are available, by distributing ULA prefixes within the network. available, by distributing ULA prefixes within the network.
4. Router Behavior 4. Router Behavior
This section describes how a router assigns prefixes to its directly This section describes how a router assigns prefixes to its directly
connected interfaces. We assume that the router has prefix(es) that connected interfaces. We assume that the router has prefix
it can use for this allocation. These prefix(es) can be manually allocation(s) that it can use for this assignment. Each such prefix
configured, acquired through DHCPv6 PD from the ISP, or learned allocation is called a usable prefix. Parts of the usable prefix may
through the distributed prefix assignment protocols described in already be assigned for some purpose; a coordinated assignment from
Section 5. Each such prefix is called a usable prefix. Parts of the the prefix is necessary before it can actually be assigned to an
usable prefix may already be assigned for some purpose; a coordinated interface.
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 Even if the assignment process is local, it still needs to follow the
requirements from Section 3. This is achieved through the following requirements from Section 3. This is achieved through the following
rules: rules:
o The router MUST maintain a list of assigned prefixes on a per- o The router MUST maintain a list of assigned prefixes on a per-
interface basis. The contents of this list consists of prefixes interface basis. The contents of this list consists of prefixes
that the router itself has assigned to the interface, as well as that the router itself has assigned to the interface, as well as
prefixes assigned to the interface by other routers. The latter prefixes assigned to the interface by other routers. The latter
are learned through the mechanisms described in Section 5, when are learned through the mechanisms described in Section 6, when
they are used. they are used. Each prefix is associated with the Router ID of
the router that assigned it.
o Whenever the router finds a combination of an interface and usable o Whenever the router finds a combination of an interface and usable
prefix that is not used on the interface, it SHOULD make a new 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 prefix assignment. That is, the router checks to see if an
interface and usable prefix such that there are no assigned interface and usable prefix exists such that there are no assigned
prefixes within that interface that are more specific than the prefixes within that interface that are more specific than the
usable prefix. In this situation the router makes an allocation usable prefix. In this situation the router makes an allocation
from the usable prefix (if possible) and adds the allocation to from the usable prefix (if possible) and adds the assignment to
the list of assigned prefixes on that interface. the list of assigned prefixes on that interface.
o An allocation from a usable prefix MUST check for other Note: The above implies that when there are multiple usable
allocations from the same usable prefix. Allocations are made for prefixes, each network will be assigned multiple prefixes.
individual /64 prefixes. The choice of a /64 among multiple free
ones MUST be made randomly or based on an algorithm that takes o An assignment from a usable prefix MUST be checked against
unique hardware characteristics of the router and the interface possible other assignments from the same usable prefix on the same
into account. This helps avoid collisions when simultaneous link by neighboring routers, to avoid unnecessary assignments.
allocations are made within a network. Assignments MUST also be examined against all existing assignments
from the same usable prefix across the network, to avoid
collisions. Assignments are made for individual /64 prefixes.
The choice of a /64 prefix 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 assignments are made
within a network.
o In order to provide a stable assignment, the router MUST store o In order to provide a stable assignment, the router MUST store
assignments affecting directly connected interfaces in non- assignments affecting directly connected interfaces and
volatile memory and attempt to re-use them in the future when automatically generated ULA prefixes in non-volatile memory and
possible. At least the 5 most recent assignments SHOULD be attempt to re-use them in the future when possible. At least the
stored. Note that this applies to both its own assignments as 5 most recent assignments SHOULD be stored. Note that this
well as assignments made by others. This ensures that the same applies to both its own assignments as well as assignments made by
prefix assignments are made regardless of the order that different others. This ensures that the same prefix assignments are made
devices are brought up. To avoid attacks on flash memory write regardless of the order that different devices are brought up. To
cycles, assignments made by others SHOULD be recorded only after avoid attacks on flash memory write cycles, assignments made by
10 minutes have passed and the assignment is still valid. others SHOULD be recorded only after 10 minutes have passed and
the assignment is still valid.
o Re-using a memorized assignment is possible when there exists a o Re-using a memorized assignment is possible when a usable prefix
usable prefix that is less specific than the prefix in the exists that is less specific than the prefix in the assignment (or
assignment (or it is the prefix itself in the assignment), and the it is the prefix itself in the assignment), and the prefix is
prefix in the assignment can be allocated for that purpose. currently unassigned.
4.1. Sending Router Advertisements
Once the router has assigned a prefix to an interface, it MUST act as Once the router has assigned a prefix to an interface, it MUST act as
a router as defined in [RFC4861] and advertise the prefix in Router a router as defined in [RFC4861] and advertise the prefix in Router
Advertisements. The lifetime of the prefix SHOULD be advertised as a Advertisements. The lifetime of the prefix SHOULD be advertised as a
reasonably long period, at least 48 hours or the lifetime of the reasonably long period, at least 48 hours or the lifetime of the
assigned prefixes, whichever is smaller. To support a variety of assigned prefixes, whichever is smaller.
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 [RFC3736] and Router Advertisement options
[RFC6106] are supported and turned on by default. This requires,
however, that a working DNS server is known and addressable via IPv6.
The mechanism in [RFC3736] and [RFC3646] can be used for this.
5. Prefix Assignment in OSPFv3 4.2. DNS Discovery
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 [RFC3736] and Router
Advertisement options [RFC6106] are supported and turned on by
default.
The above requires, however, that a working DNS server is known and
addressable via IPv6. The mechanism in [RFC3736] and [RFC3646] can
be used for this. It is RECOMMENDED that each router attempts to
discover an existing DNS server. Typically, such a server will be
provided by an ISP. However, in some cases no such server can be
found. For instance, an ISP may provide only IPv4 DNS server
addresses, or a router deep within the home network is unaware of the
IPv6 DNS servers that a home gateway router has discovered. In these
situations it is RECOMMENDED that each router turns on a local DNS
relay that fetches information from the IPv4 Internet (if a working
IPv4 DNS server is available) or a full DNS server that fetches
information from the DNS root.
5. Design Choices
The DNS discovery recommendations in Section 4.2 ensure that an IPv6-
only home network can resolve names. However, these recommendations
are suboptimal in the sense that different routers in the home may
provide different DNS servers, or multiple local DNS servers have to
be run where it would have been possible to point to one, or even
point to the one provided by the ISP. However, better coordination
for the DNS server selection would require some form of additional
communication between the routers in the home network. The authors
solicit opinions from the Working Group on whether this is something
that should be specified.
The OSPFv3-based prefix assignment protocol needs to detect two types
of conflicts:
1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for
different networks.
2. Two or more OSPFv3 routers have assigned different IPv6 prefixes
for the same network.
Several design decisions were needed to construct the protocol:
1. How to determine the winner in case of a conflict?
The algorithm in Section 6 ensures that the OSPFv3 Router with
the numerically lower OSPFv3 Router ID removes its assignment and
schedules an advertisement of LSAs that no longer describe such
an assignment. That is, the router with the highest Router ID
wins in a conflict situation.
2. How to ensure that a network-wide conflict can be detected?
We chose to define new LSA extensions -- TLVs within the new
Autoconfiguration LSA -- that are flooded throughout the network.
Another possible design would have been to re-use existing OSPFv3
LSAs, and by assuming that if a router advertises a prefix then
it has made an assignment. The advantage of the design that we
chose is that we get to specify what information is needed in the
new TLVs. This is particularly important, as not all existing
OSPFv3 LSAs are extensible. A downside is that assignments will
not be visible, unless the router using an assignment implements
this specification and advertises the new LSAs. Had we reused
existing LSAs, a manual assignment for a legacy router could have
been handled, as the legacy router would have advertised the
prefix assigned to it.
3. How to ensure that both local and network-wide conflicts can be
detected?
We chose to employ the same new Autoconfiguration LSA TLVs for
this purpose, and correlate neighbors through the Router IDs and
Interface IDs that they advertise in these TLVs. The OSPFv3
Router with a numerically lower OSPFv3 Router ID should accept
the global IPv6 prefix from the neighbor with the highest OSPFv3
Router ID.
6. Prefix Assignment in OSPFv3
This section describes how prefix assignment in a home network can be This section describes how prefix assignment in a home network can be
performed in a distributed manner via OSPFv3. It is expected that performed in a distributed manner via OSPFv3. It is expected that
the router already support the auto-configuration extensions defined the router already support the auto-configuration extensions defined
in [I-D.acee-ospf-ospfv3-autoconfig]. in [I-D.acee-ospf-ospfv3-autoconfig].
An overview to OSPFv3-based prefix assignment is as follows. OSPFv3 An overview of OSPFv3-based prefix assignment is as follows. OSPFv3
routers that are capable of auto-configuration advertise OSPFv3 Auto- routers that are capable of auto-configuration advertise an OSPFv3
Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with Auto-Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with
suitable TLVs. For prefix assignment, two TLVs are used. The Usable suitable TLVs. For prefix assignment, two TLVs are used. The Usable
Prefix TLV (Section 5.1) advertises a usable prefix, usually the Prefix TLV (Section 6.1) advertises a usable prefix, usually the
prefix that has been delegated to the home gateway router from the prefix that has been delegated to the home gateway router from the
ISP through DHCPv6 PD. These usable prefixes are necessary for ISP through DHCPv6 PD. These usable prefixes are necessary for
running the algorithm in Section 4 for determining whether prefix running the algorithm in Section 4 for determining whether prefix
assignments can and should be made. assignments can and should be made.
The Assigned Prefix TLV (Section 5.2) is used to communicate The Assigned Prefix TLV (Section 6.2) is used to communicate
assignments that routers make out of the usable prefixes. assignments that routers make out of the usable prefixes.
An assignment can be made when the algorithm in Section 4 indicates An assignment can be made when the algorithm in Section 4 indicates
that it can be made and no other router has claimed the same that it can be made and no other router has claimed the same
assignment. The router emits an OSPFv3 advertisement with Assigned assignment. The router makes an OSPFv3 advertisement with the
Prefix TLV included to let other devices know that the prefix is now Assigned Prefix TLV included to let other devices know that the
in use. Unfortunately, collisions are still possible, when the prefix is now in use. Unfortunately, collisions are still possible,
algorithms on different routers happen to choose the same free /64 when the algorithms on different routers happen to choose the same
prefix or when more /64 prefixes are needed than there are available. free /64 prefix or when more /64 prefixes are needed than are
This situation is detected through an advertisement where a different available. This situation is detected through an advertisement where
router claims the allocation of the same prefix. In this situation a different router claims the assignment of the same prefix. In this
the router with numerically lower OSPFv3 Router ID has to select situation the router with the numerically lower OSPFv3 Router ID has
another prefix. See also [I-D.acee-ospf-ospfv3-autoconfig] Section to select another prefix and immediately withdraw any assignments and
5.2. advertisements that may have been advertised in OSPFv3. See also
Section 5.2 in [I-D.acee-ospf-ospfv3-autoconfig].
5.1. Usable Prefix TLV 6.1. Usable Prefix TLV
The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration
(AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD-
BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with an 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 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 from all TLV instances is retained. The length of the TLV is
variable. variable.
The contents of the TLV include a usable prefix (Prefix) and prefix The contents of the TLV include a usable prefix (Prefix) and prefix
length (PrefixLength). PrefixLength is the length in bits of the length (PrefixLength). PrefixLength is the length in bits of the
prefix and is an 8-bit field. The PrefixLength MUST be greater than 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 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 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 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. even multiple of 32-bit words, padding with zero bits as necessary.
This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is
consistent with [RFC5340]. It MUST NOT be directly assigned to any consistent with [RFC5340]. It MUST NOT be directly assigned to any
interface before following through the procedures defined above. interface before following the procedures defined in this memo.
This TLV SHOULD be emitted by every home gateway router that has This TLV SHOULD be advertised by every home gateway router that has
either a manual or DHCPv6 PD based prefix that is shorter than /64. either a manual, DHCPv6 PD-based, or generated ULA prefix that is
shorter than /64.
This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA,
and only in combination with the Router-Hardware-Fingerprint TLV and only in combination with the Router-Hardware-Fingerprint TLV
[I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA.
0 1 2 3 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 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 | | TBD-BY-IANA-1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Reserved | | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Prefix | | Prefix |
| (4-16 bytes) | | (4-16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Usable Prefix TLV Format Usable Prefix TLV Format
5.2. Assigned Prefix TLV 6.2. Assigned Prefix TLV
The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration
(AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD-
BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an 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 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 from all TLV instances is retained. The length of the TLV is
variable. variable.
The contents of the TLV include an Interface ID, assigned prefix The contents of the TLV include an Interface ID, assigned prefix
(Prefix), and prefix length (PrefixLength). The Interface ID is the (Prefix), and prefix length (PrefixLength). The Interface ID is the
same OSPFv3 Interface ID that is described in section 4.2.1 or same OSPFv3 Interface ID that is described in section 4.2.1 or
[RFC5340]. PrefixLength is the length in bits of the prefix and is [RFC5340]. 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 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 the specification. The prefix describes an assignment of a global or
ULA prefix for a directly connected interface in the advertising ULA prefix for a directly connected interface in the advertising
router. The Prefix is an encoding of the prefix itself as an even 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 multiple of 32-bit words, padding with zero bits as necessary. This
encoding consumes (PrefixLength + 31) / 32) 32-bit words and is encoding consumes (PrefixLength + 31) / 32) 32-bit words and is
consistent with xref target="RFC5340"/>. consistent with [RFC5340].
This TLV MUST be emitted by every home router that has made This TLV MUST be advertised by the router that has made assignment
assignment from a usable prefix per Section 4. from a usable prefix per Section 4.
This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA,
and only in combination with the Router-Hardware-Fingerprint TLV and only in combination with the Router-Hardware-Fingerprint TLV
[I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA.
0 1 2 3 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 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 | | TBD-BY-IANA-2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Reserved | | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Prefix | | Prefix |
| (4-16 bytes) | | (4-16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Prefix TLV Format Assigned Prefix TLV Format
5.3. OSPFv3 Prefix Assignment 6.3. OSPFv3 Prefix Assignment
OSPFv3 Routers supporting the mechanisms in the memo will learn or OSPFv3 Routers supporting the mechanisms in the memo will learn or
assign a global /64 IPv6 prefix for each IPv6 interface. Since the assign a global /64 IPv6 prefix for each IPv6 interface. Since the
mechanisms described herein are based on OSPFv3, Router ID assignment mechanisms described herein are based on OSPFv3, Router ID assignment
as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed
successfully. successfully.
When an OSPFv3 Router receives a global prefix through DHCPv6 prefix When an OSPFv3 Router receives a global prefix through DHCPv6 prefix
delegation, manual configuration, or other means, it will advertise delegation, manual configuration, or other means, it SHOULD advertise
this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA.
This will trigger prefix assignment for auto-configured OSPFv3 This will trigger prefix assignment for auto-configured OSPFv3
routers within the routing domain including the originating OSPFv3 routers within the routing domain including the originating OSPFv3
router. router.
When an OSPFv3 Router receives an AC LSA containing a Usable Prefix Discussion: Note that while having multiple routers advertise the
TLV, it will determine whether or not a new prefix needs to be same usable address space (or address space that covers another
assigned for each of its attached IPv6 interfaces. For the purposes router's usable address space) is a configuration error, it should
of this discussion, the received prefix will be referred to as the not result in any adverse effects, as long as assignments from
Current Usable Prefix. The following steps will be peformed for each such space are still checked for collisions against all other
IPv6 interface: assignments from the same address space.
1. The OSPFv3 Router will determine whether there are any other When an OSPFv3 Router detects a change in the set of AC LSAs in its
OSPFv3 Routers connected to the same link by examining its list LSA database, it will run the prefix assignment algorithm. The
of neighbors. purpose of this algorithm is to determine, for each Usable Prefix in
the database, whether or not a new prefix needs to be assigned for
each of its attached IPv6 interfaces and whether or not existing
assignments need to be deprecated. The algorithm also detects and
removes assignments for which there is no longer a corresponding
Usable Prefix. Before the algorithm is run, all existing assignments
in assigned prefix lists for directly connected interfaces must be
marked as "invalid" and will be deleted at the end of the algorithm
if they are still in this state. An assigned prefix is considered to
be "valid" if all the following conditions are met:
2. If no OSPFv3 neighbors have been discovered, the router will wait o A containing Usable Prefix TLV exists in reachable AC LSA(s).
TBD seconds before allocating a unique /64 IPv6 prefix for the
link as described in step 5.
3. If OSPFv3 neighbors are present on the link, the router needs to o An Assigned Prefix TLV that matches this assignment exactly (same
determine whether any of them have already assigned an IPv6 prefix, same router and interface ID associated with the
prefix. This is done by examing the AC LSAs for neighbors on the assignment) exist in reachable AC LSA(s).
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.
4. If there are OSPFv3 neighbors on the link but no IPv6 Prefix is o Any router advertising an assignment for the same link and Usable
found, the task of prefix allocation is delegated to the OSPFv3 Prefix has a lower Router ID than the source of this assignment.
Router with the numerically highest OSPFv3 Router ID. Note that
this is different from OSPFv3 Desiginated Router (DR) election,
as described in [RFC5340], 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.
5. If it is determined that the OSPFv3 Router is responsible for o If this router is the source of the assignment, any router in the
prefix assignment on the link, it will: network that has assigned the same prefix on a different link has
a lower Router ID than this router.
* Examine all the AC LSA including Assigned Prefix TLVs that are Note that this definition of a "valid assignment" depends on the
subnets of the Current Usable Prefix to determine which /64s router running the algorithm: in particular, a router is not expected
prefixes are already assigned. to detect prefix collisions or duplicate prefix assignments that do
not concern assignments for which it is the responsible router. It
is the role of the responsible router to detect these cases and
update its AC LSAs accordingly. A router is, however, expected to
react to these updates from other routers which translate into
additions or removals of Usable Prefix or Assigned Prefix TLVs.
* Examine former prefix assignments stored in non-volatile The router is expected to have made a snapshot of the LSA database
storage for interface. Starting with the most recent before running this algorithm. The prefix assignment algorithm
assignment, if the prefix is both a subnet of the Current consists of the following steps run once per combination of Usable
Usable Prefix and is currently unassigned, reuse the Prefix in the LSA database and directly connected OSPFv3 interface.
assignment for the inteface. For the purposes of this discussion, the Usable Prefix will be
referred to as the Current Usable Prefix, and the interface will be
referred to as the Current Interface. The following steps will be
performed for each tuple (Usable Prefix, OSPFv3 interface):
* If no unused former prefix allocation is found, allocate a new 1. The OSPFv3 Router will search all AC LSAs for a Usable Prefix TLV
one from the subnets of the Current Usable Prefix which are describing a prefix which contains but is not equal to the
unallocated. Current Usable Prefix. If such a prefix is found, the algorithm
is skipped for the Current Usable Prefix as it either has or will
be run for the shorter prefix.
* Once a global IPv6 prefix is assigned, a new instance of the 2. The OSPFv3 router will examine its list of neighbors to find all
AC LSA will be re-originated including the Assigned Prefix neighbors in state greater than Init (these neighbors will be
TLV. referred to as active neighbors).
* In the rare event that no global /64 IPv6 prefixes are 3. The following three steps will serve to determine whether an
available within the Current Usable Prefix, no IPv6 prefix is assignment needs to be made on the link:
assigned and an error condition must be raised.
There are two types of conflicts that may be detected: i.
1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for The OSPFv3 router will determine whether or not it has the
different networks. highest Router ID of all active OSPFv3 routers on the link.
2. Two of more OSPFv3 routers have assigned different IPv6 prefixes ii.
for the same network.
In the case of the former, the OSPFv3 Router with the numerically If OSPFv3 active neighbors are present on the link, the router
lower OSPFv3 Router ID must select a new prefix and advertise a new will determine whether any of them have already assigned an
instance of its AC LSA with an updated Assign Prefix TLV for the IPv6 prefix. This is done by examining the AC LSAs of all the
link. In the latter case, the OSPFv3 Router with the numerically active neighbors on the link and looking for any that include
lower OSPFv3 Router ID should accept the global IPv6 prefix from the an Assigned Prefix TLV with the same OSPFv3 Router ID and
neighbor with the highest OSPFv3 Router ID and originate a new AC LSA Interface ID as the neighbor has. If one is found and it is a
excluding the Assigned Prefix TLV for the link. subnet of the IPv6 prefix advertised in the Usable Prefix TLV,
the router stores this prefix and the Router ID of the router
advertising it for reference in the next step. If several
such prefixes are found, only the prefix and Router ID with
the numerically highest Router ID are stored.
6. Manageability Considerations iii.
The router will compare its Router ID with the highest Router
ID among neighbors which have made an assignment on the link.
If it is higher (or if no assignments have been made by any
neighbors), it will determine whether or not it is already the
source of an assignment for the Current Interface from the
Current Usable Prefix.
4. There are four possibilities at this stage:
* The router has already made an assignment on the link and has
a higher Router ID than all eventual neighbors which have also
made an assignment. In this case, the router's existing
assignment takes precedence over all other eventual existing
assignments on the link, but the router must determine whether
its assignment is still valid throughout the whole network.
This is described in Section 6.3.2.
* An assignment has been made by a neighbor on the link, and the
router either has not made an assignment on the link, or has a
lower Router ID than the neighbor. In this case, the
neighbor's assignment takes precedence over all eventual
existing assignments on the link (including assignments made
by the router), and the router must update the assigned prefix
list of the Current Interface as well as check assignments on
other interfaces for potential collisions. This is described
in Section 6.3.4.
* No assignment has been made by anyone on the link, and the
router has the highest Router ID on the link. In this case,
it must make an assignment from the Current Usable Prefix.
This is described in Section 6.3.1.
* No assignment has been made by anyone on the link, and the
router does not have the highest Router ID on the link. In
this case, the algorithm exits as the router is not
responsible for prefix assignment on the link.
Once the algorithm has been run for each Usable Prefix and each
interface, the router must delete all assignments that are not marked
as valid on all assigned prefix lists and deprecate the corresponding
addresses. If this leads to deleting an assignment that this router
was responsible for, or if AC LSA origination was scheduled during
the algorithm, it must originate a new AC LSA advertising the
changes. The router MUST also deprecate deleted prefixes as
specified in Section 6.3.3.
6.3.1. Making a New Assignment
This procedure is executed when no assignment exists on the link and
the router is responsible for making an assignment. The router MUST:
1. Examine all the AC LSAs not advertised by this router that
include Assigned Prefix TLVs that are subnets of the Current
Usable Prefix, as well as all assignments made by this router, to
determine which prefixes are already assigned.
2. Examine former prefix assignments stored in non-volatile storage
for the 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 interface.
3. If no unused former prefix assignment is found, and an unassigned
/64 subnet of the Current Usable Prefix exists, assign that
prefix to the interface.
4. If no OSPFv3 neighbors have been discovered and previous prefix
assignments exist, the router can make the assignments
immediately. Otherwise, the hysteresis periods specified in
Section 8 are applied before making an assignment.
5. In the event that no assignment could be made to the interface, a
warning must be raised. However, the router MUST remain in a
state where it continues to assign prefixes through OSPFv3, as
prefixes may later become available.
6. Once a global IPv6 prefix is assigned, the router will mark it as
valid and schedule re-origination of the AC LSA including the
Assigned Prefix TLV once all Usable Prefixes and interfaces have
been examined.
6.3.2. Checking for Conflicts Across the Entire Network
This procedure is executed for every assignment that the router
intends to make or retain as the router responsible for an
assignment.
The router MUST verify that this assignment is still valid across the
whole network. This assigned prefix will be referred to as the
Current Assigned Prefix. The router will search for a reachable AC
LSA in the LSA database that is advertised by a router with a higher
Router ID and contains an Assigned Prefix equal to the Current
Assigned Prefix. If such an LSA is found, it needs to be deprecated
as described in Section 6.3.3. Otherwise, the router will mark its
assignment as valid.
6.3.3. Deprecating an Assigned Prefix
This procedure is executed when the router's earlier assignment of a
prefix can no longer be used. The following steps MUST be followed:
1. If the the prefix was in an interface's assigned prefix list, it
is removed.
2. If this router was the source of the prefix assignment, schedule
re-origination of the modified AC LSA once the algorithm has
finished.
3. 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 prefix in question.
6.3.4. Verifying and Making a Local Assignment
This procedure is executed when an assignment by a neighbor already
exists, and takes precedence over all other assignments on the link.
The router must check whether or not it is already aware of this
assignment. It will search for the assigned prefix matching the
neighbor's assignment and Router ID in the Current Interface's
assigned prefix list. If it is already present, the router will mark
it as valid. Otherwise, the router will check that no assignment on
any directly connected interface collides with the neighbor's
assignment. If a collision is found and the colliding prefix takes
priority over the neighbor's assignment (higher Router ID), the
router will silently ignore the neighbor's assignment. If a
collision is found but the neighbor's assignment takes priority, the
old assignment is removed as described in Section 6.3.3. If the
neighbor's assignment takes priority, or if no collision was found,
the router will provision the interface with the prefix, add it to
the list of assigned prefixes using the neighbor's Router ID and mark
it as valid.
7. ULA Generation
For ULA-based prefixes, it is necessary to elect a router as the
generator of such prefixes, have it perform the generation, and then
employ the prefixes for local interfaces and the entire router
network. This section specifies these procedures, and recommends the
generation of ULAs when no connectivity can be established otherwise.
However, the use of ULAs in parallel with global IPv6 prefixes is
outside the scope of this memo. The mechanisms in this memo could be
used for that as well.
When an OSPFv3 Router detects a change in the set of AC LSAs in its
LSA database, it will run the ULA generation algorithm. The purpose
of this algorithm is to determine whether a new ULA prefix needs to
be generated. There is no need for this router to generate a new ULA
prefix when any of the following conditions are met:
i.
A Usable Prefix TLV exists in an AC LSA advertised by a reachable
router in the LSA database, with either global or ULA address
space.
ii.
A reachable router in the OSPFv3 topology with a higher Router ID
than this OSPFv3 router exists.
iii.
This router has assignments from either IPv4 or IPv6 global
address space on any interface, or there is connectivity to the
global Internet.
Discussion: This rule is necessary in order to prevent
autoconfiguration-capable routers from unnecessarily creating
ULA address space in networks where autoconfiguration is not in
use. Similarly, from an IPv6 "happy eyeballs" perspective it
is desirable to not create local islands of IPv6 connectivity
when there is IPv4 connectivity (even through a NAT).
If none of the above conditions are met after applying the hysteresis
principles from Section 8, the router SHOULD perform the following
actions:
1. Generate a new 48-bit ULA prefix as specified in [RFC4193],
Section 3.2.
2. Record the new prefix in stable storage, per rules in Section 4.
3. Advertise the new prefix allocation in OSPFv3 as specified in
Section 6.3.
4. Assign /64 prefixes from the new prefix for its own use, as a
part of the general algorithm for making prefix assignments (also
in Section 6.3).
If the router has made such an allocation, it SHOULD continue to
advertise the prefix in OSPFv3 for as long as conditions i) through
iii) do not apply, with the exception of the generated ULA prefix
that this router is advertising.
If the router has made such an allocation, and any of the conditions
become true (except for the case of the ULA prefix that the router is
advertising) even after applying the hysteresis principles from
Section 8, then the OSPFv3 router SHOULD withdraw the advertisement
for the usable prefix. This is done by scheduling the re-origination
of an AC LSA that does not include the Usable Prefix TLV with the
ULA. Note that as a result of the general algorithm for making
prefix assignments, any /64 prefix assignments from the ULA prefix
will eventually be deprecated.
8. Hysteresis
A network may experience temporary connectivity problems, routing
protocol convergence may take time, and a set of devices may be
coming up at the same time due to power being turned on in a
synchronous manner. Due to these reasons it is important that the
prefix allocation and assignment mechanisms do not react before the
situation is allowed to stabilize. To allow for this, a hysteresis
principle is applied to new or withdrawn automatically generated
prefixes and prefix assignments.
A new automatically generated ULA prefix SHOULD NOT be allocated
before the router has waited NEW_ULA_PREFIX seconds for another
prefix or reachable OSPFv3 router to appear. See Section 12 for the
specific time value.
A previously automatically generated ULA prefix SHOULD NOT be taken
out of use before the router has waited TERMINATE_ULA_PREFIX seconds.
A new prefix assignment within a usable prefix SHOULD NOT be
committed before the router has waited NEW_PREFIX_ASSIGNMENT seconds
for another prefix or reachable OSPFv3 router to appear. Note the
exceptions to this rule in Section 6.3.1, item 4.
A previously assigned prefix SHOULD NOT be taken out of use before
the router has waited TERMINATE_PREFIX_ASSIGNMENT seconds.
9. Manageability Considerations
Advanced users may wish to manage their networks without automation, Advanced users may wish to manage their networks without automation,
and there may also be situations where manual intervention may be and there may also be situations where manual intervention may be
needed. For these purposes there MUST be a configuration mechanism needed. For these purposes there MUST be a configuration mechanism
that allows users to turn off the automatic prefix assignment on a that allows users to turn off the automatic prefix allocation and
given interface. This setting can be a part of disabling the entire assignment on a given interface. This setting can be a part of
routing auto-configuration [I-D.acee-ospf-ospfv3-autoconfig]. disabling the entire routing auto-configuration
[I-D.acee-ospf-ospfv3-autoconfig].
In addition, there SHOULD be a configuration mechanism that allows In addition, there SHOULD be a configuration mechanism that allows
users to specify the prefix that they would like the router to users to specify the prefix that they would like the router to
request for a given interface. This can be useful, for instance, 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 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 be configured to ask for the same prefix as the old one, in order to
avoid renumbering other devices on this network. avoid renumbering other devices on this network.
Finally, there SHOULD be mechanisms to display what prefixes the Finally, there SHOULD be mechanisms to display the prefixes assigned
router has been assigned, and where they came from (manual on each interface, and where they came from (manual configuration,
configuration, DHCPv6 PD, OSPFv3). DHCPv6 PD, OSPFv3).
7. Security Considerations 10. Security Considerations
Security can be always added later. Security can be always added later.
8. IANA Considerations 11. IANA Considerations
This memo makes two allocations out of the OSPFv3 Auto- Configuration This memo makes two allocations out of the OSPFv3 Auto- Configuration
(AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]: (AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]:
o The Usable Prefix TLV in Section 5.1 takes the value TBD-BY-IANA-1 o The Usable Prefix TLV in Section 6.1 takes the value TBD-BY-IANA-1
(suggested value is 2). (suggested value is 2).
o The Assigned Prefix TLV in Section 5.2 takes the value TBD-BY- o The Assigned Prefix TLV in Section 6.2 takes the value TBD-BY-
IANA-2 (suggested value is 3). IANA-2 (suggested value is 3).
9. Analysis 12. Timer Constants
An analysis of a mechanism remiscent of the one described in this NEW_ULA_PREFIX 20 seconds
specification has been published in the SIGCOMM IPv6 Workshop TERMINATE_ULA_PREFIX 120 seconds
[SIGCOMM.IPV6]. Further analysis is encouraged. NEW_PREFIX_ASSIGNMENT 20 seconds
TERMINATE_PREFIX_ASSIGNMENT 240 seconds
10. References 13. References
10.1. Normative References 13.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.
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
skipping to change at page 13, line 8 skipping to change at page 20, line 14
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[I-D.acee-ospf-ospfv3-autoconfig] [I-D.acee-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-acee-ospf-ospv3-autoconfig-00 (work in progress), draft-acee-ospf-ospv3-autoconfig-00 (work in progress),
October 2011. October 2011.
10.2. Informative References 13.2. Informative References
[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.
[I-D.chown-homenet-arch] [I-D.chown-homenet-arch]
Arkko, J., Chown, T., Weil, J., and O. Troan, "Home Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
Networking Architecture for IPv6", Networking Architecture for IPv6",
draft-chown-homenet-arch-00 (work in progress), draft-chown-homenet-arch-00 (work in progress),
September 2011. September 2011.
skipping to change at line 601 skipping to change at page 21, line 20
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Acee Lindem Acee Lindem
Ericsson Ericsson
Cary, NC 27519 Cary, NC 27519
USA USA
Email: acee.lindem@ericsson.com Email: acee.lindem@ericsson.com
Benjamin Paterson
Cisco Systems
Paris
France
Email: benjamin@paterson.fr
 End of changes. 72 change blocks. 
220 lines changed or deleted 571 lines changed or added

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