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

Lorenzo Colitti <lorenzo@google.com> Fri, 16 June 2017 04:40 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 C4420124D6C for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 21:40:07 -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 hRRzoaVJV9vO for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 21:40:05 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 9151A1200F3 for <ipv6@ietf.org>; Thu, 15 Jun 2017 21:40:05 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id j53so5783410uaa.2 for <ipv6@ietf.org>; Thu, 15 Jun 2017 21:40:05 -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=/tbDLqGzf0tYJKSmLgVJVUMx66z6FTs25Rjh4yTjefA=; b=bNNIrOCrF+1sHrOWzoGtMZZ4s3CTCDYimECfkjjgyNcsOm1qkrJOz8RBvl7MGTaAPQ F+28YiL+ISLL7hxKtLUfI4ougPInS7+Ds/7Hch3UHoqQOY/Q9jjhxi5dPX6hSKjHc/Kk C3Oe70Guai68T7UMeCRppTZoZKMQ5jHdStlGAUzqjZUPSCGU6JGmZg5KG0X4hm+JYSZb tRpMyf7vz2q8U/ketI2sLhU6Gic5l0VZCyYDa0Nu54H9xwHI0sdw2MKfUY1CH4tiJfiQ YX9dt/qxMHcJlNDW4Nku+95ipohfYJVuAd0JHdYTuKcEMNFQ1Hy+NLIIL9iZT0dUp1Ie 5tKA==
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=/tbDLqGzf0tYJKSmLgVJVUMx66z6FTs25Rjh4yTjefA=; b=p/rNxWM0eQwzTF24oMPmMkGVdG/MbaGGPDQqtv3iQXtOIg9Dj0KVTs0UgRlLZFpBT7 GRl4xkR4FsgUiWCgSRjeeN49M7AccF4LB4kq3FHZAzzDw1+JIOh23jDci23HKUZEBPgv lzkfD2pjAXy/X0SHDXlrBY0rfIHnR8UaYJtLNNF2mN5adq4YKd5FcluBwjsqP+k2/+vM ecQgIuoecRqyT/COYa84qf6HCnP4+27AXXqwC8FptG90bX/ktqvelbT6oJbZmd14BX1E +CHtENWXmc3CBOOCchxfu+FBI8C6ykm/nEtCj21ZkBIM7+gkgIrOJzsximQIErHIti5/ DS8Q==
X-Gm-Message-State: AKS2vOwlnO+qQw5ykaWG69b3xK8Z+MLE+Xszn2CzOuAzOCabWb6AVQLk uNBtVIUjmVo8BPNcpJXHqK7SEQWKgyWV
X-Received: by 10.176.83.16 with SMTP id x16mr5904611uax.11.1497588004482; Thu, 15 Jun 2017 21:40:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.12.139 with HTTP; Thu, 15 Jun 2017 21:39:43 -0700 (PDT)
In-Reply-To: <edbf9bf8-cd15-c0e6-f0f8-19f96f6333b2@gmail.com>
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> <CAKD1Yr2C74Nd+NSe5MfTpaQ0z1HSotVXCohK9uDYc0sqR3rMLg@mail.gmail.com> <edbf9bf8-cd15-c0e6-f0f8-19f96f6333b2@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 16 Jun 2017 13:39:43 +0900
Message-ID: <CAKD1Yr1X12T10qsUtFau2neUnA0yVnOkMsAk5UOB-KjS7qxNTw@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="94eb2c18f1ac07502605520c61ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-ukG5ROw93KExfs-lFDLYbxRNmw>
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: Fri, 16 Jun 2017 04:40:08 -0000

On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> I think that portability out of the box is a much stronger argument. Peter
> has chosen to hand-craft his networks.


... and hand-crafting networks is precisely what network operators do. It
is, after all, their job.


> Most people (99.99%) simply unwrap
> their new device, ignore the "quick start" guide, and switch it on. There
> is an enormous market incentive for that to work 100% of the time, which is
> an enormous incentive to stick with /64.
>

Your premise is correct but your conclusion is wrong. Yes, there is an
enormous incentive for things to work 100% of the time. But that does not
mean stick to /64. Quite the opposite - it means "work regardless of the
prefix length on the network". Before you disagree with me, observe the
fact that most implementations work on Peter's network, today, even though
Peter's network is in complete violation of RFC 4291.

Not to mention the late lamented /48 recommendation to ISPs. Again,
> nobody is trying to sabotage /64 as the norm for SLAAC networks, and
> nobody is trying to sabotage SLAAC as the norm for plug and play.
>

I know that you're not *trying* to do that. I'm trying to make you realize
that by pushing for a non-fixed boundary you *are* doing it.

As for "nobody" - it's not true that nobody is trying to do it. If you read
Job and Peter's statements carefully, you'll see that they are.


> I agree. But at the same time we need to be honest in our specs. RFC4291
> does not describe the deployed architecture accurately, which is why
> we have to fix it if we're serious about Internet Standard status.
>

That's not true for any value of "accurate" that is meaningful in the real
world. I'd argue that RFC 4291 (with the exception made in 6164), is
accurate for at least 99.9% of links on the public Internet.

Making it accurate for the remaining 0.1% is not worth removing the text in
the standard that stops operators like Peter being able to claim that hosts
should support addressing models that are bad for their users.