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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

At Thu, 3 Jul 2008 17:07:34 -0400,
"Wes Beebee (wbeebee)" <[e-mail]> 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.  

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.

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.

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.

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