--- 1/draft-ietf-ipv6-2461bis-04.txt 2006-02-04 17:26:31.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-05.txt 2006-02-04 17:26:31.000000000 +0100 @@ -1,34 +1,31 @@ INTERNET-DRAFT T. Narten, -Expires: January 2006 IBM +Expires: April 2006 IBM E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - July, 2005 + October, 2005 Neighbor Discovery for IP version 6 (IPv6) - + Status of this memo By submitting this Internet-Draft, each author represents that any 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 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 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at @@ -129,29 +126,29 @@ 10. PROTOCOL CONSTANTS............................................72 11. SECURITY CONSIDERATIONS.......................................73 11.1 Threat analysis...........................................73 11.2 Securing Neighbor Discovery messages......................74 12. RENUMBERING CONSIDERATIONS....................................75 REFERENCES.........................................................76 - Authors' Addresses.................................................78 + Authors' Addresses.................................................79 - APPENDIX A: MULTIHOMED HOSTS.......................................79 - APPENDIX B: FUTURE EXTENSIONS......................................80 - APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............81 - APPENDIX D: SUMMARY OF ISROUTER RULES..............................83 - APPENDIX E: IMPLEMENTATION ISSUES..................................84 - Appendix E.1: Reachability confirmations...........................84 - APPENDIX F: CHANGES FROM RFC 2461..................................85 + APPENDIX A: MULTIHOMED HOSTS.......................................80 + APPENDIX B: FUTURE EXTENSIONS......................................81 + APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 + APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 + APPENDIX E: IMPLEMENTATION ISSUES..................................85 + Appendix E.1: Reachability confirmations...........................85 + APPENDIX F: CHANGES FROM RFC 2461..................................86 1. INTRODUCTION This specification defines the Neighbor Discovery (ND) protocol for Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track @@ -3900,20 +3897,23 @@ [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [NDMAN] Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", draft-arkko- manual-icmpv6-sas-02 (work in progress), March 2003. [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. + [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, + February 2004. + [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences and more Specific Routes", draft-ietf-ipv6-router- selection-07, (work in progress), January 2005. [SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", @@ -3921,22 +3921,73 @@ February 2004. [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z IANA CONSIDERATIONS This document does not require any new ICMPv6 types or codes to be allocated. However, existing ICMPv6 types should be updated to point - to the document instead of RFC 2461. Assignment of ICMPv6 types/codes - is described in Section 7 of RFC 2780. + to the document instead of RFC 2461. The procedure for the assignment + 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 Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 @@ -4074,23 +4126,23 @@ retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. - INCOMPLETE NA, Solicited=any, Retransmit NS unchanged - Override=any, No Start retransmit - Link-layer address timer + INCOMPLETE NA, Solicited=any, Send ICMP error unchanged + Override=any, No (if router) or + Link-layer address log error (if host) !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached. !INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag. link-layer address @@ -4320,20 +4372,22 @@ o Clarified that inconsistency checks for CurHopLimit are done for none zero values only. o Rearranged section 7.2.5 for clarity and described the processing when receiving the NA in INCOMPLETE state. o Added clarifications in section 7.2 on how a node should react upon receiving a message without SLLAO. + O Added New IANA section. + o Miscellaneous editorials. 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