HBH Option Header Configuration (draft-hinden-6man-hbh-processing)

Bob Hinden <bob.hinden@gmail.com> Tue, 08 June 2021 20:06 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CF0FC3A3C2C for <ipv6@ietfa.amsl.com>; Tue, 8 Jun 2021 13:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kMtMRihT7bcA for <ipv6@ietfa.amsl.com>; Tue, 8 Jun 2021 13:06:38 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 134713A3C2A for <ipv6@ietf.org>; Tue, 8 Jun 2021 13:06:37 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id e11so12695452wrg.3 for <ipv6@ietf.org>; Tue, 08 Jun 2021 13:06:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=uIO+nwVpKU8jG0l6/Ev97xbZ+08NHM2nxGFF2oonKRw=; b=uRymB7dnBHm6wh3KzKqTh3bByLIT7eEvYq8MiTL88vS23iHQ4My/0fFAWmk+ZkSkRW q6hNIG1cd+BhJpJbGosXq0QUN+IuR7VBaRGtpv7QHpoedzlDRDD+byFQzIVWGkqndi53 OFd+W+WVazh1EcSLGBjHKwh8e9ACNYRaB2gaY/mij6zHyYVNNmMmX9lO009D1W5Hzeg1 hf/R3BPQWIT5zmH5OFBtivINOsoUrcE0B8LeRnUH7H2LN6gQPB0MFQxEKm06FIHimsWP 3bnVu8L+nPAGOoiATbWm9Z+gpz183t7qLC7mwDAWFj/MtGGtVcP1kN9RWe+rANVg6dte +Umw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=uIO+nwVpKU8jG0l6/Ev97xbZ+08NHM2nxGFF2oonKRw=; b=AUlXnTZkfG3aA/8H62V6Rap8/wgNefMRzBPYX70tBE+codhnR6AbLoe/npD4pKp1hl WUMJzAxERlxzYRRg+mNHm/gaMErvD1gNycs3N4df7nJQ4Owl1RFl/hVkOd5tBMnPmCIl DmfZ38x0/1Ko2D1Q2lrV4ipSWABGm/zQZsSl5MvWi5ritxtFfxaj+pBhF5dI6TdzO+Te eOfDm3rnas4rIYU3JaJQ9jDx3EVmpImnOdC1tqb7BHjY/l7SF0c49AU2vXt6OL4DsVDY h3weTq10sW6BhhpnP49C1yPD+fG0V4D9h53olSZ7lT+RVC0jN9yPPFIj4EdgJZ9ChFla 5Tcw==
X-Gm-Message-State: AOAM533Y3w2ko2mvDqZN/fzDMaIoIae4XwRerDz+JP2CZqF7P6fHrPV4 XZ8klwWP9FMnTny4CtY6Bs7BFTMlJjU=
X-Google-Smtp-Source: ABdhPJw+oSbFBWmieFsI2eVI9SWZ+3kGkVPfgfKcE1Ca8bDdXv4Jw8VnMLtGAu65OaeqUBFDHm4kdg==
X-Received: by 2002:a5d:664c:: with SMTP id f12mr24029710wrw.206.1623182794733; Tue, 08 Jun 2021 13:06:34 -0700 (PDT)
Received: from [] (c-24-5-53-184.hsd1.ca.comcast.net. []) by smtp.gmail.com with ESMTPSA id b188sm5302350wmh.18.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jun 2021 13:06:34 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_61CC06DE-4551-4DCC-A975-72238627BF0E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)
Message-Id: <90F1C7DD-A8FF-45C1-9B9F-6E57A04AB88B@gmail.com>
Date: Tue, 08 Jun 2021 13:06:31 -0700
Cc: Bob Hinden <bob.hinden@gmail.com>
To: IPv6 List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Eh4froxsJc5HNttp7edq7vLL9Hs>
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: Tue, 08 Jun 2021 20:06:40 -0000

Gorry and I are going over the comments received on draft-hinden-6man-hbh-processing-01, thanks very much for your comments, it is very helpful.  We are working on respond to them.

One issue that is common to several questions is what does configuration mean regarding HBH Option headers.    Our draft and in hindsight RFC8200 is not clear what this means.   The note in Section 4 of RFC8200:

  NOTE: While [RFC2460] required that all nodes must examine and
  process the Hop-by-Hop Options header, it is now expected that nodes
  along a packet's delivery path only examine and process the
  Hop-by-Hop Options header if explicitly configured to do so.

This can be interpreted to mean a configuration flag allowing/disallowing processing of a HBH Option Header, or specific configuration for each HBH Option type.

draft-hinden-6man-hbh-processing-01 says:

  This document updates [RFC8200] that a
  node MUST process the first Option in the Hop-by-Hop Header in the
  Fast Path and MAY process additional Hop-by-Hop Options if configured
  to do so.

Several people asked if we are proposing to remove the ability to not process the HBH Option Header.

We have discussed this and conclude that yes, we are proposing to require all nodes to examine and process the first HBH Option in the Fast Path.   Not just drop packets with HBH Option Headers.  This change needs to be made clearer in the draft.

If it is allowed to not process any HBH Options, then we don’t see any purpose for this draft.   We do want to require that a router examine and process one HBH Option in the Fast Path.

We note that while RFC8200, and it’s predecessors, didn’t call it out specifically, if did infer that a node would have code and/or configuration for each possible HBH Option Type.   Otherwise, it wouldn’t say:

  The Option Type identifiers are internally encoded such that their
  highest-order 2 bits specify the action that must be taken if the
  processing IPv6 node does not recognize the Option Type:

and there would be no reason for the two high order bits in the Option Type that describe the action.  The draft doesn’t change this.

We do note that per option configuration could be set to not support any options, that would be allowed, but it would require a router to follow the two high order bits in the Option type that control if the packet should be dropped or forwarded for at least the first option, and any other options that it was configured to support.


Bob & Gorry