On Sun, 2016-03-06 at 13:53 +0200, Saku Ytti wrote:
Yes, SLAAC, 4862 clearly does not forbid it, and there is no technical reason.
Well - yes, there are some, and I think I pointed out several.
Writing new draft which specifies behaviour for arbitrary size wouldn't be a challenge
I think you may find it more difficult than you think. But by all means write that draft.
From implementation POV, arbitrary prefix-size from 4862 is fairly obvious and logical, and dictating 64 is very weird, with no obvious benefits at all.
/64 has a lot of benefits (some one which would be shared by any fixed -length prefix, some not), but I'm not sure detailing them here would be appreciated. They've all been gone over at length here and elsewhere many times before. As Tore just wrote before I finished this :-) there's even a collected summary of many of pros and cons in RFC 7421, which by the way has lots of good references.
that's only background that I can imagine where mandating /64 might be remotely sane thought process.
The argument from personal incomprehension is not a very powerful one.
I can't recall where it would be worded so harshly.
Dunno about "harsh", but RFC 2464, section 4 says that the prefix must be 64 bits. By (extremely strong) implication, a host must not use a prefix of any other length to perform SLAAC. I say "extremely strong" because the entire description of how an IPv6 Ethernet interface identifier is formed depends on it being composed of the prefix plus an EUI-64 identifier. Later RFCs firm up the requirement and apply it in other contexts. BUT: Other prefix lengths are fine for anything except automatically formed interface identifiers, as far as I know. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4