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

Fernando Gont <> Wed, 24 February 2021 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CB883A1859; Wed, 24 Feb 2021 09:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nJAg5fnqZR1e; Wed, 24 Feb 2021 09:23:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90C823A182E; Wed, 24 Feb 2021 09:23:14 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799] (unknown [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9DFDF280192; Wed, 24 Feb 2021 17:23:10 +0000 (UTC)
To: Tom Herbert <>
Cc: Mark Smith <>, Gorry Fairhurst <>, IPv6 Operations <>,,,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Wed, 24 Feb 2021 14:22:50 -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: [Tsv-art] [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: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2021 17:23:24 -0000


On 24/2/21 14:01, Tom Herbert wrote:
> Fernando,
> The analogy doesn't hold here because unlike knives, extension headers
> are not inherently dangerous. The problems have been caused by some
> routers implementations that have assumed unwritten requirements (like
> routers must access transport layer), unquantified requirements
> (header chains can't be too long), and apparently buggy
> implementations (mentioned in the draft). This draft describes, cites,
> recommends, references, or suggests (whichever you prefer) two
> specific mitigations which are to drop packets or rate limit packets.
> These mitigations are described without context or parameterization,
> so the reader might infer that blindly dropping all packets with
> extension headers is an acceptable mitigation. Furthermore, if the
> draft is suggesting mitigations to problems created by routers, then
> an obvious one would be to ask router vendors to fix their bugs (which
> I am trying to say without cynicism).

It seems that your mis-interpreting our document.


    This document summarizes the operational implications of IPv6
    extension headers specified in the IPv6 protocol specification
    (RFC8200), and attempts to analyze reasons why packets with IPv6
    extension headers are often dropped in the public Internet.

It is an operational document produced by v6ops, and not a protocol spec 
produced by 6man. It is aimed at operators. And, if anything, the IETF 
can make use of it for further work.

It discusses challenges that are faced in the real world, from an 
operational perspective, discussing the things an operator may have at hand.

We don't provide recommendations. We don't even mean to.

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