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

"Scott O. Bradner" <sob@sobco.com> Fri, 17 February 2017 17:14 UTC

Return-Path: <sob@sobco.com>
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 6EEF5129488 for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 09:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 91pTwyt8QNkS for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 09:14:57 -0800 (PST)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6783B126579 for <ietf@ietf.org>; Fri, 17 Feb 2017 09:14:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 4BD323AA2268; Fri, 17 Feb 2017 12:14:54 -0500 (EST)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG5dw7pDz8yE; Fri, 17 Feb 2017 12:14:51 -0500 (EST)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 735303AA2252; Fri, 17 Feb 2017 12:14:51 -0500 (EST)
Content-Type: text/plain; charset=utf-8
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
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <8E5FC183-DE9B-4CBE-B1EA-301A08300A66@employees.org>
Date: Fri, 17 Feb 2017 12:14:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8637862F-DAE8-4520-9997-F4DD61629EA7@sobco.com>
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <1179DE45-3971-44A1-9630-28F76D2D652D@employees.org> <2ea64b3c-d69d-6b6c-cb04-fe63727a8bee@si6networks.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>
To: otroan@employees.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/CwrljLpZd8HRZfJwDIrPGqpNvxA>
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:14:58 -0000

> On Feb 17, 2017, at 9:12 AM, otroan@employees.org wrote:
> 
> Fernando,
> 
> It is a simple logical consequence.
> 
> Middleboxes do not exist in the IPv6 architecture.

firewalls do not exist in IPv6????
load balancers do not exist in IPv6???
content redirectors do not exist in IPv6???
…

Scott

> 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
>