As per Relevance of the word addresses, we have this rfc below:
Network Working Group S.
Request for Comments: 1971
Category: Standards Track T.
August 1996
IPv6 Stateless Address
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document specifies the steps a host takes in deciding how
autoconfigure its interfaces in IP version 6. The
process includes creating a link-local address and verifying
uniqueness on a link, determining what information should
autoconfigured (addresses, other information, or both), and in
case of addresses, whether they should be obtained through
stateless mechanism, the stateful mechanism, or both. This
defines the process for generating a link-local address, the
for generating site-local and global addresses via stateless
autoconfiguration, and the Duplicate Address Detection procedure.
details of autoconfiguration using the stateful protocol
specified elsewhere
Table of
1. INTRODUCTION............................................. 2
2. TERMINOLOGY.............................................. 4
2.1. Requirements........................................ 7
3. DESIGN GOALS............................................. 8
4. PROTOCOL OVERVIEW........................................ 9
4.1. Site Renumbering.................................... 11
5. PROTOCOL SPECIFICATION................................... 11
5.1. Node Configuration Variables........................ 12
5.2. Autoconfiguration-Related Variables................. 12
5.3. Creation of Link-Local Addresses.................... 13
5.4. Duplicate Address Detection......................... 13
5.4.1. Message Validation............................. 15
5.4.2. Sending Neighbor Solicitation Messages......... 15
5.4.3. Receiving Neighbor Solicitation Messages....... 15
Thomson & Narten Standards Track [Page 1]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
5.4.4. Receiving Neighbor Advertisement Messages...... 16
5.4.5. When Duplicate Address Detection Fails......... 16
5.5. Creation of Global and Site-Local Addresses......... 17
5.5.1. Soliciting Router Advertisements............... 17
5.5.2. Absence of Router Advertisements............... 17
5.5.3. Router Advertisement Processing................ 17
5.5.4. Address Lifetime Expiry........................ 19
5.6. Configuration Consistency........................... 19
SECURITY CONSIDERATIONS...................................... 19
REFERENCES................................................... 20
AUTHORS' ADDRESSES........................................... 21
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION. 22
1.
This document specifies the steps a host takes in deciding how
autoconfigure its interfaces in IP version 6. The
process includes creating a link-local address and verifying
uniqueness on a link, determining what information should
autoconfigured (addresses, other information, or both), and in
case of addresses, whether they should be obtained through
stateless mechanism, the stateful mechanism, or both. This
defines the process for generating a link-local address, the
for generating site-local and global addresses via stateless
autoconfiguration, and the Duplicate Address Detection procedure.
details of autoconfiguration using the stateful protocol
specified elsewhere
IPv6 defines both a stateful and stateless address
mechanism. Stateless autoconfiguration requires no
configuration of hosts, minimal (if any) configuration of routers
and no additional servers. The stateless mechanism allows a host
generate its own addresses using a combination of locally
information and information advertised by routers. Routers
prefixes that identify the subnet(s) associated with a link,
hosts generate an "interface token" that uniquely identifies
interface on a subnet. An address is formed by combining the two.
the absence of routers, a host can only generate link-
addresses. However, link-local addresses are sufficient for
communication among nodes attached to the same link
In the stateful autoconfiguration model, hosts obtain
addresses and/or configuration information and parameters from
server. Servers maintain a database that keeps track of
addresses have been assigned to which hosts. The
autoconfiguration protocol allows hosts to obtain addresses,
configuration information or both from a server. Stateless
stateful autoconfiguration complement each other. For example, a
Thomson & Narten Standards Track [Page 2]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
can use stateless autoconfiguration to configure its own addresses
but use stateful autoconfiguration to obtain other information
Stateful autoconfiguration is described in [DHCPv6].
The stateless approach is used when a site is not
concerned with the exact addresses hosts use, so long as they
unique and properly routable. The stateful approach is used when
site requires tighter control over exact address assignments.
stateful and stateless address autoconfiguration may be
simultaneously. The site administrator specifies which type
autoconfiguration to use through the setting of appropriate fields
Router Advertisement messages [DISCOVERY].
IPv6 addresses are leased to an interface for a fixed (
infinite) length of time. Each address has an associated
that indicates how long the address is bound to an interface. When
lifetime expires, the binding (and address) become invalid and
address may be reassigned to another interface elsewhere in
Internet. To handle the expiration of address bindings gracefully,
address goes through two distinct phases while assigned to
interface. Initially, an address is "preferred", meaning that its
in arbitrary communication is unrestricted. Later, an address
"deprecated" in anticipation that its current interface binding
become invalid. While in a deprecated state, the use of an address
discouraged, but not strictly forbidden. New communication (e.g.,
the opening of a new TCP connection) should use a preferred
when possible. A deprecated address should be used only
applications that have been using it and would have
switching to another address without a service disruption
To insure that all configured addresses are likely to be unique on
given link, nodes run a "duplicate address detection" algorithm
addresses before assigning them to an interface. The
Address Detection algorithm is performed on all addresses
independent of whether they are obtained via stateless or
autoconfiguration. This document defines the Duplicate
Detection algorithm
The autoconfiguration process specified in this document applies
to hosts and not routers. Since host autoconfiguration
information advertised by routers, routers will need to be
by some other means. However, it is expected that routers
generate link-local addresses using the mechanism described in
document. In addition, routers are expected to successfully pass
Duplicate Address Detection procedure described in this document
all addresses prior to assigning them to an interface
Thomson & Narten Standards Track [Page 3]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
Section 2 provides definitions for terminology used throughout
document. Section 3 describes the design goals that lead to
current autoconfiguration procedure. Section 4 provides an
of the protocol, while Section 5 describes the protocol in detail
2.
IP - Internet Protocol Version 6. The terms IPv4 and IPv
are used only in contexts where necessary to
ambiguity
node - a device that implements IP
router - a node that forwards IP packets not
addressed to itself
host - any node that is not a router
upper layer - a protocol layer immediately above IP. Examples
transport protocols such as TCP and UDP,
protocols such as ICMP, routing protocols such as OSPF
and internet or lower-layer protocols being "tunneled
over (i.e., encapsulated in) IP such as IPX, AppleTalk
or IP itself
link - a communication facility or medium over which nodes
communicate at the link layer, i.e., the
immediately below IP. Examples are Ethernets (
or bridged); PPP links; X.25, Frame Relay, or
networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself
interface - a node's attachment to a link
packet - an IP header plus payload
address - an IP-layer identifier for an interface or a set
interfaces
unicast
- an identifier for a single interface. A packet sent
a unicast address is delivered to the
identified by that address
multicast
- an identifier for a set of interfaces (
belonging to different nodes). A packet sent to
multicast address is delivered to all
Thomson & Narten Standards Track [Page 4]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
identified by that address
anycast
- an identifier for a set of interfaces (
belonging to different nodes). A packet sent to
anycast address is delivered to one of the
identified by that address (the "nearest" one
according to the routing protocol's measure
distance). See [ADDR-ARCH].
solicited-node multicast
- a multicast address to which Neighbor
messages are sent. The algorithm for computing
address is given in [DISCOVERY].
link-layer
- a link-layer identifier for an interface.
include IEEE 802 addresses for Ethernet links and E.164
addresses for ISDN links
link-local
- an address having link-only scope that can be used
reach neighboring nodes attached to the same link.
interfaces have a link-local unicast address
site-local
- an address having scope that is limited to the
site
global
- an address with unlimited scope
- any packet exchange among nodes that requires that
address of each node used in the exchange remain
same for the duration of the packet exchange.
are a TCP connection or a UDP request-response
tentative
- an address whose uniqueness on a link is
verified, prior to its assignment to an interface.
tentative address is not considered assigned to
interface in the usual sense. An interface
received packets addressed to a tentative address,
accepts Neighbor Discovery packets related to
Address Detection for the tentative address
Thomson & Narten Standards Track [Page 5]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
preferred
- an address assigned to an interface whose use by
layer protocols is unrestricted. Preferred
may be used as the source (or destination) address
packets sent from (or to) the interface
deprecated
- An address assigned to an interface whose use
discouraged, but not forbidden. A deprecated
should no longer be used as a source address in
communications, but packets sent to
addresses are delivered as expected. A
address may continue to be used as a source address
communications where switching to a preferred
causes hardship to a specific upper-layer
(e.g., an existing TCP connection).
valid
- a preferred or deprecated address. A valid address
appear as the source or destination address of
packet, and the internet routing system is expected
deliver packets sent to a valid address
invalid
- an address that is not assigned to any interface.
valid address becomes invalid when its valid
expires. Invalid addresses should not appear as
destination or source address of a packet. In
former case, the internet routing system will be
to deliver the packet, in the later case the
of the packet will be unable to respond to it
preferred
- the length of time that a valid address is
(i.e., the time until deprecation). When the
lifetime expires, the address becomes deprecated
valid
- the length of time an address remains in the
state (i.e., the time until invalidation). The
lifetime must be greater then or equal to the
lifetime. When the valid lifetime expires, the
becomes invalid
interface
- a link-dependent identifier for an interface that
(at least) unique per link. Stateless
autoconfiguration combines an interface token with
Thomson & Narten Standards Track [Page 6]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
prefix to form an address. From
autoconfiguration's perspective, an interface token
a bit string of known length. The exact length of
interface token and the way it is created is defined
a separate link-type specific document that
issues related to the transmission of IP over
particular link type (e.g., [IPv6-ETHER]). In
cases, the token will be the same as the interface'
link-layer address
2.1.
Throughout this document, the words that are used to define
significance of the particular requirements are capitalized.
words are
This word or the adjective "REQUIRED" means that the item is
absolute requirement of this specification
MUST
This phrase means the item is an absolute prohibition of
specification
This word or the adjective "RECOMMENDED" means that there may
valid reasons in particular circumstances to ignore this item,
the full implications should be understood and the case
weighed before choosing a different course
SHOULD
This phrase means that there may exist valid reasons in
circumstances when the listed behavior is acceptable or
useful, but the full implications should be understood and the
carefully weighed before implementing any behavior described
this label
This word or the adjective "OPTIONAL" means that this item is
optional. One vendor may choose to include the item because
particular marketplace requires it or because it enhances
product, for example, another vendor may omit the same item
Thomson & Narten Standards Track [Page 7]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
3. DESIGN
Stateless autoconfiguration is designed with the following goals
mind
o Manual configuration of individual machines before connecting
to the network should not be required. Consequently, a mechanism
needed that allows a host to obtain or create unique addresses
each of its interfaces. Address autoconfiguration assumes that
interface can provide a unique identifier for that interface (i.e.,
an "interface token"). In the simplest case, an interface
consists of the interface's link-layer address. An interface
can be combined with a prefix to form an address
o Small sites consisting of a set of machines attached to a
link should not require the presence of a stateful server or
as a prerequisite for communicating. Plug-and-play
is achieved through the use of link-local addresses. Link-
addresses have a well-known prefix that identifies the (single
shared link to which a set of nodes attach. A host forms a link
local address by appending its interface token to the link-
prefix
o A large site with multiple networks and routers should not
the presence of a stateful address configuration server. In
to generate site-local or global addresses, hosts must
the prefixes that identify the subnets to which they attach
Routers generate periodic Router Advertisements that
options listing the set of active prefixes on a link
o Address configuration should facilitate the graceful renumbering
a site's machines. For example, a site may wish to renumber all
its nodes when it switches to a new network service provider
Renumbering is achieved through the leasing of addresses
interfaces and the assignment of multiple addresses to the
interface. Lease lifetimes provide the mechanism through which
site phases out old prefixes. The assignment of multiple
to an interface provides for a transition period during which
a new address and the one being phased out work simultaneously
o System administrators need the ability to specify whether
autoconfiguration, stateful autoconfiguration, or both should
used. Router Advertisements include flags specifying
mechanisms a host should use
Thomson & Narten Standards Track [Page 8]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
4. PROTOCOL
This section provides an overview of the typical steps that
place when an interface autoconfigures itself. Autoconfiguration
performed only on multicast-capable links and begins when
multicast-capable interface is enabled, e.g., during system startup
Nodes (both hosts and routers) begin the autoconfiguration process
generating a link-local address for the interface. A link-
address is formed by appending the interface's token to the well
known link-local prefix
Before the link-local address can be assigned to an interface
used, however, a node must attempt to verify that this "tentative
address is not already in use by another node on the link
Specifically, it sends a Neighbor Solicitation message containing
tentative address as the target. If another node is already
that address, it will return a Neighbor Advertisement saying so.
another node is also attempting to use the same address, it will
a Neighbor Solicitation for the target as well. The exact number
times the Neighbor Solicitation is (re)transmitted and the delay
between consecutive solicitations is link-specific and may be set
system management
If a node determines that its tentative link-local address is
unique, autoconfiguration stops and manual configuration of
interface is required. To simplify recovery in this case, it
be possible for an administrator to supply an alternate
token that overrides the default token in such a way that
autoconfiguration mechanism can then be applied using the
(presumably unique) interface token. Alternatively, link-local
other addresses will need to be configured manually
Once a node ascertains that its tentative link-local address
unique, it assigns it to the interface. At this point, the node
IP-level connectivity with neighboring nodes. The
autoconfiguration steps are performed only by hosts;
(auto)configuration of routers is beyond the scope of this document
The next phase of autoconfiguration involves obtaining a
Advertisement or determining that no routers are present. If
are present, they will send Router Advertisements that specify
sort of autoconfiguration a host should do. If no routers
present, stateful autoconfiguration should be invoked
Routers send Router Advertisements periodically, but the
between successive advertisements will generally be longer than
host performing autoconfiguration will want to wait [DISCOVERY].
obtain an advertisement quickly, a host sends one or more
Thomson & Narten Standards Track [Page 9]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
Solicitations to the all-routers multicast group.
Advertisements contain two flags indicating what type of
autoconfiguration (if any) should be performed. A "managed
configuration" flag indicates whether hosts should use
autoconfiguration to obtain addresses. An "other
configuration" flag indicates whether hosts should use
autoconfiguration to obtain additional information (
addresses).
Router Advertisements also contain zero or more Prefix
options that contain information used by stateless
autoconfiguration to generate site-local and global addresses.
should be noted that the stateless and stateful
autoconfiguration fields in Router Advertisements are
independently of one another, and a host may use both stateful
stateless address autoconfiguration simultaneously. One
Information option field, the "autonomous address-
flag", indicates whether or not the option even applies to
autoconfiguration. If it does, additional option fields contain
subnet prefix together with lifetime values indicating how
addresses created from the prefix remain preferred and valid
Because routers generate Router Advertisements periodically,
will continually receive new advertisements. Hosts process
information contained in each advertisement as described above
adding to and refreshing information received in
advertisements
For safety, all addresses must be tested for uniqueness prior
their assignment to an interface. In the case of addresses
through stateless autoconfig, however, the uniqueness of an
is determined primarily by the portion of the address formed from
interface token. Thus, if a node has already verified the
of a link-local address, additional addresses created from the
interface token need not be tested individually. In contrast,
addresses obtained manually or via stateful address
should be tested for uniqueness individually. To accommodate
that believe the overhead of performing Duplicate Address
outweighs its benefits, the use of Duplicate Address Detection can
disabled through the administrative setting of a per-
configuration flag
To speed the autoconfiguration process, a host may generate
link-local address (and verify its uniqueness) in parallel
waiting for a Router Advertisement. Because a router may
responding to a Router Solicitation for a few seconds, the total
needed to complete autoconfiguration can be significantly longer
the two steps are done serially
Thomson & Narten Standards Track [Page 10]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
4.1. Site
Address leasing facilitates site renumbering by providing a
to time-out addresses assigned to interfaces in hosts. At present
upper layer protocols such as TCP provide no support for
end-point addresses while a connection is open. If an end-
address becomes invalid, existing connections break and
communication to the invalid address fails. Even when
use UDP as a transport protocol, addresses must generally remain
same during a packet exchange
Dividing valid addresses into preferred and deprecated
provides a way of indicating to upper layers that a valid address
become invalid shortly and that future communication using
address will fail, should the address's valid lifetime expire
communication ends. To avoid this scenario, higher layers should
a preferred address (assuming one of sufficient scope exists)
increase the likelihood that an address will remain valid for
duration of the communication. It is up to system administrators
set appropriate prefix lifetimes in order to minimize the impact
failed communication when renumbering takes place. The
period should be long enough that most, if not all,
are using the new address at the time an address becomes invalid
The IP layer is expected to provide a means for upper
(including applications) to select the most appropriate
address given a particular destination and possibly
constraints. An application may choose to select the source
itself before starting a new communication or may leave the
unspecified, in which case the upper networking layers will use
mechanism provided by the IP layer to choose a suitable address
the application's behalf
Detailed address selection rules are beyond the scope of
document
5. PROTOCOL
Autoconfiguration is performed on a per-interface basis
multicast-capable interfaces. For multihomed hosts
autoconfiguration is performed independently on each interface
Autoconfiguration applies primarily to hosts, with two exceptions
Routers are expected to generate a link-local address using
procedure outlined below. In addition, routers perform
Address Detection on all addresses prior to assigning them to
interface
Thomson & Narten Standards Track [Page 11]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
5.1. Node Configuration
A node MUST allow the following autoconfiguration-related variable
be configured by system management for each multicast interface
The number of consecutive Neighbor
messages sent while performing Duplicate
Detection on a tentative address. A value of
indicates that Duplicate Address Detection is
performed on tentative addresses. A value of
indicates a single transmission with no follow
retransmissions
Default: 1, but may be overridden by a link-
specific value in the document that covers
related to the transmission of IP over a
link type (e.g., [IPv6-ETHER]).
Autoconfiguration also assumes the presence of the
RetransTimer as defined in [DISCOVERY]. For
purposes, RetransTimer specifies the delay between
Neighbor Solicitation transmissions performed during
Address Detection (if DupAddrDetectTransmits is greater than 1),
well as the time a node waits after sending the last
Solicitation before ending the Duplicate Address Detection process
5.2. Autoconfiguration-Related
A host maintains a number of data structures and flags related
autoconfiguration. In the following, we present conceptual
and show how they are used to perform autoconfiguration. The
variables are used for demonstration purposes only, and
implementation is not required to have them, so long as its
behavior is consistent with that described in this document
Beyond the formation of a link-local address and using
Address Detection, how routers (auto)configure their interfaces
beyond the scope of this document
Hosts maintain the following variables on a per-interface basis
ManagedFlag Copied from the M flag field (i.e., the "
address configuration" flag) of the most
received Router Advertisement message. The
indicates whether or not addresses are to
Thomson & Narten Standards Track [Page 12]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
configured using the stateful
mechanism. It starts out in a FALSE state
OtherConfigFlag Copied from the O flag field (i.e., the "
stateful configuration" flag) of the most
received Router Advertisement message. The
indicates whether or not information other
addresses are to be obtained using the
autoconfiguration mechanism. It starts out in
FALSE state
A host also maintains a list of addresses together with
corresponding lifetimes. The address list contains
autoconfigured addresses and those configured manually
5.3. Creation of Link-Local
A node forms a link-local address whenever an interface
enabled. An interface may become enabled after any of the
events
- The interface is initialized at system startup time
- The interface is reinitialized after a temporary interface
or after being temporarily disabled by system management
- The interface attaches to a link for the first time
- The interface becomes enabled by system management after
been administratively disabled
A link-local address is formed by prepending the well-known link
local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to
interface token. If the interface token has a length of N bits,
interface token replaces the right-most N zero bits of the link-
prefix. If the interface token is more than 118 bits in length
autoconfiguration fails and manual configuration is required
A link-local address has an infinite preferred and valid lifetime;
is never timed out
5.4. Duplicate Address
Duplicate Address Detection MUST be performed on unicast
prior to assigning them to an interface whose
variable is greater than zero. Duplicate Address Detection
place on all unicast addresses, regardless of whether they
obtained through stateful, stateless or manual configuration
Thomson & Narten Standards Track [Page 13]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
(Duplicate Address Detection MUST NOT be performed on
addresses.) Each individual unicast address SHOULD be tested
uniqueness. However, when stateless address autoconfiguration
used, address uniqueness is determined solely by the interface token
assuming that subnet prefixes are assigned correctly (i.e., if all
an interface's addresses are generated from the same token,
all addresses or none of them will be duplicates). Thus, for a set
addresses formed from the same interface token, it is sufficient
check that the link-local address generated from the token is
on the link. In such cases, the link-local address MUST be tested
uniqueness before any of the other addresses formed from the
can be assigned to an interface
The procedure for detecting duplicate addresses uses
Solicitation and Advertisement messages as described below. If
duplicate address is discovered during the procedure, the
cannot be assigned to the interface. If the address is derived
an interface token, a new token will need to be assigned to
interface, or all IP addresses for the interface will need to
manually configured. Note that the method for detecting
is not completely reliable, and it is possible that
addresses will still exist (e.g., if the link was partitioned
Duplicate Address Detection was performed).
An address on which the duplicate Address Detection Procedure
applied is said to be tentative until the procedure has
successfully. A tentative address is not considered "assigned to
interface" in the traditional sense. That is, the interface
accept Neighbor Solicitation and Advertisement messages
the tentative address in the Target Address field, but processes
packets differently from those whose Target Address matches
address assigned to the interface. Other packets addressed to
tentative address should be silently discarded
It should also be noted that Duplicate Address Detection must
performed prior to assigning an address to an interface in order
prevent multiple nodes from using the same address simultaneously
If a node begins using an address in parallel with Duplicate
Detection, and another node is already using the address, the
performing Duplicate Address Detection will erroneously
traffic intended for the other node, resulting in such
negative consequences as the resetting of open TCP connections
The following subsections describe specific tests a node performs
verify an address's uniqueness. An address is considered unique
none of the tests indicate the presence of a duplicate address
RetransTimer milliseconds after having sent
Neighbor Solicitations. Once an address is determined to be unique
Thomson & Narten Standards Track [Page 14]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
it may be assigned to an interface
5.4.1. Message
A node MUST silently discard any Neighbor Solicitation
Advertisement message that does not pass the validity
specified in [DISCOVERY]. A solicitation that passes these
checks is called a valid solicitation or valid advertisement
5.4.2. Sending Neighbor Solicitation
Before sending a Neighbor Solicitation, an interface MUST join
all-nodes multicast address and the solicited-node multicast
of the tentative address. The former insures that the node
Neighbor Advertisements from other nodes already using the address
the latter insures that two nodes attempting to use the same
simultaneously detect each other's presence
To check an address, a node sends DupAddrDetectTransmits
Solicitations, each separated by RetransTimer milliseconds.
solicitation's Target Address is set to the address being checked
the IP source is set to the unspecified address and the
destination is set to the solicited-node multicast address of
target address
If the Neighbor Solicitation is the first message to be sent from
interface after interface (re)initialization, the node should
sending the message by a random delay between 0
MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. This
to alleviate congestion when many nodes start up on the link at
same time, such as after a power failure, and may help to avoid
conditions when more than one node is trying to solicit for the
address at the same time. In order to improve the robustness of
Duplicate Address Detection algorithm, an interface MUST receive
process datagrams sent to the all-nodes multicast address
solicited-node multicast address of the tentative address
delaying transmission of the initial Neighbor Solicitation
5.4.3. Receiving Neighbor Solicitation
On receipt of a valid Neighbor Solicitation message on an interface
node behavior depends on whether the target address is tentative
not. If the target address is not tentative (i.e., it is assigned
the receiving interface), the solicitation is processed as
in [DISCOVERY]. If the target address is tentative, and the
address is a unicast address, the solicitation's sender is
address resolution on the target; the solicitation should be
ignored. Otherwise, processing takes place as described below.
Thomson & Narten Standards Track [Page 15]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
all cases, a node MUST NOT respond to a Neighbor Solicitation for
tentative address
If the source address of the Neighbor Solicitation is the
address, the solicitation is from a node performing Duplicate
Detection. If the solicitation is from another node, the
address is a duplicate and should not be used (by either node).
the solicitation is from the node itself (because the node loops
multicast packets), the solicitation does not indicate the
of a duplicate address
Implementor's Note: many interfaces provide a way for upper layers
selectively enable and disable the looping back of multicast packets
The details of how such a facility is implemented may
Duplicate Address Detection from working correctly. See the
for further discussion
The following tests identify conditions under which a
address is not unique
- If a Neighbor Solicitation for a tentative address is
prior to having sent one, the tentative address is a duplicate
This condition occurs when two nodes run Duplicate
Detection simultaneously, but transmit initial solicitations
different times (e.g., by selecting different random delay
before transmitting an initial solicitation).
- If the actual number of Neighbor Solicitations received exceeds
number expected based on the loopback semantics (e.g.,
interface does not loopback packet, yet one or more
was received), the tentative address is a duplicate. This
occurs when two nodes run Duplicate Address
simultaneously and transmit solicitations at roughly the same time
5.4.4. Receiving Neighbor Advertisement
On receipt of a valid Neighbor Advertisement message on an interface
node behavior depends on whether the target address is tentative
matches a unicast or anycast address assigned to the interface.
the target address is assigned to the receiving interface,
solicitation is processed as described in [DISCOVERY]. If the
address is tentative, the tentative address is not unique
5.4.5. When Duplicate Address Detection
A tentative address that is determined to be a duplicate as
above, MUST NOT be assigned to an interface and the node SHOULD log
system management error. If the address is a link-local
Thomson & Narten Standards Track [Page 16]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
formed from an interface token, the interface SHOULD be disabled
5.5. Creation of Global and Site-Local
Global and site-local addresses are formed by appending an
token to a prefix of appropriate length. Prefixes are obtained
Prefix Information options contained in Router Advertisements
Creation of global and site-local addresses and configuration
other parameters as described in this section SHOULD be
configurable. However, the processing described below MUST be
by default
5.5.1. Soliciting Router
Router Advertisements are sent periodically to the all-
multicast address. To obtain an advertisement quickly, a host
out Router Solicitations as described in [DISCOVERY].
5.5.2. Absence of Router
If a link has no routers, a host MUST attempt to use
autoconfiguration to obtain addresses and other
information. An implementation MAY provide a way to disable
invocation of stateful autoconfiguration in this case, but
default SHOULD be enabled. From the perspective
autoconfiguration, a link has no routers if no Router
are received after having sent a small number of Router
as described in [DISCOVERY].
5.5.3. Router Advertisement
On receipt of a valid Router Advertisement (as defined
[DISCOVERY]), a host copies the value of the advertisement's M
into ManagedFlag. If the value of ManagedFlag changes from FALSE
TRUE, the host should invoke the stateful address
protocol, requesting address information. If the value of
ManagedFlag changes from TRUE to FALSE, the host should terminate
stateful address autoconfiguration protocol (i.e., stop
addresses and ignore subsequent responses to in-
transactions). If the value of the flag stays unchanged, no
action takes place. In particular, a host MUST NOT reinvoke
address configuration if it is already participating in the
protocol as a result of an earlier advertisement
An advertisement's O flag field is processed in an analogous manner
A host copies the value of the O flag into OtherConfigFlag. If
value of OtherConfigFlag changes from FALSE to TRUE, the host
invoke the stateful autoconfiguration protocol,
Thomson & Narten Standards Track [Page 17]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
information (excluding addresses). If the value of
OtherConfigFlag changes from TRUE to FALSE, any activity related
stateful autoconfiguration for parameters other than addresses
be halted. If the value of the flag stays unchanged, no
action takes place. In particular, a host MUST NOT reinvoke
configuration if it is already participating in the stateful
as a result of an earlier advertisement
For each Prefix-Information option in the Router Advertisement
a) If the Autonomous flag is not set, silently ignore the
Information option
b) If the prefix is the link-local prefix, silently ignore the
Information option
c) If the preferred lifetime is greater than the valid lifetime
silently ignore the Prefix Information option. A node MAY wish
log a system management error in this case
d) If the advertised prefix matches the prefix of an
address (i.e., obtained via stateless or stateful
autoconfiguration) in the list of addresses associated with
interface, set the preferred timer to that of the option's
lifetime, and set the valid lifetime to that of the option's
lifetime
e) If the prefix advertised does not match the prefix of an
already in the list, then form an address (and add it to the list
by appending the interface token to the prefix as follows
| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface token |
+----------------------------------------------------------------+
If the sum of the prefix length and interface token length does
equal 128 bits, the Prefix Information option MUST be ignored.
implementation MAY wish to log a system management error in
case. It is the responsibility of the system administrator to
that the lengths of prefixes contained in Router Advertisements
consistent with the length of interface tokens for that link type
In those cases where a site requires the use of longer prefixes
can be accommodated by the interface token,
autoconfiguration can be used
Thomson & Narten Standards Track [Page 18]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
If an address is formed successfully, the host adds it to the
of addresses assigned to the interface, initializing its
and valid lifetime values from the Prefix Information option
5.5.4. Address Lifetime
A preferred address becomes deprecated when its preferred
expires. A deprecated address SHOULD continue to be used as a
address in existing communications, but SHOULD NOT be used in
communications if an alternate (non-deprecated) address is
and has sufficient scope. The IP layer MUST continue to
datagrams destined to a deprecated address since a deprecated
is still a valid address for the interface. An implementation
prevent any new communication from using a deprecated address,
system management MUST have the ability to disable such a facility
An address (and its association with an interface) becomes
when its valid lifetime expires. An invalid address MUST NOT be
as a source address in outgoing communications and MUST NOT
recognized as a destination on a receiving interface
Note that if a Prefix Information option is received with a
lifetime of zero, any addresses generated from that prefix
immediately deprecated. Similarly, if both the advertised
and valid lifetimes are zero, any addresses generated from
prefix become invalid immediately
5.6. Configuration
It is possible for hosts to obtain address information using
stateless and stateful protocols since both may be enabled at
same time. It is also possible that the values of
configuration parameters such as MTU size and hop limit will
learned from both Router Advertisements and the
autoconfiguration protocol. If the same configuration information
provided by multiple sources, the value of this information should
consistent. However, it is not considered a fatal error
information received from multiple sources is inconsistent.
accept the union of all information received via the stateless
stateful protocols. If inconsistent information is learned
different sources, the most recently obtained values always
precedence over information learned earlier
SECURITY
Stateless address autoconfiguration allows a host to connect to
network, configure an address and start communicating with
nodes without ever registering or authenticating itself with
Thomson & Narten Standards Track [Page 19]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
local site. Although this allows unauthorized users to connect
and use a network, the threat is inherently present in the
architecture. Any node with a physical attachment to a network
generate an address (using a variety of ad hoc techniques)
provides connectivity
The use of Duplicate Address Detection opens up the possibility
denial of service attacks. Any node can respond to
Solicitations for a tentative address, causing the other node
reject the address as a duplicate. This attack is similar to
attacks involving the spoofing of Neighbor Discovery messages and
be addressed by requiring that Neighbor Discovery packets
authenticated [RFC1826].
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826,
1995.
[IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv
Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[ADDR-ARCH] Hinden, R., and S. Deering, "Internet Protocol
(IPv6) Addressing Architecture", RFC 1884, December 1995.
[DHCPv6] Work in Progress
[DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "
Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.
The authors would like to thank the members of both the IPNG
ADDRCONF working groups for their input. In particular, thanks to
Bound, Steve Deering, and Erik Nordmark
Thomson & Narten Standards Track [Page 20]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
AUTHORS'
Susan
445 South
Morristown, NJ 07960
Phone: +1 201-829-4514
EMail: set@thumper.bellcore.
Thomas
IBM
P.O. Box 12195
Research Triangle Park, NC 27709-2195
Phone: +1 919 254 7798
EMail: narten@vnet.ibm.
Thomson & Narten Standards Track [Page 21]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS
Determining whether a received multicast solicitation was looped
to the sender or actually came from another node is implementation
dependent. A problematic case occurs when two interfaces attached
the same link happen to have the same token and link-layer address
and they both send out packets with identical contents at roughly
same time (e.g., Neighbor Solicitations for a tentative address
part of Duplicate Address Detection messages). Although a
will receive both packets, it cannot determine which packet
looped back and which packet came from the other node by
comparing packet contents (i.e., the contents are identical). In
particular case, it is not necessary to know precisely which
was looped back and which was sent by another node; if one
more solicitations than were sent, the tentative address is
duplicate. However, the situation may not always be
straightforward
The IPv4 multicast specification [RFC1112] recommends that
service interface provide a way for an upper-layer protocol
inhibit local delivery of packets sent to a multicast group that
sending host is a member of. Some applications know that there
be no other group members on the same host, and suppressing
prevents them from having to receive (and discard) the packets
themselves send out. A straightforward way to implement
facility is to disable loopback at the hardware level (if
by the hardware), with packets looped back (if requested)
software. On interfaces in which the hardware itself
loopbacks, a node running Duplicate Address Detection simply
the number of Neighbor Solicitations received for a tentative
and compares them with the number expected. If there is a mismatch
the tentative address is a duplicate
In those cases where the hardware cannot suppress loopbacks, however
one possible software heuristic to filter out unwanted loopbacks
to discard any received packet whose link-layer source address is
same as the receiving interface's. Unfortunately, use of
criteria also results in the discarding of all packets sent
another node using the same link-layer address. Duplicate
Detection will fail on interfaces that filter received packets
this manner
o If a node performing Duplicate Address Detection discards
packets having the same source link-layer address as the
interface, it will also discard packets from other nodes also
the same link-layer address, including Neighbor Advertisement
Neighbor Solicitation messages required to make Duplicate
Detection work correctly. This particular problem can be
Thomson & Narten Standards Track [Page 22]
RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
by temporarily disabling the software suppression of
while a node performs Duplicate Address Detection
o If a node that is already using a particular IP address
received packets having the same link-layer source address as
interface, it will also discard Duplicate Address Detection-
Neighbor Solicitation messages sent by another node also using
same link-layer address. Consequently, Duplicate Address
will fail, and the other node will configure a non-unique address
Since it is generally impossible to know when another node
performing Duplicate Address Detection, this scenario can
avoided only if software suppression of loopback is
disabled
Thus, to perform Duplicate Address Detection correctly in the
where two interfaces are using the same link-layer address,
implementation must have a good understanding of the interface'
multicast loopback semantics, and the interface cannot
received packets simply because the source link-layer address is
same as the interfaces
Thomson & Narten Standards Track [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
