ADDRCONF Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT March 24, 1995
<draft-ietf-addrconf-ipv6-auto-01.txt>
IPv6 Stateless Address Autoconfiguration
Status of this Memo
This document is a submission to the ADDRCONF Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the addrconf@cisco.com mailing list.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
To learn the current status of any Internet Draft. please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
munnari.oz.au.
Abstract
This document specifies stateless address autoconfiguration. A host
can form a link-local address autonomously based on information local
to the host. A host can form an inter-link scope address in two
ways: either autonomously, based on prefixes advertised by routers,
or by using the IPv6 version of the Dynamic Host Configuration
Protocol(DHCPv6). All mechanisms rely on a host having a token that
is unique at least per link. This document specifies how a host
forms addresses autonomously. DHCPv6 is described elsewhere.
Expires September 24, 1995 [Page 1]
INTERNET-DRAFT Stateless Address Configuration March 1995
1. INTRODUCTION
An IPv6 host may have multiple addresses per interface. The addresses
can have one of three scopes:
1. a link-local address,
2. a site-local address, and
3. a global address.
All three address scopes can be autoconfigured. A host can autocon-
figure a link-local address autonomously. A host can autoconfigure a
site-local or global address only when a router or a DHCPv6 server is
present on the link.
There is only one way to form a link-local address. On initialization
of an interface, a host forms such an address by concatenating a
well-known link-local prefix[1] to a token that is unique per link.
The definition of the tokens used are link-dependent. For example,
in the case of a host attached to an link that uses IEEE 802
addresses, the token is the IEEE 802 address of the interface.
There are two ways to form a site-local or global address. In the
first mechanism, a host forms an inter-link scope address by con-
catenating a network prefix advertised in a Router Advertisement[2,3]
to a token that is unique per link. Like the link-local address, the
token is defined to be link-layer dependent. This mechanism for
forming a site-local or global address is suitable for environments
where no administrative control is desired. It is a simple protocol
designed for a very specific purpose: to make stateless address con-
figuration very straightforward to use and implement.
The other mechanism available to hosts is to use the IPv6 version of
the Dynamic Host Configuration Protocol (DHCPv6). DHCPv6 is a more
complex protocol allowing for very flexible address assignment under
the control of a system administrator. This protocol typically
requires significant system management, including server and database
configuration.
The choice of mechanism to use in forming an inter-link scope address
is advertised by a router, if present, and this choice is configur-
able by a system administrator.
Expires September 24, 1995 [Page 2]
INTERNET-DRAFT Stateless Address Configuration March 1995
This document describes how a host forms a link-local address and one
or more site-local or global addresses autonomously. It also speci-
fies how a host determines which mechanism to use to form an inter-
link scope address: the autonomous (stateless) approach or DHCPv6.
Section 2 describes the router's role in address autoconfiguration
and Section 3 the host's role.
Expires September 24, 1995 [Page 3]
INTERNET-DRAFT Stateless Address Configuration March 1995
2. ROUTER BEHAVIOR
The stateless address autoconfiguration mechanism relies on the
router discovery mechanism specified in [2,3] for forming addresses
with site-local or global scope. If configured to do so, routers
advertise prefix information in periodic Router Advertisements. The
prefixes are contained in Prefix-Information extensions of a Router
Advertisement. Each Prefix-Information extension indicates whether
the prefix can be used for autonomous address autoconfiguration and,
if so, for how long the resulting address is valid. Note that the
lifetime of the address is defined separately from that of the Router
Advertisement itself (other information is advertised in the adver-
tisement which has different lifetime requirements). The extension
also explicitly indicates to hosts whether DHCPv6 is required to be
used since it is possible that system administrators would like to
have hosts autoconfigure addresses autonomously, but also use DHCPv6
to acquire other configuration information besides the address.
Router Advertisement and Solicitation processing is specified in [2]
and the message formats in [3].
DISCUSSION: An alternative approach is to advertise address confi-
guration information in a separate advertisement entirely. This would
be somewhat cleaner since the lifetime of the advertisement would
then be that of the information advertised. On the other hand, having
two types of router advertisements would mean that prefix information
is advertised redundantly, and in particular, would double traffic on
initialisation and on router solicitations.
2.1. Router Configuration Variables
In addition to the configuration variables specified in [2,3],
routers MUST also be configurable as follows.
For each of the IPv6 unicast addresses per interface:
Autonomous Flag
Expires September 24, 1995 [Page 4]
INTERNET-DRAFT Stateless Address Configuration March 1995
If and only if TRUE, the prefix length is to be advertised for
the purposes of autonomous address configuration.
Default: TRUE
For each interface:
Administered Flag
If and only if TRUE, the host must autoconfigure other confi-
guration information using DHCPv6. Only valid in extensions
with the Autonomous Flag set to TRUE.
Default: FALSE
Address_Advertisement_Interval
The time allowed between sending unsolicited Address Advertise-
ments from the interface, in seconds. The value must not be
less than Maximum_Advertisement_Interval of Router Advertise-
ments.
Default: XX
Address_Lifetime
The value to be placed in the Lifetime field of the
Prefix_Information extension sent from the interface in
seconds. The value must not be less than
Address_Advertisement_Interval. This value indicates how long
an address formed from the prefix advertised is valid. Only
valid in extensions with the Autonomous flag set to TRUE.
Default: 3 * Address_Advertisement_Interval
All routers advertising a given prefix on a link MUST be configured
to advertise the same autoconfiguration mode to hosts.
Expires September 24, 1995 [Page 5]
INTERNET-DRAFT Stateless Address Configuration March 1995
2.2. Processing
A router MUST advertise address autoconfiguration information in a
Prefix Information Extension of a Router Advertisement. The values of
the Autonomous and Administered flags are advertised along with
Address_Lifetime. The address configuration information need not be
advertised in each Router Advertisement. It must be sent (almost)
periodically in a Router Advertisement at an interval of approxi-
mately Address_Advertisement_Interval.
Address configuration information must also be sent in the first few
Router Advertisements after startup or enabling of an interface (up
to MAX_INITIAL_ADVERTISEMENTS) and in a Router Advertisement that is
sent in response to a Router Solicitation.
Address configuration information may also be sent in a Router
Advertisement due to actions taken by system management, in particu-
lar, when the Address_Lifetime of a prefix is set to zero, e.g.
because the link is to be renumbered. In this case, a Prefix-
Information extension must be transmitted in a Router Advertisement
advertising the appropriate address prefix with the Autonomous Flag
set to TRUE and Address_Lifetime set to zero.
Expires September 24, 1995 [Page 6]
INTERNET-DRAFT Stateless Address Configuration March 1995
3. HOST ADDRESS AUTOCONFIGURATION PROCESSING
3.1. Host Configuration Variables
A host maintains a list of addresses per interface. At a minimum, the
list includes the link-local address, which the host can form auto-
nomously whenever an interface is initialised. If a router is
attached to the link or DHCPv6 server is available, the list may also
include site-local or global addresses formed either from subnet pre-
fixes advertised in Router Advertisements or by making requests using
DHCPv6. Addresses may also be manually configured. Note there may be
multiple site-local or global addresses autoconfigured per interface.
A host must maintain a list of the following configurable variables
per interface:
Address
A valid IPv6 unicast address for this interface
Default: None
Prefix Length
The length of the prefix in bits. Prefix length semantics are
specified in [2].
A host must also allow the following variable to be configured per
interface:
Perform_Auto_Config
If and only if TRUE, the host must perform address autoconfigura-
tion processing.
Expires September 24, 1995 [Page 7]
INTERNET-DRAFT Stateless Address Configuration March 1995
Default: TRUE
3.2. Host Initialization Behavior
A host must perform the following autoconfiguration procedure when-
ever an interface needs to be initialised:
When a host has no address for an interface with
Perform_Auto_Config flag set to TRUE, e.g. when a host boots or
when an interface is enabled after being disabled, the host forms
an address of link-local scope. Appendix A specifies how a host
that is attached to a link that uses IEEE 802 addresses forms a
link-local address.
Before adding the link-local address as a valid address to the
list of addresses for the interface, the host SHOULD verify that
the address is indeed unique. The procedure for validating an
address is described in Section X. A host SHOULD also validate any
manually configured addresses this way too.
The host solicits a Router Advertisement using one or more Router
Solicitations, if no Router Advertisements have been heard in the
interface. The procedure for sending Router Solicitations is
specified in [2].
If no Router Advertisement is heard after sending
MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after
each as specified in Sending Router Solicitations in [2], the host
must determine whether a DHCPv6 server is present and whether any
configuration information needs to be acquired. This is to cater
for a routerless topology which has a DHCPv6 server. Once a router
is added to the network, however, a host MUST use Router Adver-
tisements to determine the autoconfiguration mode in use as
described in the section on Router Advertisement Processing.
Expires September 24, 1995 [Page 8]
INTERNET-DRAFT Stateless Address Configuration March 1995
3.3. Router Advertisement Processing
Router Advertisement processing is specified in [2] and the message
format in [3]. In addition to this processing, the host MUST perform
the following address configuration processing when a solicited or
unsolicited Router Advertisement is received over an interface:
For each Prefix-Information extension in the Router Advertisement:
(The format of the Prefix-Information extension as amended by this
draft for autoconfiguration purposes is specified in Appendix C):
The host silently ignores the extension for the purposes of auto-
configuration if the Perform_Auto_Config flag for the interface is
FALSE.
Otherwise, the host checks the autoconfiguration mode bits.
If only the Autonomous flag is set in the Prefix-Information
extension, the host forms or verifies a site-local or global
address as specified below.
If both the Autonomous and Administered flags are set in the
Prefix-Information extension, the host forms or verifies a site-
local or global address as specified below and uses or continues
using DHCPv6 for other autoconfiguration.
Otherwise, the host silently ignores the extension for the pur-
poses of autonomous autoconfiguration.
If none of the prefixes advertised in extensions of the Router Adver-
tisement have the Autonomous flag set, then the host uses or contin-
ues using DHCPv6 for autoconfiguration.
Note that the above procedure should continue to operate when a sys-
tem administrator decides to change the autoconfiguration mode from
the autonomous mode to DHCPv6, and vice versa. The host should keep
track of the current autoconfiguration mode, so that it can detect
when there is a change. The system administrator must ensure that,
during a changeover, a DHCPv6 server is configured to hand out
addresses that are unique per link, particularly with respect to
addresses that hosts have configured autonomously and which may not
Expires September 24, 1995 [Page 9]
INTERNET-DRAFT Stateless Address Configuration March 1995
yet be invalidated. To avoid problems during a changeover, it is
recommended that a DHCP server should use exactly the same algorithm
to form a host address as that used in the autonomous mode when the
prefix is the same. It is also important to ensure that a DHCPv6
server is configured to hand out addresses only to those hosts that
it should, since, if a DHCPv6 server is present on a link, hosts may
request the server for addresses (even if the network is configured
to be in autonomous mode) when Router Advertisements are not heard
because the router is down.
For each Prefix-Information extension received over an autoconfigur-
able interface, the host updates the address list as follows when the
Autonomous flag is set:
a) If the prefix advertised matches the prefix of an autoconfigured
address already in the list, then set a timer to that of the
lifetime specified in the extension. Note there is no timer
associated with a link-local address or manually configured
address.
b) If the prefix advertised does not match the prefix of an address
already in the list, then form an address using this network
prefix. Appendix A specifies how to form an address for hosts
that have IEEE 802 tokens. The extension is ignored if the pre-
fix is not the right length for forming an address as specified
in Appendix A.
Add this address to the list with a timer set to that of the
lifetime specified in the extension.
3.3.1. Address Deprecation and Invalidation
An address is valid until the timer expires.
When the lifetime of an address expires, an address is said to be
deprecated. In general, a deprecated address should no longer be
used in new communications, but may be used in existing communica-
tions.
In particular, the internetworking layer should not select a
Expires September 24, 1995 [Page 10]
INTERNET-DRAFT Stateless Address Configuration March 1995
deprecated address as a source address in new communications. How-
ever, a deprecated address should be allowed to be used as a source
address if it is in use by the transport layer in existing communica-
tions or it is explicitly requested by an application.
The internetworking layer must continue to accept datagrams destined
to a deprecated address. The transport layer may refuse to accept new
communications requests to a deprecated address, however.
In addition, a host may send a Remote Redirect[2,3] to correspondents
when the source address used in communications is deprecated as long
as the host has a valid alternative address. Also, a deprecated
address should be removed from the Domain Name System (DNS). This may
be done by the host itself, given a DNS dynamic update protocol and
sufficient authority, or it may be done on the host's behalf.
The time at which a deprecated address becomes invalid (removed from
the list of addresses per interface) is dependent on the storage
available for the address list and is thus implementation-dependent.
A host should keep a deprecated address until it is no longer in use,
i.e. it is no longer being used in current communications such as an
existing TCP connection, and it is no longer stored or cached in the
Domain Name System. After this point, a deprecated address may be
removed from the address list.
If Router Advertisements stop being heard and all autoconfigured
inter-link scope addresses become deprecated, then the host must
determine whether a DHCPv6 server is available for address autoconfi-
guration. The host follows the same procedure as described in the
initialisation procedure in this case.
3.4. Detecting Duplicate IPv6 Addresses
One of the basic assumptions of the autoconfiguration schemes out-
lined in this document is that the host token is at least unique per
link. Tokens are defined to be link-layer dependent, and the token is
the link layer address in most cases. In practice, two hosts on the
same link may have the same link layer address because of an assign-
ment error, in which case the resulting IPv6 addresses will not be
unique. For this reason, it is prudent to check that the addresses
are indeed unique. In IPv6, it is only necessary to check that one
of the autoconfigured addresses is unique since the same token is
Expires September 24, 1995 [Page 11]
INTERNET-DRAFT Stateless Address Configuration March 1995
used to form all addresses and the prefixes used to form the
addresses are all unique (the autoconfiguration procedure should
ensure this). It is recommended that the link-local address be the
address checked since it is formed once and first, on initialisation.
The procedures use General Solicitations and Advertisements specified
in [2,3] as modified below. To validate an address, the node sends a
General Solicitation with the source and destination set to that of
the address to be checked. The node should specify an appropriate
Media-Access extension.
On receiving a General Solicitation with a source address that is the
same as the destination address and apparently from itself, a host
must respond with a General Advertisement. The General Advertisement
is sent to the All-Nodes Multicast Address with intra-link scope.
The Media-Access extension from the General Solicitation MUST NOT be
retained.
After sending a General Solicitation, the node waits for a period of
General_Solicitation_Interval. If a General Advertisement is not
received in response to the General Solicitation within the interval,
the address is considered to be validated. If a General Advertisement
is received with a source address the same as the address being vali-
dated, it must cease operation on that interface and indicate an
appropriate error.
Note that this mechanism is not completely reliable, and so it is
possible that duplicate addresses will still exist. If a duplicate
address is discovered, the host will need to be configured with a new
token, or if this is not possible, the IPv6 addresses will need to be
manually configured.
DISCUSSION: There is a problem with a race condition when two (or
more) nodes boot up at the same time. Both will send out a General
Solicitation, receive no advertisement and assume all is well. A fix
may be to have a node process General Solicitations during the vali-
dation stage and flag an error if it sees more than one General Sol-
icitation for an address it is in the process of validating.
DISCUSSION: Should the solicitations be dithered? Note that randomis-
ing based on the token (link-layer address) only does not help if the
token is not unique.
Expires September 24, 1995 [Page 12]
INTERNET-DRAFT Stateless Address Configuration March 1995
4. SECURITY CONSIDERATIONS
To be completed.
Expires September 24, 1995 [Page 13]
INTERNET-DRAFT Stateless Address Configuration March 1995
5. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS
The token for an interface on an IEEE 802 link or any link that uses
IEEE 802 addressing, such as FDDI, is the 48-bit IEEE 802 address in
canonical format, i.e. the Individual/Group bit is the low-order bit
of the furst byte.
A host forms an IPv6 address per link by concatenating an 80-bit pre-
fix with the IEEE 802 address as follows:
| 80 bits | 48 bits |
+---------------------------------------+------------------------+
| prefix | IEEE 802 address |
+----------------------------------------------------------------+
In the case of a link-local prefix, the prefix is well-defined[1].
The prefixes of other types of addresses need to be configured.
Expires September 24, 1995 [Page 14]
INTERNET-DRAFT Stateless Address Configuration March 1995
6. APPENDIX B: UNIQUENESS OF HOST TOKENS
As has been mentioned, one of the basic assumptions of the autoconfi-
guration scheme outlined in this document is that the host token is
at least unique per link, but that tokens may not always be unique,
in practice. A host should check that an address is unique using the
scheme proposed in this document. Since this is not completely reli-
able, system administrators may also use DNS to help detect when such
a problem occurs since two different hosts will register the same
IPv6 address.
Duplicate IPv6 addresses may occur as a result of non-unique tokens
in any particular network topology. One particular scenario deserves
further mention though. Consider a topology consisting of two links
with singly-homed hosts attached to each, a multi-homed host attached
to both and no router. In this case, because no router is present,
hosts will form link-local addresses only on all interfaces. It is
imperative that hosts have interface tokens that are unique across
both links. However, this may not be true for two reasons: the links
may be of different types and thus the tokens used may not be unique.
Also, the token may not be unique if it is defined to be a link layer
address and the link-layer address is only defined to be unique per
link as is true in some cases. Strictly speaking, we require that
host tokens are globally unique to ensure correct operation in these
topologies. In practice, link layer addresses are frequently glo-
bally unique and so the uniqueness problems in this scenario should
not be appreciably worse than in more traditional topologies as
described above. If two link-local scope addresses are detected to
be the same in this scenario, there are two solutions: one is to make
the multihomed host a router, the other is to manually configure the
link-local address of an offending host.
Expires September 24, 1995 [Page 15]
INTERNET-DRAFT Stateless Address Configuration March 1995
7. APPENDIX C: Prefix-Information Extension
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | Length |C|A|M| 0 | Prefix Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Identifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extension As in [3]
Length As in [3]
C As in [3]
A Autonomous Mode
Form an address using prefix of advertised
identifier.
M Administered Mode
Use DHCPv6 to autoconfigure other information.
Prefix Size Number of bits of identifier defining the
routing prefix for this link
Preference As in [3]
Identifier One of IPv6 unicast addresses of this interface
This extension is found in Router Advertisements.
Expires September 24, 1995 [Page 16]
INTERNET-DRAFT Stateless Address Configuration March 1995
8. REFERENCES
[1] R. Hinden, "Internet Protocol Version (IPv6) Specification",
Internet Draft, March 1995, <draft-ietf-ipngwg-ipv6-addr-arch-
01.txt>
[2] W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
Draft, January 1995, <draft-simpson-ipv6-discov-process-02.txt>
[3] W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
mats", Internet Draft, January 1995, <draft-simpson-ipv6-
discov-formats-02.txt>
Acknowledgements
The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. In particular, thanks to Jim Bound,
Steve Deering and Bill Simpson.
Author's Addresses
Susan Thomson
Bellcore
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 201-829-4514
Email: set@thumper.bellcore.com
Expires September 24, 1995 [Page 17]
INTERNET-DRAFT Stateless Address Configuration March 1995
Expires September 24, 1995 [Page 18]
