Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jan 2005 13:00:50 GMT
From:      Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Message-ID:  <200501181300.j0ID0oPk001461@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/75121; it has been noted by GNATS.

From: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To: Gleb Smirnoff <glebius@freebsd.org>
Cc: Antonio Tapiador del Dujo <atapiador@dit.upm.es>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 18 Jan 2005 13:51:01 +0100

 --6TrnltStXW4iwmi0
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 El martes, 18 de enero de 2005, a las 13:57:51, Gleb Smirnoff escribi=F3:
 >   Antonio,
 >=20
 > On Wed, Dec 15, 2004 at 07:22:00PM +0100, Antonio Tapiador del Dujo wrote:
 > A> >Description:
 > A> I'm researching on IPv6 multihoming.
 > A> I need a generic 6in6 tunnel interface that accepts packets from any s=
 ource, so I tried with the IFF_LINK2 as said in gif(4), but it didn't work.
 > A> Looking at the code, I found out the address checks are done regardles=
 s of the IFF_LINK2 (netinet6/in6_gif.c, line 318)
 > A> Shouldn't these checks take into account the IFF_LINK2?
 > A> Moving them inside the next if works as I expected.
 >=20
 > No they shouldn't. Perhaps you have some misconfiguration with your tunne=
 ls.
 > If you have tunnel configured as X <-> Y on machine A, then you MUST have
 > tunnel configured Y <-> X on machine B. This is requirement for gif proto=
 col.
 > Otherwise you will have odd and undefined behavior, when multiple tunnels
 > terminate on one box.
 
 I know, but this an interesting element for several multihoming solutions,
 as discused in draft-huitema-multi6-ingress-filtering-00.txt
 
 > The IFF_LINK2 means that incoming tunnel packets may come from interface
 > different to interface we use for sending out tunnel packets.
 
 gif(4) man page talks about ingress filtering:
 "Ingress filtering can be turned off by IFF_LINK2 bit."
 that has to do with source addresses (RFC 2893, section 4.3)
 Then maybe this is a gif(4) man page bug.=20
 
 > If you don't mind, I close the PR.
 =20
 Anyway I don't see why not to give the choice, because somebody who sets=20
 IFF_LINK2 knows what is doing (or maybe not :)).
 
 Cheers.
 
 --=20
 EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
 
 --6TrnltStXW4iwmi0
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: Digital signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.4 (GNU/Linux)
 
 iD8DBQFB7QY1AeZK4jlfl3cRApiCAKCj4iAxRPmDept5e/BJHlZHwCl5iwCgjXmv
 I5z/oTMsJ0nhXBCfKChmXIs=
 =EppZ
 -----END PGP SIGNATURE-----
 
 --6TrnltStXW4iwmi0--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501181300.j0ID0oPk001461>