From owner-freebsd-pf@FreeBSD.ORG Sun Mar 22 00:48:57 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 C869027F for ; Sun, 22 Mar 2015 00:48:57 +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 85EA216A for ; Sun, 22 Mar 2015 00:48:57 +0000 (UTC) Received: from [10.248.64.94] (unknown [210.160.37.27]) by venus.codepro.be (Postfix) with ESMTPSA id 3CEECB706; Sun, 22 Mar 2015 01:48:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2090\)) Subject: Re: PF IPv6 fragments handling From: Kristof Provost In-Reply-To: <550DEC94.4040805@bluerosetech.com> Date: Sun, 22 Mar 2015 09:48:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7EA47C5D-E783-408B-8A70-9F02F5348839@sigsegv.be> 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> <550DEC94.4040805@bluerosetech.com> To: list_freebsd@bluerosetech.com X-Mailer: Apple Mail (2.2090) 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 00:48:57 -0000 > On 22 Mar 2015, at 07:11, list_freebsd@bluerosetech.com wrote: >=20 > On 2015-03-16 18:15, Kristof Provost wrote: >> 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. >>>=20 >> It's an interesting idea. There are a number of advantages (like not >> modifying the fragment ID or the sizes of each packet). >>=20 >> 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. >=20 > Why would you need to copy the packet in order to store a list of = fragment IDs and offsets? >=20 That=E2=80=99s how I read Eric=E2=80=99s suggestion. We could indeed = limit ourselves to storing just the fragment IDs and offsets. That=E2=80=99= d be an improvement over copying the packet. > 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. >=20 Agreed. We actually already do it mostly that way. It=E2=80=99s just = that we only store the size of the largest fragment. That=E2=80=99s not = quite as good as storing all fragment sizes, but it does mean we don=E2=80= =99t break Path MTU. I=E2=80=99ll see if I can take a stab at doing things that way, so we = can see if that=E2=80=99s an improvement over my current proposal (i.e. = delay the size check until after the pfil hook in ip6_output()). Regards, Kristof