draft-ietf-addrconf-ipv6-auto-02.txt   draft-ietf-addrconf-ipv6-auto-03.txt 
<draft-ietf-addrconf-ipv6-auto-02.txt> ADDRCONF Working Group Susan Thomson (Bellcore)
<draft-ietf-addrconf-ipv6-auto-03.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 31 skipping to change at page 1, line 33
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
In IPv6, there are two types of address autoconfiguration: stateless This document specifies how a node configures a link-local address
address autoconfiguration and stateful address configuration. In per interface, and how a host configures a list of global or site-
stateless address autoconfiguration, no state is maintained binding a local addresses per interface, without any manual configuration.
particular host interface to a specific list of addresses. Rather, an Stateless address autoconfiguration is only one mechanism available
address is formed algorithmically by concatenating the network prefix to hosts; stateful address configuration is also available. While
of the attached link to a host token that is unique per link. Hosts stateful address configuration is outside the scope of this document,
use stateless address autoconfiguration to form a link-local unicast it is specified how hosts determine which configuration method must
address and may use stateless address autoconfiguration to form be used. The document also specifies a protocol for detecting
global and site-local unicast addresses. This document specifies how whether an address is a duplicate when it is initially configured.
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
In IPv6, there are two types of address autoconfiguration: stateless In IPv6, a host has two mechanisms available to form a global or
address autoconfiguration and stateful address configuration. In site-local address that require no manual configuration: the state-
stateless address autoconfiguration, no state is maintained binding a less method and the stateful method. In the stateless method, no
particular host interface to a specific list of addresses. Rather, an external state is maintained for the purpose of indicating to a host
interface address is formed algorithmically by concatenating the net- the list of addresses to use for an interface. Rather, a host forms a
work prefix of the attached link to a host token unique per link. In list of addresses algorithmically by concatenating each of the net-
stateful address configuration, state is maintained, typically by a work prefixes of the attached link to an interface token unique per
server. For example, the IPv6 Dynamic Host Configuration Protocol is link. The interface token is defined to be link-dependent and may be
an example of stateful address autoconfiguration. the hardware address, for example. In contrast, state is maintained
in the stateful address configuration, typically in 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 Stateless autoconfiguration is designed to make address configuration
very simple to use and implement, and is suitable for environments very simple to use and implement, and is suitable for environments
with simple topologies, e.g. routerless networks, and for environ- with simple topologies, e.g. routerless networks, and for environ-
ments where system administrative control is not desired. In con- ments where system administrative control is not desired, e.g. plug-
trast, stateful address configuration is designed to support flexible and-play environments. In contrast, stateful address configuration
address assignment and is suitable for more sophisticated topologies is designed to support flexible address assignment and is suitable
and for environments where system administrative control is desired. for more sophisticated topologies and for environments where system
administrative control is desired, e.g. corporate networks.
A host always uses stateless address autoconfiguration to form a Any node can use stateless address autoconfiguration to form a link-
link-local address per interface. A host may use either stateless or local address per interface. A host can use either stateless or
stateful autoconfiguration to configure addresses of inter-link scope stateful autoconfiguration (or both) to configure global or site-
for an interface, i.e. global or site-local addresses. local addresses for an interface. The choice of mechanism for confi-
guring global or site-local addresses is itself configurable, and
requires no manual configuration per host.
This document describes how a host forms unicast addresses per inter- One of the basic assumptions of stateless autoconfiguration is that
face using stateless autoconfiguration. It also specifies how a host the token used to form addresses per interface is at least unique per
determines whether to use the stateless mechanism or the stateful link. However, whatever the type of tokens used, interface tokens are
mechanism. Stateful address autoconfiguration is outside the scope not guaranteed to always be unique in practice because of errors in
of this document. assignment. Thus, it is possible that IPv6 addresses formed using
stateless autoconfiguration are not unique among all nodes on a link.
Since duplicate IPv6 addresses are very difficult to track down when
they occur, this document also specifies a procedure for detecting
duplicate addresses. Note that the algorithm does not only apply to
addresses autoconfigured using the stateless mode. It should be used
to verify the uniqueness of any address, for example, addresses con-
figured using the stateful mode or manually configured addresses.
2. OVERVIEW This document describes how a node configures a link-local address
per interface using stateless address autoconfiguration, and how a
host configures global or site-local unicast addresses per interface
using stateless address autoconfiguration. Stateful address autocon-
figuration is outside the scope of this document. However, the docu-
ment does specify how a host determines whether to use the stateless
mechanism or the stateful mechanism for configuring global or site-
local addresses.
An IPv6 host may have multiple unicast addresses per interface[1]. The document also describes the algorithm used by a node to detect if
The addresses can have one of three scopes: a link-local scope, a an address is a duplicate when initially configured.
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 2. TERMINOLOGY
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 node - a device that implements IPv6.
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 router - a node that forwards IPv6 packets not explicitly
able to autoconfigure addresses on startup, but to be able to recon- addressed to itself.
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.
One of the basic assumptions of stateless autoconfiguration is that host - any node that is not a router.
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 upper layer - a protocol layer immediately above IPv6. Examples are
address configuration and duplicate address detection in more detail transport protocols such as TCP and UDP, control
in the sections that follow. protocols such as ICMP, routing protocols such as OSPF,
and internet or lower-layer protocols being "tunneled"
over (i.e., encapsulated in) IPv6 such as IPX,
AppleTalk, or IPv6 itself.
3. ROUTER BEHAVIOR link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets (simple
or bridged); PPP links; X.25, Frame Relay, or ATM
networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.
The stateless address autoconfiguration mechanism relies on the pre- neighbors - nodes attached to the same link.
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- interface - a node's attachment to a link.
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 packet - an IPv6 header plus payload.
In addition to the configuration variables specified in [2], routers link MTU - the maximum transmission unit, i.e., maximum packet
MUST also be configurable as follows. size in octets, that can be conveyed in one piece over
a link.
For each of the prefixes to be advertised in Prefix Information target - a node about which address resolution information is
extensions per interface: sought, or a node which is the new first-hop when being
redirected.
Autonomous Flag address - an IPv6-layer identifier for an interface or a set of
interfaces.
If set, the prefix is being advertised for the purposes of unicast address
stateless address configuration. - an identifier for a single interface. A packet sent
to a unicast address is delivered to the interface
identified by that address.
Default: TRUE anycast address
- an identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an
anycast address is delivered to one of the interfaces
identified by that address (the "nearest" one,
according to the routing protocols' measure of
distance).
Deprecation Lifetime multicast address
- an identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a
multicast address is delivered to all interfaces
identified by that address.
The value to be placed in the Deprecation Lifetime field of link-layer address
Prefix Information extensions in Router Advertisements sent - a link-layer identifier for an interface. Examples are
from the interface in seconds. IEEE 802 addresses for Ethernet links, E.164 addresses
for ISDN links.
Invalidation Lifetime link-local address
- an address with a scope that is limited to
the locally attached link.
The value to be placed in the Invalidation Lifetime field of site-local address
Prefix Information extensions in Router Advertisements sent - an address with a scope that is limited to the
from the interface in seconds. Must be no less than Deprecation local site.
Lifetime.
For each advertising interface: global address
- an address with unlimited scope.
Administered Flag communication
- any packet exchange between nodes that requires
or recommends that the address of each node used in the
exchange remain the same for the duration of the
packet exchange. Examples are a TCP connection or a
UDP request-response.
If set, the host must autoconfigure addresses using stateful deprecation lifetime
address autoconfiguration. - indicates the time at which an address should no
longer be used as a source address in new
communications. The deprecation lifetime must be
less than or equal to the invalidation lifetime
of the address.
Default: FALSE invalidation lifetime
- indicates the time at which an address no longer
identifies an interface or set of interfaces.
The invalidation lifetime must be greater than
or equal to the deprecation lifetime of the address.
Other Flag valid address
- an address whose deprecation lifetime has not yet
expired.
If set, the host must autoconfigure other configuration infor- deprecated address
mation (besides the address) using stateful autoconfiguration. - an address whose deprecation lifetime has expired,
but whose invalidation lifetime has not.
Default: FALSE invalid address
- an address whose invalidation lifetime has
expired.
NOTE: All routers advertising a given prefix on a link MUST set all interface token
of the configuration variables to the same value. - a link-dependent identifier for an interface that is
(at least) unique per link. An example is an IEEE 802
address.
4. HOST BEHAVIOR 2.1. Requirements
Conceptually, a host maintains a list of addresses per interface. Throughout this document, the words that are used to define the sig-
Entries in the list are created as a result of forming addresses from nificance of the particular requirements are capitalized. These
prefixes advertised in Prefix Information extensions of Router Adver- words are:
tisements. Each entry in the list has two associated timers, a
deprecation timer and an invalidation timer, which have values set MUST
according to lifetimes learned from the router advertisement. In This word or the adjective "REQUIRED" means that the item is an
addition, the address list always includes the link-local address, absolute requirement of this specification.
which the host forms autonomously whenever an interface is initial-
ised. The deprecation and invalidation lifetimes of a link-local MUST NOT
address are set to infinity. This phrase means the item is an absolute prohibition of this
specification.
SHOULD
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full impliciations should be understood and the
case carefully weighed before choosing a different course.
SHOULD NOT
This phrase means that there may exist valid reasons in particu-
lar circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighted before implementing any behavior
described with this label.
MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example, another vendor may omit the
same item.
3. CONCEPTUAL MODEL OF HOST BEHAVIOR
Conceptually, a host maintains three data structures: a list of
addresses per interface and two flags. One flag, called the "address
mode" flag, indicates whether the stateful protocol is to be used for
address configuration (possibly in addition to the stateless proto-
col). The other flag, called the "other configuration mode" flag,
indicates whether the stateful protocol is to be used for configura-
tion of other information besides addresses.
The address list always includes at least one address, the host's
link-local address, which is an address that can only be used in com-
munications between nodes attached to the link. In addition, the
address list includes any global or site-local addresses that have
been manually or automatically configured.
Note that stateless address autoconfiguration applies only to the
formation of unicast addresses. A node may, however, have anycast and
multicast addresses associated with an interface. In particular, a
host must join the all-nodes multicast address on any multicast
interface, and the solicited-node multicast address corresponding to
each unicast address on any multicast interface.
3.1. Address Configuration
3.1.1. Link-Local Address
On initialization of an interface, a host must form a link-local
address by concatenating a well-known link-local prefix[1] to an
interface 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 the
48-bit IEEE 802 link-layer address of the interface. Tokens for a
specific link are defined in link-specific IPv6 documents and are
outside the scope of this document.
Note that 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.
3.1.2. Global/Site-Local Address
A host forms a new global/site-local address whenever a new prefix is
advertised by a router and stateless address configuration is
enabled. The address is formed by concatenating the network prefix
to the interface token that is unique per link in the same way as a
link-local address described above.
The mechanism used to advertise network prefixes for the purposes of
address configuration is the same as that used in Neighbor Discovery
for the purposes of prefix discovery. A router advertises prefix
information periodically and a host uses this information to config-
ure and reconfigure addresses.
3.2. Address Reconfiguration
One of the goals of IPv6 address autoconfiguration is not only to be
able to autoconfigure a list of addresses on initialization of an
interface, but to be able to change the address list dynamically.
Note that the link-local address never changes (except possibly on
interface re-initialization). Host addresses may need to change for a
number of reasons. For example, if the address assignment scheme is
provider-based, hosts may need to change addresses when hosts change
provider. Hosts may also need to change addresses when they are
disconnected from one link and connected to another. Reconfiguration
must not only allow a host to acquire a new address, but must also
allow hosts to time-out an old address.
Current networking protocols have not been designed to maintain
existing communications during an address change. For example, a TCP
connection will no longer work if one of the hosts changes its
address in the middle of a connection. Even in a UDP exchange, a host
is expected to be able to identify itself using the same address for
the length of the exchange.
To minimise disruption caused by an address change, an address is
configured with two lifetimes : a deprecation lifetime and an invali-
dation lifetime. The deprecation lifetime must be less than or equal
to the invalidation lifetime. Before expiry of the deprecation life-
time, the address is valid and may be used as the source and destina-
tion in any communications. At and after expiry of the deprecation
lifetime, but before the invalidation lifetime has expired, the
address is considered to be deprecated. A deprecated address can
still be used as the source and destination in packets legitimately,
but the deprecated address should not be used as a source address in
new communications if other valid addresses exist and these addresses
have sufficient scope. If no valid addresses of sufficient scope
exist, then the deprecated address should still be used. (Note that
there will always be at least one valid address in the address list,
the link-local address (see below), but this address is only useful
for communications on the local link, and thus cannot be used in
place of a deprecated address for non-local link communications).
An address becomes invalid when the invalidation lifetime expires.
Such an address must not be used as a source address in outgoing com-
munications or accepted as a destination address in incoming communi-
cations. An invalid address is removed from the address list of the
interface.
Note that the deprecation lifetimes and invalidation lifetimes of the
link-local address are set to infinity. Thus, the link-local address
is never deprecated.
The intention of the two lifetimes per address is to allow system
administrators to specify a graceful transition period during
renumbering. The purpose of the deprecation time is to indicate to
the host to start using another (presumably longer lasting) address
in new communications to minimise the risk of breaking communications
when the old one times out. A system administrator should set the
deprecation period long enough so that most, if not all, communica-
tions have switched over to using the new address by the time the old
one becomes invalid. The length of the deprecation period will be
environment-dependent as it depends on the expected length of commun-
ications.
The fact that addresses have a deprecation lifetime does not need to
affect the implementation of applications, i.e. an application is
not expected to react when an address it is using becomes deprecated.
The purpose of the deprecation lifetime is to help applications or
networking software to select a sufficiently long-lasting source
address at the beginning of a new communication. The IP layer is
expected to provide a means for upper layers or applications to
select the most appropriate source address given a particular desti-
nation. An application may choose to select the source address
itself before starting a new communication or may leave the address
unspecified, in which case the upper networking layers will use the
mechanism provided by the IP layer to choose a suitable address on
the application's behalf.
4. ROUTER SPECIFICATION
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 option of a Router
Advertisement. Prefix Information includes
1. the prefix itself
2. the prefix length
3. a flag indicating whether the prefix is to be used for prefix
discovery[2].
4. a flag indicating whether the prefix is to be used for stateless
address autoconfiguration
5. the deprecation lifetime of the prefix in seconds for the pur-
pose of address deprecation
6 the invalidation lifetime of the prefix for the purpose of
address invalidation. This field is also used by prefix
discovery[2].
Router Advertisement processing is specified completely in [2] along
with the message formats and configuration variables.
5. HOST SPECIFICATION
This section specifies host address autoconfiguration behavior on This section specifies host address autoconfiguration behavior on
interface initialisation and on receiving a Router Advertisement. 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 5.1. Host Configuration Variables
A host MUST allow the following variable to be configured per inter- A host SHOULD allow the following variable to be configured per mul-
face: ticast interface:
Perform_Auto_Config Perform_Addr_Config
If set, the host MUST perform address autoconfiguration process- If set, the host MUST use either stateless or stateful mechanisms
ing. to configure global or site-local addresses and to acquire other
configuration information as specified in this document.
Default: TRUE Default: TRUE
4.2. Router Advertisement Processing An interface that has the Perform_Addr_Config flag set is called an
"autoconfigurable interface".
An "autoconfigurable" interface is one on which Router Advertisements 5.2. Message Validation
are received and the Perform_Auto_Config flag is set.
A host MUST perform the following address configuration processing A host MUST silently discard any Router Advertisement that does not
when a solicited or unsolicited Router Advertisement is received over specify the validity checks as specified in [2]. An advertisement
that passes these validity checks is called a valid advertisement.
5.3. Router Advertisement Processing
To receive a Router Advertisement, a host joins the all-nodes multi-
cast address over all multicast-capable interfaces.
A host performs the following address configuration processing when a
valid solicited or unsolicited Router Advertisement is received over
an autoconfigurable interface: an autoconfigurable interface:
For each valid Router Advertisement: For each valid Router Advertisement:
If the Administered flag is set, the host MUST use stateful auto- The host stores the current value of the Address Mode and then
configuration to acquire a list of site-local or global addresses sets the Address Mode to the value of the Managed flag (M bit).
per interface. If the new value is set, the host MUST use stateful address confi-
guration to configure and maintain a list of site-local or global
addresses per interface.
If the Other flag is set, the host MUST use stateful autoconfi- Note that this does not mean that the stateful protocol is neces-
guration to acquire other configuration information besides the sarily invoked each time a Router Advertisement arrives with the M
address. bit set. The host uses the flag only to indicate whether the
stateful protocol is to be used to configure addresses. The state-
ful protocol is enabled as soon as the Address Mode changes from
FALSE to TRUE. The protocol is disabled as soon as the flag
changes from TRUE to FALSE. The actual times at which the proto-
col is invoked, for example, to request a list of addresses or
renew a list of addresses, are specified by the protocol itself.
The host stores the current value of the Other Configuration flag
and then sets the Other Configuration Mode flag to that in the
Router Advertisement (O bit). If the new value is set, the host
MUST use stateful autoconfiguration to acquire other configuration
information besides the address.
The above disclaimer applies here as well. The O bit indicates
whether the host must use the stateful mode to acquire other con-
figuration information. The stateful protocol is enabled for this
purpose as soon as the Other Configuration Mode changes from FALSE
to TRUE. The protocol is disabled as soon as the mode changes from
TRUE to FALSE. The mode does not indicate the timing of frequency
of acquiring that information. This is defined by the stateful
protocol itself.
For each Prefix-Information extension in the Router Advertisement For each Prefix-Information extension in the Router Advertisement
that has the Autonomous flag set: that has the Autonomous flag set:
- If the prefix advertised matches the prefix of an autoconfig- - If the prefix advertised matches the prefix of an
ured address already in the list, then set the deprecation autoconfigured address already in the list, then set the
timer to that of the deprecation lifetime specified in the deprecation timer to that of the deprecation lifetime speci-
extension and the invalidation timer to that of the invalida- fied in the extension and the invalidation timer to that of
tion lifetime. Note that this processing does not apply to a the invalidation lifetime.
link-local address.
Note that this processing MUST NOT be applied to the link-
local address. That is, if the well-known link-local prefix
is advertised for some reason (probably a configuration
error), then the prefix should be ignored and a system
management error logged.
- If the prefix advertised does not match the prefix of an - If the prefix advertised does not match the prefix of an
address already in the list, then form an address using this address already in the list, then form an address using this
network prefix. Appendix A specifies how to form an address network prefix and the interface token. Definitions of the
for hosts that have IEEE 802 tokens. The extension is ignored interface token to be used on a specific link are documented
if the prefix is not valid, e.g. it is not the right length elsewhere.
for forming an address with the given host token.
If the prefix advertised is too short or too long to form a
128-bit address, given the interface token, the prefix is
ignored and an error is logged.
Add this address to the list with the deprecation timer set Add this address to the list with the deprecation timer set
to that of the deprecation lifetime and the invalidation to that of the deprecation lifetime and the invalidation
timer to that of the invalidation lifetime. timer to that of the invalidation lifetime.
Note: The address list should be variable-length. Hosts
should be able to store the link-local address as well as all
addresses configured using both the stateless and stateful
modes. If the implementation cannot store all addresses, the
host should log a system management error.
Note that if the deprecation lifetime is zero, the address with Note that if the deprecation lifetime is zero, the address with
that prefix is immediately deprecated. Similarly, if the invalida- that prefix is immediately deprecated. Similarly, if the invalida-
tion lifetime is zero, the address with that prefix is immediately tion lifetime is zero, the address with that prefix is immediately
made invalid. (The invalidation lifetime is defined to be no less made invalid. (The invalidation lifetime is defined to be no less
than the deprecation lifetime.) than the deprecation lifetime.) If the deprecation lifetime is
infinity, the address is never deprecated. Similarly, if the
invalidation lifetime is infinity, the address is never invali-
dated. The value of infinity is defined in [2].
An address is valid until the deprecation timer expires. A valid An address is valid until the deprecation timer expires. A valid
address may be used as a source address in all outgoing address can be used as a source address in all outgoing
communications and MUST be accepted as a destination address in communications and is accepted as a destination address in all
all incoming communications. incoming communications.
When the deprecation lifetime of an address expires, an address is When the deprecation lifetime of an address expires, the address
said to be deprecated. A deprecated address SHOULD NOT be used as SHOULD continue to be used as a source address if it is in use in
a source address in new communications. However, a deprecated existing communications, but SHOULD NOT be used in new communica-
address SHOULD continue to be used as a source address if it is in tions if a valid address is available and it has sufficient scope.
use in existing communications. The IP layer MUST continue to The IP layer MUST continue to accept datagrams destined to a
accept datagrams destined to a deprecated address. Upper layers deprecated address since a deprecated address is still defined to
MAY refuse to accept new communications requests to a deprecated identify the interface.
address, however.
An address remains deprecated until its invalidation timer expires An address remains deprecated until its invalidation timer expires
at which point the address becomes invalid. An invalid address can at which point the address becomes invalid and is removed from the
no longer be used as a source address in outgoing communications address list. An invalid address can no longer be used as a
and is not recognised as a valid destination address in incoming source address in outgoing communications and is not recognised as
communications. a valid destination address in incoming communications since the
address is defined to no longer identify the interface.
Note that, when choosing a source address in outgoing communica- On initialisation of an interface, if a host determines that there
tons, a global valid address should be used in preference to a are no IPv6 routers on a link, a host MUST attempt to use stateful
site-local valid address, which in turn should be used in prefer- autoconfiguration to acquire addresses and other configuration
ence to the link-local address. Similarly, a global deprecated information. This is needed to support networks with no IPv6
address should also be used in preference to a site-local depre- routers. The host determines that there are no routers on the
cated addresses. Note that the link-local address is never depre- link after startup if no Router Advertisements are heard in the
cated; it is always valid. One of the implications of these rules time that it would take to send MAX_ROUTER_SOLICITATIONs and wait
is that if there are no valid inter-link scope addresses, e.g. all for a response[2]. If a router comes up on the link and Router
global and site-local addresses are deprecated, then the host will Advertisements begin to be received, a host MUST start to use
default to using the link-local address as a source address in new Router Advertisements in the normal way, and, in particular, use
communications. advertisements to determine whether stateless or stateful address
configuration should be in use.
To limit storage space required for the address list, a host may Note that it is possible for hosts to get address information
choose not to store all valid and deprecated addresses. Deprecated using both stateless and stateful protocols since both may be
addresses that are not in use by existing communications should be enabled at the same time. Even if only stateless address autocon-
discarded in favor of valid addresses and deprecated addresses figuration mode is enabled, it is still possible for hosts to get
that are in use. information from multiple sources since multiple routers may be
advertising prefix information. The rules for handling this is as
follows: hosts accept the union of all information received using
the stateless and stateful protocols. If different sources config-
ure the same address, then the address is updated with the most
recently advertised lifetime.
If a host determines that there are no IPv6 routers on a link, It is also possible for hosts to contain address information from
either on startup or during normal processing, a host MUST attempt different sources, when changing from one mechanism to the other,
to use stateful autoconfiguration to acquire addresses or other i.e. when changing from stateless mode to stateful mode, and vice
configuration information if it is not already doing so. This is versa. In this case, the rules are no different from above. If the
needed to support networks with no IPv6 routers. The host deter- newly enabled mode is configured to hand out different addresses
mines that there are no routers on the link after startup if no than the mode just disabled, then the host contains the union of
Router Advertisements are heard in the time that it would take to addresses from both sources until the addresses configured using
send MAX_ROUTER_SOLICITATIONs and wait for a response[2]. During the old protocol timeout. If both the old and new modes are con-
normal processing, it is determined that there are no routers when figured to hand out the same address, then the address is updated
all router advertisements have timed out. If a router comes up on with the most recently advertised lifetime. NOTE: The above
the link and Router Advertisements begin to be received, a host assumes that the stateless and stateful modes have the same life-
MUST start to use Router Advertisements in the normal way, and, in time semantics.
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 6. NODE SPECIFICATION
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 This section specifies the rules for forming a link-local address. It
also specifies the protocol to be used for duplicate address detec-
tion.
A host forms a link-local address when an autoconfigurable interface 6.1. Forming a Link-Local Address
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 A node MUST have a link-local address. A node forms a link-local
events: address whenever an interface is initialised. The method for forming
a link-local address is link-dependent and is outside the scope of
this document.
An interface may be initialised or become autoconfigurable after any
of the following events:
- The interface is initialized at system startup time. - The interface is initialized at system startup time.
- The interface is reinitialized after a temporary interface - The interface is reinitialized after a temporary interface
failure or after being temporarily disabled by system manage- failure or after being temporarily disabled by system manage-
ment. ment.
- The system changes from being a router to being a host, by hav- - The node is re-attached to a link after being detached for some
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. time.
- The interface has its Perform_Auto_Config flag changed from The link-local address is highly likely to need to be one of the
FALSE to TRUE. first events in the interface initialisation process. Clearly, it
must be formed before any duplicate detection processing is performed
4.4. Detecting Duplicate IPv6 Addresses for this address (Section 6.2). In hosts, a link-local address is
also required before a sends out a Router Solicitation, assuming the
node chooses to do this[2]. This is because a solicitation is only
sent if an advertisement has not yet been heard (and hence no non-
link local address can be formed), and the unspecified address cannot
be used as a source address in a Router Solicitation.
The procedure to detect duplicate addresses MUST be implemented in 6.2. Detecting Duplicate Addresses
hosts and SHOULD be used.
In stateless address configuration, it is only necessary to check The procedure to detect a duplicate address MUST be enabled by
that one of the autoconfigured addresses is unique since the same default in nodes and SHOULD be used.
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 In principle, the duplicate address detection procedure is applied to
specified in [2] to validate an address and is specified below. each new address configured for an interface, whether it be manually
configured or configured automatically using either the stateless or
stateful mode. However, if the addresses belonging to an interface
are formed using the same interface token (as is the case in state-
less autoconfiguration and may be the case in other forms of confi-
guration), then it is only necessary to check that one of the
addresses is unique on the link. In the stateless mechanism, it is
recommended that the link-local address be the address checked for
two reasons. First, it makes the implementation simpler, since the
link-local address is guaranteed to always exist in all nodes,
whereas global and site-local addresses are not. Second, in hosts,
there will be less delay in performing duplicate address detection.
Address validation can be done as soon as a link-local address is
formed (this can be done immediately on initialisation of an inter-
face), whereas checking a global or site-local address involves wait-
ing until a host hears a Router Advertisement containing address pre-
fixes, and there is the possibility that no advertisement will be
heard at all.
Note that this mechanism is not completely reliable, and so it is The procedure for duplicate address detection uses Neighbor Solicita-
possible that duplicate addresses will still exist. If a duplicate tion and Advertisement messages specified in [2] to validate an
address is discovered, the host will need to be configured with a new address as specified below. Note that before carrying out this pro-
token, or if this is not possible, the IPv6 addresses will need to be cedure, a node joins the all-nodes multicast address. Also, this
manually configured. mechanism is not completely reliable, and so it is possible that
duplicate addresses will still exist. If a duplicate address is
discovered after carrying out this procedure, the node 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 6.2.1. Soliciting Node Behavior
The host first delays a random amount of time between 0 and An address is checked for uniqueness only once, when the address is
DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation initially configured.
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 Once the address is configured, the node sends a Neighbor Solicita-
containing the address to be validated. The source is set to the tion with a target address containing the address to be validated.
unspecified address and the destination is set to the solicited-node The source is set to the unspecified address and the destination is
multicast address. The Source Link Layer Address extension SHOULD set to the solicited-node multicast address. The Source Link Layer
NOT be sent. Address extension SHOULD NOT be sent (as it will be ignored by the
destination node[2]). Loopback of the Neighbor Solicitation MUST NOT
be disabled.
NOTE: There SHOULD be some way to inhibit local delivery of the soli- NOTE: If the Neighbor Solicitation is the first message to be sent
citation since, in general, it will not be possible for a host to from an interface on interface initialisation, the node should delay
determine whether a solicitation is from itself or from another host a random amount of time between 0 and MAX_INITIALIZATION_DELAY
with a duplicate address. If local delivery cannot be inhibited, then seconds before sending the solicitation. This serves to alleviate
the host should ignore the first Neighbor Solicitation with an congestion when many nodes start up on the link at the same time,
unspecified source address or wait for a period of such as after a power failure, and helps to avoid race conditions
DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation when more than one node is trying to solicit for the same address at
before beginning to process solicitations again. the same time. (It is recommended that nodes include some unique
value in the seed used to initialise their pseudo-random number gen-
erators. Note that using only the node token as a unique value is not
sufficient to avoid race conditions since the token cannot be relied
upon to be unique. Although the randomization range is specified 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.)
If after sending a solicitation, no advertisement is received from If after sending a solicitation, no Neighbor Advertisement is
the target, the node SHOULD retransmit the solicitation every received from the target, the node SHOULD retransmit the solicitation
DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is at most every DUPL_ADDR_RETRANS_TIMER seconds until either an adver-
received or the solicitation has been retransmitted tisement is received or the solicitation has been retransmitted
MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
target address the same as the address being validated, it must cease target address the same as the address being validated in the time it
operation on that interface and indicate an appropriate error. If no takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it
such advertisement is received in response to the Neighbor Solicita- must disable that interface and log a system management error. If no
tions sent, the address is considered to be valid. such advertisement is received within the time specified, 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
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 6.2.2. Solicited Node Behavior
DUPL_ADDR_DELAY 4 seconds (XX) A node is in the process of validating an address when a Neighbor
DUPL_ADDR_IGNORE_TIMER 0.1 seconds Solicitation has been sent for the address and no Neighbor Advertise-
DUPL_ADDR_RETRANS_TIMER 4 seconds (XX) ment advertising that address has been received in the time it takes
MAX_DUPL_ADDR_RETRANS 1 transmission (XX) to send out MAX_DUPL_ADDR_RETRANS solicitations and wait for an
advertisement (DUPL_ADDR_IGNORE_TIMER seconds).
5. SECURITY CONSIDERATIONS A node must follow special rules when it receives a Neighbor Solici-
tation for an address that it is in the process of validating. This
is done to help avoid the race condition where more than one node is
attempting to validate the address at the same time, i.e. each node
sends out a Neighbor Solicitation and waits to hear a Neighbor Adver-
tisement for the address, but no node actually sends an advertisement
since the address has not yet been validated.
To be completed. The special rules are as follows: When a node is in the process of
validating an address and receives a Neighbor Solicitation for that
address, it MUST NOT send any advertisement in response to a solici-
tation for that address. Rather, the node silently discards the sol-
icitation unless the source address is the unspecified address. In
the latter case, the first such solicitation received is noted, but
otherwise silently discarded (see NOTE below). Any subsequent such
solicitations cause the node to disable the interface and log a sys-
tem management error.
6. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS NOTE: The above behavior is required because nodes send out Neighbor
Solicitations for their own address with loopback enabled. Thus, a
node will always receive at least one solicitation for its own
address. However, there is no way for the node to determine, in gen-
eral, whether the solicitation comes from itself or another node
since the source of the packet is the unspecified address. Hence, the
above rules specify that a duplicate address is detected only if the
node receives more than one solicitation for the address.
The token for an interface on an IEEE 802 link or any link that uses Once a node has validated its address, it responds to a Neighbor Sol-
IEEE 802 addressing, such as FDDI, is the 48-bit IEEE 802 address in icitation with a Neighbor Advertisement as specified in [2].
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- 6.2.3. Constants
fix with the IEEE 802 address as follows:
| 80 bits | 48 bits | MAX_INITIALIZATION_DELAY 3 seconds
+---------------------------------------+------------------------+ DUPL_ADDR_RETRANS_TIMER 3 seconds
| prefix | IEEE 802 address | MAX_DUPL_ADDR_RETRANS 1 transmission
+----------------------------------------------------------------+
In the case of a link-local prefix, the prefix is well-defined[1]. 7. SECURITY CONSIDERATIONS
The prefixes of other types of addresses need to be configured. To be completed.
7. REFERENCES 8. REFERENCES
[1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6) [1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
Addressing Architecture", Internet Draft, May 1995, draft-ietf- Addressing Architecture", Internet Draft, May 1995, draft-ietf-
ipngwg-addr-arch-02.txt ipngwg-addr-arch-02.txt
[2] T. Narten and E. Nordmark, "IPv6 Neighbor Discovery", Internet [2] T. Narten, E. Nordmark and W. A. Simpson, "IPv6 Neighbor
Draft, June 1995, <draft-ietf-ipngwg-discovery-00.txt> Discovery", Internet Draft, July 1995, <draft-ietf-ipngwg-
discovery-01.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, Erik Nordmark and Bill Simpson. Steve Deering, Erik Nordmark and Bill Simpson.
Author's Addresses Author's Addresses
Susan Thomson Susan Thomson
 End of changes. 84 change blocks. 
375 lines changed or deleted 593 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/