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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E21812970A for <>; Tue, 14 Feb 2017 11:12:54 -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 GLYJpP84mi4G for <>; Tue, 14 Feb 2017 11:12:52 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id A70031294C2 for <>; Tue, 14 Feb 2017 11:12:52 -0800 (PST)
Received: from ([]) by with ESMTP; 14 Feb 2017 19:12:52 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 5AAEED788E; Tue, 14 Feb 2017 11:12:52 -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=J0U122sRmw+OECQOMorB7Jg+5Qc=; b= qJsX+MugKiEiQatYaK+MZWIV237hvV8j5xBRtDcW9SzAb2+pDVO1ORrC7yx7jfvZ b7mzZyPLAz0+VwiofvyRyvnTic876mrD4IeglFABSiOtY6G3U7JSjyjQV1Ju/Qzt EQkK73zio0yh4tOFJLp6K29EmFuSQYBBJR+LoaADeB8=
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=YZQuwKBH3tiObx4d7MzcUrw eDZhVP71SdX57uC/7KrnHyxzG4PXUzMkyF28wfEjMYN2fnLBhqG/crG9D/Rf5BVl wm+mUKhfIha0UzqhaCV4VX7lVqdNoBNJEUqg0fV2PpC2uf9axsN3DWMe4OFbiHV8 eXA0shKkjFlaX2OxCn2k=
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 E1E75D788B; Tue, 14 Feb 2017 11:12:51 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 71DC28AE2ED5; Tue, 14 Feb 2017 20:12:57 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_437B81B8-3B90-444C-8ACE-58116BED0314"; 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 20:12:57 +0100
In-Reply-To: <>
To: "Joel M. Halpern" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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 19:12:54 -0000


> Ole, it is true that we write in English, and there is always room for
> "interpretation", sometimes reasoanble room, sometimes not.
> But in this case we have a demonstrated difference in how people
> understand the existing text.  When we have such a demonstrated
> difference, we have an obligation to address it.

This particular issue has caused no interoperability issue, and only a single question to the working group 20 years ago.
The current debate has been caused by a set of new proposals, independently of 2460, where the authors have in a creative reading of the current text figured out that they can shoe-horn header insertion in without actually violating the specification. Now, if clarifying the text was done, then I presume these proposals would just adapt to update 2460bis instead. The real battle would in any case have to be over those documents, not this one.

Now for the snarkiness; an issue that has created real problems is both IETF specifications (although experimental) and implementations of address rewriting by intermediate boxes. And there isn't a explicit ban on address rewriting in 2460. Should we add that? Would it help?

> PS: The ability to do ECMP is why I helped with and supported the effort to get the flow label use for ECMP entropy documented.  That would ameliorate a number of problems.  I do not expect this revision of 2460 to fix that, particularly since there seems to be little adoption.  I try not to get distracted looking for perfection.

Yes, and that's greatly appreciated!

Best regards,