draft-ietf-ipv6-2461bis-05.txt   draft-ietf-ipv6-2461bis-06.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: April 2006 IBM Expires: September 2006 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
October, 2005 March, 2006
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-05.txt> <draft-ietf-ipv6-2461bis-06.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 52, line 18 skipping to change at page 52, line 18
indicated in the Destination Cache modulo any changes to the indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages. Destination Cache caused by Redirect messages.
The policy for selecting routers from the Default Router List is as The policy for selecting routers from the Default Router List is as
follows: follows:
1) Routers that are reachable or probably reachable (i.e., in any 1) Routers that are reachable or probably reachable (i.e., in any
state other than INCOMPLETE) SHOULD be preferred over routers state other than INCOMPLETE) SHOULD be preferred over routers
whose reachability is unknown or suspect (i.e., in the whose reachability is unknown or suspect (i.e., in the
INCOMPLETE state, or for which no Neighbor Cache entry exists). INCOMPLETE state, or for which no Neighbor Cache entry exists).
An implementation may choose to always return the same router or Further implementation hints on default router selection when
cycle through the router list in a round-robin fashion as long multiple equivalent routers are available are discussed in
as it always returns a reachable or a probably reachable router [LD-SHRE].
when one is available.
2) When no routers on the list are known to be reachable or 2) When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been return the same router until all other routers have been
selected. selected.
Cycling through the router list in this case ensures that all Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default Unreachability Detection algorithm. A request for a default
skipping to change at page 56, line 5 skipping to change at page 56, line 5
7.2. Address Resolution 7.2. Address Resolution
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 or a router It is possible that a host may receive a solicitation, a router
advertisement without a link-layer address option included. These advertisement, or a Redirect message without a link-layer address
messages MUST not create or update neighbor cache entries, except option included. These messages MUST not create or update neighbor
with respect to the IsRouter flag as specified in sections 6.3.4 and cache entries, except with respect to the IsRouter flag as specified
7.2.5. If a neighbor cache entry does not exist for the source of in sections 6.3.4 and 7.2.5. If a neighbor cache entry does not exist
such a message, Address Resolution will be required before unicast for the source of such a message, Address Resolution will be required
communications with that address to begin. This is particularly before unicast communications with that address to begin. This is
relevant for unicast responses to solicitations where an additional particularly relevant for unicast responses to solicitations where an
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
the all-nodes multicast address on that interface, as well as the the all-nodes multicast address on that interface, as well as the
solicited-node multicast address corresponding to each of the IP solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface. addresses assigned to the interface.
The set of addresses assigned to an interface may change over time. The set of addresses assigned to an interface may change over time.
New addresses might be added and old addresses might be removed New addresses might be added and old addresses might be removed
skipping to change at page 82, line 50 skipping to change at page 82, line 50
retransmissions. retransmissions.
INCOMPLETE NA, Solicited=0, Record link-layer STALE INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=any, Send ICMP error unchanged INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No (if router) or Override=any, No IsRouter flag
Link-layer address log error (if host) Link-layer address
- NS, RS, Redirect - -
No link layer address
!INCOMPLETE NA, Solicited=1, - REACHABLE !INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0 Override=0
Same link-layer Same link-layer
address as cached. address as cached.
!INCOMPLETE NA, Solicited=any, Update content of unchanged !INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No IsRouter flag. Override=any, No IsRouter flag.
link-layer address link-layer address
skipping to change at page 88, line 20 skipping to change at page 88, line 23
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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
 End of changes. 7 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/