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

Fernando Gont <> Wed, 08 February 2017 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 124C8129B1A; Wed, 8 Feb 2017 06:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iN_rAq3TRMwv; Wed, 8 Feb 2017 06:25:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0FCC129B20; Wed, 8 Feb 2017 06:25:45 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4726A809C0; Wed, 8 Feb 2017 15:25:40 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To:, Pete Resnick <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 8 Feb 2017 11:25:25 -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 <>, Stefano Previdi <>,
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: Wed, 08 Feb 2017 14:25:53 -0000

On 02/08/2017 10:51 AM, wrote:
>> There were three main positions argued in the working group.
>> 1) Ban header insertion outright. 2) Describe the problems with
>> header insertion. 3) No changes to RFC2460 text.
>> What did you see as the objections to going with (1) (which I
>> presume to be the equivalent of Brian's proposed text)? Why was it
>> that people thought the protocol could not be clarified to say
>> that? And was your assessment that those arguments were correct, or
>> that they simply were not addressed by the WG? I've seen several
>> people argue on this list that (1) was always the intent of the
>> protocol, and that damage occurs if you don't follow that
>> directive. I haven't seen anyone here argue otherwise. Could you
>> summarize?
> I can try. It has been difficult to distill the essence out of all
> the mailing list discussions. This is _my_ take of the discussion and
> arguments as I understood them. Please chime in with corrections.
> The arguments of what would break are correct. The counter-arguments
> given would be that this is done within a controlled domain and the
> potential for damage could be controlled.

There need not be "counter arguments". It was clear to everyone that
IPv6 never allowed EH insertion. If you want to change that, you have to
update RFC2460 (and if you do it before rfc2460bis is published, good
luck with moving it to Standard).

OTOH, if the argument is that you want to break a protocol in your own
environment, in which you can "control the damage"... why do you need an
RFC for that? why should we rubberstamp it?

> The discussion went something like (paraphrasing):
> - Inserting headers will break Path MTU discovery, AH and may result

You miss the most important point: EH insertion was never allowed in
IPv6.  Quite a lot of us find the argument that "we're doing EH
insertion because RFC2460 doesn't explicitly prohibit *insertion*" quite

I'm not against EH-insertion per se. I'm against what looks like a
procedural hack.

If people want EH insertion, fine: write a proposal that updates
RFC2460, and let's have the discussion. But please do not pretend that
RFC2460 allows EH insertion.

> in unsuspecting hosts receiving ICMP error messages. - We will do
> this in a controlled domain only. - Even if you can guarantee it will
> not leak, it is not appropriate to specify that in the core IPv6
> specification - We don't need that, we just need 2460 not to ban it.
> IPv6 is used in many networks not only the capital I Internet.
> There was also quite a bit of discussion on the intent of the
> original authors. I don't know how much value it is correct to give
> that argument. "This is what I intended, but not what I wrote...".
> Given that this is in any case the output of the IETF and not two
> individual authors.
> 1) Ban header insertion outright.
> b) RFC2460 is already clear and no clarification is needed. No
> interoperability issue has been shown caused by this perceived
> ambiguity.

RFC2460 already bans EH insertion. Only when SR wa published people
started to argue otherwise.

Given that for some guys there was room for EH insertion, we clearly
need to make the point clear.

> There was hard to find consensus on either of the alternatives. As
> the poll shows there was a clear preference (if people couldn't get
> their first choice) to describe the problem, over banning it, or over
> saying nothing.

Based on the mailing-list discussion, it was quite clear that most of
the folks arguing in favor of "ambiguity" were from the same company
pushing a proposal with EH insertion. That's not a minor datapoint.

Besides, moving a document to Standard with "ambiguity" on an item that
led to 600+ messages discussion at the same group that specifies the
protocol would be really bad.

We're moving RFC2460 to standard. I think it should be able to answer
the very basic question "Is it possible to insert EHs in the middle of
the network?"  -- or, framed in a different way: "is IPv6 and end-to-end

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