RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

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: 'Jinmei_Tatuya@isc.org'; '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: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org]
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)" <shemant@cisco.com> 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
--------------------------------------------------------------------