Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Job Snijders <[e-mail]>]

On Wed, Feb 22, 2017 at 11:20:33PM +0900, Lorenzo Colitti wrote:
> On Wed, Feb 22, 2017 at 7:46 PM, Job Snijders <[e-mail]> 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