The host has 4001:420:3800:809::/64 as a prefix in host PrefixList because the RA sent this prefix as on-link. The host has cached on-link determination for this prefix and the current lifetime of the prefix is much longer than the time it takes the host to reboot. Now the host is rebooted and during this reboot, the admin of the network renumbered the prefix to expire and also configured a new RA where RA has no PIO. After reboot, the host still continues to use this cached information because the prefix hasn't timed out and host did not see the renumbering RA. After reboot, when the host sees a new RA the host is supposed to update information from. RFC4861 says to use union of information from different RA's, except where MTU or Lifetime of a prefix is concerned, to take the new information only. But the new RA has no PIO and hence no Lifetime. So it gets murky. Do we keep a union of 4001:420:3800:809::/64 as on-link and all other non-link-local destinations as off-link due to an RA with no PIO or do we consider the new RA with no PIO to signal Lifetime for any non-link-local prefix as zero?
What if the cache gets corrupted and the corruption changes a few bits in the cached prefix and even a reboot doesn't fix the changed bits. The RA remains same between reboot. But a totally different prefix now exists as on-link. Why is this not a problem? Also interesting is the fact that Suresh Krishnan who is author of DNA protocol and Chairs DNA blessed our bullet 3 on June 18th, 2008 to prohibit caching of on-link determination but Thomas is reporting that DNA proposes the caching we disallow. Hemant -----Original Message----- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 9:30 PM To: JINMEI Tatuya / ???? Cc: Wes Beebee (wbeebee); Hemant Singh (shemant); Brian Haberman; Bob Hinden; ipv6@ietf.org Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Note: replying to a number of separate messages here... JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> writes: > At Thu, 3 Jul 2008 17:07:34 -0400, > "Wes Beebee (wbeebee)" <[EMAIL PROTECTED]> wrote: > > <wb> > > What if there are cache-inconsistency problems, prefix renumbering, > > or stale information? I think it's better just to get rid of > > caching on-link information in stable storage and get such > > information fresh from RA's. That way, administrators can better > > rationalize the behavior of their network from the configured RA's. > > </wb> > The same argument applies to caching the address, so it cannot be a > reason why we specifically prohibit the (on-link) prefix part of this > behavior. Exactly. > Actually, I see it can rather be harmful if we only prohibit the > on-link prefix part of this behavior. Again, I agree. Note also, that DNA approaches essentially "cache" information about the configuration of an interface across interfaces going up and down -- which is very similar to the type of caching you are proposing to disallow. There is nothing wrong with caching information (as long as it has not expired) so long as one replaces it if updated information comes along later. So I continue to be unpersuaded by any of the discussion so far that we should saying "don't do that". Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
