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(_at_)ntt(_dot_)net> 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