On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
The problem is (and why we wrote 7421) is that stuff breaks with subnet
prefixes longer than 64, *except* for the point-to-point case covered
by 6164. Yes, I see the problem in enshrining this but I think we face
signifcant issues if we do otherwise.
Also, RFC7934 says that networks that provide service to general-purpose
hosts should be assigned /64 prefixes to avoid address scarcity. Networks
that provide service to general purpose hosts make up a lot of the Internet.
What we could conceivably say is that /64 is mandatory except for
links where SLAAC will never be used. (SLAAC itself is designed
to work with any reasonable length of IID, but again in practice it
only works with /64, because we need mix-and-match capability. So
although IID length is a parameter in the SLAAC design, it's a
parameter whose value needs to be fixed globally.)
I don't think that's a good idea.
I strongly believe that unlike most areas of the IPv6 protocol where it is
a good idea to automatically apply the lessons we learned in IPv4, in the
specific field of IP subnet sizing, we should *not* automatically translate
IPv4 practices to IPv6. This is because the difference between 32 bits and
128 bits is large enough that the semantics are fundamentally different. We
may be lured by the fact that 128 is just 4 times larger than 32, but the
difference is huge - remember that even just the first 64 bits are 4
billion times larger than the whole of the current Internet.
So while Randy may well be right that we will move away from classful
eventually (we certainly never had it in the top 64 bite of the address), I
don't think it's necessarily a good idea to do that now. Let's have that
conversation when IPv6 deployment has reached 90% and we have experience
running the whole Internet with IPv6.
For now, I'd much prefer to just add a similar exception to the one we have
in 7421.