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

Job Snijders <> Wed, 22 February 2017 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 776F1129A1E; Wed, 22 Feb 2017 07:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aEBcqH_Jd3iE; Wed, 22 Feb 2017 07:32:19 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E8AE129A1C; Wed, 22 Feb 2017 07:32:19 -0800 (PST)
Received: by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1cgYtk-0005xc-4W (; Wed, 22 Feb 2017 15:32:18 +0000
Date: Wed, 22 Feb 2017 16:31:29 +0100
From: Job Snijders <>
To: Lorenzo Colitti <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <>
References: <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <>
Cc: 6man WG <>,, IETF-Discussion Discussion <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2017 15:32:20 -0000

On Wed, Feb 22, 2017 at 11:53:29PM +0900, Lorenzo Colitti wrote:
> On Wed, Feb 22, 2017 at 11:41 PM, Job Snijders <> 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

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,