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

[Erik Nordmark <[e-mail]>]

JINMEI Tatuya / 神明達哉 wrote:

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

Jinmei,

there are currently two places where we treat autoconfigured addresses 
differently than on-link prefixes.
One is the text about storing the address and associated lifetime in RFC 
4862 that we are debating here.
The other one is the 2 hour rule that was very explicitly added only for 
the addrconf property of the prefix and not the on-link property.

I don't recall the different treatment for the first case.
But for the second case I clearly recall the argument that loosing the 
IP address (by an accidental or malicious RA with a zero valid lifetime 
for the prefix) was considered a lot worse than loosing the on-link 
property. Basically that loosing the IP address for a short time (it 
might be re-added by the next RA) is something we must avoid, but that 
"routing" (the on-link property) is something which must be able to 
recover from temporary failures in any case.

[I don't know if the same argument was present when the storing of 
addresses was discussed.]

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

If we are going to require that all aspects of a prefix should be 
treated identically then to be consistent we must also make the 2 hour 
rule be consistent (by either removing it for the addrconf property or 
adding it to the on-link property).

FWIW I think forcing such consistency is not necessary; it would just 
result in unneeded changes to already deployed standards.

Is your concern that there are deployed implementations which store 
on-link prefixes across reboots?

Regards,
    Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------