Date: Sun, 22 Mar 2015 09:48:46 +0900 From: Kristof Provost <kristof@sigsegv.be> To: list_freebsd@bluerosetech.com Cc: freebsd-pf@freebsd.org Subject: Re: PF IPv6 fragments handling Message-ID: <7EA47C5D-E783-408B-8A70-9F02F5348839@sigsegv.be> In-Reply-To: <550DEC94.4040805@bluerosetech.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 22 Mar 2015, at 07:11, list_freebsd@bluerosetech.com wrote: > > 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? > That’s how I read Eric’s suggestion. We could indeed limit ourselves to storing just the fragment IDs and offsets. That’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. > Agreed. We actually already do it mostly that way. It’s just that we only store the size of the largest fragment. That’s not quite as good as storing all fragment sizes, but it does mean we don’t break Path MTU. I’ll see if I can take a stab at doing things that way, so we can see if that’s an improvement over my current proposal (i.e. delay the size check until after the pfil hook in ip6_output()). Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7EA47C5D-E783-408B-8A70-9F02F5348839>