Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Middleboxes

Ole Troan <> Sun, 02 August 2020 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68C7D3A0BE6 for <>; Sun, 2 Aug 2020 05:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 qbjFbw_qykts for <>; Sun, 2 Aug 2020 05:05:30 -0700 (PDT)
Received: from ( [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEC263A0A8E for <>; Sun, 2 Aug 2020 05:05:29 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 6BEF24E11B28; Sun, 2 Aug 2020 12:05:28 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-EEEB731C-825F-40F8-9EFD-27352B49BEB8
Content-Transfer-Encoding: 7bit
From: Ole Troan <>
Mime-Version: 1.0 (1.0)
Date: Sun, 2 Aug 2020 14:05:25 +0200
Message-Id: <>
References: <>
Cc: "" <>
In-Reply-To: <>
To: Vasilenko Eduard <>
X-Mailer: iPhone Mail (17G68)
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Middleboxes
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: Sun, 02 Aug 2020 12:05:31 -0000

> On 1 Aug 2020, at 18:47, Vasilenko Eduard <> wrote:
> I am still not happy that middleboxes (Firewall, Load Balancer) are discarded as the reasons for EH drops.
> Tom (Herbert) is right that “FWs and middleboxes that insist on meddling in protocol layers beyond the networking layer where both the standard and the Internet architecture say they are not supposed to look at”
> But they are! We should not ignore the reality.
> It is especially evident that they are among reasons for EHs drops after response:
> > I would love to see the firewall device that is capable of processing ALL protocol headers in the IETF protocol suite! Reality is that firewalls can only process what they are programmed to process which is typically a very small subset of the possible protocols a host might want to use.
> It is not good to ignore/hide some type of drops that we do not like.
I think you have a good point. 

If I was implementing a function to wash traffic in front of a set of eg DNS servers, why would I ever let any EH through? Known or unknown.

There’s a chicken and egg situation. Awaiting  an across the Internet useful EH option. 

Apart from measuring the transparency level of the core Internet, it’s unclear to me what useful conclusions we can draw from this work.