draft-ietf-ipv6-2461bis-07.txt | draft-ietf-ipv6-2461bis-08.txt | |||
---|---|---|---|---|
INTERNET-DRAFT T. Narten, | INTERNET-DRAFT T. Narten, | |||
Expires: November 2006 IBM | Expires: November 2006 IBM | |||
E. Nordmark, | Obsoletes: 2461 (if approved) E. Nordmark, | |||
Sun Microsystems | Sun Microsystems | |||
W. Simpson, | W. Simpson, | |||
Daydreamer | Daydreamer | |||
H. Soliman, | H. Soliman, | |||
Flarion | Flarion | |||
May, 2006 | September, 2006 | |||
Neighbor Discovery for IP version 6 (IPv6) | Neighbor Discovery for IP version 6 (IPv6) | |||
<draft-ietf-ipv6-2461bis-07.txt> | <draft-ietf-ipv6-2461bis-08.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 | |||
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 to 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 | |||
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 | 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 | Copyright Notice | |||
directed to the IPv6 WG mailing list, ipv6@ietf.org. | ||||
Copyright (C) The Internet Society (2006). | ||||
Abstract | Abstract | |||
This document specifies the Neighbor Discovery protocol for IP | This document specifies the Neighbor Discovery protocol for IP | |||
Version 6. IPv6 nodes on the same link use Neighbor Discovery to | Version 6. IPv6 nodes on the same link use Neighbor Discovery to | |||
discover each other's presence, to determine each other's link-layer | discover each other's presence, to determine each other's link-layer | |||
addresses, to find routers and to maintain reachability information | addresses, to find routers and to maintain reachability information | |||
about the paths to active neighbors. | about the paths to active neighbors. | |||
Table of Contents | Table of Contents | |||
skipping to change at page 3, line 49 | skipping to change at page 3, line 50 | |||
REFERENCES.........................................................76 | REFERENCES.........................................................76 | |||
Authors' Addresses.................................................80 | Authors' Addresses.................................................80 | |||
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..................................86 | APPENDIX F: CHANGES FROM RFC 2461..................................87 | |||
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 4, line 29 | skipping to change at page 4, line 29 | |||
over a particular link type) this document applies to all link types. | over a particular link type) this document applies to all link types. | |||
However, because ND uses link-layer multicast for some of its | However, because ND uses link-layer multicast for some of its | |||
services, it is possible that on some link types (e.g., NBMA links) | services, it is possible that on some link types (e.g., NBMA links) | |||
alternative protocols or mechanisms to implement those services will | alternative protocols or mechanisms to implement those services will | |||
be specified (in the appropriate document covering the operation of | be specified (in the appropriate document covering the operation of | |||
IP over a particular link type). The services described in this | IP over a particular link type). The services described in this | |||
document that are not directly dependent on multicast, such as | document that are not directly dependent on multicast, such as | |||
Redirects, Next-hop determination, Neighbor Unreachability Detection, | Redirects, Next-hop determination, Neighbor Unreachability Detection, | |||
etc., are expected to be provided as specified in this document. The | 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- | details of how one uses ND on NBMA links are addressed in [IPv6- | |||
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use | NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of | |||
of this protocol over some cellular links, which are examples of NBMA | this protocol over some cellular links, which are examples of NBMA | |||
links. | links. | |||
The authors would like to acknowledge the contributions of the IPv6 | The authors would like to acknowledge the contributions of the IPv6 | |||
working group and, in particular, (in alphabetical order) Ran | working group and, in particular, (in alphabetical order) Ran | |||
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen | Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen | |||
Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, | Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, | |||
Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles | Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles | |||
Perkins, Matt Thomas, and Susan Thomson. | Perkins, Matt Thomas, and Susan Thomson. | |||
2. TERMINOLOGY | 2. TERMINOLOGY | |||
skipping to change at page 9, line 24 | skipping to change at page 9, line 25 | |||
all-routers multicast address | all-routers multicast address | |||
- the link-local scope address to reach all routers, | - the link-local scope address to reach all routers, | |||
FF02::2. | FF02::2. | |||
solicited-node multicast address | solicited-node multicast address | |||
- a link-local scope multicast address that is computed | - a link-local scope multicast address that is computed | |||
as a function of the solicited target's address. The | as a function of the solicited target's address. The | |||
function is described in [ADDR-ARCH]. The function is | function is described in [ADDR-ARCH]. The function is | |||
chosen so that IP addresses which differ only in the | chosen so that IP addresses which differ only in the | |||
least significant bits, e.g., due to multiple | most significant bits, e.g., due to multiple | |||
high-order prefixes associated with different | prefixes associated with different providers, will map | |||
providers, will map to the same solicited-node address | to the same solicited-node address thereby reducing the | |||
thereby reducing the number of multicast addresses a | number of multicast addresses a node must join. | |||
node must join. | ||||
link-local address | link-local address | |||
- a unicast address having link-only scope that can be | - a unicast address having link-only scope that can be | |||
used to reach neighbors. All interfaces on routers | used to reach neighbors. All interfaces on routers | |||
MUST have a link-local address. Also, [ADDRCONF] | MUST have a link-local address. Also, [ADDRCONF] | |||
requires that interfaces on hosts have a link-local | requires that interfaces on hosts have a link-local | |||
address. | address. | |||
unspecified address | unspecified address | |||
- a reserved address value that indicates the lack of an | - a reserved address value that indicates the lack of an | |||
skipping to change at page 17, line 12 | skipping to change at page 17, line 14 | |||
The protocol can presumably be extended in the | The protocol can presumably be extended in the | |||
future to find viable paths in environments that | future to find viable paths in environments that | |||
lack reflexive and transitive connectivity. | lack reflexive and transitive connectivity. | |||
3.3. Securing Neighbor Discovery messages | 3.3. Securing Neighbor Discovery messages | |||
Neighbor Discovery messages are needed for various functions. Several | Neighbor Discovery messages are needed for various functions. Several | |||
functions are designed to allow hosts to ascertain the ownership of | functions are designed to allow hosts to ascertain the ownership of | |||
an address or the mapping between link layer and IP layer addresses. | 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 | Vulnerabilities related to Neighbor Discovery are discussed in | |||
section 11.1. A general solution for securing Neighbor Discovery is | section 11.1. A general solution for securing Neighbor Discovery is | |||
outside the scope of this specification and is discussed in [SEND]. | outside the scope of this specification and is discussed in [SEND]. | |||
However, Section 11.2 explains how and under which constraints IPsec | However, Section 11.2 explains how and under which constraints IPsec | |||
AH or ESP can be used to secure Neighbor Discovery. | AH or ESP can be used to secure Neighbor Discovery. | |||
4. MESSAGE FORMATS | 4. MESSAGE FORMATS | |||
4.1. Router Solicitation Message Format | 4.1. Router Solicitation Message Format | |||
skipping to change at page 18, line 4 | skipping to change at page 17, line 52 | |||
to the sending interface. | to the sending interface. | |||
Destination Address | Destination Address | |||
Typically the all-routers multicast address. | Typically the all-routers multicast address. | |||
Hop Limit 255 | Hop Limit 255 | |||
ICMP Fields: | ICMP Fields: | |||
Type 133 | Type 133 | |||
Code 0 | ||||
Code 0 | ||||
Checksum The ICMP checksum. See [ICMPv6]. | Checksum The ICMP checksum. See [ICMPv6]. | |||
Reserved This field is unused. It MUST be initialized to | Reserved This field is unused. It MUST be initialized to | |||
zero by the sender and MUST be ignored by the | zero by the sender and MUST be ignored by the | |||
receiver. | receiver. | |||
Valid Options: | Valid Options: | |||
Source link-layer address | Source link-layer address | |||
The link-layer address of the sender, if known. | The link-layer address of the sender, if known. | |||
MUST NOT be included if the Source Address is the | MUST NOT be included if the Source Address is the | |||
skipping to change at page 74, line 46 | skipping to change at page 74, line 43 | |||
11.2 Securing Neighbor Discovery messages | 11.2 Securing Neighbor Discovery messages | |||
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. | |||
In order to allow for IP layer authentication, a mechanism is | Cryptographic security mechanisms for Neighbor Discovery are outside | |||
required to allow for dynamic keying between neighbors. The use of | the scope of this document and are defined in [SEND]. Alternatively, | |||
the Internet Key Exchange [ICMPIKE] is not suited for creating | IPsec can be used for IP layer authentication. The use of the | |||
dynamic security associations that can be used to secure address | Internet Key Exchange (IKE) is not suited for creating dynamic | |||
resolution or neighbor solicitation messages as documented in | security associations that can be used to secure address resolution | |||
[ICMPIKE]. The security of Neighbor Discovery messages through | or neighbor solicitation messages as documented in [ICMPIKE]. | |||
dynamic keying is outside the scope of this document and is addressed | ||||
in [SEND]. | ||||
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-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 | 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-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the | [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for | |||
purpose of authentication. Packets that fail authentication checks | the purpose of authentication. Packets that fail authentication | |||
MUST be silently discarded. | checks MUST be silently discarded. | |||
12. RENUMBERING CONSIDERATIONS | 12. RENUMBERING CONSIDERATIONS | |||
The Neighbor Discovery protocol together with IPv6 Address | The Neighbor Discovery protocol together with IPv6 Address | |||
Autoconfiguration [ADDRCONF] provides mechanisms to aid in | Autoconfiguration [ADDRCONF] provides mechanisms to aid in | |||
renumbering - new prefixes and addresses can be introduced and old | renumbering - new prefixes and addresses can be introduced and old | |||
ones can be deprecated and removed. | ones can be deprecated and removed. | |||
The robustness of these mechanisms is based on all the nodes on the | The robustness of these mechanisms is based on all the nodes on the | |||
link receiving the Router Advertisement messages in a timely manner. | link receiving the Router Advertisement messages in a timely manner. | |||
skipping to change at page 76, line 31 | skipping to change at page 76, line 26 | |||
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 18 | skipping to change at page 77, line 20 | |||
[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. | |||
[DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration | ||||
Protocol (DHCP)for IPv6", RFC 3736, April 2004. | ||||
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- | [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- | |||
Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", | [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", | |||
draft-arkko-icmpv6-ike-effects-02 (work in progress), | draft-arkko-icmpv6-ike-effects-02 (work in progress), | |||
March 2003. | March 2003. | |||
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, | [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, September 1981. | RFC 792, September 1981. | |||
skipping to change at page 77, line 50 | skipping to change at page 77, line 49 | |||
[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-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, " | |||
IPv6 over Non-broadcast Multiple Access (NBMA) | IPv6 over Non-broadcast Multiple Access (NBMA) | |||
networks", RFC 2491, January 1999. | 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 2401, November 1998. | |||
[IPv6-AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", | [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December | |||
RFC 2402, November 1998. | 2005. | |||
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security | [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC | |||
Payload (ESP)", RFC 2406, November 1998. | 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 | [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. | |||
[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, | [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 | |||
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)",RFC3971, | |||
draft-ietf-send-ndopt-04 (work in progress), | March 2005. | |||
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. The procedure for the assignment | to the document instead of RFC 2461. The procedure for the assignment | |||
skipping to change at page 80, line 37 | skipping to change at page 80, line 38 | |||
Daydreamer | Daydreamer | |||
Computer Systems Consulting Services | Computer Systems Consulting Services | |||
1384 Fontaine | 1384 Fontaine | |||
Madison Heights, Michigan 48071 | Madison Heights, Michigan 48071 | |||
USA | USA | |||
EMail: Bill.Simpson@um.cc.umich.edu | EMail: Bill.Simpson@um.cc.umich.edu | |||
bsimpson@MorningStar.com | bsimpson@MorningStar.com | |||
Hesham Soliman | Hesham Soliman | |||
Flarion Technologies | Qualcomm-Flarion Technologies | |||
Phone: +1 908 997 9775 | Email: Hesham@Qualcomm.com | |||
Email: H.Soliman@flarion.com | ||||
APPENDIX A: MULTIHOMED HOSTS | APPENDIX A: MULTIHOMED HOSTS | |||
There are a number of complicating issues that arise when Neighbor | There are a number of complicating issues that arise when Neighbor | |||
Discovery is used by hosts that have multiple interfaces. This | Discovery is used by hosts that have multiple interfaces. This | |||
section does not attempt to define the proper operation of multihomed | section does not attempt to define the proper operation of multihomed | |||
hosts with regard to Neighbor Discovery. Rather, it identifies | hosts with regard to Neighbor Discovery. Rather, it identifies | |||
issues that require further study. Implementors are encouraged to | issues that require further study. Implementors are encouraged to | |||
experiment with various approaches to making Neighbor Discovery work | experiment with various approaches to making Neighbor Discovery work | |||
on multihomed hosts and to report their experiences. Further work | on multihomed hosts and to report their experiences. Further work | |||
skipping to change at page 88, line 42 | skipping to change at page 88, line 45 | |||
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 November, 2006. | This Internet-Draft expires February, 2007. | |||
End of changes. 24 change blocks. | ||||
46 lines changed or deleted | 45 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |