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 14:42 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 280741299AD; Wed, 22 Feb 2017 06:42:41 -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 DLe53W_jbgP9; Wed, 22 Feb 2017 06:42:40 -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 4EFA11299AC; Wed, 22 Feb 2017 06:42:40 -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 1cgY7c-0000ru-WA (job@us.ntt.net); Wed, 22 Feb 2017 14:42:39 +0000
Date: Wed, 22 Feb 2017 15:41:47 +0100
From: Job Snijders <job@ntt.net>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170222144147.GC89584@hanna.meerval.net>
References: <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zCtdvQNYy0ZKYpDadPEHQkuH7vE>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@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: Wed, 22 Feb 2017 14:42:41 -0000

On Wed, Feb 22, 2017 at 11:20:33PM +0900, Lorenzo Colitti wrote:
> On Wed, Feb 22, 2017 at 7:46 PM, Job Snijders <job@ntt.net>; wrote:
> > One of the immediate benefits of using a /126, is that it's not a /64!
> 
> That argument is nonsensical. You can't prove that A is better than B only
> by saying that A is not the same as B.

Since you are unwilling to accept that there could be downsides to using
a /64, i understand the argument makes no sense to you. Reasonable
people can disagree with each other.

> > Also, a /126 is the smallest non-64 size with the highest likeliness
> > to get the job done from an interoperability perspective (not the
> > /127).
> 
> I don't see how you can simultaneously argue that /126 is good because
> vendors don't implement the RFC 6164 and allow /127 AND that you want
> to change the standard. If vendors don't implement the standard, then
> what good does changing the standard do you?

Don't you see the common theme here? The "standard" is a red thread.

I'm advocating to align the Addressing Architecture documentation with
operational reality and operational expectations. If vendors support
/64-/127, and if operators use /64-/127 - then you should not insist
that anything non-/64 is invalid. Its not.

The 64-bit boundry is useful in some contexts [SLAAC], nobody is
disputing that. The boundry is not useful in every context, especially
in the case of explicit configuration, and the documentation should
reflect and acknowledge that fact. 

Why publish a document that conflicts with (almost) every deployed
global IPv6 backbone? This would be a farce.

Kind regards,

Job