Re: Removing PF

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> 
> - mss clamping (Brian Buhrow)

This is supported and has been documented for years..

> - ftp-proxy (Jan Danielsson)
> ...
> - dynamic NAT updates

These two are related and should soon be addressed.

> - pf route-through/reply-to (Brian Buhrow)

That is more of working with NetBSD's network stack.  Once the network
stack provides an API (needs to work with IPv4 and IPv6, handle possible
interface detach, etc), calling it from NPF is fairly straightforward.

> - ipf groups (Manuel Bouyer)

I have a design for shared rulesets in mind, but have not had time to
implement it yet.  No ETA yet.

> - dynamic ifaddrs(netifN) (John D. Baker)

This is supported in NetBSD -current (the documentation needs a sync
from the Github version, though).

> - pf netifN:0, netifN:network notation (John D. Baker)
> ...
> - address subset selection (John D. Baker)

These two are the same.

> - pf synproxy state (John D. Baker)

I am not convinced this should be a part of NPF core, but I see this
being useful for certain networks.  Happy to support it as an extension,
though, so patches are welcome!

> - BRIDGE_IPF (Piotr Meyer)

IIRC, this is just a matter of testing.

> - ipf migration path (manu)

Patches / pull requests with documentation improvements are welcome!

> - https://gnats.netbsd.org/53199 (Patrick Welche)

Not sure what exactly the submitter wants.  NPF establishes per-interface
state (for a good reason).  It seems that some users want a global state
which would be picked up on any interface and in either direction.  This
will be added to NetBSD with the next NPF sync from Github; however, there
are drawbacks of such behaviour and it will not be a default.

> - altq (Thor Lancelot Simon)

In general, I would say that traffic shaping / packet scheduling should
be the problem of the network stack.  It deals with the queues and can
handle it efficiently.  Packet filter would either heavy rely on it or
would end up duplicating the concepts and mechanisms for packet queuing.

However, I am not against adding the framework for this within NPF.
Primarily, because it is used outside NetBSD where it would not be able
to rely on particular network stack mechanisms.

Note: NPF can easily integrate with an already existing packet shaping
mechanism, such as ALTQ, using packet/mbuf tagging.  Writing NPF extensions
to do such simple things like tagging is really straightforward.

> - port redirection (MLH)

Huh?  NPF supports port redirection (and documents it) pretty much since
its creation.

> - greylisting integration (MLH)
> - equivalent of `log followers' (MLH)

What are these?

-- 
Mindaugas