--- 1/draft-ietf-ipv6-2461bis-07.txt 2006-09-08 17:12:29.000000000 +0200 +++ 2/draft-ietf-ipv6-2461bis-08.txt 2006-09-08 17:12:29.000000000 +0200 @@ -1,48 +1,49 @@ INTERNET-DRAFT T. Narten, Expires: November 2006 IBM - E. Nordmark, +Obsoletes: 2461 (if approved) E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - May, 2006 + September, 2006 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. 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". + material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/lid-abstracts.txt + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html + http://www.ietf.org/shadow.html. - This document is a submission of the IETF IPv6 WG. Comments should be - directed to the IPv6 WG mailing list, ipv6@ietf.org. +Copyright Notice + + Copyright (C) The Internet Society (2006). Abstract This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Table of Contents @@ -134,21 +135,21 @@ REFERENCES.........................................................76 Authors' Addresses.................................................80 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 + APPENDIX F: CHANGES FROM RFC 2461..................................87 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 @@ -160,22 +161,22 @@ over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., NBMA links) alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [IPv6- - NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use - of this protocol over some cellular links, which are examples of NBMA + NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of + this protocol over some cellular links, which are examples of NBMA links. The authors would like to acknowledge the contributions of the IPv6 working group and, in particular, (in alphabetical order) Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, and Susan Thomson. 2. TERMINOLOGY @@ -411,25 +412,24 @@ all-routers multicast address - the link-local scope address to reach all routers, FF02::2. solicited-node multicast address - a link-local scope multicast address that is computed as a function of the solicited target's address. The function is described in [ADDR-ARCH]. The function is chosen so that IP addresses which differ only in the - least significant bits, e.g., due to multiple - high-order prefixes associated with different - providers, will map to the same solicited-node address - thereby reducing the number of multicast addresses a - node must join. + most significant bits, e.g., due to multiple + prefixes associated with different providers, will map + to the same solicited-node address thereby reducing the + number of multicast addresses a node must join. link-local address - a unicast address having link-only scope that can be used to reach neighbors. All interfaces on routers MUST have a link-local address. Also, [ADDRCONF] requires that interfaces on hosts have a link-local address. unspecified address - a reserved address value that indicates the lack of an @@ -804,24 +804,20 @@ The protocol can presumably be extended in the future to find viable paths in environments that lack reflexive and transitive connectivity. 3.3. Securing Neighbor Discovery messages Neighbor Discovery messages are needed for various functions. Several functions are designed to allow hosts to ascertain the ownership of an address or the mapping between link layer and IP layer addresses. - Having Neighbor Discovery functions on the ICMP layer allows for the - use of IP layer security mechanisms, which are available - independently of the availability of security on the link layer. - Vulnerabilities related to Neighbor Discovery are discussed in section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec AH or ESP can be used to secure Neighbor Discovery. 4. MESSAGE FORMATS 4.1. Router Solicitation Message Format @@ -846,22 +842,22 @@ to the sending interface. Destination Address Typically the all-routers multicast address. Hop Limit 255 ICMP Fields: Type 133 - Code 0 + Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the @@ -3726,38 +3721,36 @@ 11.2 Securing Neighbor Discovery messages The protocol reduces the exposure to the above threats in the absence of authentication by ignoring ND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. - In order to allow for IP layer authentication, a mechanism is - required to allow for dynamic keying between neighbors. The use of - the Internet Key Exchange [ICMPIKE] is not suited for creating - dynamic security associations that can be used to secure address - resolution or neighbor solicitation messages as documented in - [ICMPIKE]. The security of Neighbor Discovery messages through - dynamic keying is outside the scope of this document and is addressed - in [SEND]. + Cryptographic security mechanisms for Neighbor Discovery are outside + the scope of this document and are defined in [SEND]. Alternatively, + IPsec can be used for IP layer authentication. The use of the + Internet Key Exchange (IKE) is not suited for creating dynamic + security associations that can be used to secure address resolution + or neighbor solicitation messages as documented in [ICMPIKE]. In some cases, it may be acceptable to use statically configured - security associations with either [IPv6-AH] or [IPv6-ESP] to secure + security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts. In any case, if either - [IPv6-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the - purpose of authentication. Packets that fail authentication checks - MUST be silently discarded. + [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for + the purpose of authentication. Packets that fail authentication + checks MUST be silently discarded. 12. RENUMBERING CONSIDERATIONS The Neighbor Discovery protocol together with IPv6 Address Autoconfiguration [ADDRCONF] provides mechanisms to aid in renumbering - new prefixes and addresses can be introduced and old ones can be deprecated and removed. The robustness of these mechanisms is based on all the nodes on the link receiving the Router Advertisement messages in a timely manner. @@ -3813,20 +3806,27 @@ sending Router Advertisements that contain appropriate (and current) prefixes. A host connected to a network that has no functioning routers is likely to have more serious problems than just a lack of a valid prefix and address. The above discussion does not distinguish between the preferred and valid lifetimes. For all practical purposes it is probably sufficient to track the valid lifetime since the preferred lifetime will not exceed the valid lifetime. +13. IPR Acknowledgements + + 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. + REFERENCES NORMATIVE [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. [ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. @@ -3851,23 +3851,20 @@ [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. - [DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration - Protocol (DHCP)for IPv6", RFC 3736, April 2004. - [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2003. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. @@ -3883,60 +3880,62 @@ [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, " IPv6 over Non-broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. - [IPv6-AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", - RFC 2402, November 1998. + [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December + 2005. - [IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security - Payload (ESP)", RFC 2406, November 1998. + [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005. [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999. [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. + [PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor + Discovery (ND) Trust and Threats", RFC 3756, May 2004. + [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)", - draft-ietf-send-ndopt-04 (work in progress), - February 2004. + Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971, + March 2005. [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. The procedure for the assignment @@ -4018,23 +4017,22 @@ Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Hesham Soliman - Flarion Technologies - Phone: +1 908 997 9775 - Email: H.Soliman@flarion.com + Qualcomm-Flarion Technologies + Email: Hesham@Qualcomm.com APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. Further work @@ -4428,11 +4428,11 @@ 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. -This Internet-Draft expires November, 2006. +This Internet-Draft expires February, 2007.