rfc2462.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,404 行 · 第 1/4 页

      - 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