On Wed, Feb 22, 2017 at 11:20:33PM +0900, Lorenzo Colitti wrote:
On Wed, Feb 22, 2017 at 7:46 PM, Job Snijders <job(_at_)ntt(_dot_)net> wrote:
One of the immediate benefits of using a /126, is that it's not a /64!
That argument is nonsensical. You can't prove that A is better than B only
by saying that A is not the same as B.
Since you are unwilling to accept that there could be downsides to using
a /64, i understand the argument makes no sense to you. Reasonable
people can disagree with each other.
Also, a /126 is the smallest non-64 size with the highest likeliness
to get the job done from an interoperability perspective (not the
/127).
I don't see how you can simultaneously argue that /126 is good because
vendors don't implement the RFC 6164 and allow /127 AND that you want
to change the standard. If vendors don't implement the standard, then
what good does changing the standard do you?
Don't you see the common theme here? The "standard" is a red thread.
I'm advocating to align the Addressing Architecture documentation with
operational reality and operational expectations. If vendors support
/64-/127, and if operators use /64-/127 - then you should not insist
that anything non-/64 is invalid. Its not.
The 64-bit boundry is useful in some contexts [SLAAC], nobody is
disputing that. The boundry is not useful in every context, especially
in the case of explicit configuration, and the documentation should
reflect and acknowledge that fact.
Why publish a document that conflicts with (almost) every deployed
global IPv6 backbone? This would be a farce.
Kind regards,
Job