diff options
Diffstat (limited to 'doc/rfc/rfc2462.txt')
| -rw-r--r-- | doc/rfc/rfc2462.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2462.txt b/doc/rfc/rfc2462.txt new file mode 100644 index 0000000..7fe9d63 --- /dev/null +++ b/doc/rfc/rfc2462.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 2462 Bellcore +Obsoletes: 1971 T. Narten +Category: Standards Track IBM + December 1998 + + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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........................................ 6 + 3. DESIGN GOALS............................................. 7 + 4. PROTOCOL OVERVIEW........................................ 8 + 4.1. Site Renumbering.................................... 10 + 5. PROTOCOL SPECIFICATION................................... 10 + 5.1. Node Configuration Variables........................ 11 + 5.2. Autoconfiguration-Related Variables................. 11 + 5.3. Creation of Link-Local Addresses.................... 12 + + + +Thomson & Narten Standards Track [Page 1] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 5.4. Duplicate Address Detection......................... 13 + 5.4.1. Message Validation............................. 14 + 5.4.2. Sending Neighbor Solicitation Messages......... 14 + 5.4.3. Receiving Neighbor Solicitation Messages....... 15 + 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......... 16 + 5.5.1. Soliciting Router Advertisements............... 16 + 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 + 6. SECURITY CONSIDERATIONS.................................. 20 + 7. References............................................... 20 + 8. Acknowledgements and Authors' Addresses.................. 21 + 9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS + DETECTION.............................................. 22 + 10. APPENDIX B: CHANGES SINCE RFC 1971....................... 24 + 11. Full Copyright Statement................................. 25 + +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 identifier" 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. + + + + +Thomson & Narten Standards Track [Page 2] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 + can use stateless autoconfiguration to configure its own addresses, + but use stateful autoconfiguration to obtain other information. + Stateful autoconfiguration for IPv6 is the subject of future work + [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. + + + + + + +Thomson & Narten Standards Track [Page 3] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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. + + 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 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. + + + +Thomson & Narten Standards Track [Page 4] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + + 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 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. + + 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. + + + + + +Thomson & Narten Standards Track [Page 5] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 from or 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 to their intended recipients. + + 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 identifier - a link-dependent identifier for an interface + that is (at least) unique per link [ADDR-ARCH]. Stateless + address autoconfiguration combines an interface identifier with + a prefix to form an address. From address autoconfiguration's + perspective, an interface identifier is a bit string of known + length. The exact length of an interface identifier 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 identifier will be the same as the interface's link- + layer address. + +2.1. Requirements + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [KEYWORDS]. + + + + +Thomson & Narten Standards Track [Page 6] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +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 + identifier"). In the simplest case, an interface identifier + consists of the interface's link-layer address. An interface + identifier 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 identifier 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 7] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +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 identifier 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 + identifier that overrides the default identifier in such a way that + the autoconfiguration mechanism can then be applied using the new + (presumably unique) interface identifier. 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 8] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 identifier. Thus, if a node has already verified the + uniqueness of a link-local address, additional addresses created from + the same interface identifier 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 9] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + +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 10] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +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: + + + + + + +Thomson & Narten Standards Track [Page 11] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 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 is to be obtained using the + stateful autoconfiguration mechanism. It starts + out in a FALSE state. + + In addition, when the value of the ManagedFlag is + TRUE, the value of OtherConfigFlag is implicitely + TRUE as well. It is not a valid configuration for + a host to use stateful address autoconfiguration + to request addresses only, without also accepting + other configuration + information. + + 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. + + + + + +Thomson & Narten Standards Track [Page 12] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + A link-local address is formed by prepending the well-known link- + local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the + interface identifier. If the interface identifier has a length of N + bits, the interface identifier replaces the right-most N zero bits of + the link-local prefix. If the interface identifier is more than 118 + bits in length, autoconfiguration fails and manual configuration is + required. Note that interface identifiers will typically be 64-bits + long and based on EUI-64 identifiers as described in [ADDR-ARCH]. + + A link-local address has an infinite preferred and valid lifetime; it + is never timed + out. + +5.4. Duplicate Address Detection + + Duplicate Address Detection is performed on unicast addresses prior + to assigning them to an interface whose DupAddrDetectTransmits + variable is greater than zero. Duplicate Address Detection MUST take + place on all unicast addresses, regardless of whether they are + obtained through stateful, stateless or manual configuration, with + the exception of the following cases: + + - 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 + identifier, assuming that subnet prefixes are assigned correctly + (i.e., if all of an interface's addresses are generated from the + same identifier, either all addresses or none of them will be + duplicates). Thus, for a set of addresses formed from the same + interface identifier, it is sufficient to check that the link- + local address generated from the identifier is unique on the + link. In such cases, the link-local address MUST be tested for + uniqueness, and if no duplicate address is detected, an + implementation MAY choose to skip Duplicate Address Detection + for additional addresses derived from the same interface + identifier. + + 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 identifier, a new identifier 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 + + + +Thomson & Narten Standards Track [Page 13] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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, + 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, + + + +Thomson & Narten Standards Track [Page 14] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 + 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: + + + + + +Thomson & Narten Standards Track [Page 15] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + - 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 + formed from an interface identifier, 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 + identifier 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]. + + + +Thomson & Narten Standards Track [Page 16] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + +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, and the host is not already running the stateful address + autoconfiguration protocol, the host should invoke the stateful + address autoconfiguration protocol, requesting both address + information and other information. If the value of the ManagedFlag + changes from TRUE to FALSE, the host should continue running the + stateful address autoconfiguration, i.e., the change in the value of + the ManagedFlag has no effect. 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 + information (excluding addresses if ManagedFlag is set to FALSE). If + the value of the OtherConfigFlag changes from TRUE to FALSE, the host + should continue running the stateful address autoconfiguration + protocol, i.e., the change in the value of OtherConfigFlag has no + effect. 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. + + + + +Thomson & Narten Standards Track [Page 17] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + 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 prefix advertised does not match the prefix of an address + already in the list, and the Valid Lifetime is not 0, form an + address (and add it to the list) by combining the advertised + prefix with the link's interface identifier as follows: + + | 128 - N bits | N bits | + +---------------------------------------+------------------------+ + | link prefix | interface identifier | + +----------------------------------------------------------------+ + + + If the sum of the prefix length and interface identifier 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 + identifiers for that link type. Note that interface identifiers + will typically be 64-bits long and based on EUI-64 identifiers as + described in [ADDR-ARCH]. + + 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. + + e) If the advertised prefix matches the prefix of an autoconfigured + address (i.e., one obtained via stateless or stateful address + autoconfiguration) in the list of addresses associated with the + interface, the specific action to perform depends on the Valid + Lifetime in the received advertisement and the Lifetime + associated with the previously autoconfigured address (which we + call StoredLifetime in the discussion that follows): + + 1) If the received Lifetime is greater than 2 hours or greater + than StoredLifetime, update the stored Lifetime of the + corresponding address. + + 2) If the StoredLifetime is less than or equal to 2 hours and the + received Lifetime is less than or equal to StoredLifetime, + ignore the prefix, unless the Router Advertisement from which + + + +Thomson & Narten Standards Track [Page 18] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + this Prefix Information option was obtained has been + authenticated (e.g., via IPSec [RFC2402]). If the Router + Advertisment was authenticated, the StoredLifetime should be + set to the Lifetime in the received option. + + 3) Otherwise, reset the stored Lifetime in the corresponding + address to two hours. + + The above rules address a specific denial of service attack in + which a bogus advertisement could contain prefixes with very + small Valid Lifetimes. Without the above rules, a single + unauthenticated advertisement containing bogus Prefix Information + options with short Lifetimes could cause all of a node's + addresses to expire prematurely. The above rules insure that + legitimate advertisements (which are sent periodically) will + "cancel" the short lifetimes before they actually take effect. + +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. IP and higher layers (e.g., TCP, UDP) 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, and the facility MUST be disabled by + default. + + 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. + +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 + + + +Thomson & Narten Standards Track [Page 19] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + stateful protocols. If inconsistent information is learned different + sources, the most recently obtained values always have precedence + over information learned earlier. + +6. 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 + 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 [RFC2402]. + +7. References + + [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", + RFC 2402, November 1998. + + [IPv6-ETHER] Crawford, M., "A Method for the Transmission of + IPv6 Packets over Ethernet Networks", RFC 2464, + December 1998. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March + 1997. + + [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 2373, July 1998 + + [DHCPv6] Bound, J. and C. Perkins, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", Work in Progress. + + + + + + +Thomson & Narten Standards Track [Page 20] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + +8. 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, Richard Draves, and Erik Nordmark. Thanks also + goes to John Gilmore for alerting the WG of the "0 Lifetime Prefix + Advertisement" denial of service attack vulnerability; this document + incorporates changes that address this vulnerability. + +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@raleigh.ibm.com + + + + + + + + + + + + + + + + + + +Thomson & Narten Standards Track [Page 21] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +9. APPENDIX A: 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 identifier 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 + + + +Thomson & Narten Standards Track [Page 22] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + + particular problem can be avoided 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] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +10. APPENDIX B: CHANGES SINCE RFC 1971 + + o Changed document to use term "interface identifier" rather than + "interface token" for consistency with other IPv6 documents. + + o Clarified definition of deprecated address to make clear it is OK + to continue sending to or from deprecated addresses. + + o Reworded section 5.4 for clarity (no substantive change). + + o Added rules to Section 5.5.3 Router Advertisement processing to + address potential denial-of-service attack when prefixes are + advertised with very short Lifetimes. + + o Clarified wording in Section 5.5.4 to make clear that all upper + layer protocols must process (i.e., send and receive) packets sent + to deprecated addresses. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Narten Standards Track [Page 24] + +RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Narten Standards Track [Page 25] + |