From owner-freebsd-pf@FreeBSD.ORG  Sat Mar 21 22:11:49 2015
Return-Path: <owner-freebsd-pf@FreeBSD.ORG>
Delivered-To: freebsd-pf@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 4852B23F
 for <freebsd-pf@freebsd.org>; Sat, 21 Mar 2015 22:11:49 +0000 (UTC)
Received: from luigi.brtsvcs.net (luigi.brtsvcs.net
 [IPv6:2607:fc50:1000:1f00::2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 223DE143
 for <freebsd-pf@freebsd.org>; Sat, 21 Mar 2015 22:11:48 +0000 (UTC)
Received: from chombo.houseloki.net (c-71-59-211-166.hsd1.or.comcast.net
 [71.59.211.166])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by luigi.brtsvcs.net (Postfix) with ESMTPSA id 2A6502D4F8D;
 Sat, 21 Mar 2015 22:11:47 +0000 (UTC)
Received: from [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29] (unknown
 [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by chombo.houseloki.net (Postfix) with ESMTPSA id A229C9A2;
 Sat, 21 Mar 2015 15:11:44 -0700 (PDT)
Message-ID: <550DEC94.4040805@bluerosetech.com>
Date: Sat, 21 Mar 2015 15:11:32 -0700
From: list_freebsd@bluerosetech.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Kristof Provost <kristof@sigsegv.be>
Subject: Re: PF IPv6 fragments handling
References: <20150203202519.GD2167@vega.codepro.be>
 <20150209232416.GB37777@vega.codepro.be>
 <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org>
 <20150317011507.GC2036@vega.codepro.be>
In-Reply-To: <20150317011507.GC2036@vega.codepro.be>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-pf@freebsd.org
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
 \(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 22:11:49 -0000

On 2015-03-16 18:15, Kristof Provost wrote:
> On 2015-03-16 09:51:55 (-0400), Eric van Gyzen <vangyzen@FreeBSD.org> wrote:
>> Here is a brainstorm that might give the best of both:  Return the
>> reassembled packet from PFIL_IN, but with the original fragment chain
>> stashed in metadata.  Most of the stack operates on the single,
>> reassembled packet.  ip6_output() sends the original fragment chain.
>> Sure, it uses more memory, but reduced CPU time might be worth it.
>>
> It's an interesting idea. There are a number of advantages (like not
> modifying the fragment ID or the sizes of each packet).
>
> It won't reduce CPU usage though because we'd have to copy the packet
> which is something we don't do at the moment.

Why would you need to copy the packet in order to store a list of 
fragment IDs and offsets?

You need that information anyway for refragmentation because an IPv6 
router is not supposed to fragments.  I'd interpret that to mean the 
fragmentation pattern coming out of pf should match what went in.  A 
later hop wouldn't be able to send back a meaningful PTB message otherwise.