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@xxxxxxx> 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