draft-ietf-addrconf-ipv6-auto-01.txt   draft-ietf-addrconf-ipv6-auto-02.txt 
ADDRCONF Working Group Susan Thomson (Bellcore) <draft-ietf-addrconf-ipv6-auto-02.txt>
<draft-ietf-addrconf-ipv6-auto-01.txt>
IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration
Status of this Memo Status of this Memo
This document is a submission to the ADDRCONF Working Group of the This document is a submission to the ADDRCONF Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the addrconf@cisco.com mailing list. to the addrconf@cisco.com mailing list.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
skipping to change at page 1, line 33 skipping to change at page 1, line 31
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." draft" or "work in progress."
To learn the current status of any Internet Draft. please check the To learn the current status of any Internet Draft. please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow 1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
munnari.oz.au. munnari.oz.au.
Abstract Abstract
This document specifies stateless address autoconfiguration. A host In IPv6, there are two types of address autoconfiguration: stateless
can form a link-local address autonomously based on information local address autoconfiguration and stateful address configuration. In
to the host. A host can form an inter-link scope address in two stateless address autoconfiguration, no state is maintained binding a
ways: either autonomously, based on prefixes advertised by routers, particular host interface to a specific list of addresses. Rather, an
or by using the IPv6 version of the Dynamic Host Configuration address is formed algorithmically by concatenating the network prefix
Protocol(DHCPv6). All mechanisms rely on a host having a token that of the attached link to a host token that is unique per link. Hosts
is unique at least per link. This document specifies how a host use stateless address autoconfiguration to form a link-local unicast
forms addresses autonomously. DHCPv6 is described elsewhere. 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
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.
1. INTRODUCTION 1. INTRODUCTION
An IPv6 host may have multiple addresses per interface. The addresses In IPv6, there are two types of address autoconfiguration: stateless
can have one of three scopes: 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.
1. a link-local address, 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.
2. a site-local address, and 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.
3. a global address. 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.
All three address scopes can be autoconfigured. A host can autocon- 2. OVERVIEW
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 An IPv6 host may have multiple unicast addresses per interface[1].
of an interface, a host forms such an address by concatenating a The addresses can have one of three scopes: a link-local scope, a
well-known link-local prefix[1] to a token that is unique per link. site-local scope, or a global scope. Addresses of all three address
The definition of the tokens used are link-dependent. For example, scopes can be autoconfigured. A host is able to autoconfigure a
in the case of a host attached to an link that uses IEEE 802 link-local address completely autonomously. In particular, a host can
addresses, the token is the IEEE 802 address of the interface. 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.
There are two ways to form a site-local or global address. In the On initialization of an interface, a host forms a link-local address
first mechanism, a host forms an inter-link scope address by con- by concatenating a well-known link-local prefix[1] to a token that is
catenating a network prefix advertised in a Router Advertisement[2,3] unique per link. The definition of the tokens used are link-
to a token that is unique per link. Like the link-local address, the dependent. For example, in the case of a host attached to a link
token is defined to be link-layer dependent. This mechanism for that uses IEEE 802 addresses, the token is an IEEE 802 address asso-
forming a site-local or global address is suitable for environments ciated with the interface.
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 A host forms or updates an inter-link scope address on hearing prefix
the Dynamic Host Configuration Protocol (DHCPv6). DHCPv6 is a more advertisements advertised by a router. A global or site-local address
complex protocol allowing for very flexible address assignment under is formed by concatenating a network prefix to a host token that is
the control of a system administrator. This protocol typically unique per link in the same way as described above. The mechanism
requires significant system management, including server and database used to advertise network prefixes for the purposes of address confi-
configuration. 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.
The choice of mechanism to use in forming an inter-link scope address One of the goals of IPv6 address autoconfiguration is not only to be
is advertised by a router, if present, and this choice is configur- able to autoconfigure addresses on startup, but to be able to recon-
able by a system administrator. 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
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.
This document describes how a host forms a link-local address and one One of the basic assumptions of stateless autoconfiguration is that
or more site-local or global addresses autonomously. It also speci- the host token is at least unique per link. However, in practice,
fies how a host determines which mechanism to use to form an inter- host tokens are not always unique because of errors in assignment.
link scope address: the autonomous (stateless) approach or DHCPv6. Thus, it cannot be guaranteed that IPv6 addresses formed from a host
Section 2 describes the router's role in address autoconfiguration token are indeed unique among all hosts on a link. Since duplicate
and Section 3 the host's role. 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.
2. ROUTER BEHAVIOR This document specifies router and host behavior related to stateless
address configuration and duplicate address detection in more detail
in the sections that follow.
The stateless address autoconfiguration mechanism relies on the 3. ROUTER BEHAVIOR
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] The stateless address autoconfiguration mechanism relies on the pre-
and the message formats in [3]. 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.
DISCUSSION: An alternative approach is to advertise address confi- Router Advertisement and Solicitation processing is specified com-
guration information in a separate advertisement entirely. This would pletely in [2] along with the message formats and configuration vari-
be somewhat cleaner since the lifetime of the advertisement would ables. Additional configuration variables pertinent to stateless
then be that of the information advertised. On the other hand, having address configuration are specified below.
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 3.1. Router Configuration Variables
In addition to the configuration variables specified in [2,3], In addition to the configuration variables specified in [2], routers
routers MUST also be configurable as follows. MUST also be configurable as follows.
For each of the IPv6 unicast addresses per interface: For each of the prefixes to be advertised in Prefix Information
extensions per interface:
Autonomous Flag Autonomous Flag
If and only if TRUE, the prefix length is to be advertised for
the purposes of autonomous address configuration.
Default: TRUE
For each interface: If set, the prefix is being advertised for the purposes of
stateless address configuration.
Administered Flag
If and only if TRUE, the host must autoconfigure other confi- Default: TRUE
guration information using DHCPv6. Only valid in extensions
with the Autonomous Flag set to TRUE.
Default: FALSE Deprecation Lifetime
Address_Advertisement_Interval The value to be placed in the Deprecation Lifetime field of
Prefix Information extensions in Router Advertisements sent
from the interface in seconds.
The time allowed between sending unsolicited Address Advertise- Invalidation Lifetime
ments from the interface, in seconds. The value must not be
less than Maximum_Advertisement_Interval of Router Advertise-
ments.
Default: XX 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.
Address_Lifetime For each advertising interface:
The value to be placed in the Lifetime field of the Administered Flag
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 If set, the host must autoconfigure addresses using stateful
address autoconfiguration.
All routers advertising a given prefix on a link MUST be configured Default: FALSE
to advertise the same autoconfiguration mode to hosts.
2.2. Processing Other Flag
A router MUST advertise address autoconfiguration information in a If set, the host must autoconfigure other configuration infor-
Prefix Information Extension of a Router Advertisement. The values of mation (besides the address) using stateful autoconfiguration.
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 Default: FALSE
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 NOTE: All routers advertising a given prefix on a link MUST set all
Advertisement due to actions taken by system management, in particu- of the configuration variables to the same value.
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.
3. HOST ADDRESS AUTOCONFIGURATION PROCESSING 4. HOST BEHAVIOR
3.1. Host Configuration Variables 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.
A host maintains a list of addresses per interface. At a minimum, the This section specifies host address autoconfiguration behavior on
list includes the link-local address, which the host can form auto- interface initialisation and on receiving a Router Advertisement.
nomously whenever an interface is initialised. If a router is This section also specifies a host protocol for attempting to verify
attached to the link or DHCPv6 server is available, the list may also that an address is not a duplicate.
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 4.1. Host Configuration Variables
per interface:
Address A host MUST allow the following variable to be configured per inter-
face:
A valid IPv6 unicast address for this interface Perform_Auto_Config
Default: None If set, the host MUST perform address autoconfiguration process-
ing.
Prefix Length Default: TRUE
The length of the prefix in bits. Prefix length semantics are 4.2. Router Advertisement Processing
specified in [2].
A host must also allow the following variable to be configured per An "autoconfigurable" interface is one on which Router Advertisements
interface: are received and the Perform_Auto_Config flag is set.
Perform_Auto_Config A host MUST perform the following address configuration processing
when a solicited or unsolicited Router Advertisement is received over
an autoconfigurable interface:
If and only if TRUE, the host must perform address autoconfigura- For each valid Router Advertisement:
tion processing.
Default: TRUE 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.
3.2. Host Initialization Behavior If the Other flag is set, the host MUST use stateful autoconfi-
guration to acquire other configuration information besides the
address.
A host must perform the following autoconfiguration procedure when- For each Prefix-Information extension in the Router Advertisement
ever an interface needs to be initialised: that has the Autonomous flag set:
When a host has no address for an interface with - If the prefix advertised matches the prefix of an autoconfig-
Perform_Auto_Config flag set to TRUE, e.g. when a host boots or ured address already in the list, then set the deprecation
when an interface is enabled after being disabled, the host forms timer to that of the deprecation lifetime specified in the
an address of link-local scope. Appendix A specifies how a host extension and the invalidation timer to that of the invalida-
that is attached to a link that uses IEEE 802 addresses forms a tion lifetime. Note that this processing does not apply to a
link-local address. link-local address.
Before adding the link-local address as a valid address to the - If the prefix advertised does not match the prefix of an
list of addresses for the interface, the host SHOULD verify that address already in the list, then form an address using this
the address is indeed unique. The procedure for validating an network prefix. Appendix A specifies how to form an address
address is described in Section X. A host SHOULD also validate any for hosts that have IEEE 802 tokens. The extension is ignored
manually configured addresses this way too. if the prefix is not valid, e.g. it is not the right length
for forming an address with the given host token.
The host solicits a Router Advertisement using one or more Router Add this address to the list with the deprecation timer set
Solicitations, if no Router Advertisements have been heard in the to that of the deprecation lifetime and the invalidation
interface. The procedure for sending Router Solicitations is timer to that of the invalidation lifetime.
specified in [2].
If no Router Advertisement is heard after sending Note that if the deprecation lifetime is zero, the address with
MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after that prefix is immediately deprecated. Similarly, if the invalida-
each as specified in Sending Router Solicitations in [2], the host tion lifetime is zero, the address with that prefix is immediately
must determine whether a DHCPv6 server is present and whether any made invalid. (The invalidation lifetime is defined to be no less
configuration information needs to be acquired. This is to cater than the deprecation lifetime.)
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.
3.3. Router Advertisement Processing An address is valid until the deprecation timer expires. A valid
address may be used as a source address in all outgoing
communications and MUST be accepted as a destination address in
all incoming communications.
Router Advertisement processing is specified in [2] and the message When the deprecation lifetime of an address expires, an address is
format in [3]. In addition to this processing, the host MUST perform said to be deprecated. A deprecated address SHOULD NOT be used as
the following address configuration processing when a solicited or a source address in new communications. However, a deprecated
unsolicited Router Advertisement is received over an interface: 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.
For each Prefix-Information extension in the Router Advertisement: An address remains deprecated until its invalidation timer expires
(The format of the Prefix-Information extension as amended by this at which point the address becomes invalid. An invalid address can
draft for autoconfiguration purposes is specified in Appendix C): no longer be used as a source address in outgoing communications
and is not recognised as a valid destination address in incoming
communications.
The host silently ignores the extension for the purposes of auto- Note that, when choosing a source address in outgoing communica-
configuration if the Perform_Auto_Config flag for the interface is tons, a global valid address should be used in preference to a
FALSE. 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.
Otherwise, the host checks the autoconfiguration mode bits. 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 only the Autonomous flag is set in the Prefix-Information If a host determines that there are no IPv6 routers on a link,
extension, the host forms or verifies a site-local or global either on startup or during normal processing, a host MUST attempt
address as specified below. 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
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.
If both the Autonomous and Administered flags are set in the A host must behave reasonably when there is a change from the
Prefix-Information extension, the host forms or verifies a site- stateless mode to the stateful mode, and vice versa. This can hap-
local or global address as specified below and uses or continues pen because routers advertise a new configuration mode due to a
using DHCPv6 for other autoconfiguration. 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.
Otherwise, the host silently ignores the extension for the pur- 4.3. Host Initialisation
poses of autonomous autoconfiguration.
If none of the prefixes advertised in extensions of the Router Adver- A host forms a link-local address when an autoconfigurable interface
tisement have the Autonomous flag set, then the host uses or contin- is initialised. Appendix A specifies how a host that is attached to
ues using DHCPv6 for autoconfiguration. a link that uses IEEE 802 addresses forms a link-local address.
Note that the above procedure should continue to operate when a sys- Note that an interface may be initialised after any of the following
tem administrator decides to change the autoconfiguration mode from events:
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
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- - The interface is initialized at system startup time.
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 - The interface is reinitialized after a temporary interface
address already in the list, then set a timer to that of the failure or after being temporarily disabled by system manage-
lifetime specified in the extension. Note there is no timer ment.
associated with a link-local address or manually configured
address.
b) If the prefix advertised does not match the prefix of an address - The system changes from being a router to being a host, by hav-
already in the list, then form an address using this network ing its IP forwarding capability turned off by system manage-
prefix. Appendix A specifies how to form an address for hosts ment.
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 - The host is re-attached to a link after being detached for some
lifetime specified in the extension. time.
3.3.1. Address Deprecation and Invalidation - The interface has its Perform_Auto_Config flag changed from
FALSE to TRUE.
An address is valid until the timer expires. 4.4. Detecting Duplicate IPv6 Addresses
When the lifetime of an address expires, an address is said to be The procedure to detect duplicate addresses MUST be implemented in
deprecated. In general, a deprecated address should no longer be hosts and SHOULD be used.
used in new communications, but may be used in existing communica-
tions.
In particular, the internetworking layer should not select a In stateless address configuration, it is only necessary to check
deprecated address as a source address in new communications. How- that one of the autoconfigured addresses is unique since the same
ever, a deprecated address should be allowed to be used as a source token is used to form all addresses. It is recommended that the
address if it is in use by the transport layer in existing communica- link-local address be the address checked since the host always forms
tions or it is explicitly requested by an application. this address.
The internetworking layer must continue to accept datagrams destined The procedure uses Neighbor Solicitation and Advertisement messages
to a deprecated address. The transport layer may refuse to accept new specified in [2] to validate an address and is specified below.
communications requests to a deprecated address, however.
In addition, a host may send a Remote Redirect[2,3] to correspondents Note that this mechanism is not completely reliable, and so it is
when the source address used in communications is deprecated as long possible that duplicate addresses will still exist. If a duplicate
as the host has a valid alternative address. Also, a deprecated address is discovered, the host will need to be configured with a new
address should be removed from the Domain Name System (DNS). This may token, or if this is not possible, the IPv6 addresses will need to be
be done by the host itself, given a DNS dynamic update protocol and manually configured.
sufficient authority, or it may be done on the host's behalf.
The time at which a deprecated address becomes invalid (removed from 4.4.1. Soliciting Host Behavior
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 The host first delays a random amount of time between 0 and
inter-link scope addresses become deprecated, then the host must DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation
determine whether a DHCPv6 server is available for address autoconfi- for the address. This serves to alleviate congestion when many hosts
guration. The host follows the same procedure as described in the start up on the link at the same time, such as after a power failure,
initialisation procedure in this case. 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.)
3.4. Detecting Duplicate IPv6 Addresses 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.
One of the basic assumptions of the autoconfiguration schemes out- NOTE: There SHOULD be some way to inhibit local delivery of the soli-
lined in this document is that the host token is at least unique per citation since, in general, it will not be possible for a host to
link. Tokens are defined to be link-layer dependent, and the token is determine whether a solicitation is from itself or from another host
the link layer address in most cases. In practice, two hosts on the with a duplicate address. If local delivery cannot be inhibited, then
same link may have the same link layer address because of an assign- the host should ignore the first Neighbor Solicitation with an
ment error, in which case the resulting IPv6 addresses will not be unspecified source address or wait for a period of
unique. For this reason, it is prudent to check that the addresses DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation
are indeed unique. In IPv6, it is only necessary to check that one before beginning to process solicitations again.
of the autoconfigured addresses is unique since the same token is
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 If after sending a solicitation, no advertisement is received from
in [2,3] as modified below. To validate an address, the node sends a the target, the node SHOULD retransmit the solicitation every
General Solicitation with the source and destination set to that of DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is
the address to be checked. The node should specify an appropriate received or the solicitation has been retransmitted
Media-Access extension. 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.
On receiving a General Solicitation with a source address that is the 4.4.2. Solicited Node Behavior
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 When a host is in the process of validating an address, it MUST NOT
General_Solicitation_Interval. If a General Advertisement is not send any advertisement in response to a solicitation for that
received in response to the General Solicitation within the interval, address. Rather, all solicitations for the address are ignored,
the address is considered to be validated. If a General Advertisement except when the solicitation is from the unspecified address i.e.
is received with a source address the same as the address being vali- the Neighbor Solicitation message has a target address which is the
dated, it must cease operation on that interface and indicate an same as the address to be validated, and a source address that is the
appropriate error. 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.
Note that this mechanism is not completely reliable, and so it is Once a host has validated its address, it responds to a Neighbor Sol-
possible that duplicate addresses will still exist. If a duplicate icitation with a Neighbor Advertisement as specified in [2]. However,
address is discovered, the host will need to be configured with a new the processing of the solicitation is somewhat different from that in
token, or if this is not possible, the IPv6 addresses will need to be [2] when a solicitation is received from the unspecified address. In
manually configured. 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.
DISCUSSION: There is a problem with a race condition when two (or 4.4.3. Constants
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- DUPL_ADDR_DELAY 4 seconds (XX)
ing based on the token (link-layer address) only does not help if the DUPL_ADDR_IGNORE_TIMER 0.1 seconds
token is not unique. DUPL_ADDR_RETRANS_TIMER 4 seconds (XX)
MAX_DUPL_ADDR_RETRANS 1 transmission (XX)
4. SECURITY CONSIDERATIONS 5. SECURITY CONSIDERATIONS
To be completed. To be completed.
5. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS 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 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 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 canonical format, i.e. the Individual/Group bit is the low-order bit
of the furst byte. of the furst byte.
A host forms an IPv6 address per link by concatenating an 80-bit pre- A host forms an IPv6 address per link by concatenating an 80-bit pre-
fix with the IEEE 802 address as follows: fix with the IEEE 802 address as follows:
| 80 bits | 48 bits | | 80 bits | 48 bits |
+---------------------------------------+------------------------+ +---------------------------------------+------------------------+
| prefix | IEEE 802 address | | prefix | IEEE 802 address |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
In the case of a link-local prefix, the prefix is well-defined[1]. 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. The prefixes of other types of addresses need to be configured.
6. APPENDIX B: UNIQUENESS OF HOST TOKENS 7. REFERENCES
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.
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.
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 [1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
Draft, January 1995, <draft-simpson-ipv6-discov-process-02.txt> Addressing Architecture", Internet Draft, May 1995, draft-ietf-
ipngwg-addr-arch-02.txt
[3] W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For- [2] T. Narten and E. Nordmark, "IPv6 Neighbor Discovery", Internet
mats", Internet Draft, January 1995, <draft-simpson-ipv6- Draft, June 1995, <draft-ietf-ipngwg-discovery-00.txt>
discov-formats-02.txt>
Acknowledgements Acknowledgements
The author would like to thank the members of both the IPNG and ADDRCONF 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, working groups for their input. In particular, thanks to Jim Bound,
Steve Deering and Bill Simpson. Steve Deering, Erik Nordmark and Bill Simpson.
Author's Addresses Author's Addresses
Susan Thomson Susan Thomson
Bellcore Bellcore
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
U.S.A. U.S.A.
Phone: +1 201-829-4514 Phone: +1 201-829-4514
 End of changes. 89 change blocks. 
393 lines changed or deleted 385 lines changed or added

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