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