Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Job Snijders <> Wed, 22 February 2017 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 280741299AD; Wed, 22 Feb 2017 06:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.936
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DLe53W_jbgP9; Wed, 22 Feb 2017 06:42:40 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EFA11299AC; Wed, 22 Feb 2017 06:42:40 -0800 (PST)
Received: by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1cgY7c-0000ru-WA (; Wed, 22 Feb 2017 14:42:39 +0000
Date: Wed, 22 Feb 2017 15:41:47 +0100
From: Job Snijders <>
To: Lorenzo Colitti <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <>
Cc: 6man WG <>,, IETF-Discussion Discussion <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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,