We're against blind caching and re-use of unverified (and possibly bogus) information. If that information is deprecated and later verified (as it is in DNA) - then the information can be re-used without a problem.
Tatuya - In the new text, we have eliminated any normative language. Therefore, the draft is simply clarifying this point by demonstrating via example what can go wrong if unverified cached information is later reused blindly. We have also changed the title of section 2 from "Host Behavior Rules" to "Host Behavior and Rules". - Wes -----Original Message----- From: Hemant Singh (shemant) Sent: Thursday, July 10, 2008 12:09 PM To: '[EMAIL PROTECTED]'; 'Suresh Krishnan' Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden; ipv6@ietf.org Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Tatuya, Since you don't want any new rules added by our draft, we changed bullet 3 related to caching on-link determination. The new bullet text does not add any normative requirements but clearly says why it is a bad idea to cache on-link determination. Also, our draft is about on-link determination - we are not adding anything related to IPv6 address caching - we have said repeatedly, save it for another day. The old text of bullet 3 was: On-link determination SHOULD NOT persist across IPv6 interface initializations. Note that section 5.7 of [RFC4862] describes the use of stable storage for addresses acquired with stateless address autoconfiguration with a note that the Preferred and Valid Lifetimes must be retained if this approach is used. However no RFC suggests or recommends retaining the on-link prefixes. New text is as follows: If on-link determination persists across IPv6 interface initializations, then lack of IPv6 connectivity can result. For example, a host receives an RA from a router with on-link prefix A. The host reboots. During the reboot, the router sends out prefix A with on-link bit set and a zero lifetime to indicate a renumbering. The host misses the renumbering. The host comes online. Then, the router sends an RA with no PIO. The host uses cached on-link prefix A and issues NS's instead of sending traffic to a default router. The "Observed Incorrect Implementation Behavior" section below describes how this can result in lack of IPv6 connectivity. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2008 1:15 AM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden; ipv6@ietf.org Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt At Wed, 9 Jul 2008 20:54:04 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > Thanks for the reply. Let's see if we can meet common ground with you. > > Our justification for prohibiting on-link caching is only in emails to > 6man as follows: > > "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." And I replied to this justification, saying this itself cannot justify killing on-link caching while (perhaps implicitly) allowing address caching. > Also, when Suresh Krishnan pointed out that he supports bullet 3, he > made us explicitly mention in the bullet that it's a new rule. We have > been clear in the draft where there is a new rule and where it's > clarification. Besides this new rule, the rest of the draft is > clarification. Suresh has his right to express his opinion, of course, and so do I. I would not like this document to set new rules (note, again, that I'm not objecting to discussing new changes to RFC4861/4862. I'm simply objecting to doing that in this document). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------