Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Tom Herbert <> Thu, 03 June 2021 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F4E43A15EB for <>; Thu, 3 Jun 2021 08:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UGQt2jw5HBYm for <>; Thu, 3 Jun 2021 08:17:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9483E3A15E6 for <>; Thu, 3 Jun 2021 08:17:59 -0700 (PDT)
Received: by with SMTP id cb9so7602361edb.1 for <>; Thu, 03 Jun 2021 08:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b6cc4bD6ZeSRfQk32gftzYOgfLd1gt+E3iVxaIgJynw=; b=hxT2trJTIcgsrWqb9C91JW8gb3wSDD9phHlOwRR4s4f6bsZEeRYL2PfPNVg3dR9UgB 2gnh2n/75NA+LAgPGklTuwmJpn6TE9z6z2fDAPWz3PrKUQYJ0g6O+Q90DgRwzb1qzeAq atdQvONYLX6e6ZjW0xtaFMKxcAo821IiIVGWRMyvX9S4qhIqcnwr9oXl1UsbnULWAHm8 8VogC9BJzQuaytXjqcFVEB0tXZQOPFBqUydr5VYeAnqqEdHGSB2j/ZHet+Jnfkp//Psk 1XJhDo/2M+ny16P83TTRa7LUexAjhAKOomLErzjSz6IyOCE7ZJvepoLf5XoNqBtZC1Dm SnuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b6cc4bD6ZeSRfQk32gftzYOgfLd1gt+E3iVxaIgJynw=; b=MmjqiaLIED+HG4dvzvq4Vq9dH8OTBe0ihgaGbc7Z3calKYHWwXy/nu+pkSISD8pVtp 526JMgUzUfzDrYQ0hjB5fPUC8P78CiiubHawnCGzbyEPmBBXMQNU1uMEBtuRZ6ZNgjrT cq38uOM4EjRJfBfsNYgDAgX/iWe7IvYBXq1dlb5L4W+F5PSBawAl+DGy7ApVoogO23Dm g+Ql20MgS/dvPX6u35sJdKkd/TJhOWOPOF5q6v/UIqZbDGeVKSp7yUZa20AxauA3qv3z 6HLXziiViXc3TNyO5UDx5lwTljCeBDb63uu3q4defWpkXGc6J3c+6pWuYjfaRTzUu02Y M/Zw==
X-Gm-Message-State: AOAM531E50C5VSfiWio16ZRwfAV6tZZStaWiPXSAescQhkWlhfOgg3ee vLP/80OSAExatuzK/XnuBOkTS12k/y9deFDp54Nlcw==
X-Google-Smtp-Source: ABdhPJyIghkH1UTZ0g6+V1FSoNdhwPdrs0irptL9cktFWNhQVAQh/W9yYEh3dSZmarspRSFlXHm9YfOlJHyfgZYAfsU=
X-Received: by 2002:a05:6402:1601:: with SMTP id f1mr272831edv.383.1622733472572; Thu, 03 Jun 2021 08:17:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 03 Jun 2021 08:17:41 -0700
Message-ID: <>
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
To: Bob Hinden <>
Cc: IPv6 List <>, Gorry Fairhurst <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Jun 2021 15:18:04 -0000

Hello, a few comments on the draft:

>From the draft: "Unfortunately, this did not improve the processing of
Hop-by-Hop options and did not significantly improve deployment and
use in the Internet."

Is there data that supports this statement? Since RFC8200 was
published, have router implementations been changed to ignore HBH
options instead of dropping packets containing them? The primary
problem with supporting HBH Options in the Internet isn't that we need
all nodes in the path to process them, it's that we need all nodes in
the Internet to at least forward packets containing them and not
blindly drop the packets.

"This document updates [RFC8200] that a node MUST process the first
Option in the Hop-by-Hop Header in the Fast Path"

It think this should be "This document updates [RFC8200] that a node
MUST process the first Option in the Hop-by-Hop Header in the Fast
Path if a node is configured to process Hop-by-Hop Options"

"The share of traffic containing more than one EH however, is very
small.  For the design of hardware able to handle the dynamic nature
of EHs, we therefore recommend to support at least one EH"

I suspect that the share of traffic containing any EH is very small
:-). There's an obvious tradeoff here in limiting an extensibility
mechanism to elicit feasible implementation versus not restricting the
mechanism so much that it inhibits innovation. So we need to define
and recommend some number of options N that satisfies both these
objectives. Emerging programmable devices, such as those based on P4
or PANDA, are more capable and flexible than ASIC based
implementations, so N=1 might not be the best choice looking forward
since it is overly restrictive. Note also that section 5.3 of RFC8504
sets N=8 for end host processing of HBH and Dest Options (I suggest
RFC8504 should be referenced by the draft).

"A node configured not to process HBH options, MUST drop the packet if
the top two bits of the Option Type field of the first HBH option is

This is a change to RFC8200 that would make a lot of implementations
retroactively non-conformant. I don't think it's practical. I would
suggest updating to RFC8200 with these requirements instead.

- If an intermediate node processes an option it does not recognize
and the top two bits of the Option Type field of the option are
non-zero, then the node MUST stop option processing and SHOULD NOT
drop the packet and SHOULD NOT send an ICMP Parameter Problem.
- A final destination node MUST process all the Hop-by-Hop Options, or
drop the packet if the number of options exceeds the configured limit
per RFC8504. This includes processing per the top two bits of Option
Type when an option is unrecognized as specified in RFC8200.
- New Hop-by-Hop Options SHOULD be defined with 00 as the top two bits
of the Option Type (that is new option should be defined to be ignored
if they are unrecognized by a node).


On Wed, Jun 2, 2021 at 11:32 AM Bob Hinden <> wrote:
> Hi,
> We posted a new version of draft-hinden-6man-hbh-processing.    The changes include:
>    *  Expanded terminology section to include Forwarding Plane and
>       Control Plane.
>    *  Changed draft that only one HBH Option MUST be processed and
>       additional HBH Options MAY be processed based on local
>       configuration.
>    *  Clarified that all HBH options (with one exception) must be
>       processed on the Fast Path.
>    *  Kept the Router Alert options as the single exception for Slow
>       Path processing.
>    *  Rewrote and expanded section on New Hop-by-Hop Options.
>    *  Removed requirement for HBH Option size and alignment.
>    *  Removed sections evaluating currently defined HBH Options.
>    *  Added content to the Security Considerations section.
>    *  Added people to the acknowledgements section.
>    *  Numerous editorial changes
> We think this resolves most of the issues raised on the list and at the pervious IETF meeting.
> Please review and comment on the list.
> Bob & Gorry
> Begin forwarded message:
> From:
> Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
> Date: June 2, 2021 at 11:27:07 AM PDT
> To: "Robert M. Hinden" <>, "Godred Fairhurst" <>, "Gorry Fairhurst" <>, "Robert Hinden" <>
> A new version of I-D, draft-hinden-6man-hbh-processing-01.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> Name: draft-hinden-6man-hbh-processing
> Revision: 01
> Title: IPv6 Hop-by-Hop Options Processing Procedures
> Document date: 2021-06-02
> Group: Individual Submission
> Pages: 13
> URL:  
> Status:
> Html: 
> Htmlized:
> Diff: 
> Abstract:
>   This document specifies procedures for how IPv6 Hop-by-Hop options
>   are processed.  It modifies the procedures specified in the IPv6
>   Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-
>   Hop options practical with the goal of making IPv6 Hop-by-Hop options
>   useful to deploy and use in the Internet.  When published, this
>   document updates RFC8200.
> The IETF Secretariat
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------