From owner-freebsd-pf@FreeBSD.ORG Tue Mar 17 01:15:12 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57B69152; Tue, 17 Mar 2015 01:15:12 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16FCE3C9; Tue, 17 Mar 2015 01:15:11 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 736FE126D5; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 2473F78399; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Date: Tue, 17 Mar 2015 02:15:08 +0100 From: Kristof Provost To: Eric van Gyzen Subject: Re: PF IPv6 fragments handling Message-ID: <20150317011507.GC2036@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5506DFFB.7050302@FreeBSD.org> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, bz@FreeBSD.org, ae@FreeBSD.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:15:12 -0000 On 2015-03-16 09:51:55 (-0400), Eric van Gyzen 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. In addition to that there's the concern you pointed out that we'd forget to adapt them both, or that we'd end up checking the wrong one at any point in the stack. Regards, Kristof