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

otroan@employees.org Fri, 17 February 2017 17:15 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59E129646 for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 09:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qx-1HQZvm_j for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 09:15:13 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1A1294E0 for <ietf@ietf.org>; Fri, 17 Feb 2017 09:15:13 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 17 Feb 2017 17:15:12 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4662BD788D; Fri, 17 Feb 2017 09:15:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=9N1moh+D3t/6vLb7NtA6QtGE5Zk=; b= e3fJ32WdHJbS62bMghHF0cW0UXkY6LUrWZ6dRX9Cu7xTkGLMyHyjKXjXUFg6Xroy Sc758KZwlnLMrwpd1P/Vmqdt9k6FZB7b7ZXSBV8Af1TNqznoDkyYUGwDe8jGaqOa jJd3Gu+/pgyx89oX0ZwEzYZlHZBO+vTJOBsS61cJIX8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=PKik+1y392TW2UWEVx9giqm HGnzCGq4CzL4cKEpAEku0waBf0+4Yf6MfNeaAgl5rzQwK+cPaEtFQ/QexPipkS7q z07MDK1CJNMM1Kd+d5it+TihNY21QIb81vyruF5H5DqcH8f1BrdUXL/OAeMJQLGc kfMPb4RiUWVGbc+Yiq0I=
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E65ABD788B; Fri, 17 Feb 2017 09:15:11 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2DB648C9373B; Fri, 17 Feb 2017 18:15:26 +0100 (CET)
From: otroan@employees.org
Message-Id: <67A86E2D-80A3-4EC7-858E-A838160934CC@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_445BBDE0-BC03-46D4-8E73-EABE245B804D"; 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:15:25 +0100
In-Reply-To: <8ac0ada8-b8c6-6299-cbd7-615c207caa53@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <23C46409-337C-468D-BCDC-34027BB56CAD@employees.org> <30715b9e-e9b7-320e-f9e2-fc3f64615d5c@si6networks.com> <CAJE_bqcKu1XVQOPzcd+8b68WcQyjH9QmszaSvKWhT8SvHJ0ppg@mail.gmail.com> <m2y3xdpmjd.wl-randy@psg.com> <5333378B-0F8D-4966-82B2-DFF9639CEC7D@fugue.com> <3a180e40-936b-956b-9fc3-5ecdd4d905ee@gmail.com> <m2poippisc.wl-randy@psg.com> <13830253-67ab-cb26-4fa0-f40a24f1a5bc@gmail.com> <76D87C97-1ECB-4E92-8FE7-ADAF464DB8FD@employees.org> <a0aaa86f-db08-4363-f9c6-0b55ceadc3b9@gmail.com> <48b1988d-2074-3e60-62ba-5943e6ec8b91@joelhalpern.com> <523D6E9B-5504-4AA6-81B7-81B68E742E6E@employees.org> <79f04816-0249-c0b8-a72a-5d5bdf77d3f5@joelhalpern.com> <35A94D95-63B8-41BA-8CA1-010544DE1252@employees.org> <eedfd457-14a7-1c98-f765-68f2c5a84860@si6networks.com> <8D0C4CBD-8AB1-42A4-ACF6-6F2E40F9C464@employees.org> <553cdd65-e5a5-8081-fb9a-c66d34496025@si6networks.com> <8E5FC183-DE9B-4CBE-B1EA-301A08300A66@employees.org> <8ac0ada8-b8c6-6299-cbd7-615c207caa53@joelhalpern.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/r5ZLywnOYP2NFpOX-JvqXKxOYUg>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2017 17:15:15 -0000

Joel,

> Given that different people have interpreted 2460 as permitting or prohibiting the addition of Extension Headers by intermediate devices, there clearly is an ambiguity.

I'm a little uncertain if I'm unclear or if you simply didn't read my message. :-)

Do we agree that you can see this at two different angles?

1) Are there any interoperability issue or ambiguity in the protocol specification of 2460 and how implementors of 2460 have interpreted that?

2) Is 2460 "future-ambiguous", i.e it is unclear if 2460 permits a future extension? Like ECMP, Header insertion NAT...

The answer to 1 is no. And no-one has claimed otherwise in these discussions.

For 2, that would be in the area of stating the law for what future extensions of IPv6 can or cannot do.
If we want to go there 2460, yes there are ambiguities. It's hard to predict what the IETF can possible invent in the future and if that should be permitted or not. And of course what effect that would have on future documents regardless.

Clear?

Best regards,
Ole




> 
> 
> That is the point that concerns me.
> 
> Yours,
> Joel
> 
> On 2/17/17 9:12 AM, otroan@employees.org wrote:
>> Fernando,
>> 
>> It is a simple logical consequence.
>> 
>> Middleboxes do not exist in the IPv6 architecture.
>> There is no interpretation of 2460 that can lead to an implementor inserting headers other places than at the source.
>> Therefore, there is no interoperability issue in RFC2460 nor any ambiguity that needs to be resolved in RFC2460.
>> 
>> We're not writing law, we're writing interoperable protocol.
>> 
>> Ole
>> 
>> 
>>> On 17 Feb 2017, at 13:40, Fernando Gont <fgont@si6networks.com> wrote:
>>> 
>>> On 02/15/2017 07:18 AM, otroan@employees.org wrote:
>>>> 
>>>>>>> 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,
>>>>> 
>>>>> May I ask what's the data that support this statement?
>>>> 
>>>> From the shepherd's writeup:
>>>>  IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
>>>>  including proprietary and open source.  A list of products that have
>>>>  received the IPV6 Ready logo can be found at:
>>>> 
>>>>  https://www.ipv6ready.org/db/index.php/public/?o=4
>>> 
>>> This has nothing to do wth the interoperability problems that may be
>>> caused by a middlebox that inserts EHs.
>>> 
>>> 
>>> 
>>>>> You certainly have no way of knowing this, or whether interoperability
>>>>> issues may arise in the future.
>>>> 
>>>> Yes, we do know if our protocols have interoperability issues.
>>>> Have you implemented RFC2460? I have. So have many others on this list.
>>>> In the context of implementing 2460 there just is no ambiguity and this issue will never arise.
>>> 
>>> Huh?  Yes, if you connect two IPv6 devices, without a middle-box
>>> inserting EHs in the middle, you will not experience the associated
>>> possible problems. What's the news here?
>>> 
>>> 
>>> 
>>>> What you are talking about is something else. You are talking about the hypothetical "What if someone standardised something new in the future?"
>>> 
>>> :-)
>>> 
>>> C'mon, Ole. Take a look at the initial versions of the SR I-D -- and, EH
>>> insertion has reportedly been deployed as a result of the implementation
>>> of such initial versions of the I-D.
>>> 
>>> 
>>> You can clarify that EH insertion is banned, and move rfc2460bis to full
>>> stanard (since that's what's supposed to be mature)
>>> 
>>> You can delay rfc2460->std, and work to update rfc2460.
>>> 
>>> Now, moving rfc2460 to full std knowingly leaving a hole there such that
>>> after rfc2460 is std you completely change the architecture (e2e vs
>>> !e2e) with EH insertion doesn't seem a serious thing to do, IMO.
>>> 
>>> Thanks,
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont@si6networks.com
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>