On Wed, Feb 22, 2017 at 11:53:29PM +0900, Lorenzo Colitti wrote: > On Wed, Feb 22, 2017 at 11:41 PM, Job Snijders <job@xxxxxxx> wrote: > > > 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. > > I stand by the position that "/126 is better than /64 because /126 is > not /64" is a nonsensical argument. Saying "/126 is better than /64 > due to reasons A, B, C, ..." will likely be more effective - well, > depending on what A, B and C are. But I haven't heard much in the way > of supporting evidence from you other than "my network uses lots of > prefix lengths thus /64 is bad". That in itself is not convincing to > me. Perhaps I am missing something else you said? Apologies to the working group for having to repeat these refences again. rfc6164 and rfc6583 are great examples that document considerations regarding not using a /64, it simply is not always the best fit. Their very existence show me that one can legitimately state "i want to use something other then a /64". The tandem of RFC 3627 and RFC 6164 is what caused both /126 and /127 to become popular in operational circles. While /126 does not enjoy the same recognised status as /127 from an IETF paperwork perspective, that doesn't invalidate its use and existence. Of course it is possible that two people look at the same data and arrive at different conclusions. > > Why publish a document that conflicts with (almost) every deployed > > global IPv6 backbone? This would be a farce. > > > > "Conflicts with the NTT backbone" != "conficts with almost every > deployed backbone". You gross over the fact that NTT connects with many other backbones, and that the data I shared is a reflection on both NTT's own addressing structure as well as peering partner's or customer's addressing. When NTT interconnects with another network, both parties have to agree on a prefix and prefix length, and which party will use what IP address. Thus, if the other party proposes and configures a /126, NTT will also configure a /126. As such, I am confident to state that almost every deployed backbone uses a mixture of /64, /127, /126 and perhaps other lengths. This information can also be gleaned from public resources such as PeeringDB, public BGP Looking Glasses and hallway conversations at IETF. > The backbone I am familiar with uses a combination of /127, /64, and > link-local point to point interfaces, or at least it did last time I > checked. There is public data that suggests that the backbone you are familiar with might be connected to a public internet exchange which uses a /112 as peering lan prefix. I hope this won't cause an existential crisis! Of course one such anecdotal datapoint is worthless, and perhaps it is childish of me to bring it up. I hope you'll share my amazement at all the curious things that together form the internet. :-) The key point here is that there is a larger pattern of '/64 avoidance' amongst internet backbone operators, and that needs to be acknowledged in the Addressing Architecture document. There have been numerous suggestions to improve the text. > Also, backbone networks are a tiny percentage of the links on the planet. I certainly will not deny that fact. Are you familiar with the concept of the McNamara fallacy? Kind regards, Job