Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Brian E Carpenter <> Thu, 09 February 2017 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64F7F129409; Thu, 9 Feb 2017 14:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 M1zN3aS9Wfbl; Thu, 9 Feb 2017 14:55:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55F3512945F; Thu, 9 Feb 2017 14:55:23 -0800 (PST)
Received: by with SMTP id e4so1077888pfg.0; Thu, 09 Feb 2017 14:55:23 -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=qdiANBhIoelzfEgV7yU3YVYocdoD72vozdqoP1HAIDA=; b=GZrPYQoYtWgHU9MN8s8sxHBmYuPGUL1gOaQNK42HzEAYokE6CXo8+YH2+O3WeEwyC2 2UlnC2ECboU1QiBbWLBcJOryBDiYDLvJv6fcgRd8+kmnRVBEmE54OffOIpdqpTpVUPTH GEx/QwDcM2x/ruTjnna5/VfCsR2rwyUF4/PgPuKAH1uPKQZ51sHl4m08G9mUfjCJ7wZX 4CBdFVVwo8B8fTqZRjaitUq+iQhcLhesypekQ+WVt39X0HrSi3ne8BtG4zSA704BXi5T TpaJXh0X0rx4nopRVVkbvCxG/oMZw4Y/3g4Y+nO0qYPUqbWjFOrMO2bwFWUir7JdFGsU JPHg==
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=qdiANBhIoelzfEgV7yU3YVYocdoD72vozdqoP1HAIDA=; b=B4QszF2fLGH2Thr0xMvgUbnQs2bS/q1OzfAXaB1Yzxzw/KP4lX3rqEFNiSPxJ/n0W5 B6EJTptcuePt5yu4dNAkr4BsWV+EwdeDcuH0hQeF52WgOrtHS8O8NS76Ow+SVI0qAvvH oH+d563EHxA9TKvJJYACrP5Zr1qF3YQAjhzgzeaQsFix5qrQd0t233drJ3qz+kYIZimw nPAtivF14x1s6nsmPgE5VTyjDwxzV5ow2joA1qB7jSAZ4obsHvunojAAIecjq/c3wBCs 0kQQheVLf/sON4dxHSnhCxrMW3MkKAQqBcByyLClwJukdefLynUqkuWZM5IafPV/QNtG w25w==
X-Gm-Message-State: AMke39n/XF6rQdyPtYa9aeHKeLgPvj+sTuV3tuo9MZtr+CbAD0n4rZNo5YeAjPMOVyKy+w==
X-Received: by with SMTP id 30mr7260769pla.128.1486680922827; Thu, 09 Feb 2017 14:55:22 -0800 (PST)
Received: from ?IPv6:2406:e007:7ac3:1:28cc:dc4c:9703:6781? ([2406:e007:7ac3:1:28cc:dc4c:9703:6781]) by with ESMTPSA id 88sm31453517pfr.41.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 14:55:22 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Fernando Gont <>,
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 10 Feb 2017 11:55:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, Pete Resnick <>,, IETF 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, 09 Feb 2017 22:55:24 -0000

Hi Fernando,

First let me say that I though Ole's summary was fair. One comment below:

On 10/02/2017 10:30, Fernando Gont wrote:
> On 02/09/2017 07:36 AM, wrote:
>> Fernando,
>> Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
>> I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.
>> I don't understand your message.
>> Do you disagree with the summary itself? Are there arguments missing?
>> Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?
>> Or are you just rehashing your position on the issue?
> I think that some points are not as clear as they should be:
> 1) The current state of affairs with respect to IPv6 EH insertion is
> that insertion is forbidden. It has always been clear to everyone.

I don't think it has. In fact, that's the whole point: some people
have *not* deduced that rule from the RFC2460/RFC1883 wording.


> 2) However, some folks came up with proposals to insert EH, on the basis
> that "RFC2460 does not explicitly ban EH insertion". If there's people
> arguing that, we clearly need to make this clear in the spec.
> 3) There was a consensus call, yes. When the call was made on the
> mailing-list, the vast majority of supporters of "let's keep the
> ambiguity" were folks from the same company as "2)". I have no idea if
> this changes (or not) "consensus"... but this is clearly an important
> datapoint.
> 4) Given "1)" and "2)" above, it should be evident that the spec needs
> to be crystal-clear on this topic.
> 5) Arguing in favor of keeping ambiguity in a spec that has generated
> 600+ messages in the very group that standardizes the protocol pretty
> much reads like "Let's publish a lousy spec!". And I think that would be
> very bad. We're talking about something that is at the core of the
> protocol, essentially "Is IPv6 an end-to-end protocol?". I would expect
> rfc2460bis to answer such a very basic question, and I'm curious how we
> could move a spec to (full) Standard without answering such a basic
> question.
> There's no grief at all. If anything, just a concern that some of these
> items might not be clear enough, and, in particular that without the
> datapoint in "3)", folks might get a misleading interpretation of the
> discussions that happened in th wg. "3" could be read pretty much like
> "all folks from the same company that has a proposal to insert EHs what
> insertion of EHs to be allowed".
> Thanks,