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

Fernando Gont <> Fri, 17 February 2017 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC8FB129AA2 for <>; Fri, 17 Feb 2017 06:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U52B2GLeO-Ic for <>; Fri, 17 Feb 2017 06:28:27 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E9D2129AA0 for <>; Fri, 17 Feb 2017 06:28:27 -0800 (PST)
Received: from [IPv6:2001:1291:200:42e::2] ( [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F020B80C03; Fri, 17 Feb 2017 15:28:23 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 17 Feb 2017 11:28:12 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Feb 2017 14:28:29 -0000

On 02/17/2017 11:12 AM, wrote:
> Fernando,
> It is a simple logical consequence.
> Middleboxes do not exist in the IPv6 architecture.
> There is no interpretation of 2460 that can lead to an implementor inserting headers other places than at the source.
> Therefore, there is no interoperability issue in RFC2460 nor any ambiguity that needs to be resolved in RFC2460.

lAt the Last 6man meeting there was a bunch of people arguing that
inserting EHs was "ok" because "it was not explicitly banned" -- the
"interpretation" :-) at the time being that "'processed' doesn't mean

I asked you whether EH insertion was allowed, and you didn't answer the
question, even after asking multiple times (it should be in the audio

Now you say the above. When did you change your mind?


1) It was clear to everyone that EH insertion wasn't allowed.

2) Some folks came with a funny interpretation, such that EHs could be

3) Lots of supporters of EH-insertion (mostly from the same company)
argued that "it wasn't forbidden". And this wasted lots of people's time.

So a clarification is warranted. That's it.

P.S.: And then folks wonder why people "give up"??

Me, I'm not wasting more time on this. It should be pretty clear to the
IESG what's going on here.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492