Network abstractions and netfilter?

[Niels M�ller]

There has been some talk about what network abstractions are
appropriate when extending pfinet. There seems to be several
abstractions/interfaces that are needed in order to support

1. More network interfaces,

2. IPSEC processing,

3. Firewalling machinery,

4. Routing machinery and configuration thereof.

(and then IPv6 should be integrated some way, but that's quite a lot
of hair that I don't understand, although I suspect that one would
want to have a single pfinet to handle bothIPv4 and IPv6).

It would be a good thing if some or all of these interfaces could be
unified. Has anybody here looked into Linux' netfilter? Perhaps some
ideas can be stolen from that design. Perhaps even the netfilter
"hooks" can be translated directly into pfinet HURD interfaces. A
short overview, taken from <URL:
http://cvs.samba.org/cgi-bin/cvsweb/netfilter/HOWTO/netfilter-hacking-HOWTO.sgml>,
is included below. Does anything like this fit the HURD problem space?

Happy hacking,
/Niels

--------------8<------------------

Netfilter Architecture

Netfilter is merely a series of hooks in various points in a
protocol stack (at this stage, IPv4, IPv6 and DECnet).  The
(idealized) IPv4 traversal diagram looks like the following:

A Packet Traversing the Netfilter System:

   --->[1]--->[ROUTE]--->[3]--->[4]--->
                 |            ^
                 |            |
                 |         [ROUTE]
                 v            |
                [2]          [5]
                 |            ^
                 |            |
                 v            |

On the left is where packets come in: having passed the simple sanity
checks (i.e., not truncated, IP checksum OK, not a promiscuous
receive), they are passed to the netfilter framework's
NF_IP_PRE_ROUTING [1] hook.

Next they enter the routing code, which decides whether the packet is
destined for another interface, or a local process.  The routing code
may drop packets that are unroutable.

If it's destined for the box itself, the netfilter framework is called
again for the NF_IP_LOCAL_IN [2] hook, before being passed to the
process (if any).

If it's destined to pass to another interface instead, the netfilter
framework is called for the NF_IP_FORWARD [3] hook.

The packet then passes a final netfilter hook, the NF_IP_POST_ROUTING
[4] hook, before being put on the wire again.

The NF_IP_LOCAL_OUT [5] hook is called for packets that are created
locally.  Here you can see that routing occurs after this hook is
called: in fact, the routing code is called first (to figure out the
source IP address and some IP options): if you want to alter the
routing, you must alter the `skb->dst' field yourself, as is done in
the NAT code.

--------------8<------------------