INTERNET-DRAFT June 5, 1995
<draft-ietf-addrconf-ipv6-auto-02.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
In IPv6, there are two types of address autoconfiguration: stateless
address autoconfiguration and stateful address configuration. In
stateless address autoconfiguration, no state is maintained binding a
particular host interface to a specific list of addresses. Rather, an
address is formed algorithmically by concatenating the network prefix
of the attached link to a host token that is unique per link. Hosts
use stateless address autoconfiguration to form a link-local unicast
address and may use stateless address autoconfiguration to form
global and site-local unicast addresses. This document specifies how
a host uses stateless address autoconfiguration to form a list of
Expires December 5, 1995 [Page 1]
INTERNET-DRAFT Stateless Address Configuration June 1995
unicast addresses per interface. It also specifies how a host
determines whether to use the stateless mechanism or the stateful
mechanism. Stateful address autoconfiguration is outside the scope
of this document.
Expires December 5, 1995 [Page 2]
INTERNET-DRAFT Stateless Address Configuration June 1995
1. INTRODUCTION
In IPv6, there are two types of address autoconfiguration: stateless
address autoconfiguration and stateful address configuration. In
stateless address autoconfiguration, no state is maintained binding a
particular host interface to a specific list of addresses. Rather, an
interface address is formed algorithmically by concatenating the net-
work prefix of the attached link to a host token unique per link. In
stateful address configuration, state is maintained, typically by a
server. For example, the IPv6 Dynamic Host Configuration Protocol is
an example of stateful address autoconfiguration.
Stateless autoconfiguration is designed to make address configuration
very simple to use and implement, and is suitable for environments
with simple topologies, e.g. routerless networks, and for environ-
ments where system administrative control is not desired. In con-
trast, stateful address configuration is designed to support flexible
address assignment and is suitable for more sophisticated topologies
and for environments where system administrative control is desired.
A host always uses stateless address autoconfiguration to form a
link-local address per interface. A host may use either stateless or
stateful autoconfiguration to configure addresses of inter-link scope
for an interface, i.e. global or site-local addresses.
This document describes how a host forms unicast addresses per inter-
face using stateless autoconfiguration. It also specifies how a host
determines whether to use the stateless mechanism or the stateful
mechanism. Stateful address autoconfiguration is outside the scope
of this document.
Expires December 5, 1995 [Page 3]
INTERNET-DRAFT Stateless Address Configuration June 1995
2. OVERVIEW
An IPv6 host may have multiple unicast addresses per interface[1].
The addresses can have one of three scopes: a link-local scope, a
site-local scope, or a global scope. Addresses of all three address
scopes can be autoconfigured. A host is able to autoconfigure a
link-local address completely autonomously. In particular, a host can
form a link-local address without a router present on the link. A
host is able to autoconfigure an inter-link scope address only when a
router is present on the link. The scope of the inter-link address
formed depends on the prefix advertised on the link.
On initialization of an interface, a host forms a link-local 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 a link
that uses IEEE 802 addresses, the token is an IEEE 802 address asso-
ciated with the interface.
A host forms or updates an inter-link scope address on hearing prefix
advertisements advertised by a router. A global or site-local address
is formed by concatenating a network prefix to a host token that is
unique per link in the same way as described above. The mechanism
used to advertise network prefixes for the purposes of address confi-
guration is the same as that used in Neighbor Discovery[2] for the
purposes of prefix discovery. Rather than specify two separate
mechanisms to advertise the same prefix information, we use a single
mechanism which requires hosts to perform both prefix discovery pro-
cessing and address autoconfiguration processing on receiving a pre-
fix advertisement. Note that, when prefixes are advertised, it is
possible to indicate whether the prefixes are to be used for prefix
discovery only, address autoconfiguration only or both.
One of the goals of IPv6 address autoconfiguration is not only to be
able to autoconfigure addresses on startup, but to be able to recon-
figure addresses dynamically. Address reconfiguration ("renumbering")
enables hosts to acquire new addresses and relinquish old addresses
automatically. Old addresses may then be reused. To enable hosts to
renumber with minimal disruption of existing communications, prefixes
are advertised with two lifetimes: a deprecation lifetime and an
invalidation lifetime. The deprecation lifetime indicates when an
address formed from a prefix must be deprecated. A deprecated address
may continue to be used as a source address in existing
Expires December 5, 1995 [Page 4]
INTERNET-DRAFT Stateless Address Configuration June 1995
communications, but should not be used as a source address in new
communications. The invalidation lifetime indicates when an address
formed from a prefix is no longer valid and may be reused. Invalid
addresses cannot be used in any communications. By specifying two
separate lifetimes, a host can gradually phase out use of old
addresses, while beginning to use new addresses for new communica-
tions (if any). The deprecation and invalidation lifetimes are con-
figurable by a system administrator and so the transition from old to
new addresses may be as quick (the deprecation and invalidation life-
times are the same) or as slow as desired.
One of the basic assumptions of stateless autoconfiguration is that
the host token is at least unique per link. However, in practice,
host tokens are not always unique because of errors in assignment.
Thus, it cannot be guaranteed that IPv6 addresses formed from a host
token are indeed unique among all hosts on a link. Since duplicate
IPv6 addresses are very difficult to track down and debug, we specify
a procedure for detecting duplicate addresses that hosts should use
on initialising an interface. Note that this procedure is not com-
pletely reliable, and so duplicate addresses may still exist. The
procedure makes use of Neighbor Solicitations and Advertisements[2]
in a special-purpose way. Briefly, a host uses a Neighbor Solicita-
tion to solicit for itself. If it discovers that another host has
the address through receiving a Neighbor Advertisement, the valida-
tion check fails and the host ceases operation on that interface.
Note that the host that is already using the address (presumably leg-
itimately) continues unharmed, although it may log a message to the
effect that it has received a solicitation for its own address.
This document specifies router and host behavior related to stateless
address configuration and duplicate address detection in more detail
in the sections that follow.
Expires December 5, 1995 [Page 5]
INTERNET-DRAFT Stateless Address Configuration June 1995
3. ROUTER BEHAVIOR
The stateless address autoconfiguration mechanism relies on the pre-
fix discovery mechanism specified in [2] for advertising network pre-
fixes required for the formation of addresses with site-local or glo-
bal scope. A prefix is advertised in a Prefix Information extension
of a Router Advertisement. The Prefix Information extension includes
the prefix and its length, flags indicating whether the information
is to be used for prefix discovery or address configuration, and two
lifetimes: the deprecation lifetime and the invalidation lifetime.
The Router Advertisement itself includes flags indicating whether
stateful address configuration should be used by hosts and whether
other configuration information (besides an address) needs to be con-
figured.
Router Advertisement and Solicitation processing is specified com-
pletely in [2] along with the message formats and configuration vari-
ables. Additional configuration variables pertinent to stateless
address configuration are specified below.
3.1. Router Configuration Variables
In addition to the configuration variables specified in [2], routers
MUST also be configurable as follows.
For each of the prefixes to be advertised in Prefix Information
extensions per interface:
Autonomous Flag
If set, the prefix is being advertised for the purposes of
stateless address configuration.
Default: TRUE
Deprecation Lifetime
The value to be placed in the Deprecation Lifetime field of
Expires December 5, 1995 [Page 6]
INTERNET-DRAFT Stateless Address Configuration June 1995
Prefix Information extensions in Router Advertisements sent
from the interface in seconds.
Invalidation Lifetime
The value to be placed in the Invalidation Lifetime field of
Prefix Information extensions in Router Advertisements sent
from the interface in seconds. Must be no less than Deprecation
Lifetime.
For each advertising interface:
Administered Flag
If set, the host must autoconfigure addresses using stateful
address autoconfiguration.
Default: FALSE
Other Flag
If set, the host must autoconfigure other configuration infor-
mation (besides the address) using stateful autoconfiguration.
Default: FALSE
NOTE: All routers advertising a given prefix on a link MUST set all
of the configuration variables to the same value.
Expires December 5, 1995 [Page 7]
INTERNET-DRAFT Stateless Address Configuration June 1995
4. HOST BEHAVIOR
Conceptually, a host maintains a list of addresses per interface.
Entries in the list are created as a result of forming addresses from
prefixes advertised in Prefix Information extensions of Router Adver-
tisements. Each entry in the list has two associated timers, a
deprecation timer and an invalidation timer, which have values set
according to lifetimes learned from the router advertisement. In
addition, the address list always includes the link-local address,
which the host forms autonomously whenever an interface is initial-
ised. The deprecation and invalidation lifetimes of a link-local
address are set to infinity.
This section specifies host address autoconfiguration behavior on
interface initialisation and on receiving a Router Advertisement.
This section also specifies a host protocol for attempting to verify
that an address is not a duplicate.
4.1. Host Configuration Variables
A host MUST allow the following variable to be configured per inter-
face:
Perform_Auto_Config
If set, the host MUST perform address autoconfiguration process-
ing.
Default: TRUE
4.2. Router Advertisement Processing
An "autoconfigurable" interface is one on which Router Advertisements
are received and the Perform_Auto_Config flag is set.
A host MUST perform the following address configuration processing
when a solicited or unsolicited Router Advertisement is received over
Expires December 5, 1995 [Page 8]
INTERNET-DRAFT Stateless Address Configuration June 1995
an autoconfigurable interface:
For each valid Router Advertisement:
If the Administered flag is set, the host MUST use stateful auto-
configuration to acquire a list of site-local or global addresses
per interface.
If the Other flag is set, the host MUST use stateful autoconfi-
guration to acquire other configuration information besides the
address.
For each Prefix-Information extension in the Router Advertisement
that has the Autonomous flag set:
- If the prefix advertised matches the prefix of an autoconfig-
ured address already in the list, then set the deprecation
timer to that of the deprecation lifetime specified in the
extension and the invalidation timer to that of the invalida-
tion lifetime. Note that this processing does not apply to a
link-local address.
- 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 prefix is not valid, e.g. it is not the right length
for forming an address with the given host token.
Add this address to the list with the deprecation timer set
to that of the deprecation lifetime and the invalidation
timer to that of the invalidation lifetime.
Note that if the deprecation lifetime is zero, the address with
that prefix is immediately deprecated. Similarly, if the invalida-
tion lifetime is zero, the address with that prefix is immediately
made invalid. (The invalidation lifetime is defined to be no less
than the deprecation lifetime.)
An address is valid until the deprecation timer expires. A valid
address may be used as a source address in all outgoing
Expires December 5, 1995 [Page 9]
INTERNET-DRAFT Stateless Address Configuration June 1995
communications and MUST be accepted as a destination address in
all incoming communications.
When the deprecation lifetime of an address expires, an address is
said to be deprecated. A deprecated address SHOULD NOT be used as
a source address in new communications. However, a deprecated
address SHOULD continue to be used as a source address if it is in
use in existing communications. The IP layer MUST continue to
accept datagrams destined to a deprecated address. Upper layers
MAY refuse to accept new communications requests to a deprecated
address, however.
An address remains deprecated until its invalidation timer expires
at which point the address becomes invalid. An invalid address can
no longer be used as a source address in outgoing communications
and is not recognised as a valid destination address in incoming
communications.
Note that, when choosing a source address in outgoing communica-
tons, a global valid address should be used in preference to a
site-local valid address, which in turn should be used in prefer-
ence to the link-local address. Similarly, a global deprecated
address should also be used in preference to a site-local depre-
cated addresses. Note that the link-local address is never depre-
cated; it is always valid. One of the implications of these rules
is that if there are no valid inter-link scope addresses, e.g. all
global and site-local addresses are deprecated, then the host will
default to using the link-local address as a source address in new
communications.
To limit storage space required for the address list, a host may
choose not to store all valid and deprecated addresses. Deprecated
addresses that are not in use by existing communications should be
discarded in favor of valid addresses and deprecated addresses
that are in use.
If a host determines that there are no IPv6 routers on a link,
either on startup or during normal processing, a host MUST attempt
to use stateful autoconfiguration to acquire addresses or other
configuration information if it is not already doing so. This is
needed to support networks with no IPv6 routers. The host deter-
mines that there are no routers on the link after startup if no
Router Advertisements are heard in the time that it would take to
send MAX_ROUTER_SOLICITATIONs and wait for a response[2]. During
normal processing, it is determined that there are no routers when
Expires December 5, 1995 [Page 10]
INTERNET-DRAFT Stateless Address Configuration June 1995
all router advertisements have timed out. If a router comes up on
the link and Router Advertisements begin to be received, a host
MUST start to use Router Advertisements in the normal way, and, in
particular, use advertisements to determine whether stateless or
stateful address configuration should be in use. Note that if a
host does not receive Router Advertisements because of some error,
e.g. all routers are down or there is a network partition, hosts
will attempt to change mode from stateless (assuming this was the
advertised mode) to stateful and then back again when Router
Advertisements start being heard. This means that if the stateful
mode is available, it should be configured correctly to serve only
the hosts that it should, since hosts may attempt to use it, even
if it is not the intention that they do so.
A host must behave reasonably when there is a change from the
stateless mode to the stateful mode, and vice versa. This can hap-
pen because routers advertise a new configuration mode due to a
deliberate change by a system administrator, or because of a
change in topology, e.g. an IPv6 router is connected to or removed
from the link. It is possible and quite likely that during the
change-over, a host will have addresses autoconfigured using both
mechanisms. If the addresses acquired using the two mechanisms are
the same, then the new addresses should replace the old and the
aging semantics associated with the new mode apply. If the
addresses acquired using the two mechanisms are different, then
the old addresses should be aged according to the rules specified
in the old configuration mode and the new addresses should follow
the rules of the new mode.
4.3. Host Initialisation
A host forms a link-local address when an autoconfigurable interface
is initialised. Appendix A specifies how a host that is attached to
a link that uses IEEE 802 addresses forms a link-local address.
Note that an interface may be initialised after any of the following
events:
- The interface is initialized at system startup time.
- The interface is reinitialized after a temporary interface
Expires December 5, 1995 [Page 11]
INTERNET-DRAFT Stateless Address Configuration June 1995
failure or after being temporarily disabled by system manage-
ment.
- The system changes from being a router to being a host, by hav-
ing its IP forwarding capability turned off by system manage-
ment.
- The host is re-attached to a link after being detached for some
time.
- The interface has its Perform_Auto_Config flag changed from
FALSE to TRUE.
4.4. Detecting Duplicate IPv6 Addresses
The procedure to detect duplicate addresses MUST be implemented in
hosts and SHOULD be used.
In stateless address configuration, it is only necessary to check
that one of the autoconfigured addresses is unique since the same
token is used to form all addresses. It is recommended that the
link-local address be the address checked since the host always forms
this address.
The procedure uses Neighbor Solicitation and Advertisement messages
specified in [2] to validate an address and is specified below.
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.
4.4.1. Soliciting Host Behavior
The host first delays a random amount of time between 0 and
DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation
Expires December 5, 1995 [Page 12]
INTERNET-DRAFT Stateless Address Configuration June 1995
for the address. This serves to alleviate congestion when many hosts
start up on the link at the same time, such as after a power failure,
and helps to avoid race conditions when more than one host is trying
to solicit for the same address at the same time. (It is recommended
that hosts include some unique value in the seed used to initialise
their pseudo-random number generators. Note that using only the host
token as a unique value is not sufficient since the token cannot be
relied upon to be unique. Although the randomization range is speci-
fied in units of seconds, the actual randomly-chosen value should not
be in units of whole seconds, but rather in units of the highest
available timer resolution.)
The node then sends a Neighbor Solicitation with a target address
containing the address to be validated. The source is set to the
unspecified address and the destination is set to the solicited-node
multicast address. The Source Link Layer Address extension SHOULD
NOT be sent.
NOTE: There SHOULD be some way to inhibit local delivery of the soli-
citation since, in general, it will not be possible for a host to
determine whether a solicitation is from itself or from another host
with a duplicate address. If local delivery cannot be inhibited, then
the host should ignore the first Neighbor Solicitation with an
unspecified source address or wait for a period of
DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation
before beginning to process solicitations again.
If after sending a solicitation, no advertisement is received from
the target, the node SHOULD retransmit the solicitation every
DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is
received or the solicitation has been retransmitted
MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
target address the same as the address being validated, it must cease
operation on that interface and indicate an appropriate error. If no
such advertisement is received in response to the Neighbor Solicita-
tions sent, the address is considered to be valid.
4.4.2. Solicited Node Behavior
When a host is in the process of validating an address, it MUST NOT
send any advertisement in response to a solicitation for that
Expires December 5, 1995 [Page 13]
INTERNET-DRAFT Stateless Address Configuration June 1995
address. Rather, all solicitations for the address are ignored,
except when the solicitation is from the unspecified address i.e.
the Neighbor Solicitation message has a target address which is the
same as the address to be validated, and a source address that is the
unspecified address. (Note that any solicitation that is likely to be
a loopback solicitation should be ignored too as mentioned in the
above section.) If a solicitation is received from the unspecified
address, the host must cease operation on that interface and indicate
an appropriate error.
Once a host has validated its address, it responds to a Neighbor Sol-
icitation with a Neighbor Advertisement as specified in [2]. However,
the processing of the solicitation is somewhat different from that in
[2] when a solicitation is received from the unspecified address. In
this case, the host MUST ignore any Link Layer Address Extension in
the solicitation and MUST NOT perform any link-layer address resolu-
tion processing before sending a Neighbor Advertisement. The host
sends the Neighbor Advertisement to the all-nodes multicast address
of the soliciting host. The target address is copied from the solici-
tation message. The source address MUST be set to the address of the
target field. The Target Link Layer Address extension need not be
filled in.
4.4.3. Constants
DUPL_ADDR_DELAY 4 seconds (XX)
DUPL_ADDR_IGNORE_TIMER 0.1 seconds
DUPL_ADDR_RETRANS_TIMER 4 seconds (XX)
MAX_DUPL_ADDR_RETRANS 1 transmission (XX)
5. SECURITY CONSIDERATIONS
To be completed.
Expires December 5, 1995 [Page 14]
INTERNET-DRAFT Stateless Address Configuration June 1995
6. 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 December 5, 1995 [Page 15]
INTERNET-DRAFT Stateless Address Configuration June 1995
7. REFERENCES
[1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
Addressing Architecture", Internet Draft, May 1995, draft-ietf-
ipngwg-addr-arch-02.txt
[2] T. Narten and E. Nordmark, "IPv6 Neighbor Discovery", Internet
Draft, June 1995, <draft-ietf-ipngwg-discovery-00.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, Erik Nordmark 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 December 5, 1995 [Page 16]
INTERNET-DRAFT Stateless Address Configuration June 1995
Expires December 5, 1995 [Page 17]
