Taylor R Campbell <[email protected]> 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
