WDIFF

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

ADDRCONF Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT January 31, March 24, 1995
<draft-ietf-addrconf-ipv6-auto-00.txt>
<draft-ietf-addrconf-ipv6-auto-01.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 how a host autoconfigures one or more
addresses per interface. stateless address autoconfiguration. A host
can form an intra-link scope a link-local address autonomously based on information local
to the host. A host can form an inter-link scope address in two
ways: either semi-autonomously, autonomously, based on knowledge of subnet prefixes advertised by routers,
or by using DHCPv6. the IPv6 version of the Dynamic Host Configuration
Protocol(DHCPv6). All mechanisms rely on a host having a token per
interface that
is unique at least per subnet. link. This document specifies how a host
forms an intra-link scope address autonomously
and an inter-link scope address semi-autonomously using IEEE 802
tokens to identify each interface. addresses autonomously. DHCPv6 is described elsewhere.

Expires July 31, September 24, 1995 [Page 1]

INTERNET-DRAFT Stateless Address Configuration January March 1995

1. INTRODUCTION

An IPv6 host may have multiple addresses per interface. The addresses
can autoconfigure two types have one of address: three scopes:

1. an intra-link scope a link-local address,

2. an inter-link scope a site-local address, and

3. a global address.

An intra-link scope

All three address is autoconfigurable in the absence of scopes can be autoconfigured. A host can autocon-
figure a
router. An inter-link scope link-local address autonomously. A host can autoconfigure a
site-local or global address is autoconfigurable only when a router or a DHCPv6 server is
present on the link.

There is only one way to form an intra-link scope a link-local address. On ini-
tialization initialization
of an interface, a host forms such an IPv6 intra-link scope address by concatenating a predefined intra-link scope prefix
well-known link-local prefix[1] to a token that is unique per link. Typically, the
The definition of the
token is link-layer dependent. In tokens used are link-dependent. For example,
in the case of a host attached to an link that uses IEEE 802 network, for example,
addresses, the token is the IEEE 802 address of the interface.

There are two ways to form an inter-link scope a site-local or global address. In the
first mechanism, a host forms an IPv6 inter-link scope address by con-
catenating a network prefix advertised in a Router
Advertisement[IPv6-DISC-PROC,IPv6-DISC-PROC] Advertisement[2,3]
to a token that is unique per link. The other mechanism available to hosts is to use the
IPv6 version of Like the Dynamic Host Configuration Protocol
(DHCPv6)[IPv6-DHCP]. The choice of protocol to use is advertised by link-local address, the router, and this choice
token is configurable by the system administra-
tor.

The first defined to be link-layer dependent. This mechanism for
forming an inter-link scope a site-local or global address is suit-
able suitable for environments
where no administrative control is desired. It is a simple, efficient simple protocol
designed for a very specific purpose: to make stateless address configuration con-
figuration very straightforward to use and implement.

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

This document describes the general host address autoconfiguration
procedure

The choice of mechanism to use in Section 2, and how a host forms an intra-link scope
address and forming an inter-link scope address without using DHCPv6 in Sec-
tions 3 and 4, respectively. The DHCPv6 protocol
is specified else-
where [IPv6-DHCP]. The scope of the document advertised by a router, if present, and this choice is limited to hosts configur-
able by a system administrator.

Expires July 31, September 24, 1995 [Page 2]

INTERNET-DRAFT Stateless Address Configuration January March 1995

attached

This document describes how a host forms a link-local address and one
or more site-local or global addresses autonomously. It also speci-
fies how a host determines which mechanism to IEEE 802 networks. The effect of use to form an inter-
link scope address: the transition scheme on autonomous (stateless) approach or DHCPv6.
Section 2 describes the router's role in address autoconfiguration procedure is discussed in
and Section 5. 3 the host's role.

Expires July 31, September 24, 1995 [Page 3]

INTERNET-DRAFT Stateless Address Configuration January March 1995

2. PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES

A host maintains a list of addresses per interface. At a minimum, the
list includes the intra-link scope address, which ROUTER BEHAVIOR

The stateless address autoconfiguration mechanism relies on the host can form
autonomously whenever an interface is initialised. If a
router is
attached to the link, the list will also include inter-link scope
addresses formed either from subnet prefixes advertised discovery mechanism specified in router
advertisements [2,3] for forming addresses
with site-local or by making requests global scope. If configured to DHCPv6. Inter-link scope
addresses may also be manually configured.

2.1. Host Configuration

A host must maintain a list do so, routers
advertise prefix information in periodic Router Advertisements. The
prefixes are contained in Prefix-Information extensions of a Router
Advertisement. Each Prefix-Information extension indicates whether
the following configurable variables
per interface:

Address

A valid IPv6 unicast prefix can be used for autonomous address autoconfiguration and,
if so, for this interface

Default: None

LifeTime:

The length how long the resulting address is valid. Note that the
lifetime of time for which an the address is valid defined separately from that of the Router
Advertisement itself (other information is advertised in seconds.

Default: Infinity

An intra-link scope address and all manually configured addresses
have their lifetimes set to infinity.

A host may also allow the following variable adver-
tisement which has different lifetime requirements). The extension
also explicitly indicates to hosts whether DHCPv6 is required to be configured by a
used since it is possible that system administrator per interface:

Perform_Auto_Address

If TRUE, administrators would like to
have hosts autoconfigure addresses autonomously, but also use DHCPv6
to acquire other configuration information besides the host must perform address autoconfiguration process-
ing. Otherwise, address.

Router Advertisement and Solicitation processing is specified in [2]
and the host performs no message formats in [3].

DISCUSSION: An alternative approach is to advertise address autoconfiguration confi-
guration information in a separate advertisement entirely. This would
be somewhat cleaner since the lifetime of the advertisement would
then be that of the information advertised. On the other hand, having
two types of router advertisements would mean that prefix information
is advertised redundantly, and in particular, would double traffic on
initialisation and on router solicitations.

2.1. Router Configuration Variables

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

For each of the IPv6 unicast addresses per interface:

Autonomous Flag

Expires July 31, September 24, 1995 [Page 4]

INTERNET-DRAFT Stateless Address Configuration January March 1995

processing at all.

Default: TRUE

2.2. Router Configuration

A router must be configurable by a system administrator so that the
choice of mechanism used for host configuration of inter-link scope
addresses can be controlled. Thus, a router must allow

If and only if TRUE, the following
variable prefix length is to be configured by a system administrator per advertised for
the purposes of autonomous address configuration.

Default: TRUE

For each interface:

Perform_Auto_Address

Administered Flag

If and only if TRUE, the router host must send an 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 Prefix exten-
sion Advertise-
ments from the interface, in every seconds. The value must not be
less than Maximum_Advertisement_Interval of Router Advertisement. Advertise-
ments.

Default: TRUE

All router interfaces advertising a given subnet XX

Address_Lifetime

The value to be placed in the Lifetime field of the
Prefix_Information extension sent from the interface in
seconds. The value must not be less than
Address_Advertisement_Interval. This value indicates how long
an address formed from the prefix advertised is valid. Only
valid in extensions with the Autonomous flag set to TRUE.

Default: 3 * Address_Advertisement_Interval

All routers advertising a given prefix on a link
must MUST be configured
to advertise the same address autoconfiguration mode to hosts.

2.3. Host

Expires September 24, 1995 [Page 5]

INTERNET-DRAFT Stateless Address Autoconfiguration Procedure Configuration March 1995

2.2. Processing

A host must perform router MUST advertise address autoconfiguration information in a
Prefix Information Extension of a Router Advertisement. The values of
the following procedure for Autonomous and Administered flags are advertised along with
Address_Lifetime. The address configuration information need not be
advertised in each interface when
booting or whenever an interface needs to Router Advertisement. It must be initialised:

When sent (almost)
periodically in a host boots or Router Advertisement at any time when a host has no address for an
autoconfigurable interface, e.g. when interval of approxi-
mately Address_Advertisement_Interval.

Address configuration information must also be sent in the first few
Router Advertisements after startup or enabling of an interface (up
to MAX_INITIAL_ADVERTISEMENTS) and in a Router Advertisement that is enabled
after being disabled,
sent in response to a Router Solicitation.

Address configuration information may also be sent in a Router
Advertisement due to actions taken by system management, in particu-
lar, when the host forms an address Address_Lifetime of intra-link
scope and adds it a prefix is set to zero, e.g.
because the list of addresses. Section 3 specifies
how link is to be renumbered. In this case, a host forms an intra-link scope address.

The host Prefix-
Information extension must send be transmitted in a Router Solicitation so that inter-link scope
addresses can be formed (or verified) as soon as possible. Advertisement
advertising the appropriate address prefix with the Autonomous Flag
set to TRUE and Address_Lifetime set to zero.

Expires July 31, September 24, 1995 [Page 5] 6]

INTERNET-DRAFT Stateless Address Configuration January March 1995

When

3. HOST ADDRESS AUTOCONFIGURATION PROCESSING

3.1. Host Configuration Variables

A host maintains a solicited list of addresses per interface. At a minimum, the
list includes the link-local address, which the host can form auto-
nomously whenever an interface is initialised. If a router is
attached to the link or unsolicited Router Advertisement DHCPv6 server is received over
an interface, available, the list may also
include site-local or global addresses formed either from subnet pre-
fixes advertised in Router Advertisements or by making requests using
DHCPv6. Addresses may also be manually configured. Note there may be
multiple site-local or global addresses autoconfigured per interface.

A host must perform maintain a list of the following address configura-
tion processing:

If an configurable variables
per interface:

Address

A valid IPv6 unicast address for this interface

Default: None

Prefix extension exists, Length

The length of the host forms or verifies
its inter-link addresses autonomously as prefix in bits. Prefix length semantics are
specified in Section 4.

Otherwise, [2].

A host must also allow the implication is that following variable to be configured per
interface:

Perform_Auto_Config

If and only if TRUE, the host must use DHCPv6 for
address autoconfiguration. If no perform address exists on the interface,
the autoconfigura-
tion processing.

Expires September 24, 1995 [Page 7]

INTERNET-DRAFT Stateless Address Configuration March 1995

Default: TRUE

3.2. Host Initialization Behavior

A host must initiate a request perform the following autoconfiguration procedure when-
ever an interface needs to be initialised:

When a DHCPv6 server host has no address for an interface with
Perform_Auto_Config flag set to acquire TRUE, e.g. when a
new address. (Verification and renewal of existing addresses host boots or
when an interface is
performed at DHCPv6-specified times.) If DHCPv6 fails for any rea-
son, enabled after being disabled, the host falls back to using forms
an intra-link scope address or a
manually configured inter-link scope address until of link-local scope. Appendix A specifies how a DHCPv6 server
request is successful.

Note host
that the above procedure should continue is attached to operate when a sys-
tem administrator decides to change link that uses IEEE 802 addresses forms a
link-local address.

Before adding the autoconfiguration mode from link-local address as a valid address to the
list of addresses for the interface, the autonomous mode (the host forms SHOULD verify that
the address) to DHCPv6, and vice
versa. address is indeed unique. The requirement during procedure for validating an
address is described in Section X. A host SHOULD also validate any
manually configured addresses this way too.

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

If no Router Advertisement is heard after sending
MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after
each as specified in Sending Router Solicitations in [2], the system
administrator host
must ensure that determine whether a DHCPv6 server is configured present and whether any
configuration information needs to hand
out addresses that are unique per subnet, particularly with respect be acquired. This is to addresses that hosts configure autonomously. To avoid problems
during cater
for a changeover, it is recommended that routerless topology which has a DHCP server should use
exactly the same algorithm to form DHCPv6 server. Once a host address as that used in the
autonomous mode, particularly when the subnet prefix used router
is the
same. Otherwise, further precautionary measures will need to be
taken to ensure correct operation.

To support the changeover from autonomous mode added to DHCPv6 mode, DHCPv6
should provide the ability for network, however, a host to specify in a request previ-
ously configured inter-link addresses. A DHCPv6 server can then
validate, deprecate or forbid the MUST use of the autonomously formed
addresses.

Changing from DHCPv6 mode Router Adver-
tisements to autonomous mode is somewhat tricky.
Normal autonomous mode processing should support determine the changeover from
DHCPv6 mode to autonomous autoconfiguration mode assuming the above recommendation is
followed. DHCPv6-assigned addresses can be validated or deprecated in use as a normal part of host processing when an Address Prefix extension
is heard
described in a the section on Router Advertisement. The Drop Address Prefix can be
used to invalidate DHCPv6 addresses, if desired. Advertisement Processing.

Expires July 31, September 24, 1995 [Page 6] 8]

INTERNET-DRAFT Stateless Address Configuration January March 1995

3. FORMING AN IEEE 802 IPv6 ADDRESS

3.3. Router Advertisement Processing

Router Advertisement processing is specified in [2] and the message
format in [3]. In addition to this processing, the host forms an IEEE 802 IPv6 MUST perform
the following address for an interface by concatenat-
ing configuration processing when a solicited or
unsolicited Router Advertisement is received over an 80-bit subnet prefix with interface:

For each Prefix-Information extension in the 48-bit IEEE 802 address Router Advertisement:
(The format of the
interface Prefix-Information extension as follows:

In amended by this
draft for autoconfiguration purposes is specified in Appendix C):

The host silently ignores the case extension for the purposes of an intra-link scope prefix, auto-
configuration if the subnet prefix Perform_Auto_Config flag for the interface is
well-defined (TBD).

In
FALSE.

Otherwise, the case of an inter-link scope prefix, host checks the subnet prefix autoconfiguration mode bits.

If only the Autonomous flag is con-
figurable (typically set in the Prefix-Information
extension, the host forms or verifies a router).

Expires July 31, 1995 [Page 7]

INTERNET-DRAFT Address Configuration January 1995

4. FORMING INTER-LINK SCOPE IPv6 ADDRESSES AUTONOMOUSLY

4.1. Router Operation

4.1.1. Sending Router Advertisements with Address Extensions

A router may be configured to advertise address configuration infor-
mation in extensions of Router Advertisements. Two extensions are
defined for site-local or global
address configuration: as specified below.

If both the Address Prefix extension which
advertises valid subnet prefixes to enable hosts to form their own
addresses autonomously, Autonomous and Administered flags are set in the Drop Address Prefix Extension which
indicates that
Prefix-Information extension, the host forms or verifies a subnet prefix (and hence an site-
local or global address formed from such
a subnet prefix) is unrouteable.

ED'S NOTE: I have used two new extensions here as specified below and uses or continues
using DHCPv6 for illustrative
purposes. It is likely other autoconfiguration.

Otherwise, the case that host silently ignores the Address Prefix Extension
and extension for the Drop Prefix Extension can be supported using pur-
poses of autonomous autoconfiguration.

If none of the Routing
Information Extensions and Change Prefix extensions defined prefixes advertised in
neighbor discovery, respectively. The details extensions of combining the
semantics of Router Adver-
tisement have the existing extensions with Autonomous flag set, then the host uses or contin-
ues using DHCPv6 for autoconfiguration.

Note that of the following
extensions still need above procedure should continue to be worked out.

Expires July 31, 1995 [Page 8]

INTERNET-DRAFT Address Configuration January 1995

4.1.2. Address Prefix Extension Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | Length | Reserved |M| Prefix Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extension TBD

Length 18

Reserved Must be zero

M When set, indicates more IPv6 parameters operate when a sys-
tem administrator decides to
configure besides address.

Use DHCPv6 change the autoconfiguration mode from
the autonomous mode to acquire these parameters.

Prefix Size Length DHCPv6, and vice versa. The host should keep
track of subnet prefix in bits.

Subnet Prefix Valid subnet prefix for this link.

This extension the current autoconfiguration mode, so that it can detect
when there is found in Router Advertisements.

4.1.3. Drop Address Prefix Extension Format

Extension TBD

Length 18 a change. The system administrator must ensure that,
during a changeover, a DHCPv6 server is configured to hand out
addresses that are unique per link, particularly with respect to
addresses that hosts have configured autonomously and which may not

Expires July 31, September 24, 1995 [Page 9]

INTERNET-DRAFT Stateless Address Configuration January March 1995

Reserved Must be zero

Prefix Size Length of subnet prefix in bits.

Subnet Prefix Subnet prefix for this link to

yet be invalidated.

This extension To avoid problems during a changeover, it is found
recommended that a DHCP server should use exactly the same algorithm
to form a host address as that used in Router Advertisements.

4.2. Host Operation

4.2.1. Processing the autonomous mode when the
prefix is the same. It is also important to ensure that a DHCPv6
server is configured to hand out addresses only to those hosts that
it should, since, if a DHCPv6 server is present on a link, hosts may
request the server for addresses (even if the network is configured
to be in autonomous mode) when Router Advertisements are not heard
because the router is down.

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

a) If the prefix advertised matches the prefix of an autoconfigured
address already in the list, then set a timer to that of the
lifetime specified in the extension. Note there is no timer
associated with a link-local address or manually configured
address.

b) 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 is not the right length for forming an address as specified
in Appendix A.

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

3.3.1. Address Extensions

On hearing Deprecation and Invalidation

An address is valid until the timer expires.

When the lifetime of an address expires, an address is said to be
deprecated. In general, a deprecated address should no longer be
used in new communications, but may 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, a deprecated address should be allowed 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.

The internetworking layer must continue to accept datagrams destined
to a deprecated address. The transport layer may refuse to accept new
communications requests to a deprecated address, however.

In addition, a host may send a Remote Redirect[2,3] to correspondents
when the source address used in communications is deprecated as long
as the host has a valid alternative address. Also, a deprecated
address should be removed from the Domain Name System (DNS). This may
be done by the host itself, given a DNS dynamic update protocol and
sufficient authority, or it may be done on the host's behalf.

The time at which a Router Advertisement deprecated address becomes invalid (removed from
the list of addresses per interface) is dependent on an interface, a host checks the storage
available for
an Address Prefix extension the address list and a Drop Address Prefix extension. is thus implementation-dependent.
A host processes an Address Prefix extension as described in Section
4.2.2 below and should keep a Drop Address Prefix extension deprecated address until it is no longer in use,
i.e. it is no longer being used in current communications such as an
existing TCP connection, and it is no longer stored or cached in Section 4.2.3.

4.2.2. Address Prefix Extension Processing

For each the
Domain Name System. After this point, a deprecated address prefix advertised on an autoconfigurable interface, may be
removed from the address list.

If Router Advertisements stop being heard and all autoconfigured
inter-link scope addresses become deprecated, then the host updates must
determine whether a DHCPv6 server is available for address autoconfi-
guration. The host follows the list of addresses same procedure as follows:

1. If described in the prefix advertised matches
initialisation procedure in this case.

3.4. Detecting Duplicate IPv6 Addresses

One of the prefix basic assumptions of an address
already in the list, then set autoconfiguration schemes out-
lined in this document is that the lifetime host token is at least unique per
link. Tokens are defined to infinity.

2. If be link-layer dependent, and the prefix advertised does not match token is
the prefix of an link layer address
already in most cases. In practice, two hosts on the list, then form an inter-link scope
same link may have the same link layer address using
this network prefix. Section 3 specifies how to form because of an inter-
link scope address.

Add assign-
ment error, in which case the resulting IPv6 addresses will not be
unique. For this address reason, it is prudent to check that the addresses
are indeed unique. In IPv6, it is only necessary to check that one
of the list with an infinite lifetime.

3. All other autoconfigured inter-link addresses in is unique since the list have same token is

Expires July 31, September 24, 1995 [Page 10] 11]

INTERNET-DRAFT Stateless Address Configuration January March 1995

their lifetimes set

used to zero.

An inter-link scope address is valid for as long as the subnet prefix
is advertised in form all addresses and the appropriate extension of a Router Advertisement.
A lifetime of infinity is prefixes used in the above algorithm to indicate
this. An address is deprecated when form the subnet prefix
addresses are all unique (the autoconfiguration procedure should
ensure this). It is no longer
advertised in the Address Prefix extension of the Router Advertise-
ment, but recommended that the subnet prefix has not been explicitly invalidated by a
Drop Address Prefix extension. An link-local address is also deprecated when a
new Router Advertisement is not heard before be the old advertisement
times out. A lifetime of zero
address checked since it is used formed once and first, on initialisation.

The procedures use General Solicitations and Advertisements specified
in [2,3] as modified below. To validate an address, the above algorithm node sends a
General Solicitation with the source and destination set to
indicate that of
the address has been deprecated.

A deprecated address is likely to be routable, although it is not
guaranteed to be. In the case where checked. The node should specify an appropriate
Media-Access extension.

On receiving a subnet prefix that has been
previously advertised is no longer advertised in General Solicitation with a Router Advertise-
ment (this assumes source address that a host is hearing Router Advertisements), a
host should prepare for the time when
same as the destination address becomes invalid: and apparently from itself, a host should stop using
must respond with a General Advertisement. The General Advertisement
is sent to the address as All-Nodes Multicast Address with intra-link scope.
The Media-Access extension from the General Solicitation MUST NOT be
retained.

After sending a source address in communica-
tions, if other addresses are available, and should stop advertising General Solicitation, the address to others node waits for a period of
General_Solicitation_Interval. If a General Advertisement is not
received in DNS. Also, it should refuse to accept new
connections response to this address. However, the General Solicitation within the interval,
the address may still be used is considered to accept incoming datagrams be validated. If a General Advertisement
is received with a source address the same as the address being vali-
dated, it must cease operation on that interface and to avoid breaking existing connec-
tions. When indicate an
appropriate error.

Note that this mechanism is not completely reliable, and so it is
possible that duplicate addresses will still exist. If a duplicate
address becomes deprecated because no Router Adver-
tisements are heard (because the router is down, for example), discovered, the host may still continue will need to use the address as normal until be configured with a new
token, or if this is not possible, the next
Router Advertisement IPv6 addresses will need to be
manually configured.

DISCUSSION: There is heard.

Note that a problem with a race condition when two (or
more) nodes boot up at the 'M' bit of an address prefix extension same time. Both will send out a General
Solicitation, receive no advertisement and assume all is well. A fix
may indicate be to have a node process General Solicitations during the host that vali-
dation stage and flag an error if it must use DHCPv6 to acquire other IPv6 configuration
parameters (besides the address).

4.2.3. Drop Address Prefix Extension Processing

For each sees more than one General Sol-
icitation for an address prefix advertised, the host updates it is in the list process of
addresses as follows:

1. If validating.

DISCUSSION: Should the prefix advertised matches solicitations be dithered? Note that randomis-
ing based on the prefix of an address
already in token (link-layer address) only does not help if the list, then remove address from list.
token is not unique.

Expires July 31, September 24, 1995 [Page 11] 12]

INTERNET-DRAFT Stateless Address Configuration January March 1995

When an address is invalidated, it should no longer

4. SECURITY CONSIDERATIONS

To be used at all in
communications since the subnet prefix is no longer routable. completed.

Expires September 24, 1995 [Page 13]

INTERNET-DRAFT Stateless Address Configuration March 1995

5. TRANSITION IMPLICATIONS

IPv4-compatible IPv6 addresses are required by APPENDIX A: FORMING AN IPv6 hosts ADDRESS FOR IEEE 802 LINKS

The token for the
following purposes in the SIT scheme[IPv6-TRANS]: 1) to communicate
off a link when an IPv6 neighboring router is not present interface on the an IEEE 802 link or any link
and 2) to communicate with IPv4-only hosts.

In order that dual IPv4/IPv6 hosts can communicate using IPv6 without
the presence of an IPv6 neighboring router, uses
IEEE 802 addressing, such a host should be
able to form an IPv4-compatible IPv6 address autonomously. This as FDDI, is
done by concatenating the well-defined IPv4-compatibility prefix to 48-bit IEEE 802 address in
canonical format, i.e. the host's IPv4 address. (It Individual/Group bit is not defined here how the low-order bit
of the furst byte.

A host gets forms an
IPv4 address; the IPv4 address may have been manually configured or
autoconfigured using BOOTP, DHCP[RFC1531],etc). An IPv4-compatible IPv6 address should be formed on an interface if no Router Advertise-
ment is heard within a reasonable timeframe.

On hearing per link by concatenating an IPv6 Router Advertisement, however, the host must carry
out 80-bit pre-
fix with the IPv6 IEEE 802 address autoconfiguration procedure as normal. follows:

In the case where the router advertises subnet prefixes for autoconfigura-
tion purposes, it is possible to tell from the value of a link-local prefix, the subnet prefix advertised what form of address is to be used. well-defined[1].

The subnet
prefix advertised may contain the IPv4-compatibility prefix in which
case the IPv4-compatible form prefixes of the address is used. Otherwise, an
IPv6-only address must be formed other types of addresses need to replace any IPv4-compatible
address previously formed as described in Section 3.

6. SECURITY CONSIDERATIONS

To be completed. configured.

Expires July 31, September 24, 1995 [Page 12] 14]

INTERNET-DRAFT Stateless Address Configuration January March 1995

6. APPENDIX - B: UNIQUENESS OF HOST TOKENS

One of the basic assumptions of the autoconfiguration schemes out-
lined in this memo is that the host token is at least unique per
link. The only feasible choice for the token is the link layer
address in most cases. In practice, two hosts on the same link may
have

As has been mentioned, one of the same link layer address because basic assumptions of an assignment error, the autoconfi-
guration scheme outlined in
which case this document is that the resulting IPv6 addresses will host token is
at least unique per link, but that tokens may not always be unique. There unique,
in practice. A host should check that an address is
no automatic detection of such occurrences. The unique using the
scheme proposed in this document. Since this is not completely reli-
able, system administrators may also use of DNS to regis-
ter name to address mappings may help system administrators detect when such
a problem occurs since two different hosts will register the same
IPv6 address.

The above problem

Duplicate IPv6 addresses may occur as a result of non-unique tokens
in any particular network topology. One particular scenario deserves
further mention though. Consider a topology consisting of two links
with singly-homed hosts attached to each, a multi-homed host attached
to both and no router. In this case, because no router is present,
hosts will form intra-link link-local addresses only on all interfaces. It is
imperative that hosts have interface tokens that are unique across
both links, which is links. However, this may not be true
if a host for two reasons: the links
may be of different types and thus the tokens used may not be unique.
Also, the token may not be unique if it is defined to be a link layer
address and the link-layer address is only defined to be unique per
link as is true in some cases. Strictly speaking, we require that
host tokens are globally unique to ensure correct operation in these
topologies. In practice, link layer addresses are frequently globally glo-
bally unique and so the uniqueness problems in this scenario should
not be appreciably worse than in more traditional topologies as
described above. If two intra-link link-local scope addresses are detected to
be the same in this scenario, there are two solutions: one is to make
the multihomed host a router, the other is to manually configure the intra-link scope
link-local address of an offending host.

Expires July 31, September 24, 1995 [Page 13] 15]

INTERNET-DRAFT Stateless Address Configuration January March 1995

8. REFERENCES

[RFC1531]
R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, Buck-
nell University, October 1993.

[IPv6-TRANS]
Robert E. Gilligan and E. Nordmark, "Transition Mechanisms

7. APPENDIX C: Prefix-Information Extension

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | Length |C|A|M| 0 | Prefix Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Identifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extension As in [3]

Length As in [3]

C As in [3]

A Autonomous Mode

Form an address using prefix of advertised
identifier.

M Administered Mode

Use DHCPv6 to autoconfigure other information.

Prefix Size Number of bits of identifier defining the
routing prefix for this link

Preference As in [3]

Identifier One of IPv6 Hosts and Routers", Internet Draft, November 1994, <draft-
gilligan-ipv6-trans-mech-00.txt>

[IPv6-SPEC] unicast addresses of this interface

This extension is found in Router Advertisements.

Expires September 24, 1995 [Page 16]

INTERNET-DRAFT Stateless Address Configuration March 1995

8. REFERENCES

[1] R. Hinden, "Internet Protocol Version 6 (IPv6) Specification",
Internet Draft, February 1994, <draft-hinden-ipng-ipv6-spec-
00.txt>

[IPv6-ROAD]

[IPv6-ICMP]
A. Conta and S. Deering, "ICMP and IGMP for IPv6", Internet
Draft, September 1994, <draft-conta-ipv6-icmp-igmp-00.txt>

[IPv6-DISC-FORM] March 1995, <draft-ietf-ipngwg-ipv6-addr-arch-
01.txt>

[2] W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
mats", Processing", Internet
Draft, November 1994, <draft-simpson-ipv6-
discov-formats-01.txt>

[IPv6-DISC-PROC] January 1995, <draft-simpson-ipv6-discov-process-02.txt>

[3] W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", ICMP Message For-
mats", Internet Draft, November 1994, <draft-simpson-ipv6-discov-process-01.txt>

[IPv6-DHCP]
J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress. January 1995, <draft-simpson-ipv6-
discov-formats-02.txt>

Acknowledgements

The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input.

Expires July 31, 1995 [Page 14]

INTERNET-DRAFT Address Configuration January 1995 In particular, thanks to Jim Bound,
Steve Deering 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 July 31, September 24, 1995 [Page 15] 17]

INTERNET-DRAFT Stateless Address Configuration March 1995

Expires September 24, 1995 [Page 18]

----