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

Fernando Gont <> Thu, 08 April 2021 05:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F5943A39DB; Wed, 7 Apr 2021 22:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 yvBX3rFm1OUr; Wed, 7 Apr 2021 22:16:44 -0700 (PDT)
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 476E93A39D7; Wed, 7 Apr 2021 22:16:43 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 221C1280405; Thu, 8 Apr 2021 05:16:36 +0000 (UTC)
To: Tom Herbert <>
Cc: "Rob Wilton (rwilton)" <>, Gorry Fairhurst <>, IPv6 Operations <>, "" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 8 Apr 2021 02:16:33 -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: 8bit
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: Thu, 08 Apr 2021 05:16:50 -0000

Hi, Tom,

On 8/4/21 00:51, Tom Herbert wrote:
> Fernando,
> I will also point that the data of RFC7872 is not consistent with
> header length being the top reason for drops. If I'm reading the data
> correctly, the HBH options are drop at about 3-4 time that rate that
> Destination options in that analysis. Since there both the same size
> (8 bytes), it seems that the majotiy of HBH options are being dropped
> because they are hop-by-hop options, not because the header chain is
> too long. This makes sense, because of the original requirement that
> all intermediate nodes must process hop-by-hop options, and we know
> many vendors didn't implement then. That requirement was relaxed in
> RFC8200, and so we'd expect drop rates to drop as nodes move to
> ignoring HBH options instead of blindly dropping them.

Again: this document is not trying to explain the numbers in RFC7872. 
PLease do read the abstract and the disclaimer, because you keep trying 
to have this document do something that it's not meant to do.

You should also note that the possible impact on devices is dependent on 
the EH chain length. However, the decision to drop packets need not be 
based on the EH length -- among other reasons, because such information 
might not be readily available.

Folks running a network can't be bothered digging into how many bytes of 
EHs each device they use can handle, and then be expected to figure out 
if there'ś any way to let only packets of shorter EH-chain lengths 
through. There are other problems to tackle day-to-day -- and this one 
is not even a problem: If I have no practical requirement to support 
them, and on the other hand there'ś risk in supporting them, I don't 
need to explain what my decision will be. You'll have a hard time 
explaining your manager or CEO why your network was brought down for 
supporting something you didn't need to support ("didn't need" == "the 
folk that pays the bill didn't ask for or care about it")..

Fernando Gont
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1