Subject: RA with lifetime=0 and clearing Destination Cache?

From: Markku Savela <[email-masked]>
Date: Thu, 7 Mar 2002 16:53:45 +0200

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?

- 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"

- 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? :-]

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Mar 2002 16:25:24 +0100 (CET)

> get reinserted, when needed. But I just wanted to hear if anyone else

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.

>   cache entries for that router are flushed on every RA, even for

That seems to be an implementation choice not required by the specification.

> 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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Mar 2002 18:14:56 +0100

In your previous mail you wrote:

   
=> the deletion is *only* when the previous lifetime was not 0,
i.e. there WAS an entry.

=> you should remove redirections when the router stops to be a
default router (cf. the reference) or to be a router (no R bit in NAs).
The important detail is this is about transitions.

Regards

[email-masked]