--- 1/draft-ietf-ipv6-2461bis-05.txt 2006-03-10 01:12:19.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-06.txt 2006-03-10 01:12:19.000000000 +0100 @@ -1,23 +1,23 @@ INTERNET-DRAFT T. Narten, -Expires: April 2006 IBM +Expires: September 2006 IBM E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - October, 2005 + March, 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 @@ -2572,24 +2572,23 @@ indicated in the Destination Cache modulo any changes to the Destination Cache caused by Redirect messages. The policy for selecting routers from the Default Router List is as follows: 1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). - An implementation may choose to always return the same router or - cycle through the router list in a round-robin fashion as long - as it always returns a reachable or a probably reachable router - when one is available. + Further implementation hints on default router selection when + multiple equivalent routers are available are discussed in + [LD-SHRE]. 2) When no routers on the list are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion, so that subsequent requests for a default router do not return the same router until all other routers have been selected. Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default @@ -2762,29 +2761,29 @@ 7.2. Address Resolution Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address (see section 5.2). Address resolution is never performed on multicast addresses. - It is possible that a host may receive a solicitation or a router - advertisement without a link-layer address option included. These - messages MUST not create or update neighbor 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 for the source of - such a message, Address Resolution will be required before unicast - communications with that address to begin. This is particularly - relevant for unicast responses to solicitations where an additional - packet exchange is required for advertisement delivery. + It is possible that a host may receive a solicitation, a router + advertisement, or a Redirect message without a link-layer address + option included. These messages MUST not create or update neighbor + 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 + for the source of such a message, Address Resolution will be required + before unicast communications with that address to begin. This is + particularly relevant for unicast responses to solicitations where an + additional packet exchange is required for advertisement delivery. 7.2.1. Interface Initialization When a multicast-capable interface becomes enabled the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed @@ -4126,23 +4124,26 @@ retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. - INCOMPLETE NA, Solicited=any, Send ICMP error unchanged - Override=any, No (if router) or - Link-layer address log error (if host) + INCOMPLETE NA, Solicited=any, Update content of unchanged + Override=any, No IsRouter flag + Link-layer address + + - NS, RS, Redirect - - + No link layer address !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached. !INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag. link-layer address @@ -4402,21 +4403,21 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 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 except as set forth therein, the authors retain all their rights. 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