On Thu, Feb 16, 2017 at 3:09 AM, <otroan@xxxxxxxxxxxxx> wrote:
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.
So, is that code right or wrong? To be honest, I feel the current text says its correct to embed 64 in your code. If you truly think current text is correct, then have the courage of your convictions and embed 64 in your code too.
However, I take your example as evidence that the current text doesn't have the balance right. Is the proposed text too far the other way? Maybe. Well... actually probably it is too far the other way, but I don't see you even acknowledging there is an issue with the current text.
As far as I'm concerned, this is a policy statement masquerading as a technical requirement. Policy is all about nuance and shades of gray, and technical requirements are about clarity and making things ether black or white. The problem as I see it is, we are trying to use technical requirements language too describe something that is truly a policy issue. So we are probably doomed to fail!
How do we move forward? What I think we need is to make it clear that there are real exceptions to 64, and it is therefore not acceptable to embed 64 in code. The historic exception of addresses that start with 000 has been too amorphous, no one thinks it real. I've provided two exception that are clearly based on current standards track work, but I fear that still isn't enough. I fear some will still embed 64 and just add code for the exceptions, if it's even really needed.
Can you help me find something a little more?
What about an additional exception for manual configuration?
Thanks.
-- ===============================================
David Farmer Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
David Farmer Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================