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

Brian E Carpenter <> Thu, 23 February 2017 03:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 634BF12952E; Wed, 22 Feb 2017 19:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e02v_gz9WgNI; Wed, 22 Feb 2017 19:44:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D67A51294CC; Wed, 22 Feb 2017 19:43:58 -0800 (PST)
Received: by with SMTP id p185so732746pfb.0; Wed, 22 Feb 2017 19:43:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wQjEzg+XkiRrkw21WP273ikYruqMe/OQ2xV0TvFcTXk=; b=Sg02CUh4Nf+z+JLi+rKmFg3tTzQxOfes9Jj+j4LcwSwOuz1aL/pOlndQiYzN3HddXi bwB6APPghwxQq+ZyI+3uO8J/tQ02+pC0dqQ/yME5uraZP++yoKVpRVQA/yU2/tWWD066 aiNcVvlFiJ51j5XrNKdefCGs+hDzU5m7UuUxLzA3lPx1+TSZYVBk4XTMo2MOchrUeQLn V0Lu3MW/7ylLKvlE4JGRRCtggRyugfJ1APZ5F2q7g2u3ECr382WF9m/tA0OHs66EG8Ga IYTn3at1nbO18klbk+7qQB0WG3Mn3IEWrm4vKB18nOX3W1wmcjEeGgBG4xA/Jphp2laU RfIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wQjEzg+XkiRrkw21WP273ikYruqMe/OQ2xV0TvFcTXk=; b=csOMxudL2WFEfHMUh8tceF5HvWxZTBR84JZqjlA/T5oQgNjSNlMHswJAIiJSBe5v7/ PFrXH/4T1S/G+XSvTeDn3fI0vbuTaFTWmIswiz84BAPsN6OkjkqIfpvvAyms0g1JiISu dahNbRFVUBKyAGySCMskF3VsKYPn3dNp+20BosttOn3M2kSaMSCghJdkGBjGU+rA/j2a ZPOs//RNxQFxvv1rnkKs+Tn0i2cRxSnZYwVApnilUY2O+U+Xv0Pi7tpoJZs11Hva27iS P3AiNxhENlCsKzhOLldxXu6IGBmkCmhVFZzpDr7r+9KmFGMfi7VvTIYfz0bEzG71UXi2 i1mQ==
X-Gm-Message-State: AMke39mRHZotpFVONKcjA5WjOeIH0cLofcA2XirFYrzGw0NtplgtOVOt7Pt1Z0TsO2O79A==
X-Received: by with SMTP id z43mr52598839plh.11.1487821438300; Wed, 22 Feb 2017 19:43:58 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t184sm6199993pgb.11.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 19:43:57 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 23 Feb 2017 16:44:01 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Thu, 23 Feb 2017 03:44:03 -0000

On 23/02/2017 13:41, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 5:20 AM, Brian E Carpenter <
>> wrote:
>> Nobody is saying that /64 isn't extremely widely used where it's
>> appropriate to have a portable fixed length IID. Set the default
>> at 64 and trust operators to change it where they need to.
>> That's realistic.
> As a host developer I strongly oppose that. It will make life easier for
> network operators but make life harder for host OS developers, host
> operators, and host users.

I'm sorry, I'm wondering which word in my recent message that said
"I'm not aware of any generally available running code that will
be changed in even one instruction by the final text - that is indeed
a requirement for advancement to Internet Standard."
is hard to understand.

We are not suggesting to change the /64 usage in all the hosts that need to
use it. We are simply pointing out other nodes do and will behave differently.
/64 is an interop requirement on links that use /64. It is not an interop
requirement on links that don't use /64. RFC4291 is mistaken about this.


> And it is absolutely inappropriate to change this now in given that the /64
> boundary has been the standard for the last 20 years. It will break
> deployed code that relies on the current standard. (That includes concrete
> code I can point to that I know runs on tens of millions of devices.)
> That's not acceptable to do in a standard reclassification.