Date: Thu, 6 May 2004 10:21:13 +0200 From: Lukasz Stelmach <Lukasz.Stelmach@telmark.waw.pl> To: SUZUKI Shinsuke <suz@crl.hitachi.co.jp> Cc: freebsd-net@freebsd.org Subject: Re: if_stf bug/feature Message-ID: <20040506082113.GA15255@tygrys.k.telmark.waw.pl> In-Reply-To: <x7k6zq11lx.wl%suz@crl.hitachi.co.jp> References: <20040504181620.GB9699@tygrys.k.telmark.waw.pl> <x7k6zq11lx.wl%suz@crl.hitachi.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Byla godzina 16:00:42 w Thursday 06 May, gdy do autobusu wsiadl kanar
i wrzasnal:"SUZUKI Shinsuke!!! Bilecik do kontroli!!!" A on(a) na to:
>>>>>> On Tue, 4 May 2004 20:16:20 +0200
>>>>>> Lukasz.Stelmach@telmark.waw.pl(Lukasz Stelmach) said:
>=20
> > stf interface has one feature, very inconvinient for me. As far as i co=
uld
> > read the source it returns ENETDOWN if the inet4 address of the machine=
's
> > net interface (primary or the one would be used) does not match proper
> > part of stf's address. This is ok if one has public, routable ip4 addre=
ss.
[...]
> 6to4 is not designed for a node with private IPv4 address, as is
> hexplicitly stated in section 2 of RFC3056.
>=20
> Suppose that a subscriber site has at least one valid, globally
> unique 32-bit IPv4 address, referred to in this document as V4ADDR.
> This address MUST be duly allocated to the site by an address
> registry (possibly via a service provider) and it MUST NOT be a
> private address [RFC 1918].
Well i *have*got* one v4ADDR that is assigned to my nat/router-box. I
have also configured that it should pass all packets that are not part
of some known connections (from M1 M2 .. Mn) (including but not limited
to proto 41) to one specified machine (name it TIGGER) that acts as the
end of 6to4 tunnel for all other computers in the LAN. Now, for i
controll both the nat and TIGGER i can do such manglig without any
harm. Let's say taht to the rest of the world the nat+TIGGER act like
a single machine.
Here is a quick schetch:
[M1]+
|
[M2]+
| 10.1.1.254
[Mn]+---------[nat]-------{THE NET}
| 1.2.3.4
[TIGGER]+
10.1.1.2
IP packet with proto 41 comes to the nat with dstaddr of 1.2.3.4 it gets
mangled to 10.1.1.2 and goes to TIGGER. When tiger sends simmilar packet
with srcaddr of 10.1.1.2 it gets mangled to 1.2.3.4 before it leavs the
nat. But nat doesn't know anything about IPv6 or 6to4 it works only on
IPv4 packets.
> So my suggestion to tackle such situation in FreeBSD-4.x is either of
> the following two.
>=20
> - configure a static gif tunnel toward a site.
>=20
> Although it's a "static" tunnel, some site provides a tool
> to automatically configure gif tunnel even behind NAT
> (e.g. ports/net/freenet6)
6to4 seems to me to be better since it takes probably the shortest
path. Besides it is not a problem of tools for "behind NAT" situation
since my nat passes tunnel packets.
> - enable 6to4 on your NAT-box and let it advertise an IPv6
> prefix (if not possible, please ask the vendor to support
> such feature! :-))
Yeah, of course, naturlich... ;-) Especially it is a d-link di804-hv
cheap and crude device and support@dlink.com seems to be redirected
to /dev/null.
Czym sie cieplo SUZUKI...
--=20
|/ |_, _ .- --, Ju=BF z ka=BFdej strony pe=B3zn=B1, potworne =BF=
=B1dze
|__ |_|. | \ |_|. ._' /_. B=EAd=EA uprawia=B3 nierz=B1d, za pieni=
=B1ze
--HlL+5n6rz5pIUxbD
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAmfV5NdzY8sm9K9wRAv6kAJ9iIq4x4Du+KMiTFtGR0Vuql7Q7KgCbB/bQ
fFTivn2UPO89gcXULK/b890=
=LLdR
-----END PGP SIGNATURE-----
--HlL+5n6rz5pIUxbD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040506082113.GA15255>