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

Tatuya,

Please see in line below between <wb> and </wb> 

-----Original Message-----
From: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org]
Sent: Tuesday, July 08, 2008 9:50 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 3 Jul 2008 17:07:34 -0400,
"Wes Beebee (wbeebee)" <wbeebee@cisco.com> wrote:

> >    3.  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.
> 
> Hmm. I agree that the current specs don't suggest doing this, but is 
> it forbidden or wrong? I.e., is caching on-link information any worse 
> than caching the generated addresses? The PIO has Lifetime fields, and 
> as long as they are honored... ANd indeed, that is what point 4 
> reinforces...
> 
> <hs>True, but what if someone has manually configured an IPv6 address 
> with prefix length, what are the Lifetime values for such a prefix? I 
> am not sure what happens here. Why not be then explicit and include 
> such a bullet. Also, the subject of our draft is focused on on-link 
> determination so we added such a bullet for completeness sake since
> RFC4862 mentions persistent data across initializations. It is RFC4861 
> that deals with on-link determination. So why not have RFC4861 have 
> such text for on-link determination related to persistent storage.
> </hs>
> 
> <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.  

<wb>
We agree - and we believe implementations shouldn't be caching the address either - but, unfortunately, the text of RFC4862 already allows it and an implementation already does it - so that is something we cannot change.  However, our draft is dealing with on-link determination and we've shown clear problems with caching on-link determination.  RFC4861 and RFC4862 do not mention caching on-link information, so we can add this rule to our draft.
</wb>

Actually, I see it can rather be harmful if we only prohibit the on-link prefix part of this behavior.  Recall that the background motivation of address caching is that it may help the situation of a temporary outage of a router.  Now that we've deprecated the 'on-link by default' behavior, if the host doesn't also cache the on-link information, the cached address is almost meaningless.

<wb>
Again, they probably shouldn't be caching the address anyway - but that's an argument for another day.  We have already given our justification why on-link determination should not be cached.
</wb>

I'm not necessarily a fan of this tricky behavior, but prohibiting one aspect of feature that will make the other aspect meaningless makes logically no sense to me.

So, I tend to agree with Thomas here:

> I don't see right off why rule 3 is needed.

After all, such caching is a minor implementation detail.  I suspect it doesn't do any harm in practice even if we remove this dicey bullet.

<wb>
No - screwing up on-link determination is not a minor thing nor caching of it. See section 3 of our draft where we give one example of how data forwarding by a host may totally break down if a wrong on-link determination is made.
</wb>

Another note about the wording if still decide to keep this point:
this bullet does not correctly reflect the sense of the referred part of RFC4862: "Note that section 5.7 of [RFC4862] describes the use of stable storage for addresses acquired with stateless address autoconfiguration..."  The intent of Section 5.7 of RFC4862 was not to "describe" this behavior.  It was written because there was one known implementation that supports this behavior and we thought it might be useful to make note **just in case** other implementations want to do the same thing.  This is why this section uses weak wording such as "An implementation ... may want to retain..." and makes an explicit note of "Further details on this kind of extension are beyond the scope of this document."

As stated above, I'd rather suggest remove this bullet, in which case this concern will be resolved automatically.  But if we keep it, I'd like the wording to reflect the original intent of RFC4862.

<wb>
We would like to keep this bullet. But we totally agree with your analysis above related to the intent of section 5.7 of RFC4862. We have replaced the word "describes" in our 3rd bullet with "mentions". See new text below - does this work for you?

                  On-link determination SHOULD NOT 
                  persist across IPv6 interface initializations. 
                  This is a new requirement compared to [RFC4861].
                  Note that section 5.7 of [RFC4862] mentions the 
                  use of stable storage for addresses acquired 
                  with stateless address autoconfiguration but no RFC has any 
                  similar text about retaining or not retaining the on-link
                  prefixes.
</wb>

Thanks.

Wes & Hemant

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------