WDIFF

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

ADDRCONF Working Group Susan Thomson (Bellcore)

INTERNET-DRAFT March 24, June 5, 1995
<draft-ietf-addrconf-ipv6-auto-01.txt>
<draft-ietf-addrconf-ipv6-auto-02.txt>

IPv6 Stateless Address Autoconfiguration

Status of this Memo

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

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

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

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

Abstract

This document specifies

In IPv6, there are two types of address autoconfiguration: stateless
address autoconfiguration. A host
can form a link-local autoconfiguration and stateful address autonomously based on information local
to the host. A configuration. In
stateless address autoconfiguration, no state is maintained binding a
particular host can form interface to a specific list of addresses. Rather, an inter-link scope
address in two
ways: either autonomously, based on prefixes advertised by routers,
or is formed algorithmically by using concatenating the IPv6 version network prefix
of the Dynamic Host Configuration
Protocol(DHCPv6). All mechanisms rely on attached link to a host having a token that is unique at least per link. Hosts
use stateless address autoconfiguration to form a link-local unicast
address and may use stateless address autoconfiguration to form
global and site-local unicast addresses. This document specifies how
a host
forms addresses autonomously. DHCPv6 is described elsewhere. uses stateless address autoconfiguration to form a list of

Expires September 24, December 5, 1995 [Page 1]

INTERNET-DRAFT Stateless Address Configuration March June 1995

1. INTRODUCTION

An IPv6 host may have multiple

unicast addresses per interface. The addresses
can have one of three scopes:

1. a link-local address,

2. a site-local address, and

3. a global address.

All three address scopes can be autoconfigured. A host can autocon-
figure It also specifies how a link-local address autonomously. A host can autoconfigure a
site-local
determines whether to use the stateless mechanism or global the stateful
mechanism. Stateful address only when a router or a DHCPv6 server autoconfiguration is
present on outside the link.

There scope
of this document.

Expires December 5, 1995 [Page 2]

INTERNET-DRAFT Stateless Address Configuration June 1995

1. INTRODUCTION

In IPv6, there are two types of address autoconfiguration: stateless
address autoconfiguration and stateful address configuration. In
stateless address autoconfiguration, no state is only one way maintained binding a
particular host interface to form a link-local address. On initialization specific list of addresses. Rather, an interface, a host forms such an
interface address is formed algorithmically by concatenating a
well-known link-local prefix[1] the net-
work prefix of the attached link to a host token that is unique per link.
The definition of the tokens used are link-dependent. In
stateful address configuration, state is maintained, typically by a
server. For example,
in the case of a host attached to an link that uses IEEE 802
addresses, the token IPv6 Dynamic Host Configuration Protocol is the IEEE 802 address of the interface.

There are two ways to form a site-local or global address. In the
first mechanism, a host forms
an inter-link scope example of stateful address by con-
catenating a network prefix advertised in a Router Advertisement[2,3]
to a token that is unique per link. Like the link-local address, the
token autoconfiguration.

Stateless autoconfiguration is defined designed to be link-layer dependent. This mechanism for
forming a site-local or global 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 no system administrative control is not desired. It In con-
trast, stateful address configuration is a simple protocol designed for a very specific purpose: to make stateless support flexible
address con-
figuration very straightforward to use assignment and implement.

The other mechanism available to hosts is to use the IPv6 version of
the Dynamic Host Configuration Protocol (DHCPv6). DHCPv6 is a suitable for more
complex protocol allowing sophisticated topologies
and for very flexible address assignment under
the control of a system administrator. This protocol typically
requires significant environments where system management, including server and database
configuration.

The choice of mechanism administrative control is desired.

A host always uses stateless address autoconfiguration to form a
link-local address per interface. A host may use in forming an either stateless or
stateful autoconfiguration to configure addresses of inter-link scope address
is advertised by a router, if present, and this choice is configur-
able by a system administrator.

Expires September 24, 1995 [Page 2]

INTERNET-DRAFT Stateless Address Configuration March 1995
for an interface, i.e. global or site-local addresses.

This document describes how a host forms a link-local address and one
or more site-local or global unicast addresses autonomously. It also speci-
fies how per inter-
face using stateless autoconfiguration. It also specifies how a host
determines which mechanism whether to use to form an inter-
link scope address: the autonomous (stateless) approach or DHCPv6.
Section 2 describes stateless mechanism or the router's role in stateful
mechanism. Stateful address autoconfiguration
and Section 3 is outside the host's role. scope
of this document.

Expires September 24, December 5, 1995 [Page 3]

INTERNET-DRAFT Stateless Address Configuration March June 1995

2. ROUTER BEHAVIOR OVERVIEW

An IPv6 host may have multiple unicast addresses per interface[1].
The stateless address autoconfiguration mechanism relies on the
router discovery mechanism specified in [2,3] for forming addresses
with can have one of three scopes: a link-local scope, a
site-local scope, or a global scope. If configured to do so, routers
advertise prefix information in periodic Router Advertisements. The
prefixes are contained in Prefix-Information extensions Addresses of a Router
Advertisement. Each Prefix-Information extension indicates whether
the prefix all three address
scopes can be used for autonomous autoconfigured. A host is able to autoconfigure a
link-local address autoconfiguration and,
if so, for how long completely autonomously. In particular, a host can
form a link-local address without a router present on the resulting link. A
host is able to autoconfigure an inter-link scope address only when a
router is valid. Note that present on the
lifetime link. The scope of the inter-link address is defined separately from that of
formed depends on the Router
Advertisement itself (other information is prefix advertised in on the adver-
tisement which has different lifetime requirements). The extension
also explicitly indicates to hosts whether DHCPv6 is required link.

On initialization of an interface, a host forms a link-local address
by concatenating a well-known link-local prefix[1] to be
used since it is possible a token that system administrators would like to
have hosts autoconfigure addresses autonomously, but also use DHCPv6
to acquire other configuration information besides the address.

Router Advertisement and Solicitation processing is specified in [2]
and
unique per link. The definition of the message formats tokens used are link-
dependent. For example, in [3].

DISCUSSION: An alternative approach is the case of a host attached to advertise address confi-
guration information in a separate advertisement entirely. This would
be somewhat cleaner since the lifetime of the advertisement would
then be link
that of uses IEEE 802 addresses, the information advertised. On token is an IEEE 802 address asso-
ciated with the other hand, having
two types of router interface.

A host forms or updates an inter-link scope address on hearing prefix
advertisements would mean that advertised by a router. A global or site-local address
is formed by concatenating a network prefix information to a host token that is advertised redundantly, and
unique per link in particular, would double traffic on
initialisation and on router solicitations.

2.1. Router Configuration Variables

In addition to the configuration variables specified in [2,3],
routers MUST also be configurable same way as follows.

For each of the IPv6 unicast addresses per interface:

Autonomous Flag

Expires September 24, 1995 [Page 4]

INTERNET-DRAFT Stateless Address Configuration March 1995

If and only if TRUE, the prefix length is described above. The mechanism
used to be advertised advertise network prefixes for the purposes of autonomous address configuration.

Default: TRUE

For each interface:

Administered Flag

If and only if TRUE, the host must autoconfigure other confi-
guration information using DHCPv6. Only valid in extensions
with the Autonomous Flag set to TRUE.

Default: FALSE

Address_Advertisement_Interval

The time allowed between sending unsolicited Address Advertise-
ments from is the interface, in seconds. The value must not be
less than Maximum_Advertisement_Interval of Router Advertise-
ments.

Default: XX

Address_Lifetime

The value to be placed same as that used in Neighbor Discovery[2] for the Lifetime field
purposes of the
Prefix_Information extension sent from the interface in
seconds. The value must not be less prefix discovery. Rather than
Address_Advertisement_Interval. This value indicates how long
an address formed from specify two separate
mechanisms to advertise the same prefix advertised is valid. Only
valid in extensions with the Autonomous flag set to TRUE.

Default: 3 * Address_Advertisement_Interval

All routers advertising information, we use a given single
mechanism which requires hosts to perform both prefix discovery pro-
cessing and address autoconfiguration processing on receiving a link MUST be configured pre-
fix advertisement. Note that, when prefixes are advertised, it is
possible to advertise indicate whether the same autoconfiguration mode prefixes are to hosts.

Expires September 24, 1995 [Page 5]

INTERNET-DRAFT Stateless Address Configuration March 1995

2.2. Processing

A router MUST advertise be used for prefix
discovery only, address autoconfiguration information in a
Prefix Information Extension of a Router Advertisement. The values only or both.

One of the Autonomous and Administered flags are advertised along with
Address_Lifetime. The goals of IPv6 address configuration information need autoconfiguration is not only to be
advertised in each Router Advertisement. It must
able to autoconfigure addresses on startup, but to be sent (almost)
periodically in a Router Advertisement at an interval of approxi-
mately Address_Advertisement_Interval. able to recon-
figure addresses dynamically. Address configuration information must also be sent in the first few
Router Advertisements after startup or enabling of an interface (up reconfiguration ("renumbering")
enables hosts to MAX_INITIAL_ADVERTISEMENTS) acquire new addresses and in a Router Advertisement that is
sent in response to a Router Solicitation.

Address configuration information relinquish old addresses
automatically. Old addresses may also then be sent in a Router
Advertisement due reused. To enable hosts to actions taken by system management, in particu-
lar, when the Address_Lifetime
renumber with minimal disruption of existing communications, prefixes
are advertised with two lifetimes: a prefix is set to zero, e.g.
because the link is to be renumbered. In this case, deprecation lifetime and an
invalidation lifetime. The deprecation lifetime indicates when an
address formed from a Prefix-
Information extension prefix must be transmitted in a Router Advertisement
advertising the appropriate deprecated. A deprecated address prefix with the Autonomous Flag
set to TRUE and Address_Lifetime set
may continue to zero. be used as a source address in existing

Expires September 24, December 5, 1995 [Page 6] 4]

INTERNET-DRAFT Stateless Address Configuration March June 1995

3. HOST ADDRESS AUTOCONFIGURATION PROCESSING

3.1. Host Configuration Variables

A host maintains a list of addresses per interface. At

communications, but should not be used as a minimum, the
list includes the link-local address, which the host can form auto-
nomously whenever source address in new
communications. The invalidation lifetime indicates when an interface is initialised. If address
formed from a router prefix is
attached 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 link same) or DHCPv6 server as slow as desired.

One of the basic assumptions of stateless autoconfiguration is available, that
the list may also
include site-local or global 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 either from subnet pre-
fixes advertised in Router Advertisements or by making requests using
DHCPv6. Addresses may also be manually configured. 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 there may be
multiple site-local or global that this procedure is not com-
pletely reliable, and so duplicate addresses autoconfigured per 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.

A
Note that the host must maintain that is already using the address (presumably leg-
itimately) continues unharmed, although it may log a list of message to the following configurable variables
per interface:
effect that it has received a solicitation for its own address.

This document specifies router and host behavior related to stateless
address configuration and duplicate address detection in more detail
in the sections that follow.

Expires December 5, 1995 [Page 5]

INTERNET-DRAFT Stateless Address

A valid IPv6 unicast Configuration June 1995

3. ROUTER BEHAVIOR

The stateless address autoconfiguration mechanism relies on the pre-
fix discovery mechanism specified in [2] for this interface

Default: None advertising network pre-
fixes required for the formation of addresses with site-local or glo-
bal scope. A prefix is advertised in a Prefix Length

The length Information extension
of a Router Advertisement. The Prefix Information extension includes
the prefix and its length, flags indicating whether the information
is to be used for prefix discovery or address configuration, and two
lifetimes: the deprecation lifetime and the invalidation lifetime.
The Router Advertisement itself includes flags indicating whether
stateful address configuration should be used by hosts and whether
other configuration information (besides an address) needs to be con-
figured.

Router Advertisement and Solicitation processing is specified com-
pletely in bits. Prefix length semantics [2] along with the message formats and configuration vari-
ables. Additional configuration variables pertinent to stateless
address configuration are specified below.

3.1. Router Configuration Variables

In addition to the configuration variables specified in [2].

A host must [2], routers
MUST also allow be configurable as follows.

For each of the following variable prefixes to be configured advertised in Prefix Information
extensions per interface:

Perform_Auto_Config

Autonomous Flag

If and only if TRUE, set, the host must perform prefix is being advertised for the purposes of
stateless address autoconfigura-
tion processing. configuration.

Default: TRUE

Deprecation Lifetime

The value to be placed in the Deprecation Lifetime field of

Expires September 24, December 5, 1995 [Page 7] 6]

INTERNET-DRAFT Stateless Address Configuration March June 1995

Default: TRUE

3.2. Host Initialization Behavior

A host must perform

Prefix Information extensions in Router Advertisements sent
from the following autoconfiguration procedure when-
ever an interface needs in seconds.

Invalidation Lifetime

The value to be initialised:

When a host has no address for an interface with
Perform_Auto_Config flag set to TRUE, e.g. when a host boots or
when an interface is enabled after being disabled, the host forms
an address of link-local scope. Appendix A specifies how a host
that is attached to a link that uses IEEE 802 addresses forms a
link-local address.

Before adding the link-local address as a valid address to placed in the
list Invalidation Lifetime field of addresses for the interface, the host SHOULD verify that
the address is indeed unique. The procedure for validating an
address is described
Prefix Information extensions in Section X. A host SHOULD also validate any
manually configured addresses this way too.

The host solicits a Router Advertisement using one or more Router
Solicitations, if no Router Advertisements have been heard in sent
from the
interface. The procedure for sending Router Solicitations is
specified interface in [2].

If seconds. Must be no Router Advertisement is heard after sending
MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after less than Deprecation
Lifetime.

For each as specified in Sending Router Solicitations in [2], advertising interface:

Administered Flag

If set, the host must determine whether a DHCPv6 server is present and whether any autoconfigure addresses using stateful
address autoconfiguration.

Default: FALSE

Other Flag

If set, the host must autoconfigure other configuration information needs to be acquired. This is to cater
for a routerless topology which has a DHCPv6 server. Once a router
is added to infor-
mation (besides the network, however, address) using stateful autoconfiguration.

Default: FALSE

NOTE: All routers advertising a host given prefix on a link MUST use Router Adver-
tisements set all
of the configuration variables to determine the autoconfiguration mode in use as
described in the section on Router Advertisement Processing. same value.

Expires September 24, December 5, 1995 [Page 8] 7]

INTERNET-DRAFT Stateless Address Configuration March June 1995

3.3. Router Advertisement Processing

Router Advertisement processing is specified in [2] and the message
format in [3]. In addition to this processing, the

4. HOST BEHAVIOR

Conceptually, a host MUST perform
the following address configuration processing when maintains a solicited or
unsolicited Router Advertisement is received over an interface:

For each Prefix-Information extension in the Router Advertisement:
(The format list of addresses per interface.
Entries in the Prefix-Information extension list are created as amended by this
draft for autoconfiguration purposes is specified a result of forming addresses from
prefixes advertised in Appendix C):

The host silently ignores the extension for the purposes Prefix Information extensions of auto-
configuration if the Perform_Auto_Config flag for the interface is
FALSE.

Otherwise, Router Adver-
tisements. Each entry in the host checks list has two associated timers, a
deprecation timer and an invalidation timer, which have values set
according to lifetimes learned from the autoconfiguration mode bits.

If only router advertisement. In
addition, the Autonomous flag is set in address list always includes the Prefix-Information
extension, link-local address,
which the host forms or verifies autonomously whenever an interface is initial-
ised. The deprecation and invalidation lifetimes of a site-local or global link-local
address as specified below.

If both the Autonomous and Administered flags are set in the
Prefix-Information extension, the to infinity.

This section specifies host forms or verifies a site-
local or global address as specified below autoconfiguration behavior on
interface initialisation and uses or continues
using DHCPv6 for other autoconfiguration.

Otherwise, the host silently ignores the extension for the pur-
poses of autonomous autoconfiguration.

If none of the prefixes advertised in extensions of the on receiving a Router Adver-
tisement have the Autonomous flag set, then the Advertisement.
This section also specifies a host uses or contin-
ues using DHCPv6 protocol for autoconfiguration.

Note that the above procedure should continue attempting to operate when verify
that an address is not a sys-
tem administrator decides duplicate.

4.1. Host Configuration Variables

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

Perform_Auto_Config

If set, the host MUST perform address autoconfiguration mode from
the autonomous mode to DHCPv6, process-
ing.

Default: TRUE

4.2. Router Advertisement Processing

An "autoconfigurable" interface is one on which Router Advertisements
are received and vice versa. The the Perform_Auto_Config flag is set.

A host should keep
track of MUST perform the current autoconfiguration mode, so that it can detect following address configuration processing
when there is a change. The system administrator must ensure that,
during a changeover, a DHCPv6 server solicited or unsolicited Router Advertisement is configured to hand out
addresses that are unique per link, particularly with respect to
addresses that hosts have configured autonomously and which may not received over

Expires September 24, December 5, 1995 [Page 9] 8]

INTERNET-DRAFT Stateless Address Configuration March June 1995

yet be invalidated. To avoid problems during a changeover, it is
recommended that a DHCP server should use exactly the same algorithm
to form a host address as that used in the autonomous mode when

an autoconfigurable interface:

For each valid Router Advertisement:

If the
prefix Administered flag is set, the same. It is also important to ensure that a DHCPv6
server is configured to hand out addresses only host MUST use stateful auto-
configuration to those hosts that
it should, since, if a DHCPv6 server is present on acquire a link, hosts may
request the server for list of site-local or global addresses (even if
per interface.

If the network Other flag is configured set, the host MUST use stateful autoconfi-
guration to be in autonomous mode) when Router Advertisements are not heard
because acquire other configuration information besides the router is down.
address.

For each Prefix-Information extension received over an autoconfigur-
able interface, the host updates in the address list as follows when Router Advertisement
that has the Autonomous flag is set:

- If the prefix advertised matches the prefix of an autoconfigured autoconfig-
ured address already in the list, then set a the deprecation
timer to that of the deprecation lifetime specified in the extension. Note there is no
extension and the invalidation timer
associated with to that of the invalida-
tion lifetime. Note that this processing does not apply to a
link-local address or manually configured address.

- If the prefix advertised does not match the prefix of an
address already in the list, then form an address using this
network prefix. Appendix A specifies how to form an address
for hosts that have IEEE 802 tokens. The extension is ignored
if the pre-
fix prefix is not valid, e.g. it is not the right length
for forming an address as specified
in Appendix A. with the given host token.

Add this address to the list with a the deprecation timer set
to that of the deprecation lifetime specified in the extension.

3.3.1. Address Deprecation and Invalidation the invalidation
timer to that of the invalidation lifetime.

Note that if the deprecation lifetime is zero, the address with
that prefix is immediately deprecated. Similarly, if the invalida-
tion lifetime is zero, the address with that prefix is immediately
made invalid. (The invalidation lifetime is defined to be no less
than the deprecation lifetime.)

An address is valid until the deprecation timer expires. A valid
address may be used as a source address in all outgoing

Expires December 5, 1995 [Page 9]

INTERNET-DRAFT Stateless Address Configuration June 1995

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

When the deprecation lifetime of an address expires, an address is
said to be deprecated. In general, a A deprecated address should no longer be
used in new communications, but may SHOULD NOT be used in existing communica-
tions.

In particular, the internetworking layer should not select a

Expires September 24, 1995 [Page 10]

INTERNET-DRAFT Stateless Address Configuration March 1995

deprecated address as
a source address in new communications. How-
ever, However, a deprecated
address should be allowed SHOULD continue to be used as a source address if it is in
use by the transport layer in existing communica-
tions or it is explicitly requested by an application. communications. The internetworking IP layer must MUST continue to
accept datagrams destined to a deprecated address. The transport layer may Upper layers
MAY refuse to accept new communications requests to a deprecated
address, however.

In addition,

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

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

To limit storage space required for the host has address list, a host may
choose not to store all valid alternative address. Also, a and deprecated
address addresses. Deprecated
addresses that are not in use by existing communications should be removed from the Domain Name System (DNS). This may
be done by the
discarded in favor of valid addresses and deprecated addresses
that are in use.

If a host itself, given determines that there are no IPv6 routers on a DNS dynamic update protocol and
sufficient authority, or it may be done link,
either on the host's behalf.

The time at which startup or during normal processing, a deprecated address becomes invalid (removed from
the list of host MUST attempt
to use stateful autoconfiguration to acquire addresses per interface) or other
configuration information if it is dependent on the storage
available for the address list and not already doing so. This is thus implementation-dependent.
A
needed to support networks with no IPv6 routers. The host should keep a deprecated address until it is deter-
mines that there are no longer in use,
i.e. it is routers on the link after startup if no longer being used
Router Advertisements are heard in current communications such as an
existing TCP connection, 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 longer stored or cached in the
Domain Name System. After this point, routers when

Expires December 5, 1995 [Page 10]

INTERNET-DRAFT Stateless Address Configuration June 1995

all router advertisements have timed out. If a deprecated address may be
removed from router comes up on
the address list.

If Router Advertisements stop being heard link and all autoconfigured
inter-link scope addresses become deprecated, then the host must
determine whether a DHCPv6 server is available for address autoconfi-
guration. The Router Advertisements begin to be received, a host follows the same procedure as described
MUST start to use Router Advertisements in the
initialisation procedure normal way, and, in this case.

3.4. Detecting Duplicate IPv6 Addresses

One of the basic assumptions of the autoconfiguration schemes out-
lined
particular, use advertisements to determine whether stateless or
stateful address configuration should be in this document is use. Note that the if a
host token is at least unique per
link. Tokens does not receive Router Advertisements because of some error,
e.g. all routers are defined down or there is a network partition, hosts
will attempt to be link-layer dependent, 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 token stateful
mode is available, it should be configured correctly to serve only
the link layer address in most cases. In practice, two hosts on the
same link that it should, since hosts may have attempt to use it, even
if it is not the same link layer address intention that they do so.

A host must behave reasonably when there is a change from the
stateless mode to the stateful mode, and vice versa. This can hap-
pen because routers advertise a new configuration mode due to a
deliberate change by a system administrator, or because of an assign-
ment error, a
change in which case the resulting topology, e.g. an IPv6 addresses will not be
unique. For this reason, it router is prudent connected to check that or removed
from the addresses
are indeed unique. In IPv6, it link. It is only necessary to check possible and quite likely that one
of during the
change-over, a host will have addresses autoconfigured using both
mechanisms. If the addresses is unique since 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 same token is

Expires September 24, 1995 [Page 11]

INTERNET-DRAFT Stateless Address Configuration March 1995

used to form all
addresses and acquired using the prefixes used to form two mechanisms are different, then
the old addresses are all unique (the autoconfiguration procedure should
ensure this). It is recommended that the link-local address be aged according to the
address checked since it is formed once and first, on initialisation.

The procedures use General Solicitations and Advertisements rules specified
in [2,3] as modified below. To validate an address, the node sends a
General Solicitation with the source old configuration mode and destination set to that the new addresses should follow
the rules of the new mode.

4.3. Host Initialisation

A host forms a link-local address to be checked. The node should specify when an appropriate
Media-Access extension.

On receiving a General Solicitation with autoconfigurable interface
is initialised. Appendix A specifies how a source address 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
same as the destination address and apparently 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 itself, being a host
must respond with router to being a General Advertisement. host, by hav-
ing its IP forwarding capability turned off by system manage-
ment.

- The General Advertisement host is sent re-attached to the All-Nodes Multicast Address with intra-link scope. a link after being detached for some
time.

- The Media-Access extension interface has its Perform_Auto_Config flag changed from the General Solicitation
FALSE to TRUE.

4.4. Detecting Duplicate IPv6 Addresses

The procedure to detect duplicate addresses MUST NOT be
retained.

After sending a General Solicitation, the node waits for a period of
General_Solicitation_Interval. If a General Advertisement is not
received implemented in response
hosts and SHOULD be used.

In stateless address configuration, it is only necessary to check
that one of the General Solicitation within the interval, autoconfigured addresses is unique since the address same
token is considered used to be validated. If a General Advertisement
is received with a source address form all addresses. It is recommended that the same as
link-local address be the address being vali-
dated, it must cease operation on that interface checked since the host always forms
this address.

The procedure uses Neighbor Solicitation and indicate Advertisement messages
specified in [2] to validate an
appropriate error. address and is specified below.

Note that this mechanism is not completely reliable, and so it is
possible that duplicate addresses will still exist. If a duplicate
address is discovered, the host will need to be configured with a new
token, or if this is not possible, the IPv6 addresses will need to be
manually configured.

DISCUSSION: There is a problem with a race condition when two (or
more) nodes boot up at the same time. Both will send out a General
Solicitation, receive no advertisement and assume all is well. A fix
may be to have a node process General Solicitations during the vali-
dation stage and flag an error if it sees more than one General Sol-
icitation for an address it is in the process of validating.

DISCUSSION: Should the solicitations be dithered? Note that randomis-
ing based on the token (link-layer address) only does not help if the
token is not unique.

Expires September 24, 1995 [Page 12]

INTERNET-DRAFT Stateless Address Configuration March 1995

4. SECURITY CONSIDERATIONS

To be completed.

Expires September 24, 1995 [Page 13]

INTERNET-DRAFT Stateless Address Configuration March 1995

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

4.4.1. Soliciting Host Behavior

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 first delays a link-local prefix, the prefix is well-defined[1].

The prefixes of other types random amount of addresses need to be configured. time between 0 and
DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation

Expires September 24, December 5, 1995 [Page 14] 12]

INTERNET-DRAFT Stateless Address Configuration March June 1995

6. APPENDIX B: UNIQUENESS OF HOST TOKENS

As has been mentioned,

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 of host is trying
to solicit for the basic assumptions of same address at the autoconfi-
guration scheme outlined in this document 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 is
at least as a unique per link, but that tokens may value is not always sufficient since the token cannot be
relied upon to be unique, unique. Although the randomization range is speci-
fied in practice. A 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 check that ignore the first Neighbor Solicitation with an
unspecified source address or wait for a period of
DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation
before beginning to process solicitations again.

If after sending a solicitation, no advertisement is received from
the target, the node SHOULD retransmit the solicitation every
DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is
received or the solicitation has been retransmitted
MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
target address the same as the address being validated, it must cease
operation on that interface and indicate an appropriate error. If no
such advertisement is unique using the
scheme proposed received in this document. Since this response to the Neighbor Solicita-
tions sent, the address is not completely reli-
able, system administrators may also use DNS considered to help detect when such be valid.

4.4.2. Solicited Node Behavior

When a problem occurs since two different hosts will register host is in the same
IPv6 address.

Duplicate IPv6 addresses may occur as a result process of non-unique tokens
in validating an address, it MUST NOT
send any particular network topology. One particular scenario deserves
further mention though. Consider a topology consisting of two links
with singly-homed hosts attached advertisement in response to each, a multi-homed host attached
to both and no router. In this case, because no router is present,
hosts will form link-local addresses only on all interfaces. It is
imperative that hosts have interface tokens solicitation for that are unique across
both links. However, this may not be true

Expires December 5, 1995 [Page 13]

INTERNET-DRAFT Stateless Address Configuration June 1995

address. Rather, all solicitations for two reasons: the links
may be of different types and thus address are ignored,
except when the tokens used may not be unique.
Also, solicitation is from the token may not be unique if it unspecified address i.e.
the Neighbor Solicitation message has a target address which is defined the
same as the address to be validated, and a link layer source address and that is the link-layer address
unspecified address. (Note that any solicitation that is only defined likely to be unique per
link
a loopback solicitation should be ignored too as is true mentioned in some cases. Strictly speaking, we require that the
above section.) If a solicitation is received from the unspecified
address, the host tokens are globally unique to ensure correct must cease operation in these
topologies. In practice, link layer addresses are frequently glo-
bally unique on that interface and so the uniqueness problems in this scenario should
not be appreciably worse than in more traditional topologies as
described above. If two link-local scope addresses are detected indicate
an appropriate error.

Once a host has validated its address, it responds to
be a Neighbor Sol-
icitation with a Neighbor Advertisement as specified in [2]. However,
the same processing of the solicitation is somewhat different from that in this scenario, there are two solutions: one
[2] when a solicitation is to make received from the unspecified address. In
this case, the multihomed 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 router, Neighbor Advertisement. The host
sends the other is Neighbor Advertisement to manually configure the
link-local all-nodes multicast address
of an offending the soliciting host. The target address is copied from the solici-
tation message. The source address MUST be set to the address of the
target field. The Target Link Layer Address extension need not be
filled in.

4.4.3. Constants

DUPL_ADDR_DELAY 4 seconds (XX)
DUPL_ADDR_IGNORE_TIMER 0.1 seconds
DUPL_ADDR_RETRANS_TIMER 4 seconds (XX)
MAX_DUPL_ADDR_RETRANS 1 transmission (XX)

5. SECURITY CONSIDERATIONS

To be completed.

Expires September 24, December 5, 1995 [Page 15] 14]

INTERNET-DRAFT Stateless Address Configuration March June 1995

6. APPENDIX C: Prefix-Information Extension

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | Length |C|A|M| 0 | Prefix Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Identifier A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS

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

Extension As in [3]

Length As in [3]

C As in [3]

A Autonomous Mode

Form an IEEE 802 address using prefix of advertised
identifier.

M Administered Mode

Use DHCPv6 to autoconfigure other information.

Prefix Size Number of bits |
+----------------------------------------------------------------+

In the case of identifier defining a link-local prefix, the
routing prefix for this link

Preference As in [3]

Identifier One is well-defined[1].

The prefixes of IPv6 unicast addresses other types of this interface

This extension is found in Router Advertisements. addresses need to be configured.

Expires September 24, December 5, 1995 [Page 16] 15]

INTERNET-DRAFT Stateless Address Configuration March June 1995

7. REFERENCES

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

[2] W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
Draft, January 1995, <draft-simpson-ipv6-discov-process-02.txt>

[3] W. A. Simpson, T. Narten and E. Nordmark, "IPv6 Neighbor Discovery -- ICMP Message For-
mats", Discovery", Internet
Draft, January June 1995, <draft-simpson-ipv6-
discov-formats-02.txt> <draft-ietf-ipngwg-discovery-00.txt>

Acknowledgements

The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. In particular, thanks to Jim Bound,
Steve Deering 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 September 24, December 5, 1995 [Page 17] 16]

INTERNET-DRAFT Stateless Address Configuration March June 1995

Expires September 24, December 5, 1995 [Page 18] 17]

----