WDIFF

draft-ietf-addrconf-ipv6-auto-02.txt --> draft-ietf-addrconf-ipv6-auto-03.txt

ADDRCONF Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT June 5, July 7, 1995
<draft-ietf-addrconf-ipv6-auto-02.txt>
<draft-ietf-addrconf-ipv6-auto-03.txt>

IPv6 Stateless Address Autoconfiguration

Status of this Memo

This document is a submission to the ADDRCONF Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the addrconf@cisco.com mailing list.

This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."

To learn the current status of any Internet Draft. please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
munnari.oz.au.

Abstract

In IPv6, there are two types of address autoconfiguration: stateless
address autoconfiguration and stateful address configuration. In
stateless address autoconfiguration, no state is maintained binding a
particular host interface to a specific list of addresses. Rather, an
address is formed algorithmically by concatenating the network prefix
of the attached link to

This document specifies how a host token that is unique per link. Hosts
use stateless address autoconfiguration to form node configures a link-local unicast
address and may use stateless address autoconfiguration to form
global
per interface, and site-local unicast addresses. This document specifies how a host uses stateless address autoconfiguration to form configures a list of

Expires December 5, 1995 [Page 1]

INTERNET-DRAFT Stateless Address Configuration June 1995

unicast global or site-
local addresses per interface. It also specifies how a host
determines whether to use the stateless interface, without any manual configuration.
Stateless address autoconfiguration is only one mechanism or the available
to hosts; stateful
mechanism. Stateful address autoconfiguration configuration is also available. While
stateful address configuration is outside the scope of this document. document,
it is specified how hosts determine which configuration method must
be used. The document also specifies a protocol for detecting
whether an address is a duplicate when it is initially configured.

Expires December 5, January 7, 1995 [Page 2] 1]

INTERNET-DRAFT Stateless Address Configuration June July 1995

1. INTRODUCTION

In IPv6, there are a host has two types of address autoconfiguration: stateless mechanisms available to form a global or
site-local address autoconfiguration that require no manual configuration: the state-
less method and the stateful address configuration. method. In the stateless address autoconfiguration, method, no
external state is maintained binding for the purpose of indicating to a
particular host interface
the list of addresses to use for an interface. Rather, a host forms a specific
list of addresses. Rather, an
interface address is formed addresses algorithmically by concatenating each of the net-
work prefix prefixes of the attached link to a host an interface token unique per
link. The interface token is defined to be link-dependent and may be
the hardware address, for example. In
stateful address configuration, contrast, state is maintained, typically by 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
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. desired, e.g. plug-
and-play environments. In con-
trast, contrast, stateful address configuration
is designed to support flexible address assignment and is suitable
for more sophisticated topologies and for environments where system
administrative control is desired.

A host always uses desired, e.g. corporate networks.

Any node can use stateless address autoconfiguration to form a
link-local link-
local address per interface. A host may can use either stateless or
stateful autoconfiguration (or both) to configure global or site-
local addresses of inter-link scope for an interface, i.e. interface. The choice of mechanism for confi-
guring global or site-local addresses is itself configurable, and
requires no manual configuration per host.

One of the basic assumptions of stateless autoconfiguration is that
the token used to form addresses per interface is at least unique per
link. However, whatever the type of tokens used, interface tokens are
not guaranteed to always be unique in practice because of errors in
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.

Expires January 7, 1995 [Page 2]

INTERNET-DRAFT Stateless Address Configuration July 1995

This document describes how a node configures a link-local address
per interface using stateless address autoconfiguration, and how a
host forms configures global or site-local unicast addresses per inter-
face interface
using stateless address autoconfiguration. It also specifies 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. Stateful mechanism for configuring global or site-
local addresses.

The document also describes the algorithm used by a node to detect if
an address autoconfiguration is outside the scope
of this document. a duplicate when initially configured.

Expires December 5, January 7, 1995 [Page 3]

INTERNET-DRAFT Stateless Address Configuration June July 1995

2. OVERVIEW

An TERMINOLOGY

node - a device that implements IPv6.

router - a node that forwards IPv6 packets not explicitly
addressed to itself.

host may have multiple unicast addresses per interface[1].
The addresses can have one of three scopes: - any node that is not a link-local scope, router.

upper layer - a
site-local scope, protocol layer immediately above IPv6. Examples are
transport protocols such as TCP and UDP, control
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.

link - a global scope. Addresses of all three address
scopes communication facility or medium over which nodes can be autoconfigured. A host is able
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.

neighbors - nodes attached to autoconfigure the same link.

interface - a
link-local address completely autonomously. In particular, node's attachment to a host link.

packet - an IPv6 header plus payload.

link MTU - the maximum transmission unit, i.e., maximum packet
size in octets, that can
form a link-local address without be conveyed in one piece over
a router present on the link. A
host is able to autoconfigure an inter-link scope

target - a node about which address only when resolution information is
sought, or a
router node which is present on the link. The scope of the inter-link new first-hop when being
redirected.

address
formed depends on the prefix advertised on the link.

On initialization - an IPv6-layer identifier for an interface or a set of
interfaces.

unicast address
- an interface, identifier for a host forms single interface. A packet sent
to a link-local unicast address is delivered to the interface

Expires January 7, 1995 [Page 4]

INTERNET-DRAFT Stateless Address Configuration July 1995

identified by concatenating that address.

anycast address
- an identifier for a well-known link-local prefix[1] set of interfaces (typically
belonging to a token that different nodes). A packet sent to an
anycast address is
unique per link. The definition delivered to one of the tokens used are link-
dependent. For example, in interfaces
identified by that address (the "nearest" one,
according to the case routing protocols' measure of
distance).

multicast address
- an identifier for a host attached set of interfaces (typically
belonging to different nodes). A packet sent to a link
that uses IEEE 802 addresses, the token
multicast address is delivered to all interfaces
identified by that address.

link-layer address
- a link-layer identifier for an interface. Examples are
IEEE 802 addresses for Ethernet links, E.164 addresses
for ISDN links.

link-local address asso-
ciated with the interface.

A host forms or updates
- an inter-link scope address on hearing prefix
advertisements advertised by with a router. A global or site-local address scope that is formed by concatenating a network prefix limited to
the locally attached link.

site-local address
- an address with a host token scope that is
unique per link in the same way as described above. The mechanism
used limited to advertise network prefixes for the purposes of
local site.

global address confi-
guration is the same as
- an address with unlimited scope.

communication
- any packet exchange between nodes that requires
or recommends that the address of each node used in Neighbor Discovery[2] for the
purposes of prefix discovery. Rather than specify two separate
mechanisms to advertise
exchange remain the same prefix information, we use a single
mechanism which requires hosts to perform both prefix discovery pro-
cessing and address autoconfiguration processing on receiving a pre-
fix advertisement. Note that, when prefixes are advertised, it is
possible to indicate whether the prefixes are to be used for prefix
discovery only, address autoconfiguration only or both.

One of the goals of IPv6 address autoconfiguration is not only to be
able to autoconfigure addresses on startup, but to be able to recon-
figure addresses dynamically. Address reconfiguration ("renumbering")
enables hosts to acquire new addresses and relinquish old addresses
automatically. Old addresses may then be reused. To enable hosts to
renumber with minimal disruption duration of existing communications, prefixes the
packet exchange. Examples are advertised with two lifetimes: a TCP connection or a
UDP request-response.

deprecation lifetime and an
invalidation lifetime. The deprecation lifetime
- indicates when the time at which an address formed from a prefix must be deprecated. A deprecated address
may continue to be used as a source address in existing

Expires December 5, 1995 [Page 4]

INTERNET-DRAFT Stateless Address Configuration June 1995

communications, but should not 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

Expires January 7, 1995 [Page 5]

INTERNET-DRAFT Stateless Address Configuration July 1995

of the address.

invalidation lifetime
- indicates when the time at which 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
identifies an interface or set of old
addresses, while beginning to use new addresses for new communica-
tions (if any). interfaces.
The deprecation and invalidation lifetimes are con-
figurable by a system administrator and so the transition from old to
new addresses may lifetime must be as quick (the deprecation and invalidation life-
times are the same) greater than
or as slow as desired.

One of equal to the basic assumptions deprecation lifetime of stateless autoconfiguration is that the host address.

valid address
- an address whose deprecation lifetime has not yet
expired.

deprecated address
- an address whose deprecation lifetime has expired,
but whose invalidation lifetime has not.

invalid address
- an address whose invalidation lifetime has
expired.

interface token
- a link-dependent identifier for an interface that is at least
(at least) unique per link. However, in practice,
host tokens are not always unique because of errors in assignment.
Thus, it cannot be guaranteed An example is an IEEE 802
address.

2.1. Requirements

Throughout this document, the words that IPv6 addresses formed from a host
token are indeed unique among all hosts on a link. Since duplicate
IPv6 addresses are very difficult used to track down and debug, we specify
a procedure for detecting duplicate addresses define the sig-
nificance of the particular requirements are capitalized. These
words are:

MUST
This word or the adjective "REQUIRED" means that hosts should use
on initialising the item is an interface. Note that
absolute requirement of this procedure specification.

MUST NOT
This phrase means the item is not com-
pletely reliable, and so duplicate addresses may still exist. The
procedure makes use an absolute prohibition of Neighbor Solicitations and Advertisements[2] this
specification.

SHOULD

Expires January 7, 1995 [Page 6]

INTERNET-DRAFT Stateless Address Configuration July 1995

This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in a special-purpose way. Briefly, a host uses a Neighbor Solicita-
tion particular circumstances to solicit for itself. If it discovers that another host has ignore this
item, but the address through receiving full impliciations should be understood and the
case carefully weighed before choosing a Neighbor Advertisement, different course.

SHOULD NOT
This phrase means that there may exist valid reasons in particu-
lar circumstances when the valida-
tion check fails listed behavior is acceptable or even
useful, but the full implications should be understood and the host ceases operation on that interface.
Note that
case carefully weighted before implementing any behavior
described with this label.

MAY
This word or the host adjective "OPTIONAL" means that this item is already using the address (presumably leg-
itimately) continues unharmed, although it
truly optional. One vendor may log a message choose to include the
effect that it has received item
because a solicitation particular marketplace requires it or because it
enhances the product, for its own address.

This document specifies router and host behavior related to stateless
address configuration and duplicate address detection in more detail
in example, another vendor may omit the sections that follow.
same item.

Expires December 5, January 7, 1995 [Page 5] 7]

INTERNET-DRAFT Stateless Address Configuration June July 1995

3. ROUTER CONCEPTUAL MODEL OF HOST BEHAVIOR

The stateless address autoconfiguration mechanism relies on the pre-
fix discovery mechanism specified in [2] for advertising network pre-
fixes required for the formation

Conceptually, a host maintains three data structures: a list of
addresses with site-local or glo-
bal scope. A prefix per interface and two flags. One flag, called the "address
mode" flag, indicates whether the stateful protocol is advertised to be used for
address configuration (possibly in a Prefix Information extension
of a Router Advertisement. addition to the stateless proto-
col). The Prefix Information extension includes other flag, called the prefix and its length, flags indicating "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

Expires January 7, 1995 [Page 8]

INTERNET-DRAFT Stateless Address Configuration July 1995

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.

Expires January 7, 1995 [Page 9]

INTERNET-DRAFT Stateless Address Configuration July 1995

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 to be used for prefix discovery or removed from the address configuration, and two
lifetimes: list of the
interface.

Note that the deprecation lifetime lifetimes and the invalidation lifetime. lifetimes of the
link-local address are set to infinity. Thus, the link-local address
is never deprecated.

The Router Advertisement itself includes flags indicating whether
stateful intention of the two lifetimes per address configuration should be used by hosts and whether
other configuration information (besides an address) needs is to be con-
figured.

Router Advertisement and Solicitation processing allow system
administrators to specify a graceful transition period during
renumbering. The purpose of the deprecation time is specified com-
pletely in [2] along with to indicate to
the message formats and configuration vari-
ables. Additional configuration variables pertinent host to stateless start using another (presumably longer lasting) address configuration are specified below.

3.1. Router Configuration Variables

In addition
in new communications to minimise the configuration variables specified in [2], routers
MUST also be configurable as follows.

For each risk of breaking communications
when the prefixes 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 be advertised in Prefix Information
extensions per interface:

Autonomous Flag

If set, using the prefix is being advertised for new address by the purposes time the old
one becomes invalid. The length of
stateless address configuration.

Default: TRUE

Deprecation Lifetime the deprecation period will be
environment-dependent as it depends on the expected length of commun-
ications.

The value fact that addresses have a deprecation lifetime does not need to be placed in
affect the Deprecation Lifetime field 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

Expires December 5, January 7, 1995 [Page 6] 10]

INTERNET-DRAFT Stateless Address Configuration June July 1995

Prefix Information extensions in Router Advertisements sent
from

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 interface in seconds.

Invalidation Lifetime

The value most appropriate source address given a particular desti-
nation. An application may choose to be placed in select the Invalidation Lifetime field of
Prefix Information extensions in Router Advertisements sent
from source address
itself before starting a new communication or may leave the interface address
unspecified, in seconds. Must be no less than Deprecation
Lifetime.

For each advertising interface:

Administered Flag

If set, which case the host must autoconfigure addresses using stateful
address autoconfiguration.

Default: FALSE

Other Flag

If set, upper networking layers will use the host must autoconfigure other configuration infor-
mation (besides
mechanism provided by the address) using stateful autoconfiguration.

Default: FALSE

NOTE: All routers advertising IP layer to choose a given prefix suitable address on a link MUST set all
of the configuration variables to
the same value. application's behalf.

Expires December 5, January 7, 1995 [Page 7] 11]

INTERNET-DRAFT Stateless Address Configuration June July 1995

4. HOST BEHAVIOR

Conceptually, a host maintains a list of addresses per interface.
Entries 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 list are created as a result formation of forming addresses from
prefixes with site-local or glo-
bal scope.

A prefix is advertised in a Prefix Information extensions option of a Router Adver-
tisements. Each entry in
Advertisement. Prefix Information includes

1. the list has two associated timers, prefix itself

2. the prefix length

3. a
deprecation timer and an invalidation timer, which have values set
according flag indicating whether the prefix is to lifetimes learned from be used for prefix
discovery[2].

4. a flag indicating whether the router advertisement. In
addition, prefix is to be used for stateless
address autoconfiguration

5. the deprecation lifetime of the prefix in seconds for the pur-
pose of address list always includes deprecation

6 the link-local address,
which invalidation lifetime of the host forms autonomously whenever an interface prefix for the purpose of
address invalidation. This field is initial-
ised. The deprecation also used by prefix
discovery[2].

Router Advertisement processing is specified completely in [2] along
with the message formats and invalidation lifetimes of a link-local
address are set to infinity. configuration variables.

Expires January 7, 1995 [Page 12]

INTERNET-DRAFT Stateless Address Configuration July 1995

5. HOST SPECIFICATION

This section specifies host address autoconfiguration behavior on
interface initialisation and on
receiving a Router Advertisement.
This section also specifies a host protocol for attempting to verify
that an address is not a duplicate.

4.1.

5.1. Host Configuration Variables

A host MUST SHOULD allow the following variable to be configured per inter-
face:

Perform_Auto_Config mul-
ticast interface:

Perform_Addr_Config

If set, the host MUST perform address autoconfiguration process-
ing. use either stateless or stateful mechanisms
to configure global or site-local addresses and to acquire other
configuration information as specified in this document.

Default: TRUE

4.2. Router Advertisement Processing

An "autoconfigurable" interface is one on which Router Advertisements
are received and that has the Perform_Auto_Config Perform_Addr_Config flag set is set. called an
"autoconfigurable interface".

5.2. Message Validation

A host MUST perform silently discard any Router Advertisement that does not
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.

Expires January 7, 1995 [Page 13]

INTERNET-DRAFT Stateless Address Configuration July 1995

A host performs the following address configuration processing when a
valid solicited or unsolicited Router Advertisement is received over

Expires December 5, 1995 [Page 8]

INTERNET-DRAFT Stateless Address Configuration June 1995
an autoconfigurable interface:

For each valid Router Advertisement:

The host stores the current value of the Address Mode and then
sets the Address Mode to the Administered value of the Managed flag (M bit).
If the new value is set, the host MUST use stateful auto-
configuration address confi-
guration to configure and maintain a list of site-local or global
addresses per interface.

Note that this does not mean that the stateful protocol is neces-
sarily invoked each time a Router Advertisement arrives with the M
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 acquire request a list of site-local or global addresses
per interface.

If 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 autoconfi-
guration 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
that has the Autonomous flag set:

- If the prefix advertised matches the prefix of an autoconfig-
ured

Expires January 7, 1995 [Page 14]

INTERNET-DRAFT Stateless Address Configuration July 1995

autoconfigured address already in the list, then set the
deprecation timer to that of the deprecation lifetime specified speci-
fied in the extension and the invalidation timer to that of
the invalida-
tion invalidation lifetime.

Note that this processing does not apply MUST NOT be applied to a
link-local 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
address already in the list, then form an address using this
network prefix. Appendix A specifies how prefix and the interface token. Definitions of the
interface token to form an address
for hosts that have IEEE 802 tokens. The extension is ignored
if be used on a specific link are documented
elsewhere.

If the prefix advertised is not valid, e.g. it is not too short or too long to form a
128-bit address, given the right length
for forming an address with interface token, the given host token. prefix is
ignored and an error is logged.

Add this address to the list with the deprecation timer set
to that of the deprecation lifetime deprecation lifetime and the invalidation
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 invalidation
timer to that of implementation cannot store all addresses, the invalidation lifetime.
host should log a system management error.

Note that if the deprecation lifetime is zero, the address with
that prefix is immediately deprecated. Similarly, if the invalida-
tion lifetime is zero, the address with that prefix is immediately
made invalid. (The invalidation lifetime is defined to be no less
than the deprecation lifetime.) 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
address may can be used as a source address in all outgoing

Expires December 5, January 7, 1995 [Page 9] 15]

INTERNET-DRAFT Stateless Address Configuration June July 1995

communications and MUST be is accepted as a destination address in all
incoming communications.

When the deprecation lifetime of an address expires, an address is
said to be deprecated. A deprecated address SHOULD NOT be used as
a source address in new communications. However, a deprecated the address
SHOULD continue to be used as a source address if it is in use in
existing communications. communications, but SHOULD NOT be used in new communica-
tions if a valid address is available and it has sufficient scope.
The IP layer MUST continue to accept datagrams destined to a
deprecated address. Upper layers
MAY refuse to accept new communications requests to address since a deprecated
address, however. address is still defined to
identify the interface.

An address remains deprecated until its invalidation timer expires
at which point the address becomes invalid. invalid and is removed from the
address list. An invalid address can no longer be used as a
source address in outgoing communications and is not recognised as
a valid destination address in incoming
communications.

Note that, when choosing a source address in outgoing communica-
tons, a global valid address should be used in preference to a
site-local valid address, which in turn should be used in prefer-
ence to the link-local address. Similarly, a global deprecated
address should also be used in preference to a site-local depre-
cated addresses. Note that the link-local address is never depre-
cated; it is always valid. One of the implications of these rules
is that if there are no valid inter-link scope addresses, e.g. all
global and site-local addresses are deprecated, then the host will
default to using the link-local address as a source address in new
communications.

To limit storage space required for the address list, a host may
choose not to store all valid and deprecated addresses. Deprecated
addresses that are not valid destination address in use by existing incoming communications should be
discarded in favor since the
address is defined to no longer identify the interface.

On initialisation of valid addresses and deprecated addresses
that are in use.

If an interface, if a host determines that there
are no IPv6 routers on a link,
either on startup or during normal processing, a host MUST attempt to use stateful
autoconfiguration to acquire addresses or and other configuration information if it is not already doing so.
information. This is needed to support networks with no IPv6
routers. The host deter-
mines determines that there are no routers on the
link after startup if no Router Advertisements are heard in the
time that it would take to send MAX_ROUTER_SOLICITATIONs and wait
for a response[2]. During
normal processing, it is determined that there are no routers when

Expires December 5, 1995 [Page 10]

INTERNET-DRAFT Stateless Address Configuration June 1995

all router advertisements have timed out. If a router comes up on the link and Router
Advertisements begin to be received, a host MUST start to use
Router Advertisements in the normal way, and, in particular, use
advertisements to determine whether stateless or stateful address
configuration should be in use.

Note that if a
host does not receive Router Advertisements because of some error,
e.g. all routers are down or there it is a network partition, possible for hosts
will attempt to change mode from get address information
using both 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 protocols since both may be
enabled at the same time. Even if only stateless address autocon-
figuration mode is available, enabled, it should be configured correctly to serve only
the is still possible for hosts that it should, to get
information from multiple sources since hosts multiple routers may attempt to use it, even
if it be
advertising prefix information. The rules for handling this is not as
follows: hosts accept the intention that they do so.

A host must behave reasonably when there is a change from union of all information received using
the stateless mode to the stateful mode, and vice versa. This can hap-
pen because routers advertise a new configuration mode due to a
deliberate change by a system administrator, or because of a
change in topology, e.g. an IPv6 router stateful protocols. If different sources config-
ure the same address, then the address is connected updated with the most
recently advertised lifetime.

It is also possible for hosts to contain address information from
different sources, when changing from one mechanism to the other,
i.e. when changing from stateless mode to or removed stateful mode, and vice

Expires January 7, 1995 [Page 16]

INTERNET-DRAFT Stateless Address Configuration July 1995

versa. In this case, the rules are no different from above. If the link. It
newly enabled mode is possible and quite likely that during configured to hand out different addresses
than the mode just disabled, then the
change-over, a host will have contains the union of
addresses autoconfigured using from both
mechanisms. If sources until the addresses acquired configured using
the two mechanisms are
the same, then the new addresses should replace old protocol timeout. If both the old and the
aging semantics associated with the new mode apply. If the
addresses acquired using the two mechanisms modes are different, con-
figured to hand out the same address, then the old addresses should be aged according to address is updated
with the rules specified
in most recently advertised lifetime. NOTE: The above
assumes that the old configuration mode stateless and stateful modes have the new addresses should follow same life-
time semantics.

Expires January 7, 1995 [Page 17]

INTERNET-DRAFT Stateless Address Configuration July 1995

6. NODE SPECIFICATION

This section specifies the rules of for forming a link-local address. It
also specifies the new mode.

4.3. Host Initialisation protocol to be used for duplicate address detec-
tion.

6.1. Forming a Link-Local Address

A host node MUST have a link-local address. A node forms a link-local
address when whenever an autoconfigurable interface is initialised. Appendix A specifies how a host that is attached to
a link that uses IEEE 802 addresses forms The method for forming
a link-local address.

Note that an 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 reinitialized after a temporary interface

Expires December 5, 1995 [Page 11]

INTERNET-DRAFT Stateless Address Configuration June 1995
failure or after being temporarily disabled by system manage-
ment.

- The system changes from being a router node is re-attached to a link after being detached for some
time.

The link-local address is highly likely to need to be one of the
first events in the interface initialisation process. Clearly, it
must be formed before any duplicate detection processing is performed
for this address (Section 6.2). In hosts, a host, by hav-
ing its IP forwarding capability turned off by system manage-
ment.

- The host link-local address is re-attached
also required before a sends out a Router Solicitation, assuming the
node chooses to do this[2]. This is because a link after being detached for some
time.

- The interface solicitation is only
sent if an advertisement has its Perform_Auto_Config flag changed from
FALSE to TRUE.

4.4. 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.

6.2. Detecting Duplicate IPv6 Addresses

The procedure to detect a duplicate addresses address MUST be implemented enabled by
default in
hosts nodes and SHOULD be used.

Expires January 7, 1995 [Page 18]

INTERNET-DRAFT Stateless Address Configuration July 1995

In stateless principle, the duplicate address configuration, detection procedure is applied to
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 autoconfigured
addresses is unique since on the same
token is used to form all addresses. It 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 host
link-local address is guaranteed to always forms
this address. 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.

The procedure for duplicate address detection uses Neighbor Solicitation Solicita-
tion and Advertisement messages specified in [2] to validate an
address and is as specified below. Note that before carrying out this pro-
cedure, a node joins the all-nodes multicast address. Also, this
mechanism is not completely reliable, and so it is possible that
duplicate addresses will still exist. If a duplicate address is discovered,
discovered after carrying out this procedure, the host 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.

6.2.1. Soliciting Host Node Behavior

An address is checked for uniqueness only once, when the address is
initially configured.

Once the address is configured, the node sends a Neighbor Solicita-
tion with a target address containing the address to be validated.
The host 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 (as it will be ignored by the

Expires January 7, 1995 [Page 19]

INTERNET-DRAFT Stateless Address Configuration July 1995

destination node[2]). Loopback of the Neighbor Solicitation MUST NOT
be disabled.

NOTE: If the Neighbor Solicitation is the first delays message to be sent
from an interface on interface initialisation, the node should delay
a random amount of time between 0 and
DUPL_ADDRESS_DELAY MAX_INITIALIZATION_DELAY
seconds before sending out a Neighbor Solicitation

Expires December 5, 1995 [Page 12]

INTERNET-DRAFT Stateless Address Configuration June 1995

for the address. solicitation. This serves to alleviate
congestion when many hosts nodes 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 node is trying to solicit for the same address at
the same time. (It is recommended that hosts nodes include some unique
value in the seed used to initialise their pseudo-random number generators. gen-
erators. Note that using only the host 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 speci-
fied 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.)

The node then sends a Neighbor Solicitation with a target address
containing the address to be validated. The source is set to the
unspecified address and the destination is set to the solicited-node
multicast address. The Source Link Layer Address extension SHOULD
NOT be sent.

NOTE: There SHOULD be some way to inhibit local delivery of the soli-
citation since, in general, it will not be possible for a host to
determine whether a solicitation is from itself or from another host
with a duplicate address. If local delivery cannot be inhibited, then
the host should ignore the first Neighbor Solicitation with an
unspecified source address or wait for a period of
DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation
before beginning to process solicitations again.

If after sending a solicitation, no advertisement Neighbor Advertisement is
received from the target, the node SHOULD retransmit the solicitation
at most every DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement adver-
tisement is received or the solicitation has been retransmitted
MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
target address the same as the address being validated, validated in the time it
takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it
must cease
operation on disable that interface and indicate an appropriate log a system management error. If no
such advertisement is received in response to within the Neighbor Solicita-
tions sent, time specified, the address
is considered to be valid.

4.4.2.

6.2.2. Solicited Node Behavior

A node is in the process of validating an address when a Neighbor
Solicitation has been sent for the address and no Neighbor Advertise-
ment advertising that address has been received in the time it takes
to send out MAX_DUPL_ADDR_RETRANS solicitations and wait for an
advertisement (DUPL_ADDR_IGNORE_TIMER seconds).

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

Expires January 7, 1995 [Page 20]

INTERNET-DRAFT Stateless Address Configuration July 1995

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.

The special rules are as follows: When a host 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 solicitation solici-
tation for that

Expires December 5, 1995 [Page 13]

INTERNET-DRAFT Stateless Address Configuration June 1995 address. Rather, all solicitations for the node silently discards the sol-
icitation unless the source address are ignored,
except when is the unspecified address. In
the latter case, the first such solicitation received is from noted, but
otherwise silently discarded (see NOTE below). Any subsequent such
solicitations cause the unspecified address i.e. node to disable the Neighbor Solicitation message has interface and log a target sys-
tem management error.

NOTE: The above behavior is required because nodes send out Neighbor
Solicitations for their own address which with loopback enabled. Thus, a
node will always receive at least one solicitation for its own
address. However, there is no way for the
same as node to determine, in gen-
eral, whether the solicitation comes from itself or another node
since the address to be validated, and a source address that of the packet is the unspecified address. (Note that any solicitation that is likely to be
a loopback solicitation should be ignored too as mentioned in Hence, the
above section.) If rules specify that a solicitation duplicate address is received from detected only if the unspecified
address,
node receives more than one solicitation for the host must cease operation on that interface and indicate
an appropriate error. address.

Once a host node 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.

6.2.3. Constants

DUPL_ADDR_DELAY 4 seconds (XX)
DUPL_ADDR_IGNORE_TIMER 0.1

MAX_INITIALIZATION_DELAY 3 seconds
DUPL_ADDR_RETRANS_TIMER 4 3 seconds (XX)
MAX_DUPL_ADDR_RETRANS 1 transmission (XX)

5. SECURITY CONSIDERATIONS

To be completed.

Expires December 5, January 7, 1995 [Page 14] 21]

INTERNET-DRAFT Stateless Address Configuration June July 1995

6. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS

The token for an interface on an IEEE 802 link or any link that uses
IEEE 802 addressing, such as FDDI, is the 48-bit IEEE 802 address in
canonical format, i.e. the Individual/Group bit is the low-order bit
of the furst byte.

A host forms an IPv6 address per link by concatenating an 80-bit pre-
fix with the IEEE 802 address as follows:

In the case of a link-local prefix, the prefix is well-defined[1].

The prefixes of other types of addresses need to

7. SECURITY CONSIDERATIONS

To be configured. completed.

Expires December 5, January 7, 1995 [Page 15] 22]

INTERNET-DRAFT Stateless Address Configuration June July 1995

8. REFERENCES

[1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
Addressing Architecture", Internet Draft, May 1995, draft-ietf-
ipngwg-addr-arch-02.txt

[2] T. Narten and Narten, E. Nordmark, Nordmark and W. A. Simpson, "IPv6 Neighbor
Discovery", Internet Draft, June July 1995, <draft-ietf-ipngwg-discovery-00.txt> <draft-ietf-ipngwg-
discovery-01.txt>

Acknowledgements

The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. In particular, thanks to Jim Bound,
Steve Deering, Erik Nordmark and Bill Simpson.

Author's Addresses

Susan Thomson
Bellcore
445 South Street
Morristown, NJ 07960
U.S.A.

Phone: +1 201-829-4514
Email: set@thumper.bellcore.com

Expires December 5, January 7, 1995 [Page 16] 23]

INTERNET-DRAFT Stateless Address Configuration June July 1995

Expires December 5, January 7, 1995 [Page 17] 24]

----