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

At Wed, 9 Jul 2008 10:08:02 -0400,
"Wes Beebee (wbeebee)" <wbeebee@cisco.com> wrote:

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

Note: as I said in my previous comment, RFC4862 does not *allow*
address caching.  It just makes note when an implementation chooses to
adopt it.

Anyway, I'm not convinced with this logic.  As I pointed out, killing
on-link information caching effectively kills address caching, too, by
making the cached address of almost no use.  Again, I'm personally not
a fan of this caching trick, but effectively killing address caching
with saying "we don't talk about address caching because it's out of
scope of this document" sounds like an unfair action for me.

I'd accept, if

1. we prohibit both address caching and on-link caching (with
   reasonable argument, of course)
or,
2. we don't talk about on-link caching (either allow or prohibit) if
   we don't talk about address caching

but it would be unfair if
3. we prohibit on-link caching while ignoring its effect on address
   caching.

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

Sorry, I've not seen the justification.  At least I don't see it in
the draft.

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

I see the problem described in Section 3 and that's why I basically
support this document.  But I don't understand why this problem
justifies killing on-link caching.

As a meta level comment, my basic understanding of the purpose of this
document is to clarify a subtle point in the existing RFC(s) that can
be misinterpreted by implementors and can cause problems in the real
world operation.  I support that, but I'm not really comfortable if
this document tries to set new rules or amend the published document
as long as we deem this document as a "clarification".  Of course, I
don't oppose to that discussion per se, which will eventually be
necessary anyway, but that should be performed more explicitly and
with seeking consensus among implementors that might be affected by
that action.  I'd like this document to concentrate on its
"clarification" work.

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