Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

Tom Herbert <tom@herbertland.com> Sat, 05 December 2020 22:15 UTC

Return-Path: <tom@herbertland.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 AC9C93A0E9D for <ipv6@ietfa.amsl.com>; Sat, 5 Dec 2020 14:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 9P5WD_xuBZPn for <ipv6@ietfa.amsl.com>; Sat, 5 Dec 2020 14:15:19 -0800 (PST)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6353A0E6D for <ipv6@ietf.org>; Sat, 5 Dec 2020 14:15:15 -0800 (PST)
Received: by mail-ej1-x633.google.com with SMTP id m19so13938145ejj.11 for <ipv6@ietf.org>; Sat, 05 Dec 2020 14:15:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YQ+210y+fkgywO/hY1K+7ORd3ryKwGlmVVud3J1ycIA=; b=fbkUYXztYMjMzlM1dQEzzg/iSIL473kwWHuGt+wndIQdTRlXReBhknQNDnIucsUA2J 6P3RZ/8VUlCl0jDmwhzQ3/K7erImkobwCU4aMs+k6oqiYzQzc+HD6CAh9lloHz025ZeB 6f32/TTxPIeJ0jthTKyhRMnQ0FZC1fOAyX+ejQ/DLq3SQPzVRMPkitB3DUwwzwZcUC4E RE4MyrYpFpUDKpj+7Y2Jtr5TVtGWh1e8z/fgTKzl7k/kvqSQlJU3z4DBnJktUD4vmE9z vFtfUt+6wSTmdSmUF+ImCT3fHFw+E5eXlx0sqoeOgaK8oIv0c6CIoi4wfb2dLle52tg+ L3Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YQ+210y+fkgywO/hY1K+7ORd3ryKwGlmVVud3J1ycIA=; b=rFpeJVHxtEiikuNrHyzxh35Gg2WVIdBAMRkpeDWRLkuwG+foBRmYYwxOeJBnNoLHuK xBbJhWwJ5J25lo93NkSTg6x+rVUl7U4wZc6NJTsDJMMwWn0Ft0ULgZpYTSPkTBGjbZ5z aCGmMBD1KphemRR2a+425T8rFJI/g49QQVGp0be73qq1aBP7M72gmukxusdWpNN5aFq+ 0jVoi8HDjd1bEDJHn74iTn0/9fSmjDBIfTkEunG/8T98hDXyQx8FE4SFFTmDIV59fHWs Js4+DnYflz9kBpmfa+MaOonQTT5RvVaFaZLb3X2F3Ub5VGXKMgFSjZdxeWS336pQ24fk x/Lw==
X-Gm-Message-State: AOAM530IYbCsXBk0r8TfznrEfN24+5lz2sYszAfDp2Mmc3nFa+elnaRn gS4I8uO4jknraAL+id6TOeNN+VVpNjvUPvqAEhc0Rw==
X-Google-Smtp-Source: ABdhPJyRix4kyCWKbSklAonyDtZpnKMXfT5C3JnMxJ4Kn7cr0YEGXeAtIpCCXveJWQY2ImC2U98xtsIY/rNA81rGU9o=
X-Received: by 2002:a17:906:8255:: with SMTP id f21mr12691524ejx.265.1607206514361; Sat, 05 Dec 2020 14:15:14 -0800 (PST)
MIME-Version: 1.0
References: <160703668657.9405.8891046478566468162@ietfa.amsl.com> <C573A554-9221-49C2-94AB-E552F1BA69E4@gmail.com> <8360e9919d46478cb471ccbafe923c7a@huawei.com> <DM6PR13MB27623A5EEB29F8294C3291C89AF10@DM6PR13MB2762.namprd13.prod.outlook.com> <a6c1a352-5f31-3c4b-9b75-50a64f82c925@erg.abdn.ac.uk> <CALx6S37zOXx5T=3wACpiif91dGnpykUEcpX9DhQ9cH2zD_jGFQ@mail.gmail.com> <DM6PR05MB6348F883A7D6076685001E90AEF10@DM6PR05MB6348.namprd05.prod.outlook.com> <753bd02e-4824-0067-9a42-9b2b3de629f9@gont.com.ar> <c6d23a78-de76-7f9a-0e6a-21526b662904@gmail.com>
In-Reply-To: <c6d23a78-de76-7f9a-0e6a-21526b662904@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 05 Dec 2020 15:15:03 -0700
Message-ID: <CALx6S35K7w4-0966Lin9mTFTkwZ57JkUw6KMADKB4P2ndLj6qw@mail.gmail.com>
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Fernando Gont <fernando@gont.com.ar>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Haoyu Song <haoyu.song@futurewei.com>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VcygwpwPYmRGhiUZ_Zcv6VWe_hU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 05 Dec 2020 22:15:25 -0000

On Sat, Dec 5, 2020 at 1:03 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 05-Dec-20 19:25, Fernando Gont wrote:
> > Hi, Ron,
> >
> > On 4/12/20 13:52, Ron Bonica wrote:
> >> Folks,
> >>
> >> The following are a few things we can all agree on:
> >>
> >> - The maximum length of an HBH Options header is 2,048  bytes.
> >> - A source node can encode hundreds of options in 2,048 bytes.
> >> - Given today's technology, it would be impractical to design an ASIC that can process hundreds of options.
> >> - When an ASIC encounters a packet with more options than it can process, the best thing it can do is to drop the packet
> >>
> >> Having established that hundreds of options are too many, we are left with the following questions:
> >>
> >> - Should each node determine the maximum number of options that it can process, or should there be a global maximum?
> >> - If there should be a global maximum, what should that maximum value be?
> >>
> >> If we leave each node to determine the maximum number of options that it can process, source nodes will need to discover the maximum number of options that can be used on each path. This should remind us of PMTU Discovery. We have all seen that movie. It has  a very sad ending.
> >>
> >> If we can agree that each node should support at least a global maximum number of HBH options, we are faced with the following dilemma:
> >>
> >> - If we pick a constant that is too small, we may not be able to support future use-cases
> >> - If we pick a constant that is too large, low-cost processors may not be able to support it
> >
> > Agreed on all of the above.
> >
> > My questions are:
> >
> > 1) Does the number of options really matter?
> >
> > 2) Regardless of your response to #1, aren't we overlooking what's
> > probably the bigger elephant in the room, which is the overall length of
> > the IPv6 header chain?
>
> It's more than that. It's the *nature* of the header chain. It's a linked
> list with different logical structures for each component of the chain.
> It's something that by its nature can never be completely processed by
> predefined ASICs or FPGAs; it cries out for an NPU. Not all routers have
> NPUs.
>

Brian,

I'm not sure how to translate that into protocol requirements. What we
did in RFC8504 and RFC8883 was to define different limits that may be
applied to extension header processing (and in one case of RFC8504,
all headers processing).

>From RFC8540 the possible host limits are:

- A host MAY limit the number of consecutive PAD1 options in
destination options or hop-by-hop options to 7.
- A host MAY limit the number of bytes in a PADN option to be less than 8.
- A host MAY disallow unknown options in destination options or
hop-by- hop options.
- A host MAY impose a limit on the maximum number of non-padding
options allowed in the destination options and hop-by-hop extension
headers. (default if limit is used is 8)
- A host MAY impose a limit on the maximum length of Destination
Options or Hop-by-Hop Options extension headers.

For RFC8883 we defined ICMP errors limits that might be applied by
hosts and host routers (the limits here are super set of those
described in RFC8504:

- "Extension header too big"
- "Option too big" for length or number of consecutive padding options
exceeding a limit.
- "Option too big" for the length of an option exceeding a limit.
- "Too many options in an extension header"
- "Extension header chain too long" headers exceeding a limit.
- "Too many extension headers"
- "Headers too long"

The last one is not specific to extension headers, but can be used if
a router drops a packet because the length of all the headers it needs
to process is greater than its capabilities.

Tom



> It's well worth reading this:
> https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities-00
>
>   Brian