rfc1971.txt

RFC 的详细文档！

   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