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 00:20 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 D6D5412943B; Mon, 20 Feb 2017 16:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WS6wQSHxOlo; Mon, 20 Feb 2017 16:20:21 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 5923D12945D; Mon, 20 Feb 2017 16:20:21 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cfyBW-0008e8-UE (job@us.ntt.net); Tue, 21 Feb 2017 00:20:20 +0000
Date: Tue, 21 Feb 2017 01:19:40 +0100
From: Job Snijders <job@ntt.net>
To: otroan@employees.org
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170221001940.GB84656@Vurt.local>
References: <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mug4z6Ly1_E3dqrxQp3Qpva7PeI>
Cc: Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@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 00:20:22 -0000

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.

> - Simplicity in addressing (no more subnet masks)

That seems an overly optimistic statement.

> - A fair balance between the users and the providers of networks.
>   Ensure that users get a fair share of addresses and try to avoid
>   operators charging per address.

IETF is not a product management committee. Regardless of what is fair
or just or reasonable, vendors will charge for the strangest things.
While I sympathize with the objective, I do not think this is the
appropiate forum to achieve such a goal.

Also, I think we here touching upon the very heart of the issue: some
would like to force every link on this planet to have a routable /64
(for perhaps ideological reasons), and some don't (for perhaps
operational reasons).

I'm from the school of thought where unenforceable rules have no place
in society. There already is precedent to abandon a classful addressing
paradigm in favor of classless inter-domain routing. This implies that a
the fixed 64 bit boundary is unattainable, as such, getting classless
IPv6 is merely a matter of expending sufficient energy.

> The 64 bit boundary is so embedded in the set of IPv6 specifications
> that it would be very hard to unravel at this point. It certainly
> cannot be a single paragraph put in during the advancement of 4291.
> Write a draft. Or write a book on protocol politics and the
> underlaying values reflected in the specifications...

If this is the case, why proceed 4291bis while its content is contested?
What purpose does that serve?  By publishing 4291bis, one would add yet
another referenceable source to legitimize the 64 bit boundary, which
adds to the pile of things that need to be 'unraveled'. Perhaps the buck
should stop here?

> PS: With an implementor hat on, I write code that can deal with any prefix length.

Excellent! Keep it up.

Kind regards,

Job