Re: draft-bourbaki-6man-classless-ipv6-00

Lorenzo Colitti <lorenzo@google.com> Wed, 14 June 2017 10:13 UTC

Return-Path: <lorenzo@google.com>
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 36741129B9C for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 03:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 vER1yuUGLm6U for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 03:13:06 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACB8129B9B for <ipv6@ietf.org>; Wed, 14 Jun 2017 03:13:06 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id h39so91696652uaa.3 for <ipv6@ietf.org>; Wed, 14 Jun 2017 03:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=beamlqL2j8DHm254tFFIp7vgxCJQNuzFNjP2jJIqKo8=; b=RiO2olGwYmnfm8gxImAyht0nZN3EetirXUaSKUppLl+rVz/Yl9ZR0NM6Ob2fbCDLgB HX0FuQxQitSSH78ZPhGJ7ll2JWu6S6v/wv/Fpi0U1XNzE7KizEF4ZClOpDt3+cZ2Snkt vaFYo9i3MCMN6OUbJgkhExuGZAHdcyDfygPSGU6Ixh44vCLyCOLqCZYaYMSEvyzsyRR6 PtgEUTpBq1B87N+Zw9J9NwRRMrtwCJu08wcUQ58Td14DNufKOZPWtzmCDNXwj/8Vtinj 5ruMdwpBtDo10O6LfUawWjtBjAQ+9ckmLNhXK76wxxP31Uk0bO/D0WNIy8Z/HKd1B/fs V2Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=beamlqL2j8DHm254tFFIp7vgxCJQNuzFNjP2jJIqKo8=; b=QMk83R14/dZodMMXAbizVy2CVpxuvjUxXg244N/txesIr1R230hruz0yQpP7/I+aMs AlIwQ9kOpV0Sqtx4ELX5tGgzCULHWoeE5oI1+XpWqmVsZ17umG+J+7sW5W/mU8yr9HU4 7nD2/31+Q2TF+9t8iP6pSSw8zj4902fu8qqZvERqg/Xw2z0/Ibkh3BlX7R3x3GzJJkLm gbO5+BUzIGKmU4pFQuDj3X02ws2/XU3+QN9BubEOfY1zFpNuqSyGIINAxUfZM3QWPubX yjlQtqk0ULR7qhyafQm9+UEIs7pF0A06f1BMTFfsb95kkdOkqpRYsEAnlAHbfXOqDyIb a94w==
X-Gm-Message-State: AKS2vOy3pu+sPxHClJz79K0VB1gmfnradYxh0PpzTlweZvSeopwdMZ0p e/2jRSN8o957r8adxoqHCBS4SJLyWgB5
X-Received: by 10.176.6.132 with SMTP id g4mr2346858uag.20.1497435184790; Wed, 14 Jun 2017 03:13:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 03:12:44 -0700 (PDT)
In-Reply-To: <20170614095910.GE30896@gir.theapt.org>
References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <E61AFFF1-0354-41EE-8E11-50433B26BAF7@employees.org> <20170614094034.GC30896@gir.theapt.org> <A7502902-245B-499B-916B-28630CD5A824@employees.org> <20170614095910.GE30896@gir.theapt.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 14 Jun 2017 19:12:44 +0900
Message-ID: <CAKD1Yr2C74Nd+NSe5MfTpaQ0z1HSotVXCohK9uDYc0sqR3rMLg@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: "Brian E. Carpenter" <brian.e.carpenter@gmail.com>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>, Peter Hessler <phessler@theapt.org>
Content-Type: multipart/alternative; boundary="94eb2c123900444e4f0551e8cca2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XnRfXEqu1boNP5-tUzuJZmIkNHQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Jun 2017 10:13:08 -0000

On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler <phessler@theapt.org> wrote:

> I'm already running non-/64 subnets on my personal networks.  I'm also
> running non-/64 subnets on my $work networks.
>
> mandating /64 subnets in the _architectural specification_ is a bug,
> period.
>
> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century
> as well.
>

Brian (and everyone on this thread, really): QED.

Peter, thanks for writing this email so clearly. I think we now have a
clear example of what some operators will feel encouraged to do if we
change "is /64" to "should be /64". With the the current state of affairs,
such networks happen to work but are not guaranteed to interoperate, and
host implementations are not required to work on them. If we change the
standards to admit that subnets may be non-64 bits, there will be pressure
on implementations to conform.

Even if this sort of opinion were a minority opinion among network
operators, it is the nature of networking software development that host
implementations adapt to the lowest common denominator. Let's not do that
here. There is no technical reason to do so.

This is exactly the sort of scarcity thinking that the 64-bit boundary is
intended to avoid. Let's ensure that such limitations - which as Peter
says, belong to the last century - stay in the last century and do not
enter this one.