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