> In RFC-2461 "6.3.5 Timing out Prefixes adn Default Routers" it says: > > Whenever the Lifetime of an entry in the Default Router List > expires, that entry is discarded. When removing a router from the > Default Router list, the node MUST update the Destination Cache in > such a way that all entries using the router perform next-hop > determination again rather than continue sending traffic to the > (deleted) router. > > My problem with this is: if RA has lifetime=0, it only means it stops > being a default router, router is *NOT* "(deleted)". It can still act > as a router for other more specific prefixes (for example, from > draft-ietf-ipv6-router-selection-01.txt). > > It not a big deal to delete destination cache entries, they will just > get reinserted, when needed. But I just wanted to hear if anyone else > has opinions about this?
Note that the above quoted text does not say to delete the destination cache entries. It says to update date is to make sure that the destination cache entries are consistent with the router no longer being a default router. Presumably the draft-ietf-ipv6-router-selection-01.txt draft will make it clear how next-hop determination happens with more specific routes in place. If the next-hop determination would return the same result after the router is removed from the default router list (but still has more specific routes) then there isn't any need to change anything. An implementation can use whatever technique works to efficiently find the destination cache entries. For example, an implementation of more specific routes could presumably track which route (default or not) was used to create a particular destination cache entry and use that as a faster way to find which entries need to redo next hop determination. > - if router is advertising "More Specific routes" every 15s, but does > not want to be a default router, the side effect is that destination > cache entries for that router are flushed on every RA, even for > "specific routes" That seems to be an implementation choice not required by the specification. > > - if we have a special non-default router, which gets its "clients" > only through "redirects", those entries are cleared also on RA from > this router. > > [The reason I noticed, once again TAHI test failed, because *I* only > removed those destinations that actually are related to the default > route. I didn't remove redirections, for example... I suppose I have > to fix this feature to be RFC compliant? :-] Since redirects (unless I misremember) create/modify destination cache entries (and not 128 bit prefix routes in a routing table) it seems like the TAHI tests follow the letter of RFC 2461. One can of course debate whether this behavior for redirects is the optimal one i.e. whether the specification should be clarified that destination cache entries created or modified due to a redirect should not be re-evaulated when the router stops to be a default router. If redirects are kept around the worst case is that NUD will need to discard them should the router really disappear. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
