Re: RFC 4861: Invalidating destination cache on prefix deletion

[JINMEI Tatuya / 神明達哉 <jinmei at isl.rdc.toshiba.co.jp>]

At Mon, 15 Oct 2007 10:56:25 +0530,
"Sandeep.P A" <sandeeppa at huawei.com> wrote:

> "Whenever the invalidation timer expires for a Prefix List entry, that entry
> is discarded. 'NO EXISTING DESTINATION CACHE ENTRIES NEED BE UPDATED',
> however. Should a reachability problem arise with an existing Neighbor Cache
> entry, Neighbor Unreachability Detection will perform any needed recovery"
> 
> But in the section different approach is given for Router List entry
> 
> 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.
> 
> In both places the source for a route in destination cache is becoming
> invalid. Still two different behaviors are given in the RFC to handle it.
> And the second one looks more logical to me. 
> 
> Why corresponding destination cache entries are not deleted immediately on
> prefix lifetime expiry?

The question should be: "why corresponding destination cache entries
*do not have to be* deleted immediately on prefix lifetime expiry?",
and the RFC already answers the question: because "Neighbor
Unreachability Detection will perform any needed recovery."

On the other hand, if you didn't delete the destination cache that
refers to an expired router, you'd keep sending succeeding traffic to
that ex-router and the packets would be (most likely silently) dropped
(note: since we're talking about a "non-compliant" host, which would
not properly react to the router-flag change or detected unreachable
router either).  That's why you MUST delete the destination cache in
this case.

> If I do so, will it be a non-compliance to the RFC?

I don't think so.  The RFC says "the entries *need not be* deleted";
it doesn't say "MUST NOT be deleted".

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------