On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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.