Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers
Fernando Gont <fgont@si6networks.com> Mon, 14 September 2020 17:46 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0E93A0DDA for <v6ops@ietfa.amsl.com>; Mon, 14 Sep 2020 10:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 jwzDHnIrJvYk for <v6ops@ietfa.amsl.com>; Mon, 14 Sep 2020 10:46:21 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AA83A0DD1 for <v6ops@ietf.org>; Mon, 14 Sep 2020 10:46:19 -0700 (PDT)
Received: from [IPv6:2800:810:464:1088:9b2:ecaf:c1b2:4077] (unknown [IPv6:2800:810:464:1088:9b2:ecaf:c1b2:4077]) (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 328AF283BF6; Mon, 14 Sep 2020 17:46:15 +0000 (UTC)
To: tom petch <ietfc@btconnect.com>
Cc: IPv6 Operations <v6ops@ietf.org>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <a6ed89a8-c12e-b8d2-c720-5cc02e127a68@si6networks.com> <FCBD1043-A0B2-435A-9AB9-0FCE3566C769@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> <DEB1318E-0E5B-4093-A691-8E1FD35B9F50@strayalpha.com> <A197EF3A-1E1E-40F1-BB50-68469E3C8E63@delong.com> <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> <2ad804a2-e714-6256-3afa-4d4a92fd6d3c@si6networks.com> <9c026e30-149b-172f-0953-456fb2d1e715@gmail.com> <AM7PR07MB6248A43FCBBB5D34AA2DA9AAA0230@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <7bc1ea18-01c5-54f7-a65d-a53722a4d3c9@si6networks.com>
Date: Mon, 14 Sep 2020 14:39:47 -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: <AM7PR07MB6248A43FCBBB5D34AA2DA9AAA0230@AM7PR07MB6248.eurprd07.prod.outlook.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/v6ops/Z7xKVzC1w9-08I-PjiymkAdrtyw>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 17:46:25 -0000
On 14/9/20 07:46, tom petch wrote: > The problem that I have with this I-D is that I do not think that it > will achieve its objectives. It wants to raise awareness about the > problems caused by Extension Headers so the target audience should be > the world at large, especially those involved in setting up and > operating IPv6 networks, but the style is, to me, rather academic, as > if the audience was the sort of people who would be expected to be > familiar with the literature and need little or no explanation. That wasn't the intent (at least half of the authors are operators). But we do indeed assume that the reader knows what IPv6 extension headers are, what they are for, etc. I wouldn't mind writing a Section that sits between the current Sections 2 and 3 with more background on extension headers, if you think that would be of value. > I > see this strongly in s.1, about Extension Headers, yet devoid of any > reference, any explanation. The first reference is RFC2460, which is > Normative, so are readers expected to be familiar with the details > therein? Yes. As noted above, I don't personally mind including a section that introduces the topic, if you think that'd be of value. > One reaction might be 'So Extension Headers create problems > so don't ever use them!' Our goal is, for the most part, for folks to make an informed decision. My *personal* take is that you probably may use EHs somewhat freely and safely in a limited domain, but not on the public Internet. > The I-D lacks any explicit explanation of what an Extension Header > is, what they were intended for, which bits have worked and which > have failed so eg deprecating RHT0 is not very meaningful without > some comment about RH something else. Well, this is somewhat implied by having RFC8200 as a normative reference. > Size matters as can be > inferred from s.4 but there is no mention of the sizes involved of > the IPv6 packet, with or without headers. As I say, it seems that > the reader is expected to know the literature. There needs to be a > page or two at the start giving the context within which the detail > makes sense. Fair enough. We'll work on one. > And then there is the future; should more Extension Headers be > allocated, should they be constrained to avoid the difficulties > raised here? The I-D, for me, lacks an ending, lacks a look > forward. This is, in a way, intentional. My *personal* thoughts are: + we should *not* constrain the allocation of EHs (see below) + developers should be aware that usage of IPv6 EHs on the public Internet increases the chances of packets being dropped (* NOTE) + In limited domains, "your network, your rules", so it should be generally fine to do things like SRv6. OTOH, if you expect that to work reliably on the *public* Internet, it may not. (*) e.g., I recently changed the transport of my tunnels from v4 to v6. When doing so, Linux implicitly added a tunnel encap limit option to then, which resulting in the addition of a DO header, which led to the corresponding packets being dropped. SO the above advice would have suggested that, by default, one would have refrained from adding the DO header. Other than the above, other speculations and advice will most likely be unrealistic. "don't drop the packets" -> "I have a network to run". "Have your platform be able to look into the packet without performance penalties" -> "I will if you pay for it", etc. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] Operational Implications of IPv6 Packets … Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… otroan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… otroan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Philip Homburg
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Gert Doering
- Re: [v6ops] Operational Implications of IPv6 Pack… Joseph Touch
- Re: [v6ops] Operational Implications of IPv6 Pack… Tom Herbert
- Re: [v6ops] Operational Implications of IPv6 Pack… Owen DeLong
- Re: [v6ops] Operational Implications of IPv6 Pack… Joseph Touch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Brian E Carpenter
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fred Baker
- [v6ops] Operational Implications of IPv6 Packets … tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Vasilenko Eduard
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Brian E Carpenter
- Re: [v6ops] Operational Implications of IPv6 Pack… tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… tom petch
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Ole Troan
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra
- Re: [v6ops] Operational Implications of IPv6 Pack… Fernando Gont
- Re: [v6ops] Operational Implications of IPv6 Pack… Gyan Mishra