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

Tom Herbert <> Fri, 11 June 2021 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79D3F3A29F2 for <>; Thu, 10 Jun 2021 22:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Uljbed7PzrW for <>; Thu, 10 Jun 2021 22:48:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D729A3A2A19 for <>; Thu, 10 Jun 2021 22:48:52 -0700 (PDT)
Received: by with SMTP id k7so2727331ejv.12 for <>; Thu, 10 Jun 2021 22:48:52 -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:content-transfer-encoding; bh=lWWQJ0J+aoR7Yju36gohmtsqrOHetnWMiCs6ByP3ZcA=; b=KlkCDVSItKrAeW5Xq7CGiuzOnDuv/kRG0F7F914rc2zM57PZ5HJwW3s1WbFlw50xTO qcNSlrxcIpVU/rKIEWjojbaePj3k/xdBo5/RUWlI61WRQPR3KuKiqOctQ/axw+o3ki5C TM/y4HX8TZPRNQC2Y6tXOZY9dS+hsE5XMgaJSSoYyIOgPfEU70XByS5ZikHVWYTjLA9M Ti6rNxn6NsitqHr/iHTNcE/6R8sfy/VeWRx4fWU+9nD0ONbHEo80sxnKU7dYmBIsx33a ZlKi11yGwGe5slEzeWpUQ993RRMwh7mkmQlDNOg8U66A1RW1YmY3dORCSMx6C2xV1Zti 3h8g==
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:content-transfer-encoding; bh=lWWQJ0J+aoR7Yju36gohmtsqrOHetnWMiCs6ByP3ZcA=; b=J7QXR0PjzY7mB9zDYkYWrBSRXmwbvfBuOw53a7dumG0uy86lLP3CGMp2UI4u1M/OrK RR6srNAom2HPBakGcFmmorWN381mGa94xSFapTt3TJfHqKD33DaihsjPauq6HOUf7ALL ywYXglsUqQXQWRkzxKeVte6e61BBgZN/CJm3YGUBssN19oK1RJR0tyLcR+CmKM4I4vGZ c5X2HU0mwu8zEDy8wzu/IF1pkrWj8jPh/PKpS4oNRJeV2qsWXWxt+LT6elB6Psx8y1g6 Hgvw7NiLM8PQdzYq1fx74sSQJOv0ly81OIv6E3lnoowwNTL0j5xOJqs+4lCGQwxDYHE7 7BFQ==
X-Gm-Message-State: AOAM5331xjO6LZOs2KHzjcqQVZIL243HvxehH/ByOKXfSd5RrITVIpfn 1QhO1P4SYFW3W3UFLdRUAqa52JRlfxEQSt+VY0+7iA==
X-Google-Smtp-Source: ABdhPJyUPoidLhwk10DXI+czEYYxM+WrTVXJt2fc/HpefcsNi7BgP8lK6pSiOywxop981hn9qWmg6el3pcssdek+SX8=
X-Received: by 2002:a17:906:149a:: with SMTP id x26mr2078046ejc.41.1623390529746; Thu, 10 Jun 2021 22:48:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 10 Jun 2021 22:48:38 -0700
Message-ID: <>
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
To: Fernando Gont <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 11 Jun 2021 05:48:58 -0000

On Thu, Jun 10, 2021 at 10:21 PM Fernando Gont
<> wrote:
> Hi, Pascal,
> On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> > This might need a solution be similar to the MTU problem; e.g.,
> > during PMTUD a node might add the HbH Options that it needs to check
> > that the options make it through…
> Aside from a bunch of other evil details:
> WHat if, say, you employ this solution at, say, connection-
> establishment time, find that EHs actually "work" towards your
> destination, but them, sometime later, the path to your
> destinationchanges, and you find out that EHs no longer work?

That scenario isn't all that much different than rerouting causing a
flow to not hit the same stateful middlebox, or a NAT state times out,
or any other instances of something in the network rendering a
connection too no longer viable. In all these cases, the application
just restarts the failed connection.

>      Abort the transaction/connections?
>      "Migrate" from EH-based mechansim to the fall back mechanism?
>      Anything else?
> What about the impact on e.g. RTT for connection-establishment? What
> about the complexity of the mechanism? How many bugs/vulns before every
> implementation gets it right?
All the more reason we need to establish some guidelines as to what
the host can send in terms of extension headers and correspondingly
what intermediate nodes should support. Since RFC8200 allows
intermediate nodes to skip over HBH options, then the pertinent limit
would seem to be how long the IPv6 header chain is (solely for the
benefit of those routers that require parsing of the transport
header). I believe at least 128 byte parsing buffers are well
supported by vendors, and assuming 16 bytes for L2, and first 8 bytes
of transport header might need to be accessed by intermediate nodes,
then that implies a minimum default of 104 bytes and subtracting forty
bytes for IPv6 header gives nice round number of sixty four bytes for
extension headers. Hence, I suggest the requirements should be:
routers MUST forward IPv6 packets with sixty-four bytes or less of
extension headers, and correspondingly hosts MUST NOT send packets
with more than sixty-four bytes of extension headers unless they have
knowledge that the path supports a greater number.


> Truth #3 of comes to
> mind...
> Thanks!
> Regards,
> --
> Fernando Gont
> Director of Information Security
> EdgeUno, Inc.
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531