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
differentiate packets as "before translation" (I'd
lump NAT & 6<>4
together here) and "after translation" is
important. Well, what I really
want is a way to say that this rule applies only to
untranslated packets
(well, packets before the translation step).
I run an internal 10/X net in my house. I expect 10/8
packets on the
inside NIC, and I would not be upset by 6->4 packets for
the 10 net that
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,
Bill
|
