Re: [IPv6] Removing extension headers from packets (revisited)

Mark Smith <markzzzsmith@gmail.com> Tue, 15 August 2023 05:27 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6158EC151091 for <ipv6@ietfa.amsl.com>; Mon, 14 Aug 2023 22:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_9PVQ9xE8ay for <ipv6@ietfa.amsl.com>; Mon, 14 Aug 2023 22:27:13 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C25C15108C for <6man@ietf.org>; Mon, 14 Aug 2023 22:27:13 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5233deb7cb9so6267473a12.3 for <6man@ietf.org>; Mon, 14 Aug 2023 22:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692077232; x=1692682032; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vuo4pQsskMc9vFb2qDCu9OgPcbOytgDXkabvO4Xa6hc=; b=JLrpi2KY45kMOXU2u061O7TTmRvQiPITrW0gxvZ9oz6PLFKIZoLOSK5Fcnenu8ytFw V4LVtFt01ZEPRzmP6WshJVRC0iSwq8DZIYfddKMAdOoRWj6xT/xa1zQfPe55Ca89cIlG +qcm7FKXC+TRAh2ReeOtCxLnbMQsdc63CxSPd/SZUK8Zs52F0hi5VbZHNKG2igBqgfI2 5bwRlZbkdrVmVzTSsQ3VFMHccsXeXx4f4PVpryZ1TyuimpEMpogSbDjq99bk27Few8QC fneciUESSEAXGBliijT5M8J6qWSHynQLu5acut9TNP37XKrniwKXFLOSWSgdPnIyi/qp zCPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692077232; x=1692682032; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vuo4pQsskMc9vFb2qDCu9OgPcbOytgDXkabvO4Xa6hc=; b=llD6soc7wa32gj72lynHUuzLuFkiCywTmuIM5BserIZu2VbZ3o7jbfCFeTcpB/psGb BKNmvkNz3/1/K7LdKc4ymYs2ONKoG8cBqbUCOfiJ//br4EDEWb8mrFSyex1sPIbzGZ4z 9OldSWd13ZfBfX61RauVV5xI4vkCRdTmHfjwislDD17pnqvqDH4FX/WzZ2DDX1mNCbSk 8LO2U39JzngZxGQhXR+/Iuiucbda+K9/qirRWl2X/YvpRH/F5e0/aqcIIC9UirbWF6+K iuMf9bfOdKWM0PE6XwZaOd/o6LuYUDbUoDwK9cUJuk55pidCOnmNW7N1aMVBbNgaTFSK b3Hg==
X-Gm-Message-State: AOJu0Yw3gGAY867plxQr5Ixi3wRtnSSNMCZZCJQY4LE5pICTOVAM4Rd1 Nc+dJmjYB/+ZusysU9OjTfZcdLc/xb/I96F3eI0=
X-Google-Smtp-Source: AGHT+IGNk+q+lYYntnNW2BTrkRC1Sj/XQN5cdSN+tbV2/i0a1XO9mv1dXGjxu8HtOCr1la3Ao5Ouv9CiT6P0CHE+19c=
X-Received: by 2002:a05:6402:1611:b0:525:734a:bf30 with SMTP id f17-20020a056402161100b00525734abf30mr1021186edv.36.1692077231714; Mon, 14 Aug 2023 22:27:11 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S36gQBgNAp-Poq3pRupGWUh0iA8M546=S=vUp5cQK_82TQ@mail.gmail.com> <CAO42Z2zAf4EAKhX1ZJC1KUk4DXcNZykA82hdUfo64h45q8DVUQ@mail.gmail.com> <CALx6S36pk0+YjdjgNvWCsAjF5NVmQLnp8pKc30uOb1DZmcfasQ@mail.gmail.com> <CAO42Z2zmxiGANzdB6RdrfgGLfH_Q-D7-U_JGJ0V++3ms8nGxOg@mail.gmail.com> <CALx6S37BYjhShGhHbg8qK4Fxeubrep7BGzRBmrHD9DcBcToxPw@mail.gmail.com> <620318f4-d6ae-3c29-c5f1-93797363d47c@joelhalpern.com> <CALx6S36RvnkZf6=dfFPJZo7MHzJTU28LOjVgV1Eq27p7iA_9-Q@mail.gmail.com> <2e6fe4e1-1020-2341-94aa-cd53859b0eed@gmail.com>
In-Reply-To: <2e6fe4e1-1020-2341-94aa-cd53859b0eed@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 15 Aug 2023 15:26:44 +1000
Message-ID: <CAO42Z2znSNj4W16jEiWfR_z9TfhmQTmtZJdS8xCXAw3iur191A@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>, Joel Halpern <jmh@joelhalpern.com>, 6MAN <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8es5aUpOORjZpSBlQwwjfKoDPcE>
Subject: Re: [IPv6] Removing extension headers from packets (revisited)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2023 05:27:15 -0000

Hi Brian,

On Tue, 15 Aug 2023 at 12:04, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>

<snip>

>
> Hang on. If my initial packet is (simplified):
>
> SAx|DAy|EHz|payload
>
> (where SAx and DAy are the specific source and destination GUAs)
>
> and an egress router wraps it up as
>
> SAx|DAy|(SAx|DAy|EHz|payload)
>
> i.e. the packet was encapsulated with protocol 41 *using the same addresses* but no EH's, and later the ingress router that owns the prefix of DAy unwraps it as:
>
> SAx|DAy|EHz|payload
>
> again, it seems to me that the process can be fast and simple, and the packet on the open Internet has no EH and therefore no problem. No tunnel set-up needed, as long as everyone lets protocol 41 through.
>

The drawback of duplicate SA/DA is that a receiving router needs to
inspect literally every packet it receives beyond the fixed IPv6
header, looking for the special handling EH. (Side note: Duplicate
SA/DA was also proposed in draft-ietf-ippm-ioam-ipv6-options for
IOAM).


If special handling could be encoded in the outer packet's DA, they
could then easily be identified for special handling using a /128
route in the FIB.

Other packets without the special handling DA are forwarded normally,
without looking for the EH.


An address like this already exists:

fe80::0/128 - the link-local subnet router anycast address


The packet sent by the host would look like this (H.<address type>
meaning host address of <type>):

(Outer:)[SA:H.LLA|DA:fe80::0|Special Handling EH]
(Inner:)[SA:H.LLA/ULA/GUA|DA:<blah>|payload for <blah> DA to process]


1. The first hop router would receive the packet, FIB match on DA fe80::0/128.

2. It would remove the outer IPv6 header, and then perform the
processing according to [Special Handling EH].

3. Post-processing, the decapsulated packet is then sent back into the
forwarding plane or forwarding domain as
[SA:H.ULA/GUA|DA:<blah>][payload for DA to process] for further
forwarding.


Encoding of special handling in DAs is not new, emergency telephone
numbers (000/911/112) are also examples, as are anycast pizza chain
local shop instance phone numbers.

Regards,
Mark.