draft-ietf-ipv6-2461bis-04.txt   draft-ietf-ipv6-2461bis-05.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: January 2006 IBM Expires: April 2006 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
July, 2005 October, 2005
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-04.txt> <draft-ietf-ipv6-2461bis-05.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78).
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 cite them other than as "work in progress". material or 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
skipping to change at page 3, line 43 skipping to change at page 3, line 41
10. PROTOCOL CONSTANTS............................................72 10. PROTOCOL CONSTANTS............................................72
11. SECURITY CONSIDERATIONS.......................................73 11. SECURITY CONSIDERATIONS.......................................73
11.1 Threat analysis...........................................73 11.1 Threat analysis...........................................73
11.2 Securing Neighbor Discovery messages......................74 11.2 Securing Neighbor Discovery messages......................74
12. RENUMBERING CONSIDERATIONS....................................75 12. RENUMBERING CONSIDERATIONS....................................75
REFERENCES.........................................................76 REFERENCES.........................................................76
Authors' Addresses.................................................78 Authors' Addresses.................................................79
APPENDIX A: MULTIHOMED HOSTS.......................................79 APPENDIX A: MULTIHOMED HOSTS.......................................80
APPENDIX B: FUTURE EXTENSIONS......................................80 APPENDIX B: FUTURE EXTENSIONS......................................81
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............81 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82
APPENDIX D: SUMMARY OF ISROUTER RULES..............................83 APPENDIX D: SUMMARY OF ISROUTER RULES..............................84
APPENDIX E: IMPLEMENTATION ISSUES..................................84 APPENDIX E: IMPLEMENTATION ISSUES..................................85
Appendix E.1: Reachability confirmations...........................84 Appendix E.1: Reachability confirmations...........................85
APPENDIX F: CHANGES FROM RFC 2461..................................85 APPENDIX F: CHANGES FROM RFC 2461..................................86
1. INTRODUCTION 1. INTRODUCTION
This specification defines the Neighbor Discovery (ND) protocol for This specification defines the Neighbor Discovery (ND) protocol for
Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use
Neighbor Discovery to determine the link-layer addresses for Neighbor Discovery to determine the link-layer addresses for
neighbors known to reside on attached links and to quickly purge neighbors known to reside on attached links and to quickly purge
cached values that become invalid. Hosts also use Neighbor Discovery cached values that become invalid. Hosts also use Neighbor Discovery
to find neighboring routers that are willing to forward packets on to find neighboring routers that are willing to forward packets on
their behalf. Finally, nodes use the protocol to actively keep track their behalf. Finally, nodes use the protocol to actively keep track
skipping to change at page 78, line 21 skipping to change at page 78, line 21
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[NDMAN] Arkko, J., "Manual Configuration of Security [NDMAN] Arkko, J., "Manual Configuration of Security
Associations for IPv6 Neighbor Discovery", draft-arkko- Associations for IPv6 Neighbor Discovery", draft-arkko-
manual-icmpv6-sas-02 (work in progress), March 2003. manual-icmpv6-sas-02 (work in progress), March 2003.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004.
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
and more Specific Routes", draft-ietf-ipv6-router- and more Specific Routes", draft-ietf-ipv6-router-
selection-07, (work in progress), January 2005. selection-07, (work in progress), January 2005.
[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet [SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet
Architecture Extensions for Shared Media", RFC 1620, May Architecture Extensions for Shared Media", RFC 1620, May
1994. 1994.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",
skipping to change at page 78, line 42 skipping to change at page 78, line 45
February 2004. February 2004.
[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking, Routing Messages", IEEE/ACM Transactions on Networking,
April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
IANA CONSIDERATIONS IANA CONSIDERATIONS
This document does not require any new ICMPv6 types or codes to be This document does not require any new ICMPv6 types or codes to be
allocated. However, existing ICMPv6 types should be updated to point allocated. However, existing ICMPv6 types should be updated to point
to the document instead of RFC 2461. Assignment of ICMPv6 types/codes to the document instead of RFC 2461. The procedure for the assignment
is described in Section 7 of RFC 2780. of ICMPv6 types/codes is described in Section 6 of [ICMPv6].
This document continues to use the following ICMPv6 message types
introduced in RFC 2461 and already assigned by IANA:
Message name ICMPv6 Type
Router Solicitation 133
Router Advertisement 134
Neighbor Solicitation 135
Neighbor Advertisement 136
Redirect 137
This document continues to use the following Neighbor Discovery
option types introduced in RFC 2461 and already assigned by IANA:
Option Name Type
Source Link-Layer Address 1
Target Link-Layer Address 2
Prefix Information 3
Redirected Header 4
MTU 5
Neighbor Discovery option types are allocated using following
procedure:
1. The IANA should allocate and permanently register new option types
from IETF RFC publication. This is for all RFC types
including standards track, informational, and experimental status
that originate from the IETF and have been approved by the IESG
for publication.
2. IETF working groups with working group consensus and area director
approval can request reclaimable Neighbor Discovery option type
assignments from the IANA. The IANA will tag the values as
"reclaimable in future".
The "reclaimable in the future" tag will be removed when an RFC is
published documenting the protocol as defined in 1). This will
make the assignment permanent and update the reference on the IANA
web pages.
At the point where the option type values are 85% assigned, the
IETF will review the assignments tagged "reclaimable in the
future" and inform the IANA which ones should be reclaimed and
reassigned.
3. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document,
per 1) above. Note also that documents published as "RFC Editor
contributions" [RFC 3667] are not considered to be IETF documents.
Authors' Addresses Authors' Addresses
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
USA USA
Phone: +1 919 254 7798 Phone: +1 919 254 7798
skipping to change at page 81, line 45 skipping to change at page 82, line 50
retransmissions. retransmissions.
INCOMPLETE NA, Solicited=0, Record link-layer STALE INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=any, Retransmit NS unchanged INCOMPLETE NA, Solicited=any, Send ICMP error unchanged
Override=any, No Start retransmit Override=any, No (if router) or
Link-layer address timer Link-layer address log error (if host)
!INCOMPLETE NA, Solicited=1, - REACHABLE !INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0 Override=0
Same link-layer Same link-layer
address as cached. address as cached.
!INCOMPLETE NA, Solicited=any, Update content of unchanged !INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No IsRouter flag. Override=any, No IsRouter flag.
link-layer address link-layer address
skipping to change at page 86, line 36 skipping to change at page 87, line 42
o Clarified that inconsistency checks for CurHopLimit are done for o Clarified that inconsistency checks for CurHopLimit are done for
none zero values only. none zero values only.
o Rearranged section 7.2.5 for clarity and described the processing o Rearranged section 7.2.5 for clarity and described the processing
when receiving the NA in INCOMPLETE state. when receiving the NA in INCOMPLETE state.
o Added clarifications in section 7.2 on how a node should react o Added clarifications in section 7.2 on how a node should react
upon receiving a message without SLLAO. upon receiving a message without SLLAO.
O Added New IANA section.
o Miscellaneous editorials. o Miscellaneous editorials.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 10 change blocks. 
19 lines changed or deleted 72 lines changed or added

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