PF IPv6 fragments handling
list_freebsd at bluerosetech.com
list_freebsd at bluerosetech.com
Sat Mar 21 22:11:49 UTC 2015
On 2015-03-16 18:15, Kristof Provost wrote:
> On 2015-03-16 09:51:55 (-0400), Eric van Gyzen <vangyzen at 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.
More information about the freebsd-pf
mailing list