Subject: Re: Changing packet input processing paths
To: Darren Reed <>
From: Bill Stouder-Studenmund <>
List: tech-net
Date: 08/28/2007 10:59:48
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 27, 2007 at 04:37:46AM +0200, Darren Reed wrote:
> If IPFilter were to implement 4<>6 translation, what should
> happen to the packets after they've been converted?
> Should IPFilter just put them on the relevant packet queue
> for v4/v6 (for inbound/outbound) and filter it a second time?
> Or should it return the packet back with some special flag
> so that the mainline where the pfhooks callout was made does
> a longjump to the "other protocol"?
> Or should the various input/output functions be split in half,
> with the bottom half continuing on with a tail call that can
> also be called from elsewhere?

As Matthias noted, 6<>4 is kinda like NAT, except you're changing protocol=
families too.

I'm not sure of the right implementation method, but some way to=20
differentiate packets as "before translation" (I'd lump NAT & 6<>4=20
together here) and "after translation" is important. Well, what I really=20
want is a way to say that this rule applies only to untranslated packets=20
(well, packets before the translation step).

I run an internal 10/X net in my house. I expect 10/8 packets on the=20
inside NIC, and I would not be upset by 6->4 packets for the 10 net that=20
arrive on the inside NIC. Likewise, I expect NAT to translate packets that=
arrive on the outside NIC to 10/8 packets.

I however WANT TO BLOCK bare 10/8-destined packets from arriving on the
external NIC, and I also want to block bare 6<>4 packets destined to the
10/8 net from ariving from outside.

So please come up with some way to have a set of rules that apply "before=
translation" and a set of rules that apply "after translation".

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)