On Thu, Feb 16, 2017 at 3:09 AM, <otroan(_at_)employees(_dot_)org> 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(_at_)umn(_dot_)edu
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
===============================================