rfc1971.txt

RFC 的详细文档！

    Information option.

 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 advertised prefix matches the prefix of an autoconfigured
    address (i.e., obtained via stateless or stateful address
    autoconfiguration) in the list of addresses associated with the
    interface, set the preferred timer to that of the option's preferred
    lifetime, and set the valid lifetime to that of the option's valid
    lifetime.

 e) If the prefix advertised does not match the prefix of an address
    already in the list, then form an address (and add it to the list)
    by appending the interface token to the prefix as follows:

    |            128 - N bits               |       N bits           |
    +---------------------------------------+------------------------+
    |            link prefix                |   interface token      |
    +----------------------------------------------------------------+


    If the sum of the prefix length and interface token 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 tokens for that link type.

    In those cases where a site requires the use of longer prefixes than
    can be accommodated by the interface token, stateful
    autoconfiguration can be used.




Thomson & Narten            Standards Track                    [Page 18]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


    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.

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.  The IP layer 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.

   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.

   Note that if a Prefix Information option is received with a preferred
   lifetime of zero, any addresses generated from that prefix are
   immediately deprecated. Similarly, if both the advertised deprecated
   and valid lifetimes are zero, any addresses generated from that
   prefix become invalid immediately.

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
   stateful protocols. If inconsistent information is learned from
   different sources, the most recently obtained values always have
   precedence over information learned earlier.

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



Thomson & Narten            Standards Track                    [Page 19]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


   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 [RFC1826].

REFERENCES

   [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August
             1995.

   [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6
             Packets over Ethernet Networks", RFC 1972, August 1996.

   [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 1884, December 1995.

   [DHCPv6]  Work in Progress.

   [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.

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, and Erik Nordmark.













Thomson & Narten            Standards Track                    [Page 20]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


AUTHORS' ADDRESSES

   Susan Thomson
   Bellcore
   445 South Street
   Morristown, NJ 07960
   USA

   Phone: [phone]
   EMail: [e-mail]


   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: [phone]
   EMail: [e-mail]































Thomson & Narten            Standards Track                    [Page 21]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


APPENDIX: 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 token 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 particular problem can be avoided



Thomson & Narten            Standards Track                    [Page 22]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


     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]