draft-ietf-ipv6-rfc2462bis-03.txt   draft-ietf-ipv6-rfc2462bis-04.txt 
IETF IPv6 Working Group S. Thomson IETF IPv6 Working Group S. Thomson
Internet-Draft Cisco Internet-Draft Cisco
Expires: January 17, 2005 T. Narten Expires: February 8, 2005 T. Narten
IBM IBM
T. Jinmei T. Jinmei
Toshiba Toshiba
July 19, 2004 August 10, 2004
IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration
draft-ietf-ipv6-rfc2462bis-03.txt draft-ietf-ipv6-rfc2462bis-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005. This Internet-Draft will expire on February 8, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its process includes creating a link-local address and verifying its
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11
5.1 Node Configuration Variables . . . . . . . . . . . . . . . 11 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 11
5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12
5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12
5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13
5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14
5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14
5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16
5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17
5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17
5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 17 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18
5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18
5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18
5.5.3 Router Advertisement Processing . . . . . . . . . . . 18 5.5.3 Router Advertisement Processing . . . . . . . . . . . 18
5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20
5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21
5.7 Retaining Configured Addresses for Stability . . . . . . . 22 5.7 Retaining Configured Addresses for Stability . . . . . . . 22
6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22
7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 22 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25
B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26
C. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 26 C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29 D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 31
1. INTRODUCTION 1. INTRODUCTION
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6 (IPv6). The autoconfigure its interfaces in IP version 6 (IPv6). The
autoconfiguration process includes creating a link-local address and autoconfiguration process includes creating a link-local address and
verifying its uniqueness on a link, determining what information can verifying its uniqueness on a link, determining what information can
be autoconfigured (addresses, other information, or both), and in the be autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they can be obtained through the stateless case of addresses, whether they can be obtained through the stateless
mechanism, the stateful mechanism, or both. This document defines mechanism, the stateful mechanism, or both. This document defines
skipping to change at page 15, line 41 skipping to change at page 15, line 41
advertisement. advertisement.
Note that the delay for joining the multicast address implicitly Note that the delay for joining the multicast address implicitly
means delaying transmission of the corresponding Multicast Listener means delaying transmission of the corresponding Multicast Listener
Discovery (MLD) report message [RFC2710]. Since [RFC2710] does not Discovery (MLD) report message [RFC2710]. Since [RFC2710] does not
request a random delay to avoid race conditions, just delaying request a random delay to avoid race conditions, just delaying
Neighbor Solicitation would cause congestion by the MLD report Neighbor Solicitation would cause congestion by the MLD report
messages. The congestion would then prevent MLD-snooping switches messages. The congestion would then prevent MLD-snooping switches
from working correctly, and, as a result, prevent Duplicate Address from working correctly, and, as a result, prevent Duplicate Address
Detection from working. The requirement to include the delay for the Detection from working. The requirement to include the delay for the
MLD report in this case avoids this scenario. MLD report in this case avoids this scenario. [RFC3590] also talks
about some interaction issues between Duplicate Address Detection and
MLD.
In order to improve the robustness of the Duplicate Address Detection In order to improve the robustness of the Duplicate Address Detection
algorithm, an interface MUST receive and process datagrams sent to algorithm, an interface MUST receive and process datagrams sent to
the all-nodes multicast address or solicited-node multicast address the all-nodes multicast address or solicited-node multicast address
of the tentative address while the delaying period. This does not of the tentative address while the delaying period. This does not
necessarily conflict with the requirement that joining the multicast necessarily conflict with the requirement that joining the multicast
group be delayed. In fact, in some cases it is possible for a node group be delayed. In fact, in some cases it is possible for a node
to start listening to the group during the delay period before MLD to start listening to the group during the delay period before MLD
report transmission. It should be noted, however, that in some report transmission. It should be noted, however, that in some
link-layer environments, particularly with MLD-snooping switches, no link-layer environments, particularly with MLD-snooping switches, no
skipping to change at page 17, line 45 skipping to change at page 17, line 46
harder to diagnose than just disabling network operation on the harder to diagnose than just disabling network operation on the
interface; the user will see a partially working network where some interface; the user will see a partially working network where some
things work, and other things will not. things work, and other things will not.
On the other hand, if the duplicate link-local address is not formed On the other hand, if the duplicate link-local address is not formed
from an interface identifier based on the hardware address which is from an interface identifier based on the hardware address which is
supposed to be uniquely assigned, IP operation on the interface MAY supposed to be uniquely assigned, IP operation on the interface MAY
be continued. be continued.
Note: as specified in Section 2, "IP" means "IPv6" in the above Note: as specified in Section 2, "IP" means "IPv6" in the above
description. While the background rationale about the hardware description. While the background rationale about hardware address
address is independent of particular network protocols, the effect on is independent of particular network protocols, its effect on other
other protocols is beyond the scope of this document. protocols is beyond the scope of this document.
5.5 Creation of Global Addresses 5.5 Creation of Global Addresses
Global addresses are formed by appending an interface identifier to a Global addresses are formed by appending an interface identifier to a
prefix of appropriate length. Prefixes are obtained from Prefix prefix of appropriate length. Prefixes are obtained from Prefix
Information options contained in Router Advertisements. Creation of Information options contained in Router Advertisements. Creation of
global addresses and configuration of other parameters as described global addresses and configuration of other parameters as described
in this section SHOULD be locally configurable. However, the in this section SHOULD be locally configurable. However, the
processing described below MUST be enabled by default. processing described below MUST be enabled by default.
skipping to change at page 18, line 29 skipping to change at page 18, line 34
and hosts may want to use the mechanism. From the perspective of and hosts may want to use the mechanism. From the perspective of
autoconfiguration, a link has no routers if no Router Advertisements autoconfiguration, a link has no routers if no Router Advertisements
are received after having sent a small number of Router Solicitations are received after having sent a small number of Router Solicitations
as described in [RFC2461]. as described in [RFC2461].
Note that it is possible that there is no router on the link in this Note that it is possible that there is no router on the link in this
sense but there is a node that has the ability to forward packets. sense but there is a node that has the ability to forward packets.
In this case, the forwarding node's address must be manually In this case, the forwarding node's address must be manually
configured in hosts to be able to send packets off-link, since the configured in hosts to be able to send packets off-link, since the
only mechanism to configure the default router's address only mechanism to configure the default router's address
automatically is the one using router advertisements. automatically is the one using Router Advertisements.
5.5.3 Router Advertisement Processing 5.5.3 Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement: For each Prefix-Information option in the Router Advertisement:
a) If the Autonomous flag is not set, silently ignore the Prefix a) If the Autonomous flag is not set, silently ignore the Prefix
Information option. Information option.
b) If the prefix is the link-local prefix, silently ignore the b) If the prefix is the link-local prefix, silently ignore the
Prefix Information option. Prefix Information option.
skipping to change at line 997 skipping to change at page 22, line 9
It is possible for hosts to obtain address information using both It is possible for hosts to obtain address information using both
stateless and stateful protocols since both may be enabled at the stateless and stateful protocols since both may be enabled at the
same time. It is also possible that the values of other same time. It is also possible that the values of other
configuration parameters such as MTU size and hop limit will be configuration parameters such as MTU size and hop limit will be
learned from both Router Advertisements and the stateful learned from both Router Advertisements and the stateful
autoconfiguration protocol. If the same configuration information is autoconfiguration protocol. If the same configuration information is
provided by multiple sources, the value of this information should be provided by multiple sources, the value of this information should be
consistent. However, it is not considered a fatal error if consistent. However, it is not considered a fatal error if
information received from multiple sources is inconsistent. Hosts information received from multiple sources is inconsistent. Hosts
accept the union of all information received via the stateless and accept the union of all information received via the stateless and
stateful protocols. If inconsistent info stateful protocols. If inconsistent information is learned from
different sources, the most recently obtained values always have
precedence over information learned earlier.
5.7 Retaining Configured Addresses for Stability
An implementation that has stable storage may want to retain
addresses in the storage when the addresses were acquired using
stateless address autoconfiguration. Assuming the lifetimes used are
reasonable, this technique implies that a temporary outage (less than
the valid lifetime) of a router will never result in the node losing
its global address even if the node were to reboot. When this
technique is used, it should also be noted that the expiration times
of the preferred and valid lifetimes must be retained, in order to
prevent the use of an address after it has become deprecated or
invalid.
Further details on this kind of extension are beyond the scope of
this document.
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 stateless address autoconfiguration and Duplicate Address
Detection opens up the possibility of several denial of service
attacks. For example, any node can respond to Neighbor Solicitations
for a tentative address, causing the other node to reject the address
as a duplicate. A separate document [RFC3756] discusses details
about these attacks. These attacks can be addressed by requiring
that Neighbor Discovery packets be authenticated with IP security
[RFC2402]. However, it should be noted that [RFC3756] points out the
use of IP security is not always feasible depending on network
environments.
7. IANA CONSIDERATIONS
This document has no actions for IANA.
8. Acknowledgements
The authors would like to thank the members of both the IPNG (which
is now IPV6) and ADDRCONF working groups for their input. In
particular, thanks to Jim Bound, Steve Deering, Richard Draves, and
Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG
of the "0 Lifetime Prefix Advertisement" denial of service attack
vulnerability; this document incorporates changes that address this
vulnerability.
A number of people have contributed to identifying issues on a
previous version of this document and to proposing resolutions to the
issues, on which this version is based. In addition to those listed
above, the contributors include Jari Arkko, Brian E Carpenter,
Gregory Daley, Ralph Droms, Jun-ichiro itojun Hagino, Christian
Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Savela, and
Pekka Savola.
9. References
9.1 Normative References
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
9.2 Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September
2003.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[IEEE802.11]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", ANSI/IEEE STd
802.11, August 1999.
Authors' Addresses
Susan Thomson
Cisco Systems
EMail: sethomso@cisco.com
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
Phone: +1 919-254-7798
EMail: narten@us.ibm.com
Tatuya Jinmei
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
Phone: +81 44-549-2230
EMail: jinmei@isl.rdc.toshiba.co.jp
Appendix A. 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 identifier 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. There is even a link-layer
specification that requires to discard any such packets [IEEE802.11].
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 by temporarily disabling the software
suppression of loopbacks while a node performs Duplicate Address
Detection, if it is possible to disable the suppression.
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 interface's. It should also be noted that a link-layer
specification can conflict with the condition necessary to make
Duplicate Address Detection work.
Appendix B. CHANGES SINCE RFC 1971
o Changed document to use term "interface identifier" rather than
"interface token" for consistency with other IPv6 documents.
o Clarified definition of deprecated address to make clear it is OK
to continue sending to or from deprecated addresses.
o Added rules to Section 5.5.3 Router Advertisement processing to
address potential denial-of-service attack when prefixes are
advertised with very short Lifetimes.
o Clarified wording in Section 5.5.4 to make clear that all upper
layer protocols must process (i.e., send and receive) packets sent
to deprecated addresses.
Appendix C. CHANGES SINCE RFC 2462
Major changes that can affect existing implementations:
o Specified that a node performing Duplicate Address Detection delay
joining the solicited-node multicast group, not just delay sending
Neighbor Solicitations, explaining the detailed reason.
o Added a requirement for a random delay before sending Neighbor
Solicitations for Duplicate Address Detection if the address being
checked is configured by a multicasted Router Advertisements.
o Clarified that on failure of Duplicate Address Detection, IP
network operation should be disabled and that the rule should
apply when the hardware address is supposed to be unique.
Major clarifications:
o Clarified how the length of interface identifiers should be
determined, described the relationship with the prefix length
advertised in Router Advertisements, and avoided using a
particular length hard-coded in this document.
o Clarified that the "stateful" protocols for address configuration
and other information configuration are RFC 3315 and RFC 3736,
respectively.
o Clarified the semantics of the M and O flags based on the latest
standard and operational status. In particular, clarified that
these flags show the availability of the stateful protocol instead
of a trigger to invoke the stateful protocol. ManagedFlag and
OtherConfigFlag, which were implementation-internal variables,
were removed accordingly.
o Recommended to perform Duplicate Address Detection for all unicast
addresses more strongly, considering a variety of different
interface identifiers, while keeping care of existing
implementations.
o Clarified wording in Section 5.5.4 to make clear that a deprecated
address specified by an application should be used for any
communication.
o Revised the Security Considerations section with a reference to
RFC 3756 and a note that the use of IP security is not always
feasible.
o Added a note when an implementation uses stable storage for
autoconfigured addresses.
Other miscellaneous clarifications:
o Removed references to site-local and revised wording around the
keyword.
o Removed redundant code in denial of service protection in Section
5.5.3.
o Clarified that a unicasted Neighbor Solicitation or Advertisement
should be discarded while performing Duplicate Address Detection.
Appendix D. CHANGE HISTORY
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.]
Changes in draft-ietf-ipv6-rfc2462bis-00.txt since RFC 2462 are:
o Fixed a typo in Section 2.
o Updated references and categorized them into normative and
informative ones.
o Removed redundant code in denial of service protection in Section
5.5.3.
o Clarified that a unicasted NS or NA should be discarded while
performing Duplicate Address Detection.
o Replaced the word "StoredLifetime" with "RemainingLifetime" with a
precise definition to avoid confusion.
o Removed references to site-local and revised wording around the
keyword.
o Added a note about source address selection with regards to
deprecated vs insufficient-scope addresses, etc. Added a
reference to RFC 3484 for further details.
o Clarified what "new communication" means in Section 5.5.4.
o Added a new subsection (5.7) to mention the possibility to use
stable storage to retain configured addresses for stability.
o Revised the Security Considerations section with a reference to
RFC 3756 and a note that the use of IP security is not always
feasible.
o Added a note with a reference in Appendix A about the case where a
link-layer filtering conflicts with a condition to make Duplicate
Address Detection work correctly.
o Specified that a node performing Duplicate Address Detection delay
joining the solicited-node multicast group, not just delay sending
Neighbor Solicitations, explaining the detailed reason.
o Clarified the reason why the interface should be disabled after an
address duplicate is detected. Also clarified that the interface
may continue to be used if the interface identifier is not based
on the hardware address.
o Clarified that the preferred lifetime for an existing configured
address is always reset to the advertised value by Router
Advertisement.
o Updated the description of interface identifier considering the
latest format.
Changes since draft-ietf-ipv6-rfc2462bis-00.txt are:
o Clarified how the length of interface identifiers should be
determined, described the relationship with the prefix length
advertised in Router Advertisements, and avoided using a
particular length hard-coded in this document.
o Added a note when an implementation uses stable storage for
autoconfigured addresses.
o Resolved conflict with the Multicast Listener Discovery
specification about random delay for the first packet from the
host.
o Clarified the semantics of the M and O flags based on the latest
standard and operational status. In particular, clarified that
these flags show the availability of the stateful protocol instead
of a trigger to invoke the stateful protocol. ManagedFlag and
OtherConfigFlag, which were implementation-internal variables,
were removed accordingly.
o Recommended to perform Duplicate Address Detection for all unicast
addresses more strongly, considering a variety of different
interface identifiers, while keeping care of existing
implementations.
o Added a requirement for a random delay before sending Neighbor
Solicitations for Duplicate Address Detection if the address being
checked is configured by a multicasted Router Advertisements.
o Clarified that the prefix comparison in Section 5.5.3 is based on
exact match. Also clarified the comparison described in this
document concentrates on addresses configured by the stateless
mechanism.
o Revisited the author list.
o Added IANA Considerations Section.
Changes since draft-ietf-ipv6-rfc2462bis-02.txt are:
o Updated the I-D / IPR boilerplate to the latest ones. Applied
other editorial changes to conform to I-D nits.
o Clarified that it is IP network operation that should be disabled
on failure of Duplicate Address Detection, and that the rule
should apply when the hardware address is supposed to be unique.
o Changed the reference on the algorithm of computing solicited-node
multicast addresses to [RFC3513].
o Made the intent clearer in the clarification that unicasted NS or
NA should be discarded during Duplicate Address Detection.
Changes since draft-ietf-ipv6-rfc2462bis-03.txt are:
o Added an informative reference to [RFC3590].
o Summarized major changes since RFC 2462 to prepare for
publication.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/