draft-ietf-ipv6-rfc2462bis-06.txt   draft-ietf-ipv6-rfc2462bis-07.txt 
IETF IPv6 Working Group S. Thomson IETF IPv6 Working Group S. Thomson
Internet-Draft Cisco Internet-Draft Cisco
Expires: March 4, 2005 T. Narten Expires: June 10, 2005 T. Narten
IBM IBM
T. Jinmei T. Jinmei
Toshiba Toshiba
September 3, 2004 December 10, 2004
IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration
draft-ietf-ipv6-rfc2462bis-06.txt draft-ietf-ipv6-rfc2462bis-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This document is an Internet-Draft and is subject to all provisions
applicable patent or other IPR claims of which he or she is aware of section 3 of RFC 3667. By submitting this Internet-Draft, each
have been or will be disclosed, and any of which he or she becomes author represents that any applicable patent or other IPR claims of
aware will be disclosed, in accordance with Section 6 of RFC 3668. which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2005. This Internet-Draft will expire on June 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its process includes generating a link-local address, generating global
uniqueness on a link, determining what information can be addresses via stateless address autoconfiguration, and the Duplicate
autoconfigured (addresses, other information, or both), and in the Address Detection procedure to verify the uniqueness of the addresses
case of addresses, whether they can be obtained through the stateless on a link.
mechanism, the stateful mechanism, or both. This document defines
the process for generating a link-local address, the process for
generating global addresses via stateless address autoconfiguration,
and the Duplicate Address Detection procedure. The details of
autoconfiguration using the stateful protocol are specified in RFC
3315; an alternative way of using the stateful protocol to deliver
'other information' only is specified in RFC 3736.
Table of Contents Table of Contents
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 11 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 9
5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 10
5.1 Node Configuration Variables . . . . . . . . . . . . . . . 12 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 10
5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 11
5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 11
5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 12
5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 15 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14
5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 15 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14
5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 15
5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 16
5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 16
5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 17
5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 17
5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 17
5.5.3 Router Advertisement Processing . . . . . . . . . . . 19 5.5.3 Router Advertisement Processing . . . . . . . . . . . 18
5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 21 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20
5.6 Configuration Consistency . . . . . . . . . . . . . . . . 22 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21
5.7 Retaining Configured Addresses for Stability . . . . . . . 22 5.7 Retaining Configured Addresses for Stability . . . . . . . 21
6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 23 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22
7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 24
B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 27 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26
C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27 C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 26
D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28 D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 31
1. INTRODUCTION 1. INTRODUCTION
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6 (IPv6). The autoconfigure its interfaces in IP version 6 (IPv6). The
autoconfiguration process includes creating a link-local address and autoconfiguration process includes generating a link-local address,
verifying its uniqueness on a link, determining what information can
be autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they can be obtained through the stateless
mechanism, the stateful mechanism, or both. This document defines
the process for generating a link-local address, the process for
generating global addresses via stateless address autoconfiguration, generating global addresses via stateless address autoconfiguration,
and the Duplicate Address Detection procedure. The details of and the Duplicate Address Detection procedure to verify the
autoconfiguration using the stateful protocol is specified in uniqueness of the addresses on a link.
[RFC3315] and [RFC3736].
IPv6 defines both a stateful and stateless address autoconfiguration The IPv6 stateless autoconfiguration mechanism requires no manual
mechanism. Stateless autoconfiguration requires no manual
configuration of hosts, minimal (if any) configuration of routers, configuration of hosts, minimal (if any) configuration of routers,
and no additional servers. The stateless mechanism allows a host to and no additional servers. The stateless mechanism allows a host to
generate its own addresses using a combination of locally available generate its own addresses using a combination of locally available
information and information advertised by routers. Routers advertise information and information advertised by routers. Routers advertise
prefixes that identify the subnet(s) associated with a link, while prefixes that identify the subnet(s) associated with a link, while
hosts generate an "interface identifier" that uniquely identifies an hosts generate an "interface identifier" that uniquely identifies an
interface on a subnet. An address is formed by combining the two. interface on a subnet. An address is formed by combining the two.
In the absence of routers, a host can only generate link-local In the absence of routers, a host can only generate link-local
addresses. However, link-local addresses are sufficient for allowing addresses. However, link-local addresses are sufficient for allowing
communication among nodes attached to the same link. communication among nodes attached to the same link.
In the stateful autoconfiguration model, hosts obtain interface
addresses and/or configuration information and parameters from a
Dynamic Host Configuration Protocol (DHCPv6) server. Servers
maintain a database that keeps track of which addresses have been
assigned to which hosts. The stateful autoconfiguration protocol
allows hosts to obtain addresses, other configuration information or
both from a server. Stateless and stateful autoconfiguration
complement each other. For example, a host can use stateless
autoconfiguration to configure its own addresses, but use stateful
autoconfiguration to obtain other information.
To obtain other configuration information without configuring
addresses in the stateful autoconfiguration model, a subset of DHCPv6
[RFC3736] will be used. While the model is called "stateful" here in
order to highlight the contrast to the stateless protocol defined in
this document, the intended protocol is also defined to work in a
stateless fashion. This is based on a result, through operational
experiments, that all known "other" configuration information can be
managed by a stateless server, that is, a server that does not
maintain state of each client that the server provides with the
configuration information.
The stateless approach is used when a site is not particularly The stateless approach is used when a site is not particularly
concerned with the exact addresses hosts use, so long as they are concerned with the exact addresses hosts use, so long as they are
unique and properly routable. The stateful approach is used when a unique and properly routable. On the other hand, Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a
site requires tighter control over exact address assignments. Both site requires tighter control over exact address assignments. Both
stateful and stateless address autoconfiguration may be used stateless address autoconfiguration and DHCPv6 may be used
simultaneously. The site administrator specifies which type of simultaneously.
autoconfiguration is available through the setting of appropriate
fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis].
IPv6 addresses are leased to an interface for a fixed (possibly IPv6 addresses are leased to an interface for a fixed (possibly
infinite) length of time. Each address has an associated lifetime infinite) length of time. Each address has an associated lifetime
that indicates how long the address is bound to an interface. When a that indicates how long the address is bound to an interface. When a
lifetime expires, the binding (and address) become invalid and the lifetime expires, the binding (and address) become invalid and the
address may be reassigned to another interface elsewhere in the address may be reassigned to another interface elsewhere in the
Internet. To handle the expiration of address bindings gracefully, Internet. To handle the expiration of address bindings gracefully,
an address goes through two distinct phases while assigned to an an address goes through two distinct phases while assigned to an
interface. Initially, an address is "preferred", meaning that its interface. Initially, an address is "preferred", meaning that its
use in arbitrary communication is unrestricted. Later, an address use in arbitrary communication is unrestricted. Later, an address
skipping to change at page 4, line 36 skipping to change at page 4, line 6
an address is discouraged, but not strictly forbidden. New an address is discouraged, but not strictly forbidden. New
communication (e.g., the opening of a new TCP connection) should use communication (e.g., the opening of a new TCP connection) should use
a preferred address when possible. A deprecated address should be a preferred address when possible. A deprecated address should be
used only by applications that have been using it and would have used only by applications that have been using it and would have
difficulty switching to another address without a service disruption. difficulty switching to another address without a service disruption.
To ensure that all configured addresses are likely to be unique on a To ensure that all configured addresses are likely to be unique on a
given link, nodes run a "duplicate address detection" algorithm on given link, nodes run a "duplicate address detection" algorithm on
addresses before assigning them to an interface. The Duplicate addresses before assigning them to an interface. The Duplicate
Address Detection algorithm is performed on all addresses, Address Detection algorithm is performed on all addresses,
independent of whether they are obtained via stateless or stateful independent of whether they are obtained via stateless
autoconfiguration. This document defines the Duplicate Address autoconfiguration or DHCPv6. This document defines the Duplicate
Detection algorithm. Address Detection algorithm.
The autoconfiguration process specified in this document applies only The autoconfiguration process specified in this document applies only
to hosts and not routers. Since host autoconfiguration uses to hosts and not routers. Since host autoconfiguration uses
information advertised by routers, routers will need to be configured information advertised by routers, routers will need to be configured
by some other means. However, it is expected that routers will by some other means. However, it is expected that routers will
generate link-local addresses using the mechanism described in this generate link-local addresses using the mechanism described in this
document. In addition, routers are expected to successfully pass the document. In addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this document on Duplicate Address Detection procedure described in this document on
all addresses prior to assigning them to an interface. all addresses prior to assigning them to an interface.
skipping to change at page 7, line 46 skipping to change at page 7, line 11
some set of addresses, but the two sets of definitions must be some set of addresses, but the two sets of definitions must be
consistent. In many cases, the identifier will be derived from consistent. In many cases, the identifier will be derived from
the interface's link-layer address. the interface's link-layer address.
2.1 Requirements 2.1 Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. document, are to be interpreted as described in [RFC2119].
Note that this document intentionally limits the use of the keywords
to the protocol specification (Section 5).
3. DESIGN GOALS 3. DESIGN GOALS
Stateless autoconfiguration is designed with the following goals in Stateless autoconfiguration is designed with the following goals in
mind: mind:
o Manual configuration of individual machines before connecting them o Manual configuration of individual machines before connecting them
to the network should not be required. Consequently, a mechanism to the network should not be required. Consequently, a mechanism
is needed that allows a host to obtain or create unique addresses is needed that allows a host to obtain or create unique addresses
for each of its interfaces. Address autoconfiguration assumes for each of its interfaces. Address autoconfiguration assumes
that each interface can provide a unique identifier for that that each interface can provide a unique identifier for that
interface (i.e., an "interface identifier"). In the simplest interface (i.e., an "interface identifier"). In the simplest
case, an interface identifier consists of the interface's case, an interface identifier consists of the interface's
link-layer address. An interface identifier can be combined with link-layer address. An interface identifier can be combined with
a prefix to form an address. a prefix to form an address.
o Small sites consisting of a set of machines attached to a single o Small sites consisting of a set of machines attached to a single
link should not require the presence of a stateful server or link should not require the presence of a DHCPv6 server or router
router as a prerequisite for communicating. Plug-and-play as a prerequisite for communicating. Plug-and-play communication
communication is achieved through the use of link-local addresses. is achieved through the use of link-local addresses. Link-local
Link-local addresses have a well-known prefix that identifies the addresses have a well-known prefix that identifies the (single)
(single) shared link to which a set of nodes attach. A host forms shared link to which a set of nodes attach. A host forms a
a link-local address by appending its interface identifier to the link-local address by appending its interface identifier to the
link-local prefix. link-local prefix.
o A large site with multiple networks and routers should not require o A large site with multiple networks and routers should not require
the presence of a stateful address configuration server. In order the presence of a DHCPv6 server for address configuration. In
to generate global addresses, hosts must determine the prefixes order to generate global addresses, hosts must determine the
that identify the subnets to which they attach. Routers generate prefixes that identify the subnets to which they attach. Routers
periodic Router Advertisements that include options listing the generate periodic Router Advertisements that include options
set of active prefixes on a link. listing the set of active prefixes on a link.
o Address configuration should facilitate the graceful renumbering o Address configuration should facilitate the graceful renumbering
of a site's machines. For example, a site may wish to renumber of a site's machines. For example, a site may wish to renumber
all of its nodes when it switches to a new network service all of its nodes when it switches to a new network service
provider. Renumbering is achieved through the leasing of provider. Renumbering is achieved through the leasing of
addresses to interfaces and the assignment of multiple addresses addresses to interfaces and the assignment of multiple addresses
to the same interface. Lease lifetimes provide the mechanism to the same interface. Lease lifetimes provide the mechanism
through which a site phases out old prefixes. The assignment of through which a site phases out old prefixes. The assignment of
multiple addresses to an interface provides for a transition multiple addresses to an interface provides for a transition
period during which both a new address and the one being phased period during which both a new address and the one being phased
out work simultaneously. out work simultaneously.
o System administrators need the ability to specify whether
stateless autoconfiguration, stateful autoconfiguration, or both
are available. Router Advertisements include flags which can be
used to indicate which mechanisms are available.
4. PROTOCOL OVERVIEW 4. PROTOCOL OVERVIEW
This section provides an overview of the typical steps that take This section provides an overview of the typical steps that take
place when an interface autoconfigures itself. Autoconfiguration is place when an interface autoconfigures itself. Autoconfiguration is
performed only on multicast-capable links and begins when a performed only on multicast-capable links and begins when a
multicast-capable interface is enabled, e.g., during system startup. multicast-capable interface is enabled, e.g., during system startup.
Nodes (both hosts and routers) begin the autoconfiguration process by Nodes (both hosts and routers) begin the autoconfiguration process by
generating a link-local address for the interface. A link-local generating a link-local address for the interface. A link-local
address is formed by appending the interface's identifier to the address is formed by appending the interface's identifier to the
well-known link-local prefix. well-known link-local prefix [RFC3513].
Before the link-local address can be assigned to an interface and Before the link-local address can be assigned to an interface and
used, however, a node must attempt to verify that this "tentative" used, however, a node must attempt to verify that this "tentative"
address is not already in use by another node on the link. address is not already in use by another node on the link.
Specifically, it sends a Neighbor Solicitation message containing the Specifically, it sends a Neighbor Solicitation message containing the
tentative address as the target. If another node is already using tentative address as the target. If another node is already using
that address, it will return a Neighbor Advertisement saying so. If that address, it will return a Neighbor Advertisement saying so. If
another node is also attempting to use the same address, it will send another node is also attempting to use the same address, it will send
a Neighbor Solicitation for the target as well. The exact number of a Neighbor Solicitation for the target as well. The exact number of
times the Neighbor Solicitation is (re)transmitted and the delay time times the Neighbor Solicitation is (re)transmitted and the delay time
skipping to change at page 9, line 37 skipping to change at page 8, line 48
Once a node ascertains that its tentative link-local address is Once a node ascertains that its tentative link-local address is
unique, it assigns the address to the interface. At this point, the unique, it assigns the address to the interface. At this point, the
node has IP-level connectivity with neighboring nodes. The remaining node has IP-level connectivity with neighboring nodes. The remaining
autoconfiguration steps are performed only by hosts; the autoconfiguration steps are performed only by hosts; the
(auto)configuration of routers is beyond the scope of this document. (auto)configuration of routers is beyond the scope of this document.
The next phase of autoconfiguration involves obtaining a Router The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If routers Advertisement or determining that no routers are present. If routers
are present, they will send Router Advertisements that specify what are present, they will send Router Advertisements that specify what
sort of autoconfiguration a host can do. Note that stateful sort of autoconfiguration a host can do. Note that the DHCPv6
autoconfiguration may still be available even if no routers are service for address configuration may still be available even if no
present. routers are present.
Routers send Router Advertisements periodically, but the delay Routers send Router Advertisements periodically, but the delay
between successive advertisements will generally be longer than a between successive advertisements will generally be longer than a
host performing autoconfiguration will want to wait host performing autoconfiguration will want to wait
[I-D.ietf-ipv6-2461bis]. To obtain an advertisement quickly, a host [I-D.ietf-ipv6-2461bis]. To obtain an advertisement quickly, a host
sends one or more Router Solicitations to the all-routers multicast sends one or more Router Solicitations to the all-routers multicast
group. Router Advertisements contain two flags indicating what type group.
of stateful autoconfiguration (if any) is available. A "managed
address configuration (M)" flag indicates whether hosts can use
stateful autoconfiguration [RFC3315] to obtain addresses. An "other
stateful configuration (O)" flag indicates whether hosts can use
stateful autoconfiguration [RFC3736] to obtain additional information
(excluding addresses).
The details of how a host may use the M flag, including any use of
the "on" and "off" transitions for this flag, to control the use of
the stateful protocol for address assignment will be described in a
separate document. Similarly, the details of how a host may use the
O flag, including any use of the "on" and "off" transitions for this
flag, to control the use of the stateful protocol for getting other
configuration information will be described in a separate document.
However a host uses the M and O flags, and local configuration to
control autoconfiguration, the default setting will result in
received Router Advertisements being processed for stateless address
autoconfiguration.
Router Advertisements also contain zero or more Prefix Information Router Advertisements also contain zero or more Prefix Information
options that contain information used by stateless address options that contain information used by stateless address
autoconfiguration to generate global addresses. It should be noted autoconfiguration to generate global addresses. It should be noted
that the stateless and stateful address autoconfiguration fields in that a host may use both stateless address autoconfiguration and
Router Advertisements are processed independently of one another, and DHCPv6 simultaneously. One Prefix Information option field, the
a host may use both stateful and stateless address autoconfiguration "autonomous address-configuration flag", indicates whether or not the
simultaneously. One Prefix Information option field, the "autonomous option even applies to stateless autoconfiguration. If it does,
address-configuration flag", indicates whether or not the option even additional option fields contain a subnet prefix together with
applies to stateless autoconfiguration. If it does, additional lifetime values indicating how long addresses created from the prefix
option fields contain a subnet prefix together with lifetime values remain preferred and valid.
indicating how long addresses created from the prefix remain
preferred and valid.
Because routers generate Router Advertisements periodically, hosts Because routers generate Router Advertisements periodically, hosts
will continually receive new advertisements. Hosts process the will continually receive new advertisements. Hosts process the
information contained in each advertisement as described above, information contained in each advertisement as described above,
adding to and refreshing information received in previous adding to and refreshing information received in previous
advertisements. advertisements.
For safety, all addresses must be tested for uniqueness prior to By default, all addresses should be tested for uniqueness prior to
their assignment to an interface. The test should individually be their assignment to an interface for safety. The test should
performed on all addresses obtained manually, via stateless address individually be performed on all addresses obtained manually, via
autoconfiguration, or via stateful address autoconfiguration. To stateless address autoconfiguration, or via DHCPv6. To accommodate
accommodate sites that believe the overhead of performing Duplicate sites that believe the overhead of performing Duplicate Address
Address Detection outweighs its benefits, the use of Duplicate Detection outweighs its benefits, the use of Duplicate Address
Address Detection can be disabled through the administrative setting Detection can be disabled through the administrative setting of a
of a per-interface configuration flag. per-interface configuration flag.
To speed the autoconfiguration process, a host may generate its To speed the autoconfiguration process, a host may generate its
link-local address (and verify its uniqueness) in parallel with link-local address (and verify its uniqueness) in parallel with
waiting for a Router Advertisement. Because a router may delay waiting for a Router Advertisement. Because a router may delay
responding to a Router Solicitation for a few seconds, the total time responding to a Router Solicitation for a few seconds, the total time
needed to complete autoconfiguration can be significantly longer if needed to complete autoconfiguration can be significantly longer if
the two steps are done serially. the two steps are done serially.
4.1 Site Renumbering 4.1 Site Renumbering
skipping to change at page 13, line 42 skipping to change at page 12, line 32
carefully define the length so that link-local addresses can be carefully define the length so that link-local addresses can be
autoconfigured on the link. autoconfigured on the link.
A link-local address has an infinite preferred and valid lifetime; it A link-local address has an infinite preferred and valid lifetime; it
is never timed out. is never timed out.
5.4 Duplicate Address Detection 5.4 Duplicate Address Detection
Duplicate Address Detection MUST be performed on all unicast Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateful, stateless or manual whether they are obtained through stateless autoconfiguration,
configuration, with the following exceptions: DHCPv6, or manual configuration, with the following exceptions:
- An interface whose DupAddrDetectTransmits variable is set to zero - An interface whose DupAddrDetectTransmits variable is set to zero
does not perform Duplicate Address Detection, does not perform Duplicate Address Detection,
- Duplicate Address Detection MUST NOT be performed on anycast - Duplicate Address Detection MUST NOT be performed on anycast
addresses (note that anycast addresses cannot syntactically be addresses (note that anycast addresses cannot syntactically be
distinguished from unicast addresses), and distinguished from unicast addresses), and
- Each individual unicast address SHOULD be tested for uniqueness. - Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip Duplicate Address Detection for the link-local address and skip
the test for the global address using the same interface the test for the global address using the same interface
identifier as that of the link-local address. Whereas this identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of document does not invalidate such implementations, this kind of
"optimization" is NOT RECOMMENDED, and new implementations MUST "optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization. This optimization came from the NOT do that optimization. This optimization came from the
assumption that all of an interface's addresses are generated from assumption that all of an interface's addresses are generated from
the same identifier. However, the assumption does actually not the same identifier. However, the assumption does actually not
skipping to change at page 18, line 39 skipping to change at page 17, line 32
Note: as specified in Section 2, "IP" means "IPv6" in the above Note: as specified in Section 2, "IP" means "IPv6" in the above
description. While the background rationale about hardware address description. While the background rationale about hardware address
is independent of particular network protocols, its effect on other is independent of particular network protocols, its effect on other
protocols is beyond the scope of this document. protocols is beyond the scope of this document.
5.5 Creation of Global Addresses 5.5 Creation of Global Addresses
Global addresses are formed by appending an interface identifier to a Global addresses are formed by appending an interface identifier to a
prefix of appropriate length. Prefixes are obtained from Prefix prefix of appropriate length. Prefixes are obtained from Prefix
Information options contained in Router Advertisements. Creation of Information options contained in Router Advertisements. Creation of
global addresses and configuration of other parameters as described global addresses as described in this section SHOULD be locally
in this section SHOULD be locally configurable. However, the configurable. However, the processing described below MUST be
processing described below MUST be enabled by default. enabled by default.
5.5.1 Soliciting Router Advertisements 5.5.1 Soliciting Router Advertisements
Router Advertisements are sent periodically to the all-nodes Router Advertisements are sent periodically to the all-nodes
multicast address. To obtain an advertisement quickly, a host sends multicast address. To obtain an advertisement quickly, a host sends
out Router Solicitations as described in [I-D.ietf-ipv6-2461bis]. out Router Solicitations as described in [I-D.ietf-ipv6-2461bis].
5.5.2 Absence of Router Advertisements 5.5.2 Absence of Router Advertisements
Even if a link has no routers, stateful autoconfiguration to obtain Even if a link has no routers, the DHCPv6 service to obtain addresses
addresses and other configuration information may still be available, may still be available, and hosts may want to use the service. From
and hosts may want to use the mechanism. From the perspective of the perspective of autoconfiguration, a link has no routers if no
autoconfiguration, a link has no routers if no Router Advertisements Router Advertisements are received after having sent a small number
are received after having sent a small number of Router Solicitations of Router Solicitations as described in [I-D.ietf-ipv6-2461bis].
as described in [I-D.ietf-ipv6-2461bis].
Note that it is possible that there is no router on the link in this Note that it is possible that there is no router on the link in this
sense but there is a node that has the ability to forward packets. sense but there is a node that has the ability to forward packets.
In this case, the forwarding node's address must be manually In this case, the forwarding node's address must be manually
configured in hosts to be able to send packets off-link, since the configured in hosts to be able to send packets off-link, since the
only mechanism to configure the default router's address only mechanism to configure the default router's address
automatically is the one using Router Advertisements. automatically is the one using Router Advertisements.
5.5.3 Router Advertisement Processing 5.5.3 Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement: For each Prefix-Information option in the Router Advertisement:
a) If the Autonomous flag is not set, silently ignore the Prefix a) If the Autonomous flag is not set, silently ignore the Prefix
skipping to change at page 20, line 24 skipping to change at page 19, line 17
autoconfiguration. autoconfiguration.
Note that a future revision of the address architecture [RFC3513] Note that a future revision of the address architecture [RFC3513]
and a future link-type specific document, which will still be and a future link-type specific document, which will still be
consistent with each other, could potentially allow for an consistent with each other, could potentially allow for an
interface identifier of length other than the value defined in the interface identifier of length other than the value defined in the
current documents. Thus, an implementation should not assume a current documents. Thus, an implementation should not assume a
particular constant. Rather, it should expect any lengths of particular constant. Rather, it should expect any lengths of
interface identifiers. interface identifiers.
If an address is formed successfully, the host adds it to the list If an address is formed successfully and the address is not yet in
of addresses assigned to the interface, initializing its preferred the list, the host adds it to the list of addresses assigned to
and valid lifetime values from the Prefix Information option. the interface, initializing its preferred and valid lifetime
values from the Prefix Information option. Note that the check
against the prefix performed at the beginning of this step cannot
always detect the address conflict in the list. It could be
possible that an address already in the list, configured either
manually or by DHCPv6, happens to be identical to the newly
created address whereas such a case should be atypical.
e) If the advertised prefix is equal to the prefix of an address e) If the advertised prefix is equal to the prefix of an address
configured by stateless autoconfiguration in the list, the configured by stateless autoconfiguration in the list, the
preferred lifetime of the address is reset to the Preferred preferred lifetime of the address is reset to the Preferred
Lifetime in the received advertisement. The specific action to Lifetime in the received advertisement. The specific action to
perform for the valid lifetime of the address depends on the Valid perform for the valid lifetime of the address depends on the Valid
Lifetime in the received advertisement and the remaining time to Lifetime in the received advertisement and the remaining time to
the valid lifetime expiration of the previously autoconfigured the valid lifetime expiration of the previously autoconfigured
address. We call the remaining time "RemainingLifetime" in the address. We call the remaining time "RemainingLifetime" in the
following discussion: following discussion:
skipping to change at page 22, line 20 skipping to change at page 21, line 22
address selection including this case are described in [RFC3484] and address selection including this case are described in [RFC3484] and
beyond the scope of this document. beyond the scope of this document.
An address (and its association with an interface) becomes invalid An address (and its association with an interface) becomes invalid
when its valid lifetime expires. An invalid address MUST NOT be used when its valid lifetime expires. An invalid address MUST NOT be used
as a source address in outgoing communications and MUST NOT be as a source address in outgoing communications and MUST NOT be
recognized as a destination on a receiving interface. recognized as a destination on a receiving interface.
5.6 Configuration Consistency 5.6 Configuration Consistency
It is possible for hosts to obtain address information using both It is possible for hosts to obtain address information using both the
stateless and stateful protocols since both may be enabled at the stateless protocol and DHCPv6 since both may be enabled at the same
same time. It is also possible that the values of other time. It is also possible that the values of other configuration
configuration parameters such as MTU size and hop limit will be parameters such as MTU size and hop limit will be learned from both
learned from both Router Advertisements and the stateful Router Advertisements and DHCPv6. If the same configuration
autoconfiguration protocol. If the same configuration information is information is provided by multiple sources, the value of this
provided by multiple sources, the value of this information should be information should be consistent. However, it is not considered a
consistent. However, it is not considered a fatal error if fatal error if information received from multiple sources is
information received from multiple sources is inconsistent. Hosts inconsistent. Hosts accept the union of all information received via
accept the union of all information received via the stateless and the stateless protocol and DHCPv6. If inconsistent information is
stateful protocols. If inconsistent information is learned from learned from different sources, the most recently obtained values
different sources, the most recently obtained values always have always have precedence over information learned earlier.
precedence over information learned earlier.
5.7 Retaining Configured Addresses for Stability 5.7 Retaining Configured Addresses for Stability
An implementation that has stable storage may want to retain An implementation that has stable storage may want to retain
addresses in the storage when the addresses were acquired using addresses in the storage when the addresses were acquired using
stateless address autoconfiguration. Assuming the lifetimes used are stateless address autoconfiguration. Assuming the lifetimes used are
reasonable, this technique implies that a temporary outage (less than reasonable, this technique implies that a temporary outage (less than
the valid lifetime) of a router will never result in the node losing the valid lifetime) of a router will never result in the node losing
its global address even if the node were to reboot. When this its global address even if the node were to reboot. When this
technique is used, it should also be noted that the expiration times technique is used, it should also be noted that the expiration times
skipping to change at page 23, line 47 skipping to change at page 22, line 47
of the "0 Lifetime Prefix Advertisement" denial of service attack of the "0 Lifetime Prefix Advertisement" denial of service attack
vulnerability; this document incorporates changes that address this vulnerability; this document incorporates changes that address this
vulnerability. vulnerability.
A number of people have contributed to identifying issues on a A number of people have contributed to identifying issues on a
previous version of this document and to proposing resolutions to the previous version of this document and to proposing resolutions to the
issues, on which this version is based. In addition to those listed issues, on which this version is based. In addition to those listed
above, the contributors include Jari Arkko, Brian E Carpenter, above, the contributors include Jari Arkko, Brian E Carpenter,
Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro itojun Hagino, Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro itojun Hagino,
Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku
Savela, and Pekka Savola. Savela, Pekka Savola, and Margaret Wasserman.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998. 2402, November 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[I-D.ietf-ipv6-2461bis] [I-D.ietf-ipv6-2461bis]
Narten, T., Nordmark, E., Simpson, W. and H. Soliman, Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. draft-ietf-ipv6-2461bis-01 (work in progress), October
2004.
Note: this reference is expected to be published in Note: this reference is expected to be published in
parallel with the referring document, both of which will parallel with the referring document, both of which will
be recycled as a draft standard. Upon publication the be recycled as a draft standard. Upon publication the
reference will be updated and this note will be removed. reference will be updated and this note will be removed.
9.2 Informative References 9.2 Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[I-D.ietf-send-cga] [I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)", Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004. draft-ietf-send-cga-06 (work in progress), April 2004.
skipping to change at page 28, line 15 skipping to change at page 27, line 9
o Clarified that on failure of Duplicate Address Detection, IP o Clarified that on failure of Duplicate Address Detection, IP
network operation should be disabled and that the rule should network operation should be disabled and that the rule should
apply when the hardware address is supposed to be unique. apply when the hardware address is supposed to be unique.
Major clarifications: Major clarifications:
o Clarified how the length of interface identifiers should be o Clarified how the length of interface identifiers should be
determined, described the relationship with the prefix length determined, described the relationship with the prefix length
advertised in Router Advertisements, and avoided using a advertised in Router Advertisements, and avoided using a
particular length hard-coded in this document. particular length hard-coded in this document.
o Clarified that the "stateful" protocols for address configuration o Removed the text regarding the M and O flags, considering the
and other information configuration are RFC 3315 and RFC 3736, maturity of implementations and operational experiences.
respectively. ManagedFlag and OtherConfigFlag were removed accordingly. (Note
o Clarified the semantics of the M and O flags based on the latest that this change does not mean the use of these flags is
standard and operational status. In particular, clarified that deprecated.)
these flags show the availability of the stateful protocol instead o Avoided the wording of "stateful configuration", which is known to
of a trigger to invoke the stateful protocol. ManagedFlag and be quite confusing, and simply used "DHCPv6" wherever appropriate.
OtherConfigFlag, which were implementation-internal variables,
were removed accordingly.
o Recommended to perform Duplicate Address Detection for all unicast o Recommended to perform Duplicate Address Detection for all unicast
addresses more strongly, considering a variety of different addresses more strongly, considering a variety of different
interface identifiers, while keeping care of existing interface identifiers, while keeping care of existing
implementations. implementations.
o Clarified wording in Section 5.5.4 to make clear that a deprecated o Clarified wording in Section 5.5.4 to make clear that a deprecated
address specified by an application should be used for any address specified by an application should be used for any
communication. communication.
o Clarified the prefix check described in Section 5.5.3 using more
appropriate terms and that the check is done against the prefixes
of addresses configured by stateless autoconfiguration.
o Revised the Security Considerations section with a reference to o Revised the Security Considerations section with a reference to
RFC 3756 and a note that the use of IP security is not always RFC 3756 and a note that the use of IP security is not always
feasible. feasible.
o Added a note when an implementation uses stable storage for o Added a note when an implementation uses stable storage for
autoconfigured addresses. autoconfigured addresses.
Other miscellaneous clarifications: Other miscellaneous clarifications:
o Removed references to site-local and revised wording around the o Removed references to site-local and revised wording around the
keyword. keyword.
skipping to change at page 31, line 4 skipping to change at page 29, line 46
Changes since draft-ietf-ipv6-rfc2462bis-05.txt are: Changes since draft-ietf-ipv6-rfc2462bis-05.txt are:
o Clarified the role of RFC 3736 in the abstract. o Clarified the role of RFC 3736 in the abstract.
o Clarified that the default configuration method is the one o Clarified that the default configuration method is the one
described in this document. described in this document.
o Changed the reference for the Neighbor Discovery protocol to o Changed the reference for the Neighbor Discovery protocol to
[I-D.ietf-ipv6-2461bis]. [I-D.ietf-ipv6-2461bis].
o Reorganized the conditions at the beginning of Section 5.4 with an o Reorganized the conditions at the beginning of Section 5.4 with an
additional note to avoid confusion. additional note to avoid confusion.
o Clarified the role of the link-local prefix in Section 5.3. o Clarified the role of the link-local prefix in Section 5.3.
o Added a reference to RFC 3810 as well as to RFC 2710. o Added a reference to RFC 3810 as well as to RFC 2710.
o Clarified the MLD issues a bit more. o Clarified the MLD issues a bit more.
o Replaced "multicast interface" with "multicast-capable interface". o Replaced "multicast interface" with "multicast-capable interface".
o Clarified that the autoconfiguration protocol would basically be o Clarified that the autoconfiguration protocol would basically be
used on all types of links in line with the Neighbor Discovery used on all types of links in line with the Neighbor Discovery
protocol. protocol.
Changes since draft-ietf-ipv6-rfc2462bis-06.txt are:
o Removed text mentioning the M and O flags to avoid having a stale
reference.
o Noted that the host should make sure that an autoconfigured global
address is not yet in the address list before adding it to the
list.
o Replaced "stateful configuration" with "DHCPv6".
o Added a reference to [RFC3513] from Section 4.
o Changed wording about Duplicate Address Detection in Section 4 to
avoid confusion on the requirement level.
o Clarified that the use of the RFC2119 keywords is intentionally
limited to the protocol specification (Section 5).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/