Tatuya,
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."
We can add such text to the draft against bullet 3 and also add text
that even address SHOULD NOT be cached like we say for on-link
determination. Notice our rule is also not very strict by saying "MUST
NOT". It's a SHOULD NOT. With the SHOULD NOT also including address, we
still do not go against any existing RFC and also allow an existing
implementation to still cache the address if the implementation wants
to.
3. On-link determination and IPv6 address SHOULD NOT persist
across IPv6 interface initializations. This is a new requirement
compared to [RFC4861]. If such information is cached, there is
risk associated with cache-inconsistency problems, prefix
renumbering,
or stale information. It is better to just get information fresh
from RA's. That way, administrators can better rationalize the
behavior
of their network from the configured RA's.
Thanks.
Hemant
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 8:35 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 Wed, 9 Jul 2008 10:08:02 -0400,
"Wes Beebee (wbeebee)" <[EMAIL PROTECTED]> 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
--------------------------------------------------------------------
