Dear Randy, >>>> If your statement is that we only have the 64 bit boundary because of >>>> SLAAC I believe you are wrong. >>> >>> cite, please. what else actually needs it? >> >> https://tools.ietf.org/html/rfc7421 > > that excuses it. cite where it is actually needed to do something > useful other than slaac. "something useful" makes it subjective. If you only care about technical issues, then: SLAAC, NPT66, ILNP are the biggest one that I can think of. Trivial to make SLAAC work with variable length prefixes of course. As well as we don't know the consequences for implementations. 7421 seems to indicate it mostly works. But then you have people who write code like this: https://git.fd.io/vpp/tree/src/vnet/map/map.h#n332 Where it clearly will not work with a longer prefix than 64. Feel free to contribute a patch, but make sure to count the cycles spent through that code. I expect you'll find that most implementations deal with variable prefix length reasonably well, as long as you stay away from any of the above technologies. There are many other issues here though, do we want to keep the option of an identifier and locator split open? Do the collective we trust the collective you to not put us into the same situation we had with IPv4 were users are forced to pay per address and instead chooses to deploy NAT? It is upon you to provide evidence and justification for a proposed change. Not the other way around. Write a draft. Best regards, Ole
Attachment:
signature.asc
Description: Message signed with OpenPGP