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

Job Snijders <job@ntt.net> Tue, 21 February 2017 10:14 UTC

Return-Path: <job@ntt.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558511298AB; Tue, 21 Feb 2017 02:14:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVA5gkI2b65G; Tue, 21 Feb 2017 02:14:06 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D317612940B; Tue, 21 Feb 2017 02:14:06 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cg7SH-000CpA-IN (job@us.ntt.net); Tue, 21 Feb 2017 10:14:06 +0000
Date: Tue, 21 Feb 2017 11:13:39 +0100
From: Job Snijders <job@ntt.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170221101339.GC84656@Vurt.local>
References: <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ltEO3Rd-0AIXT0CvngcSsp7Rjcs>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2017 10:14:07 -0000

On Tue, Feb 21, 2017 at 02:11:15PM +1300, Brian E Carpenter wrote:
> On 21/02/2017 13:19, Job Snijders wrote:
> > On Thu, Feb 16, 2017 at 09:40:01AM +0100, otroan@employees.org wrote:
> >> There are many reasons for the 64 bit boundary.
> >> - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
> > 
> > Irrelevant.
> 
> Not really. They are both running code. You may not want them in
> *your* network but that isn't the point. Some people want them.
> 
> And there is a lot of other running code too, not just SLAAC which is
> mandatory to implement in every IPv6 host. So this actually trumps all
> the other arguments: it's 64 bits because it's 64 bits.

When someone utters the phrase "it is X because it is X", the rhetorical
imperative seems to be to dismiss further conversation (perhaps any
internal dialogue as well, which may be the primary purpose). "It is
what it is" therefore, there’s nothing more to be said about it...

Except when it's not 64 bits?

> > If this is the case, why proceed 4291bis while its content is
> > contested?
> 
> What we're discussing is the exact text to describe the inconvenient
> truth. I'm not aware of any generally available running code that will
> be changed in even one instruction by the final text - that is indeed
> a requirement for advancement to Internet Standard.

The below is truth.

AS 2914 is one of the larger Internet backbones. If the Internet
Archives are to believed they started deployment of IPv6 15+ years ago.

I've looked at all configured IPv6 addresses on AS 2914 equipment.
Interestingly enough, the below table is a reflection of not only NTT's
own addressing, and (since AS2914's core function is to connect networks
to each other) also of its peers and customers. In the end, whatever
makes the thing work is the thing that will be configured.

	/127 - 22%
	/126 - 52%
	/125 - 0,9%
	/124 - 0,5%
	/120 - 0,04%
	/112 - 0,02%
	/64  - 23%

The above percentages come from grepping through configurations of
thousands of interconnections. I'm confident that other networks will
show similar prefix length distributions.

I'd be interested to see an accomodation for staticly configured
environments in the text.

Kind regards,

Job