> Hmm.... the IPv6 neighbor discovery says that after probes > fail, entry should be removed, see RFC-2461 7.3.3 > > Upon entering the PROBE state, a node sends a unicast Neighbor > Solicitation message to the neighbor using the cached link-layer > address..... > ..... If no response is received after waiting RetransTimer > milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, > retransmissions cease and the entry SHOULD be deleted.
I think to implement router-selection, you need to keep track of whether a router is reachable or unreachable. Whether that's in the Neighbor Cache Entry or not and how it interacts with the ND states is an implementation concern that is not specified in the draft. Note that RFC 2461 does not really say that implementations should delete a data structure, it is saying that implementations should behave as if the conceptual data structure were deleted. RFC 2461 is a protocol spec not an implementation spec. > As to 3.4 in internet-drafts/draft-ietf-ipv6-router-selection-02.txt, > it talks only about routers X and Y. > > Playing nasty, I imagine situation where I have routers X, Y > and Z (with prefix lengths X > Y > Z) and destination > matching all of them. Now, if only Z is currently reachable, > I should probably probe both X and Y using some logic... Yes both X & Y should be probed. I think section 3.4 implies that, although it could be clarified. Section 3.4 says "When a host avoids using a non-reachable router X ..." - it's quite possible for this clause to apply to more than one router. Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
