Just a few comments: 3.4. Router Reachability Probing
When a host avoids using a non-reachable router X and instead uses another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe router X's reachability by sending a Neighbor Solicitation. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. [...] ==> I think 'MUST NOT' there is very strict wording. Is it really necessary to be so? Would SHOULD NOT be sufficient? We probably agree that it shouldn't be done because it just wastes bandwidth but I don't think nodes doing it would actually break anything. ND is being performed in the presence of real traffic anyway (at least my KAME box does so).. When a host chooses from multiple equivalent routers, it MUST choose randomly. ==> Did we settle this SHOULD/MUST debate? I'm not sure if MUST is best, but I can deal with that. Routers SHOULD NOT include in a Router Advertisement two Route Information Options with the same Prefix and Prefix Length ==> s/in a Router Advertisement two Route Information Options/ two Route Information Options in a Router Advertisement/ ? On Tue, 11 Jun 2002 [EMAIL PROTECTED] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group Working Group of the >IETF. > > Title : Default Router Preferences, More-Specific Routes and > Load Sharing > Author(s) : R. Draves, B. Hinden > Filename : draft-ietf-ipv6-router-selection-02.txt > Pages : 13 > Date : 10-Jun-02 > > This document describes two changes to Neighbor Discovery. The first > change is an optional extension to Router Advertisement messages for > communicating default router preferences and more-specific routes > from routers to hosts. This improves the ability of hosts to pick an > appropriate router, especially when the host is multi-homed and the > routers are on different links. The preference values and specific > routes advertised to hosts require administrative configuration; > they are not automatically derived from routing tables. The second > change is a mandatory modification of the conceptual sending > algorithm to support load-sharing among equivalent routers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipv6-router-selection-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > [EMAIL PROTECTED] > In the body type: > "FILE /internet-drafts/draft-ietf-ipv6-router-selection-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
