On Wednesday 23 July 2014 20:59:19 Bjoern A. Zeeb wrote:
> On 23 Jul 2014, at 20:41 , Allan Jude <allanj...@freebsd.org> wrote:
> > On 2014-07-23 16:38, Bjoern A. Zeeb wrote:
> >> On 23 Jul 2014, at 15:42 , Cy Schubert <cy.schub...@komquats.com> wrote:
> >>> Taking this discussion slightly sideways but touching on this thread a
> >>> little, each of our packet filters will need nat66 support too. Pf
> >>> doesn't
> >>> support it for sure. I've been told that ipfw may and I suspect ipfilter
> >>> doesn't as it was on Darren's todo list from 2009.
> >> 
> >> our pf does support IPv6 prefix rewriting quite nicely and has for years.
> > 
> > Bjoern: What IPv6 stuff does our pf not do well?
> I think the most pressing, as Peter said, is fragment handling, though a
> good fraction of major content providers seems to do mss clamping to a min
> IPv6 mtu on IPv6 and drop fragments at the edge (not much different to
> IPv4, which makes you wonder?).    Whoever is clever will think of how many
> different queueing and fragment handling implementations we need in the
> kernel, and how often we have to do it on an end node that might also run a
> firewall,  pick one we have, turn it into a library thing, apply it to all
> places, and then add the latest IETF suggestions on top of it.


There is code in the openbsd cvs history where they added it while the 
internal APIs looked similar enough to ours.  It's simpler than ipv4 
reassembly - taking advantage of things like overlapping fragments not being 

I'm almost desperate enough to take a shot at it myself, but mbufs and I do 
not get along.  Nobody wants code I've touched to be in the tree if mbufs are 

The initial commits.. first the supporting changes:

(refactor code for reuse)

(add ipv6 defrag/refrag)

Then they added the code to defragment/refragment:
(pf_test6 defrag/refrag)

The catch is that they fixed a lot of edge cases so one needs to follow the 
history forward a bit to make sure it it's covered.  The other problem is our 
codebase is even older than when this was added so some looking at older 
commits is required.

In the time since the feature was added, they have refactored it a few times 
and merged the two code paths for ipv4 and ipv6.  It bears no resemblance to 
what we have in our tree.

The killer reason why this is a problem that needs to be solved.. IPv6 + 
DNSSEC exercises this code a lot.

Performance isn't a factor - it's basic functionality that's at stake.

Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to