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

Job Snijders <job@ntt.net> Wed, 22 February 2017 01:51 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 C02621294E0; Tue, 21 Feb 2017 17:51:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 z84eaqKlTuiK; Tue, 21 Feb 2017 17:51:42 -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 225461294EE; Tue, 21 Feb 2017 17:51:41 -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 1cgM5Y-0008Xb-K0 (job@us.ntt.net); Wed, 22 Feb 2017 01:51:40 +0000
Date: Wed, 22 Feb 2017 02:50:41 +0100
From: Job Snijders <job@ntt.net>
To: Lorenzo Colitti <lorenzo@google.com>
Message-ID: <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark>
In-Reply-To: <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com>
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> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
X-Readdle-Message-ID: 54c81141-e4f5-4436-9479-9c02be6c09bb@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58acee89_109cf92e_1cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EEeHL76ZtD3Yj_nQVI12v9aqAf0>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@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: Wed, 22 Feb 2017 01:51:44 -0000

Perhaps you are jesting, but I'll bite.

Those "thousands of interconnections" facilitate the communication between millions of those hosts. Have you considered that not all interconnections are equal? The type of interconnection I am mainly (but not exclusively) referring to is the interconnection between Autonomous Systems to facilitate the exchange of routing information using BGP-4. Autoconfiguration plays no role here, everything is configured explicitly. I'd argue that the use case is hardly comparable with a residential or mobile connection.

Surely you don't mean to say that the Internet's backbone routers are irrelevant because they are the minority from a device count perspective? It's fine if you do, it'll help me put your comments in perspective.

In the last 15 years we've been through all kinds of phases, the observant reader might perceive an intricate tension between two schools of thought blossom, a dance even:

RFC 3513 "only /64 is valid"
RFC 3627 "don't use /127, use /126 if you must"
RFC 4291 "reaffirming: only /64 is valid"
RFC 6164 "a /127 is OK to use too"
RFC 6583 "there are problems with /64"
RFC 7421 "/64 is the best!"
RFC 7608 "every prefix length must be forward-able"
RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"

As pointed out in this thread, real networks use all kinds of prefix lengths. Also, one doesn't renumber everything every time a new document comes out - you stick to things that work for you.

Some vendors in this thread have admitted to strive to make things work with any prefix length, why is there then still a discussion that people must use /64 - when both vendors and users are not always doing so, for good reasons?

I'm confident this discussion will eventually resolve itself and conclude that /64 is not the only valid prefix length, rigid positions rarely are attainable. Water can flow or it can crash.

Kind regards,

Job

On 22 Feb 2017, 01:20 +0100, Lorenzo Colitti <lorenzo@google.com>, wrote:
> On Tue, Feb 21, 2017 at 7:13 PM, Job Snijders <job@ntt.net (mailto:job@ntt.net)> wrote:
> > I've looked at all configured IPv6 addresses on AS 2914 equipment.
> > The above percentages come from grepping through configurations of
> > thousands of interconnections. I'm confident that other networks will
> > show similar prefix length distributions.
>
> "Thousands of interconnections" are not really relevant given that we're well into the hundreds of millions of IPv6 hosts on residential or mobile connections that provide one or more /64s.