Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Address

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

signature.asc
Description: Message signed with OpenPGP