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