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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
