Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard Thu, 09 February 2017 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CB9812996F; Thu, 9 Feb 2017 02:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nceBm3P88maP; Thu, 9 Feb 2017 02:36:53 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 587BC129967; Thu, 9 Feb 2017 02:36:53 -0800 (PST)
Received: from ([]) by with ESMTP; 09 Feb 2017 10:36:51 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 08D90D788B; Thu, 9 Feb 2017 02:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=IS07E1Yut2AHUKB9g53++fkVFnA=; b= cTHzCpUvpUx78eJZICsgISlnD9sf2leYcwI1Eqgjxxni8g34D7e5924GER+1nfjG 0XDN3NjiBWqwrQObC/srVeUbbU3YhdovGZUzF7TQ9RJJp+8X2TqI7xfcMKttdk+T 7zH3Kt2oLtMS9e7VjTa83uGFDRa/5McY2ZVQu+hgFXY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=NkucE+KZ0xHHYibHFotg/O+ bC5iIlWuGG4VT6511iHvaJh+EUcYhqXYZ0eZO1jFz6JDj8dmgqe5Wx8ByFqk3jky OENarVZv/iB8qprLHxDjM27Z1Oh+MSOFqjIvphcZhuWgDY9At5jOR4p10bdHaC2m VWuLM/rT7VvvSIaK90og=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id A60B1D7890; Thu, 9 Feb 2017 02:36:50 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 41D1B88226BF; Thu, 9 Feb 2017 11:36:51 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_460BAB5C-377D-4C7B-8984-D1E11437AE6E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Thu, 9 Feb 2017 11:36:50 +0100
In-Reply-To: <>
To: Fernando Gont <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc:, IETF Discussion <>, Pete Resnick <>,,
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 10:36:55 -0000


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?


> On 8 Feb 2017, at 15:25, Fernando Gont <> wrote:
> 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
> funny.
> 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
> protocol?"
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492