IPV6 planning

Karl Auer kauer at biplane.com.au
Sun Mar 6 12:39:49 UTC 2016

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 at biplane.com.au)

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

More information about the NANOG mailing list