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 was (is?) another case that in certain situations with certain pf options 
IPv6/ULP packets would not pass or get corrupted.  I think no one who 
experienced it never tracked it down to the code but I am sure there are PRs 
for this;  best bet is that not all header sizes are equal and length/offsets 
into IPv6 packets are different to IPv4, especially when you scrub.

Apart from that my knowledge of pf is diminishing.

Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to