stf and NAT

Hi,

I wrote a patch for if_stf.c in order to accept DMZ type
setup.

http://82.67.230.130/
patch.diff
http://82.67.230.130/if
_stf.c (the full file)

Did I make any mistake in processing ?
Any comments ?

Actually, I'm using it without any problem.

This patch should not disturb existing setups (as the only
exception
is tolerance about our local address on emission or
reception) and can
be activated or not using a define (so it can be a kernel
option like
IPSEC_NAT_T).

I encountered this problem by the past and I use to resolve
it using
NAT tricks (also if aliases tricks). Accepting 'dmz'
behavior may be a
cleaner way to use 6to4.

I did this for me so the patch is against the 3-1-release
branch, but
I'll work for a patch for -current if needed.

Regards,
-- 
There is currently insufficient research to definitively
conclude that
unix overuse is an addiction.

2007/7/18, Rodolphe De Saint Leger <rdesaintlegergmail.com>:
> Hi,
>
> I wrote a patch for if_stf.c in order to accept DMZ
type setup.
>
> http://82.67.230.130/
patch.diff
> http://82.67.230.130/if
_stf.c (the full file)
>
> Did I make any mistake in processing ?
> Any comments ?
>
> Actually, I'm using it without any problem.
>
> This patch should not disturb existing setups (as the
only exception
> is tolerance about our local address on emission or
reception) and can
> be activated or not using a define (so it can be a
kernel option like
> IPSEC_NAT_T).
>
> I encountered this problem by the past and I use to
resolve it using
> NAT tricks (also if aliases tricks). Accepting 'dmz'
behavior may be a
> cleaner way to use 6to4.
>
> I did this for me so the patch is against the
3-1-release branch, but
> I'll work for a patch for -current if needed.
>
> Regards,
> --
> There is currently insufficient research to
definitively conclude that
> unix overuse is an addiction.
>
Looks good.
Can you please write a patch for current.
Thanks, Zafer.

On 7/18/07, Zafer Aydogan <zaferaydogan.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://8
2.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 ?

Regards

-- 
There is currently insufficient research to definitively
conclude that
unix overuse is an addiction.

On Sat, Jul 21, 2007 at 06:23:35PM +0200, Rodolphe De Saint
Leger wrote:
> On 7/18/07, Zafer Aydogan <zaferaydogan.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://8
2.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
dyoungojctech.com      Urbana, IL * (217) 278-3933 ext 24