Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

tom petch <ietfc@btconnect.com> Tue, 15 September 2020 09:05 UTC

Return-Path: <ietfc@btconnect.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 48E6A3A0B75 for <v6ops@ietfa.amsl.com>; Tue, 15 Sep 2020 02:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.onmicrosoft.com
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 o_S1dI2MdL-x for <v6ops@ietfa.amsl.com>; Tue, 15 Sep 2020 02:05:21 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2139.outbound.protection.outlook.com [40.107.22.139]) (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 4BC593A0B4B for <v6ops@ietf.org>; Tue, 15 Sep 2020 02:05:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IewvV7W6BLXJ5QF57UThRaVwQ0kOd8lvbTTF7Zq7jaPGdQK7+FT3bAllt72hxDJvlYTJHCifMWvIlWxfQ5P3/yaEWrLalSj5MN6ofI59+yjdo7uUvVNosc1wR9b0P7k/kOg14+2kD5wtbvRoE7M4oZno0p5bHRWOmRV5XxXOI+ZEy6Tg1eFQBhU+gf+anUweYu6trkZu3sW2fmNYcpfs5rUZ/cgcLdtY0eVXOgpA1Ahou+BE+Hx7JvzfAmFpEF5k925ftrpd6zC8n3Rehz/e+ABy6QnOy42ehc5plRcBScOvqYNiAv7Rpq1AWEffr8GUO0QhQ9zPdph6Nk5MDLGRHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jr5MBZiYMK8oH3/fhhb24gB+NfscQmCClOsXM2YWmBk=; b=QKteNE+zOKak/KQuM/I/H2OTFhtrau43UUjcAJOsGvpjp3t4jqp/5/ozeNxGMmF8ekb138+HbE3XjOxsF1D/uBkYsvisKq/bDbzkhXiCRLqpnspd+3MxTYBNrbuib6GZcTL1ePzVKcI+UAzsnh/AII4+h8dopo2m2BwUqaQ7+M00udoNKWae1mDjNzt9NEtFOh9CjuP6PQS3D8vM77bsDlfhinnQiKTvNhovzbctnEaNEPDqDpddxrzeiXDp6Q6Gc27veJG50fj60ldTLjP8dSCSyor46oLXnTSuGYHCFeTS/bIP2ernWbtXcDNEPvUMpqf31XPardanlq6WKRBMAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jr5MBZiYMK8oH3/fhhb24gB+NfscQmCClOsXM2YWmBk=; b=xPnSSo58Ypis3GJu/A1M4IJiTDRsB/H7wnNwfLs97w1scj2OowoB3nAth+FQ3RogbSsLoWXlBdRSo3xFLh438DJgYPsADQsf6J5vWF9T06se0FUwr7IK3iGnlO2pxJWKPxlaSY6Bllie+QmP0+0RHF0NyF60TaLhpEXEAerlFIg=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB6039.eurprd07.prod.outlook.com (2603:10a6:20b:9e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.6; Tue, 15 Sep 2020 09:05:18 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::189c:ac35:ce23:d38a]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::189c:ac35:ce23:d38a%6]) with mapi id 15.20.3391.006; Tue, 15 Sep 2020 09:05:18 +0000
From: tom petch <ietfc@btconnect.com>
To: Fernando Gont <fgont@si6networks.com>
CC: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers
Thread-Index: AQHWioRBZz2U4F4heEuV50FukUSdTKloZwuAgAD9wTg=
Date: Tue, 15 Sep 2020 09:05:18 +0000
Message-ID: <AM7PR07MB624842F364784EF3AC5B0647A0200@AM7PR07MB6248.eurprd07.prod.outlook.com>
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>, <7bc1ea18-01c5-54f7-a65d-a53722a4d3c9@si6networks.com>
In-Reply-To: <7bc1ea18-01c5-54f7-a65d-a53722a4d3c9@si6networks.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: si6networks.com; dkim=none (message not signed) header.d=none;si6networks.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.155.63.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 44230118-abfd-48ca-9451-08d8595677fc
x-ms-traffictypediagnostic: AM6PR07MB6039:
x-microsoft-antispam-prvs: <AM6PR07MB6039C259B704E643AC73DA1EA0200@AM6PR07MB6039.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TddfiX/q+H2wCUWd/4RfZiRsXGBLJbVJa99UzI/EuYgAxEQuaGAD1ENirNGk1VkW8JbYiQITq1Z5L33/8AlSw5yoWA4wKJixuXoPEosPti2Tv0Q2tc4EyKWKNMmb6PDVZib+6fICs07loFI+qvKJZkfaRbGj9PWY3hXV8tFkWIt7KfMbZDdnAhtPQY8f/hnb5LWjNnLBrJ0YCEpc49vQXg9vBjYSOWWUWPS5tOYHwOByvRgEJ6pyPuBpQr8ul89gciK1nz1EEd+2oXd/CEd7oFBt/B+dGa/qtnckPoBOPPsj5ZnBPSza7xblC+I19CwHWpP9E8rxZ1OvGZqNs1H9YGHRt7b5UXfaoZo87J0fUjyFpJGauNyuVIi/Xd4Crode
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(366004)(346002)(396003)(64756008)(55016002)(8936002)(478600001)(6916009)(66574015)(8676002)(4326008)(86362001)(83380400001)(2906002)(71200400001)(52536014)(5660300002)(91956017)(66476007)(66446008)(66556008)(9686003)(76116006)(66946007)(7696005)(316002)(26005)(33656002)(186003)(6506007)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 3lAC3c1IAgKbkd3Sk9zMR6CpJ1BBFd1F1nydZ7a22+8VDlZm6TqTUjRc5NkQ716xC80AqywCeEW9tywq0vof5EUT7DKiEEBGioQvJSojvAbvNixdnuJPebOCJ2Dznad7zf9mPzeGXIYGxWa9E9N0CRSMcXz4fZMMYMT2ZpiJuPQAELPJWSnkb6jXaKByO9oPqpiO5Q69q62XBJKH8T8yZ9d2QM+dsnJ2P8R7YXI3lJmupg4iSdfTHIYxrWKWhowxUpp14JJlpzx4xGwpU3yNCbqqxm7aspt0Es3OovoZ54vNNbZu4q79CCko6z+tFv5hT4dTO796Pu6+ohbQj/Yh8PUsA2guPX56mO+ptFw9/NV1GwGswmTgLgec1bMvUh3mveQW8opidZlc5GoBi3lmYGKyhoA4d5VuKRSVNrqQhhAoKZs9ahLzNmbLXPZHlNOEESlxai5QncUG3ltxswW/3HNDZ6OhmZD6VgVfowHy+orRqdCoPmTAohGEivme9O43a9tvS4n0o0s0k+QGNuSF/DiJSm75zjjwuMsKskro0ND/feRZt73A1H8DvjR4rJNz3b7vbjZpRJpnQziOHKGnXe4l2r/QFR7No6o7gcXoFGWcdrnFBeJeegZPxFVUs4q4aZwYINiVEDW0OTRyRPxNHw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 44230118-abfd-48ca-9451-08d8595677fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 09:05:18.7219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +FEpF9glBVtRTBPVEeeNaotIpCKOTjx/ifwQ0y/utRDb+8jNqTxcxbuI2wCT+sa3SltSKHyU7S4OKZ0oPZefYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6039
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/87G9SYWu8GeaKTSBRob5YwQN4No>
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: Tue, 15 Sep 2020 09:05:27 -0000

From: Fernando Gont <fgont@si6networks.com>
Sent: 14 September 2020 18:39

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.

<tp>
Yes please.  One page or two pages max, summarising why they were thought a good idea, the different types and their uses, how widely used they are  and with references;  RFC8200 may be Normative but it takes a while to appear and that after RFC2460!  Section 3 makes reference to security, fragmentation and such like with no apparent connection to EH; I think that such a connection should be explicit earlier.

And below ....
</tp>


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

<tp> 
but it leaves the I-D without an ending, it just peters out.  With an introduction saying what EH are used for then you could have a summary harking back to that and saying which, or which kind of, work and which do not implying, without being explicit, what future developments might or might not be a problem.

Tom Petch
.
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