Re: Papers on IPv6 fragmentation

Fernando Gont <> Mon, 23 June 2008 03:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9CFFE3A68A8; Sun, 22 Jun 2008 20:28:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C3213A68A8 for <>; Sun, 22 Jun 2008 20:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.152
X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_SPEEDY_AR=0.808]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VZG3fXJWar3A for <>; Sun, 22 Jun 2008 20:21:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B60A3A688F for <>; Sun, 22 Jun 2008 20:21:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42DAC6B6777; Mon, 23 Jun 2008 00:21:47 -0300 (ART)
Received: from ( [] (may be forged)) (authenticated bits=0) by (8.14.1/8.13.8) with ESMTP id m5N3LP1j004622; Mon, 23 Jun 2008 00:21:26 -0300
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 23 Jun 2008 00:18:21 -0300
To: "Vishwas Manral" <>
From: Fernando Gont <>
Subject: Re: Papers on IPv6 fragmentation
In-Reply-To: < m>
References: <> <>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Mon, 23 Jun 2008 00:21:45 -0300 (ART)
Cc: IETF IPv6 Mailing List <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

At 08:22 a.m. 22/06/2008, Vishwas Manral wrote:

>Though this may not be exactly what you are looking for, you may want
>to look at some of the issues we identified a long while back with
>IPv6 Tiny Fragments.

I had a quick look at your document. Here are some quick and dirty comments:

* Your documents talk about specifying a minimum size for non-last 
fragments. Actually, I think one should be concerned only about the 
*first* fragment. That's the one that's used to create state at firewalls, etc.

* I don't think imposing such a requirement will, by itself, help to 
ensure that you have in the first packet all the information you need 
to apply firewalls rules. It would be trivial for an attacker to 
comply with such a requirement, but still do not provide all the 
relevant information that would be needed by the firewall to apply 
its rules. The attacker could just add one or several extension 
headers, with lots of PadN options. Thus, it would comply with your 
requirement, but still avoid sending e.g. the TCP source and destination ports.

Kind regards,

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

IETF IPv6 working group mailing list
Administrative Requests: