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/ |