Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet

Hannes Frederic Sowa <> Wed, 06 November 2013 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E28621F9E50; Wed, 6 Nov 2013 05:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tQa4gzLjQGAu; Wed, 6 Nov 2013 05:01:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 219E621F9FB6; Wed, 6 Nov 2013 05:01:48 -0800 (PST)
Received: by (Postfix, from userid 500) id 3DCDC1A0C287; Wed, 6 Nov 2013 14:01:41 +0100 (CET)
Date: Wed, 6 Nov 2013 14:01:40 +0100
From: Hannes Frederic Sowa <>
To: Fernando Gont <>
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800
Cc: IPv6 Operations <>, "" <>
Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2013 13:01:53 -0000

Hi Fernando,

On Mon, Nov 04, 2013 at 03:01:48PM -0800, Fernando Gont wrote:
> I did a presentation on the topic at the IEPG meeting earlier this week.
> It provides some concrete data regarding IPv6 fragmentation and
> Extension Header filtering on the Internet.
> The slideware is available at:
> <>
> Certainly there's *much* more work to be done in this area, but I
> thought that this could be good food sfor some of the discussions that
> we were having on the topic.

We had some some bugs in path MTU handling in the linux IPv6 stack which
will get resolved with the next stable kernels.

If such an experiment is repeated I would suggest keeping a tcpdump of
the traffic and an ip -6 monitor route log while doing this experiment.

I currently don't know if we report path MTU events back up to user space,
and if not, it will be hard to do so because that would confuse user space
routing daemons which already listen for route change notifications. But
for such an experiment I could provide such a patch. It would be nice
that we don't drop path mtu discovery on such busy boxes because of
regular routing garbage collector pressure or just because of bugs.