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

Job Snijders <job@instituut.net> Fri, 16 June 2017 05:07 UTC

Return-Path: <job@instituut.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 2C284129420 for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 22:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 a5vTMZmBNw1a for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 22:07:26 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 6358B1200F3 for <ipv6@ietf.org>; Thu, 15 Jun 2017 22:07:21 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id d64so1259010wmf.1 for <ipv6@ietf.org>; Thu, 15 Jun 2017 22:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eTYFG4efwi9Gp1+XNhTYHwhRJfh2JHIUzJzlLfLlxOw=; b=Vc43VIi4BKlhouR+6LmzS9ZNjykW8IvpGOnHaGr9fIC9PX1f4gEtCUvfBdAslPmw39 fO6v4rKGw7yjc1IhevhXtA+tO3TB4on6Eeyhl7IALB4F7O3oBtqDY9LgGOf3VeJtr4gI aGCruW9uE9w6Rl1YrpdyUr+bhFp9Ma76bCXv3HhPL2f9ciqm5Kx3EqUW2Ho1gCOu6H2o d3wfTvsi/2y6dWQm0B8O127pQSn3tH2PoGvTBZIURcysJyki7T5mtXTix2COZM0+w5ZU msifBcLIcaDu72nM+J1uMQdb7iC4xPrxGzvRNPycT3yB8FSiYIhuAzXHW++miGpO744o SNMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eTYFG4efwi9Gp1+XNhTYHwhRJfh2JHIUzJzlLfLlxOw=; b=pSkTLXRDlQXru/CmZKZvSnlyUY0I3ldBtfTz0o47N6TXPQ10ikZ54aIozlNsufSkhW Ncrm/CIZ//bE0yQp4ybbWablGvZbNJNmPVrDRL4hQdCgifyil6mRoRcIs50uuioMXhV7 rhGwuAsdb7CNFtOd8dgwqzlx/tv26F7UmpVAnZEidevb25Xlu1QkPiZvdpX+8S4s4pS9 fchtgFg1G0IZjgtu0fe38eXo0wyS/9XKvdDJJcWeKzH/ZfKfd4SS7vlx+vCpYNFwAF67 emZ/X7dUmuQNd+AEcdxRBL1ptwrik3vKZgdfMh60kGRqrVMF+UpAHt+nceugJGowIJvV fIwg==
X-Gm-Message-State: AKS2vOwtjMUHXuFEtJMRmL01isVbUtEztolawdf8Y2R523SimIFYfi2w 0k5sG44bvHhQRPYI
X-Received: by 10.80.151.71 with SMTP id d7mr5974028edb.163.1497589639857; Thu, 15 Jun 2017 22:07:19 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:48ae:a8c:82e7:c07b]) by smtp.gmail.com with ESMTPSA id m30sm732859edd.11.2017.06.15.22.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 22:07:18 -0700 (PDT)
Date: Fri, 16 Jun 2017 07:07:18 +0200
From: Job Snijders <job@instituut.net>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, IETF IPv6 Mailing List <ipv6@ietf.org>, Peter Hessler <phessler@theapt.org>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
Message-ID: <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net>
References: <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> <CAKD1Yr1X12T10qsUtFau2neUnA0yVnOkMsAk5UOB-KjS7qxNTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKD1Yr1X12T10qsUtFau2neUnA0yVnOkMsAk5UOB-KjS7qxNTw@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170428 (1.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sM_MOtMCqcmHjFhlEtQUOWLDUMQ>
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 05:07:28 -0000

On Fri, Jun 16, 2017 at 01:39:43PM +0900, Lorenzo Colitti wrote:
> On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > 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.

That is quite the accusation.

> > 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.

Even if it is as low as 0.1%, has it ever occurred to you that that
small number might serve a majority of IPv6 users in non-trivial
matters? For example, their ability to reach each other? It is a shame
to see such blatant disregard for this group of IPv6 users.

I've shown before that 6164 accomodates some, but not all cases for both
historic and pragmatic reasons. 6164 does not solve all operational
challenges.

> 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.

You realise that the above remarks come across as extremely judgemental?
Who do you think you are to know what is good for all groups of users?
I still simply argue that nobody can know what is needed in every
context in every situation, pretending otherwise would be folly.

It is painful to see you view operators as some kind of minority (a
nuisance even?), and as such they don't need or deserve to be
accommodated by standards.

Regards,

Job