Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Fernando Gont <> Mon, 22 February 2021 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB9833A1EEA; Mon, 22 Feb 2021 10:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9p5d96WInkQc; Mon, 22 Feb 2021 10:14:58 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E4393A1EB9; Mon, 22 Feb 2021 10:14:38 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:4897:2501:35bb:1428] (unknown [IPv6:2800:810:464:2b9:4897:2501:35bb:1428]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 04EFA280182; Mon, 22 Feb 2021 18:14:30 +0000 (UTC)
To: Tom Herbert <>
Cc: Brian E Carpenter <>, Gorry Fairhurst <>,,,, IPv6 Operations <>
References: <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Mon, 22 Feb 2021 14:24:17 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Feb 2021 18:15:05 -0000


On 22/2/21 11:55, Tom Herbert wrote:
> On Sun, Feb 21, 2021 at 2:39 AM Fernando Gont <> wrote:
>> Hello, Tom,
>> On 20/2/21 12:32, Tom Herbert wrote:
>> [...]
>>> This is reflected in the statement: "If an IPv6 header chain is
>>> sufficiently long that it exceeds the packet look-up capacity of the
>>> router, the router might be unable to determine how the packet should
>>> be handled, and thus could resort to dropping the packet." It's not to
>>> me clear what "sufficiently long" means; in particular, such a
>>> statement isn't helpful to the host stack developer trying to figure
>>> out if the packets they're creating will be properly forwarded.
>> "Long enough" for the router handling the packet. There are different
>> vendors, and different models. S the specific value will vary across
>> router vendors and models. In our document, we reference two sample
>> values -- but they are certainly not the only ones.
> Fernando,
> Yes, different routers do different things, but can you quantify what
> the most commonly deployed routers do? 

That's not what this document is about.

> If we can do that then we could
> establish a better requirement for host stacks more than just "don't
> send IPv6 header chains that are too long".

This document intentionally focuses on elaborating on the underlying 
problem, and *not* on providing such a recommendation.  We can certainly 
embark ourselves on that project once we complete this one.

> For instance, from the
> draft: "some contemporary high-end routers are known to inspect up to
> 192 bytes, while others are known to parse up to 384 bytes of
> header.". That's good information since it at least starts to quantify
> the router implementation constraints that are mostly the subject of
> this draft (this data really needs a reference by the way).

We reference such values for informative purposes. But the goal of this 
document is to provide a *qualitative* analysis.

(We did include a reference for the two cited values, but our 
responsible AD suggested not to mention specific vendors/products. GIven 
your comment, I'll raise the question to him)

> If we
> establish what the most common limit is, say the 192 bytes that are
> mentioned, then we could establish a requirement on routers that sets
> a reasonable expectation for hosts stack as to what will be forwarded
> with high probability.

As noted, that's certainly out of the scope of this document. That said, 
it would seem to me that RFC7872 is providing the kind of information 
that you seem to be looking for (modulo a recommendation).

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492