draft-ietf-ipv6-2461bis-08.txt   draft-ietf-ipv6-2461bis-09.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: November 2006 IBM Expires: April 2007 IBM
Obsoletes: 2461 (if approved) E. Nordmark, Obsoletes: 2461 (if approved) E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
September, 2006 October, 2006
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-08.txt> <draft-ietf-ipv6-2461bis-09.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.
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
skipping to change at page 3, line 42 skipping to change at page 3, line 43
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.................................................80 Authors' Addresses.................................................79
APPENDIX A: MULTIHOMED HOSTS.......................................80 APPENDIX A: MULTIHOMED HOSTS.......................................80
APPENDIX B: FUTURE EXTENSIONS......................................81 APPENDIX B: FUTURE EXTENSIONS......................................81
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82
APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 APPENDIX D: SUMMARY OF ISROUTER RULES..............................84
APPENDIX E: IMPLEMENTATION ISSUES..................................85 APPENDIX E: IMPLEMENTATION ISSUES..................................85
Appendix E.1: Reachability confirmations...........................85 Appendix E.1: Reachability confirmations...........................85
APPENDIX F: CHANGES FROM RFC 2461..................................87 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 56, line 7 skipping to change at page 56, line 9
Address resolution is the process through which a node determines the Address resolution is the process through which a node determines the
link-layer address of a neighbor given only its IP address. Address link-layer address of a neighbor given only its IP address. Address
resolution is performed only on addresses that are determined to be resolution is performed only on addresses that are determined to be
on-link and for which the sender does not know the corresponding on-link and for which the sender does not know the corresponding
link-layer address (see section 5.2). Address resolution is never link-layer address (see section 5.2). Address resolution is never
performed on multicast addresses. performed on multicast addresses.
It is possible that a host may receive a solicitation, a router It is possible that a host may receive a solicitation, a router
advertisement, or a Redirect message without a link-layer address advertisement, or a Redirect message without a link-layer address
option included. These messages MUST not create or update neighbor option included. These messages MUST NOT create or update neighbor
cache entries, except with respect to the IsRouter flag as specified cache entries, except with respect to the IsRouter flag as specified
in sections 6.3.4 and 7.2.5. If a neighbor cache entry does not exist in sections 6.3.4 and 7.2.5. If a neighbor cache entry does not exist
for the source of such a message, Address Resolution will be required for the source of such a message, Address Resolution will be required
before unicast communications with that address to begin. This is before unicast communications with that address to begin. This is
particularly relevant for unicast responses to solicitations where an particularly relevant for unicast responses to solicitations where an
additional packet exchange is required for advertisement delivery. additional packet exchange is required for advertisement delivery.
7.2.1. Interface Initialization 7.2.1. Interface Initialization
When a multicast-capable interface becomes enabled the node MUST join When a multicast-capable interface becomes enabled the node MUST join
skipping to change at page 74, line 45 skipping to change at page 74, line 47
The protocol reduces the exposure to the above threats in the absence The protocol reduces the exposure to the above threats in the absence
of authentication by ignoring ND packets received from off-link of authentication by ignoring ND packets received from off-link
senders. The Hop Limit field of all received packets is verified to senders. The Hop Limit field of all received packets is verified to
contain 255, the maximum legal value. Because routers decrement the contain 255, the maximum legal value. Because routers decrement the
Hop Limit on all packets they forward, received packets containing a Hop Limit on all packets they forward, received packets containing a
Hop Limit of 255 must have originated from a neighbor. Hop Limit of 255 must have originated from a neighbor.
Cryptographic security mechanisms for Neighbor Discovery are outside Cryptographic security mechanisms for Neighbor Discovery are outside
the scope of this document and are defined in [SEND]. Alternatively, the scope of this document and are defined in [SEND]. Alternatively,
IPsec can be used for IP layer authentication. The use of the IPsec can be used for IP layer authentication [IPv6-SA]. The use of
Internet Key Exchange (IKE) is not suited for creating dynamic the Internet Key Exchange (IKE) is not suited for creating dynamic
security associations that can be used to secure address resolution security associations that can be used to secure address resolution
or neighbor solicitation messages as documented in [ICMPIKE]. or neighbor solicitation messages as documented in [ICMPIKE].
In some cases, it may be acceptable to use statically configured In some cases, it may be acceptable to use statically configured
security associations with either [IPv6-AUTH] 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 Neighbor Discovery messages. However, it is important to note that
statically configured security associations are not scalable statically configured security associations are not scalable
(especially when considering multicast links) and are therefore (especially when considering multicast links) and are therefore
limited to small networks with known hosts. In any case, if either limited to small networks with known hosts. In any case, if either
[IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for
skipping to change at page 76, line 26 skipping to change at page 76, line 29
sending Router Advertisements that contain appropriate (and current) sending Router Advertisements that contain appropriate (and current)
prefixes. A host connected to a network that has no functioning 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 routers is likely to have more serious problems than just a lack of a
valid prefix and address. valid prefix and address.
The above discussion does not distinguish between the preferred and The above discussion does not distinguish between the preferred and
valid lifetimes. For all practical purposes it is probably valid lifetimes. For all practical purposes it is probably
sufficient to track the valid lifetime since the preferred lifetime sufficient to track the valid lifetime since the preferred lifetime
will not exceed the valid 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 REFERENCES
NORMATIVE NORMATIVE
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message [ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998. (IPv6) Specification", RFC 2463, December 1998.
skipping to change at page 77, line 8 skipping to change at page 76, line 55
INFORMATIVE INFORMATIVE
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May
2005. 2005.
[ADDR-SEL] Draves, R., "Default Address Selection for Internet [ADDR-SEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", [ARP] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, November 1982. STD 37, RFC 826, November 1982.
[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
skipping to change at page 77, line 42 skipping to change at page 77, line 34
3314, September 2002. 3314, September 2002.
[IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J. [IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J.
Wiljakka, " Internet Protocol version 6 (IPv6) for Some Wiljakka, " Internet Protocol version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316, Second and Third Generation Cellular Hosts", RFC 3316,
April 2003. April 2003.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998. 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 [IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 4301, December 2005.
[IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December
2005. 2005.
[IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005. Sharing", RFC 4311, November 2005.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999. Listener Discovery for IPv6", RFC 2710, October 1999.
[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
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 [PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust and Threats", RFC 3756, May 2004. Discovery (ND) Trust and Threats", RFC 3756, May 2004.
[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, [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004. February 2004.
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
skipping to change at page 88, line 45 skipping to change at page 88, line 29
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires February, 2007. This Internet-Draft expires April, 2007.
 End of changes. 13 change blocks. 
27 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/