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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"