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

Tom Herbert <> Thu, 10 June 2021 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E7D3A1D6F for <>; Thu, 10 Jun 2021 15:47:58 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6HEnDK7y1S43 for <>; Thu, 10 Jun 2021 15:47:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D42B63A1D70 for <>; Thu, 10 Jun 2021 15:47:55 -0700 (PDT)
Received: by with SMTP id ba2so33203960edb.2 for <>; Thu, 10 Jun 2021 15:47:55 -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=ykM7DeYaIdtiOUhbziR7QK9gTquMfbKqCcw3txxhCuI=; b=errWWG/frYOtpnjDLn6n+WDbL4W9PY6/mAO8/wRtKZmJDT4nt3cC2EihWK/Yc2RWyh X2eybOsi+UQkYTL3F3JFPC9pe/lujb4/jYaFpCy3ab+ywFy6gqE4Pxbe91AvKs3VWPBh Z6LRqpArOa8Qnopfqz35DD7U3B/SwrBLl6dipOzWm7CO21tfwofag+Vq+pox3+Nymw0K 7/TjJw137tAefTrLTaBh0HPnEgrJul1UPyguC6a/Lq9YRx08MpZFM0Uy/5P4OYE4Xmcv BwpgDpp/paAtjft6A4Dduc4mxn5M6Xf8WgnLXnG/ALVesxOSMw4xeBcwKAbJ8OdFPUNl 2VJA==
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=ykM7DeYaIdtiOUhbziR7QK9gTquMfbKqCcw3txxhCuI=; b=deOs9MBb0Ql+fxViJ8OAuk7AeZ7PZu1DIQzFP89QgvIkxNxpee93vJoZ/z/B8jD0lO E/P4jaVyD9Cf8W4SRTju6IfuZFhWRKa4prB9EnESvuo96iJrBUWcHNoY4KW6SeIDjIDX dxpo3hOmA75h7JNBxcl7ipqWB6RXcYUxWZBh+puLpdKuHUB+zJzauKp0wECrp2uEbdX7 5oU9zNDu4qQyQlOHe4dmi9ZRogroyKXiKS0GGWaRc/amQvPjGMUHvlMpYpnialICftiB a7XWkiR3OBRKf845JuQdOreD3+7HTRYzokz3OHEoyjOFlyLBY79k0Ehpzy5b5dKoz6Zz uDoA==
X-Gm-Message-State: AOAM532rrMo4iDsQK7cWSjjLWFPPzRx8U7XJRAtnbH10koL5BD6ha6Oa 29sqWXbUbV2c9HR3upJyWyv3sUq3rs5K+fEgp6dLWg==
X-Google-Smtp-Source: ABdhPJx59ojLyRaVNbZPDWOnk+42iQrN5a2l4ecwOqC3D2q/6ZdbHcD6vuENUCuyXIObjJCuoliaMbMcxIJgH/qL5YM=
X-Received: by 2002:a05:6402:645:: with SMTP id u5mr712359edx.293.1623365273583; Thu, 10 Jun 2021 15:47:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 10 Jun 2021 15:47:42 -0700
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
To: Brian E Carpenter <>
Cc: Fernando Gont <>, "" <>, "" <>, "" <>
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, 10 Jun 2021 22:47:59 -0000

On Thu, Jun 10, 2021 at 3:20 PM Brian E Carpenter
<> wrote:
> On 11-Jun-21 03:07, Tom Herbert wrote:
> > On Thu, Jun 10, 2021 at 12:41 AM Fernando Gont
> > <> wrote:
> ...
> <big snip>
> ...
> > If you are pursuing that path, you should also limite the overall IPv6
> > header chain length. That;s probably even more important than limiting
> > the number of EHs or number of HbH options.
> >
> >> Fernando,
> >
> >> That limit and other pertinent ones are defined in RFC8504 section 5.3
> >> and RFC8883. The limits in RFC8504 are specified for hosts, but it
> >> would be straightforward to apply them to routers  where the behavior
> >> when a limit is exceeded would be different-- end hosts should drop
> >> packets that exceed the limit, intermediate nodes should stop parsing
> >> and forward the packet. If a node decides to drop the packet then it
> >> can send an RFC8883 ICMP error to inform the sender what the exceeded
> >> limit was. Recommended defaults can be provided for limits; e.g. in
> >> RFC8504 the limit of HBH or DestOpts is eight meaning that receivers
> >> should support up to eight options and senders should be able to send
> >> up to eight options with reasonable confidence their packets won't be
> >> dropped. A similar default could be established for length of IP
> >> header chain (for hosts this isn't immediately necessary since hosts,
> >> unlike routers, usually don't have a concept of fixed sized parsing
> >> buffer holding headers, although with hardware acceleration that limit
> >> might be more applicable to set in the host).
> Which all, IMHO, shows that the Internet cannot ever be assumed to be
> transparent to extension headers of any kind; either we accept that
> extensions are confined to limited domains or we need a probing process
> before using them, to determine whether they can survive the trip.
> Not much has changed (and it's exactly the same for IPv4 options): unusable
> across the Internet.


By that same logic, IPv6 itself is unusable across the Internet since
not all Internet paths support IPv6 :-). For that matter, probably any
protocol, with the possible exception of plain TCP/IPv4 without
options, is "unusable" if the definition of usable is that there is a
100% probability that packets of a protocol will reach their

It seems like this is an exercise of making protocols ever more
usable-- either by fallbacks (e.g. Happy Eyeballs) as you mentioned,
but also by clarifications to the protocol requirements to elicit
practical implementation. For instance, RFC8200 allowing nodes to
completely ignore HBH options instead of requiring every single node
in the path to process was a big step in the right direction.
Specifying a reasonable default limit for the number of options that
should be processed or length of the IPv6 header chain that is
supported would be another step. Note these things won't get us to
100% support, but they could increase reachability and hence increase
utility of the protocols.


>    Brian