Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard Tue, 14 February 2017 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F36721294C2 for <>; Tue, 14 Feb 2017 10:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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] 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 C-d3dj9R7dpe for <>; Tue, 14 Feb 2017 10:59:44 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id EBCC2129739 for <>; Tue, 14 Feb 2017 10:59:43 -0800 (PST)
Received: from ([]) by with ESMTP; 14 Feb 2017 18:59:43 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 9BC6BD788A; Tue, 14 Feb 2017 10:59:43 -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=YkVufYEEk23ImnRC0oVrvTFRi5Y=; b= sX99y3UJqgr2MdNIiXS9oEBiX+nlKuoE565us0x5opCEa4VuYU0ejbL5rLnXi1MJ 2fGfoVH/exulkSDDB752Dy8JmfmuUwBXjVBMnVK2DlX4FHIimjILNdBH8bxkWttd Q9h4JAgaM41ZXHQVoo0lArfrEXuRUxOCr9/GLILQlR4=
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=i2fk2nGL9i1qfWWWuKKrSnZ /U4NbKZequUWIT+kCIFYVKirnxJEWY46d6aEv6kRiPNFYpvXNYgC2Chq3Xc6Gedr vHvwa361xwiAFsJmTH+wAD1b8w2Wi3jk22FcohVLvBM9XXE+mzC1vXu0r/6kWuAq UrCPQzb93oKZTKoxu8ak=
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 3EE4DD788E; Tue, 14 Feb 2017 10:59:43 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 388148ADFA4F; Tue, 14 Feb 2017 19:59:49 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_61DD03A2-BF32-430C-B198-CAC7EFDDC689"; 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: Tue, 14 Feb 2017 19:59:48 +0100
In-Reply-To: <>
To: "Joel M. Halpern" <>
References: <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
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: Tue, 14 Feb 2017 18:59:46 -0000


> There are two separate but related issues here.  One is what behavior we want to require.  The other is whether we make the document clear.
> I think choosing to leave a document going to Internet Standard ambiguous is a serious mistake, bordering on failure.  We know that the choice of permitting insertion of extension headers has interoperability implications.  There are weveral ways we can clarify the text.
> o We could say "MUST NOT" be added.  Preferably with explaantion of the problems being avoided.


> o We could say "MUST NOT unless some other standards track RFC says it is okay" which is technically correct but confusing.

That's redundant. A new standards RFC can always be written that will override this.

> o We can say "SHOULD NOT unless ..." as long as we can write a clear description of the conditions under which it is safe.

As the 6man chair we declared that as out of scope in the context of advancing 2460 to Internet standard.

> o We can say "AMY< but note that doing so has the following risks" if that is the IETF rough consensus.

Middleboxes live in unregulated territory, there was no support (or even suggestion) in the working group for explicitly permitting header insertion.

> But leaving it ambiguous ought to be a non-starter.

Leaving it as it was, including describing what we would imagine it would break was the preferred solution in the working group.
Note that both IPv4 and IPv6 has this so-called ambiguity, that has caused no known interoperability issues and has existed for decades.

This is perceived as an ambiguity only because we as a community have accepted layer violations for so long.
This can be exemplified by discussions on maximum extension header length in IPv6. The only reason that discussion happens is because middleboxes require access to the transport header and beyond. In a purist 2460 view a router doing 5-tuple ECMP is not compliant with the specification. Clarifying that ambiguity would probably not make the operational community proud of us.

The only purpose an outright ban would achieve, would be a pre-emptive strike against potential future standardisation.

So when you think long enough about it, which choice you pick will unlikely have much consequence either way. It has no effect on implementations, it is not testable. In the context of 2460 this isn't a debate with many technical points.

Which is why the working group could not reach a consensus, and we ended up decided it with a poll. Do you prefer your bike shed red, yellow or green. You have added a couple of more colours.

> Personally, I would go with "MUST NOT", as I think that is the robust and interoperable answer.  But that is MUCH less important to me than our being unambiguous.

There is an infinite set of creative (ab)uses of 2460 that hasn't been banned. I would claim it would be impossible to write a document which would MUST NOT every potential abuse.

Best regards,