rfc2462.txt

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

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