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<------------------ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
