Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Fernando Gont <fgont@si6networks.com> Thu, 27 February 2020 21:42 UTC
Return-Path: <fgont@si6networks.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 1C99E3A0C95; Thu, 27 Feb 2020 13:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fKvhxNiu1XyM; Thu, 27 Feb 2020 13:42:55 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7063A0C96; Thu, 27 Feb 2020 13:42:54 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CE95180BF1; Thu, 27 Feb 2020 22:42:50 +0100 (CET)
Subject: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
To: "'ietf@ietf.org'" <ietf@ietf.org>, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, architecture-discuss@iab.org
From: Fernando Gont <fgont@si6networks.com>
X-Forwarded-Message-Id: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
Message-ID: <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com>
Date: Thu, 27 Feb 2020 18:42:42 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sbb95BqdPifuRb_NPc3aeiqBbfM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 27 Feb 2020 21:42:58 -0000
Folks, If you haven't been following recent developments in the Spring WG, you may be surprised about some of the work that is being pursued (or was being pursued)- Such work has included proposing that some IPv6 routers insert and remove routing headers en-route to the final destination. After many very heated and lengthy debates, some of this work was dropped, but other remains (e.g. routers removing IPv6 EHs from packets en-route to their final destination, part of what they call "PSP"). For the most part, the proponents have argued that "we have implemented it, and the industry wants it" -- as if we just have to rubberstamp what they have done. On the technical side, the proponents have argued that: If a packet employs source routing (and hence its Destination Address is modified en-route to direct the packet through each of these "waypoints"), then any of such "waypoint" routers are free to add or remove IPv6 extension headers at will. (No, not encap/decap, but rather add/remove EHs from the IPv6 header chain). That seems to me like a very major deviation from what's supposed to be our current "architecture", where IPv6 is an end to end protocol. Besides, it should be obvious that removal/insertion of EHs en-route error reporting (since host typically check that the ICMP errors they receive correspond to something that they actually sent). A number of us have raised this a number of times, and at least some of us feel that our concerns are being ignored. It would seem to me that these documents and decisions have a concrete impact on our architecture, and that they are being pursued without any proper oversight. There is also a widespread feeling that having one or a few big vendors pushing these ideas might be playing a role here. (See, for instance: * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/ * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/ ) What I would expect is that all thes major changes to our existing architecture and protocols would only done by formally updating existing standards *if* deemed appropriate, as opposed to just trying to sneak changes "when nobody is watching", or by having very curious interpretations of our protocols and standards. I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d list before, but so far haven't been lucky or seen anything meaningful happen in this area. I have also submitted an errata to make RFC8200 even more clear on the topic, but it remains unprocessed. So my questions are: * On the technical area: + Is IPv6 an End To End protocol? Or is the IETF's stance that routers are free to mangle with the packet structure as they please? + Was IPv6 designed that way? And if it wasn't, when/how was the architecture changed? * On the procedural area: + Where/how should IETF WGs seek for architecture-related advice? + What do do in situations like the above? Wait and see how things evolve, and upon any formal decisions, just submit formal Appeals if deemed necessary? (and after way too much energy consumed from everyone) I would have expected that as soon as these issues were raised, the offending text would be removed rightaway. But that wasn't the case. And when the changes did happen, it wasn't without an extraordinary waste of time and energy from all of us. For instance, any work on IPv6 header insertion/deletion wouldn't seem to fit within the charters of the 6man or spring wgs. FWIW, this is not the first instance of issues surrounding the same topic. It goes back to the rfc2460bis effort, when a similar set of folks (too many from one big vendor) got to have 6man ship what became RFC8200 with a noted "ambiguity", just to be able to have some playground for EH insertion/deletion. And we only got to improve on that during IETF LC: (see: https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/) Thoughts or advice on the technical and/or procedural aspects will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: Errata #5933 for RFC8200 Date: Thu, 27 Feb 2020 17:07:36 -0300 From: Fernando Gont <fgont@si6networks.com> To: Suresh Krishnan <suresh.krishnan@gmail.com> CC: 6man@ietf.org <6man@ietf.org> Suresh, Two months ago I filled an errata on RFC8200 regarding the processing of IPv6 extension headers. The errata is available here: https://www.rfc-editor.org/errata/eid5933 While I believe that folks with a knowledge of Internet Protocols would be able to interpret what is in RFC8200, given recent discussions on the topic, and upon a re-read of the text, I believe a clarification is warranted, such that we allow all sorts of curious interpretations of the text. I send a heads-up on the 6man mailing list (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), and the proposed text received the review of at least Brian Carpenter, Ron Bonica, and Mark Smith. Their reviews are available on such thread. In the light that some folks seem to be pretending to leverage "the lack of clarify" in RFC8200 (an Internet Standard) to violate it, I'd appreciate that the reported errata be processed. Processing the aforementioned errata is key to many of the discussions this and other WGs are having. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Er… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Tom Herbert
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Phillip Hallam-Baker
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Bernard Aboba
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Tom Herbert
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Tom Herbert
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Keith Moore
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Keith Moore
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joe Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Keith Moore
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Mark Andrews
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… S Moonesamy
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Phillip Hallam-Baker
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Tom Herbert
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Christian Huitema
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Bernard Aboba
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Fernando Gont
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Fernando Gont
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Fernando Gont
- Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P… Fernando Gont
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… S Moonesamy
- RE: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… Larry Masinter
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Tom Herbert
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Dino Farinacci
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Tom Herbert
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Bernard Aboba
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joseph Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joseph Touch
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Joseph Touch
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… Fernando Gont
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Fernando Gont
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… Fernando Gont
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Joseph Touch
- Re: Is IPv6 End-to-End? R.I.P. Architecture? (Fwd… S Moonesamy
- [arch-d] Is IPv6 End-to-End? R.I.P. Architecture?… Guntur Wiseno Putra
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- [arch-d] Is IPv6 End-to-End? R.I.P. Architecture?… Guntur Wiseno Putra
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Keith Moore
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Robert Raszuk
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Tom Herbert
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Tom Herbert
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… John C Klensin
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Phillip Hallam-Baker
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Keith Moore
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joseph Touch
- Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P… Joseph Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joseph Touch
- Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architect… Andrew Alston
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Joseph Touch
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Andrew Alston
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- Re: [Int-area] Is IPv6 End-to-End? R.I.P. Archite… Fernando Gont
- [arch-d] Is IPv6 End-to-End? R.I.P. Architecture?… Guntur Wiseno Putra