Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

Fernando Gont <> Tue, 15 September 2020 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C1513A0AB0 for <>; Tue, 15 Sep 2020 04:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DDJsTt6ggNuP for <>; Tue, 15 Sep 2020 04:39:01 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B98713A0AAA for <>; Tue, 15 Sep 2020 04:39:00 -0700 (PDT)
Received: from [IPv6:2800:810:464:1088:61a8:9ab9:865a:8c48] (unknown [IPv6:2800:810:464:1088:61a8:9ab9:865a:8c48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D814A40008; Tue, 15 Sep 2020 13:38:56 +0200 (CEST)
To: tom petch <>
Cc: IPv6 Operations <>
References: <> <20200729084351.GG2485@Space.Net> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Tue, 15 Sep 2020 08:24:22 -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] Operational Implications of IPv6 Packets with Extension Headers
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: Tue, 15 Sep 2020 11:39:03 -0000

Hi, Tom,

On 15/9/20 06:05, tom petch wrote:
> I wouldn't mind writing a Section that sits between the current Sections
> 2 and 3 with more background on extension headers, if you think that
> would be of value.
> <tp>
> Yes please.  One page or two pages max, summarising why they were thought a good idea, the different types and their uses, how widely used they are  and with references;  RFC8200 may be Normative but it takes a while to appear and that after RFC2460! 

An intro to EHs -- and e.g., how the structure compares to the IPv4 
packet structure is simply and doable. OTOH, what you suggest might now. :-)

e.g.,Not sure one can tell how widely used they are. Also, getting into 
enumerating EHs will result in the relevant section becoming stale soon, 
since there seems to be quite a bit of development in this area.

> Section 3 makes reference to security, fragmentation and such like with no apparent connection to EH; I think that such a connection should be explicit earlier.

I'll craft some text and post to the list for review before 
incorporating into the I-D...

> <tp>
> but it leaves the I-D without an ending, it just peters out.  With an introduction saying what EH are used for then you could have a summary harking back to that and saying which, or which kind of, work and which do not implying, without being explicit, what future developments might or might not be a problem.

The think is that, on the public Internet, all that I have checked are 
unreliable. -- That's a sad fact... but a fact. :-)

If you control the network, well.. you control whether they are dropped.

And the obvious corollary is that use cases that are targetted at 
limited domains will likely work, where any targetted at the public 
Internet will fail, at least for some time.

That's as much as we can say so far -- based on data... since otherwise, 
guesswork is just guesswork.


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