rfc2462.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/5 页


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]