Subject: Re: stf and NAT
To: None <tech-net@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-net
Date: 07/21/2007 19:24:23
On Sat, Jul 21, 2007 at 06:23:35PM +0200, Rodolphe De Saint Leger wrote:
> On 7/18/07, Zafer Aydogan <zafer@aydogan.de> wrote:
> >>
> >Looks good.
> >Can you please write a patch for current.
> >Thanks, Zafer.
> >
>
> Here is (almost) the same patch for current,
>
> http://82.67.230.130/strict/current/cpatch.diff
> http://82.67.230.130/strict/current/if_stf.c
>
> I added another option (strict checking of 6to4 traffic) and ingress
> filtering for ipv6 addresses.
>
> I made some tests, it seems to work.
> Any comments ?
>
> Could it be commited to head ?
I am not sure I understand the problem you are trying to solve. It seems
that your host has an ethernet (say) with an RFC1918 address assigned;
your host plugs into a router that translates the host's RFC1918 number
to and from some globally-routable IPv4 address. You want for your host
to use that globally-routable IPv4 address for 6to4. The address in
the encapsulated IPv6 packet has to embed the global IPv4 adddress; the
encapsulation IPv4 header needs to contain the host's RFC1918 address,
which the router will translate. The stf(4) pseudo-interface does not
provide for that. Is that about right?
Can you meet your needs using IP Filter or PF? Or, if a general-purpose
tool will not do, doesn't it make sense to isolate the "DMZ adaptation"
in its own pseudo-interface? That may benefit more NetBSD applications
in a DMZ than a stf(4) modification alone.
Dave
--
David Young OJC Technologies
dyoung@ojctech.com Urbana, IL * (217) 278-3933 ext 24