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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10B9A129AEA for <>; Fri, 17 Feb 2017 09:39:31 -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 X9KIucTmeMom for <>; Fri, 17 Feb 2017 09:39:29 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 4B0A0129AE5 for <>; Fri, 17 Feb 2017 09:39:29 -0800 (PST)
Received: from ([]) by with ESMTP; 17 Feb 2017 17:39:29 +0000
Received: from (localhost []) by (Postfix) with ESMTP id E1E26D788D; Fri, 17 Feb 2017 09:39:28 -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=4/S6lvv+k9fmF98lsISIeOsHe+Q=; b= CD20VGaLAgiSm3QICYncuyRWQOf7upLgo0fnmObZi+PEfvaix75Iro2bisEVLLUm lm6MQzsz4SJnCq8YwfcmpedSaJbqoPsPOdPk5WZtpPopYxuer16nM/5fmi/Y+pzX ibxOm8ovYxGdGmLNYLSivsZ+08QqOWa56fL5ILObwY0=
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=m+C6Kb/whL1FcC3eT3gxw4U JPbxMSadV9EKMVAeQQz3XiOTZ8GVyJTi7jlH1BNVPU+zRHoXEClYMFT9qeAlxmbE cfW1nlU1t+vRTZqm9fW5ygEQESyf4PcHkUlIRM8MJmSWgcDu/IXiQbpd5WMWHBkN Fz6R3cnuOVF0jCfUzYgE=
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 8514BD788A; Fri, 17 Feb 2017 09:39:28 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id D4B6D8C9AD86; Fri, 17 Feb 2017 18:39:42 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_A61DDFA8-B91F-48C7-87EB-E81478ECF108"; 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: Fri, 17 Feb 2017 18:39:42 +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: Fri, 17 Feb 2017 17:39:31 -0000


> I am not sure what youa re asking with either of your quesitons.
> With regard to question 1, you seem to be asking whether we have seen folks adding EHs, and whether it has been observed to cause difficulties.  We have seen folks trying to standardize exactly such additions.  So I presume they have already implemented them.  And we have seen folks explaining a range of cases where it causes problems.

No, that's not what I'm asking.
I'm asking if an implementor of the 2460 specification has interpreted the text as ambiguous and if that has led to interoperability issues.
The answer to that is no.

Do you see my point here? That this point is important for advancing RFC2460. There is no shown ambiguity that has had any consequence for 2460 implementors.

Header insertion just doesn't exist in the context of implementing 2460.

> With regard to 2, you seem to be you seem to be constructing a very odd reading of an RFC.  Some people have clearly said that they read the existing RFC as permitting additions of EHs.  That is not a matter of future RFCs, but of current readers.  Other people have said that they read the text as clearly prohibiting such behavior.  Which would at a minimum mean that any IETF effort to change it would be required to explain why it was acceptable and interoperable to change the rules.
> Given that the existing wording has been interpreted in different ways by different people, and that there is good reason to beileve that the differing interpretations will (if they have not already) cause interoperability issues, it seems to me incumbent on the WG to be clear about what it means.

Can you please explain how that can create interoperability issues? An implementation of 2460 does not do header insertion.
You must be talking about some future specification (there are drafts) that specify header insertion.
_Those_ specifications will create interoperability problems. I think we should not standardise those.

Sure you could ban NAT's, ECMP and header insertion, and whatever else you can imagine in 2460, but how exactly is that going to prohibit anyone from writing the above set of specs? We're not writing law, we're writing interoperable protocols.