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

"Joel M. Halpern" <> Fri, 17 February 2017 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF52E12957B for <>; Fri, 17 Feb 2017 09:44:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7CGPwvUS5bTe for <>; Fri, 17 Feb 2017 09:44:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A552E12955C for <>; Fri, 17 Feb 2017 09:44:46 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E8A53C2FCF; Fri, 17 Feb 2017 09:44:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1487353486; bh=cAJre5d1w62ArEAQkDapbPB8kWjOJt9ahFzlnIrrDQs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VakjlrLL6MYBiRI3yuCEqxecWlrh2RKmJS2wcGZR0KevGYJEAi4V4Tg6cRx0FfjwO FDApb5HPbTLlGB4qzCLPP7V1ES7WhmT6xLSDrmt3Nf8SKL2FUFJfaNUAw1mLLpk6TJ o9T+TbaYIElZpVJg6TeDFl2G1ErGz8KdbjpRg5gQ=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 221B61C02F3; Fri, 17 Feb 2017 09:44:46 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Fri, 17 Feb 2017 12:44:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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:44:48 -0000

I disagree with your interpretation of the bar the document must meet.
I believe I have clearly stated my concern.
I will leave that judgment to the relevant ADs and IESG when they review 
the last call results.


On 2/17/17 12:39 PM, wrote:
> Joel,
>> 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.
> Cheers,
> Ole