--ZOudaV4lSIjFTlHv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 09, 2004 at 05:42:30PM -0500, Greg Troxel wrote:
> In the past gif(4) had a multi-destination behavior.  One did
> 'ifconfig link0', and the gif had two behavior changes:
>=20
> a) incoming packets were accepted even if the source address did not
> match the configured destination (which was INADDR_ANY I think), and
>=20
> b) the outer destination address of outgoing packets was taken from a
> gateway route sockaddr obtained from the lookup the inner destination
> (that pointed to the gif in the first place).
>=20
> So, you could=20
>=20
>   route add 192.168.0.1 10.0.0.30 -ifp gif0
>=20
> to cause packets for 192.160.0.1 to be encapsulated to 10.0.0.30. =20

I wasn't aware of this previous behaviour, it seems potentially very
useful and elegant from an administrator's point of view (arguments
about implementation internals aside).  So I'd also like to see it
come back in some form.

Using transport-mode IPsec on a gif tunnel packet, rather than
tunnel-mode ipsec, has some advantages -- particularly when it comes
to ipf'ing the packets exiting the tunnel, as they're presented again
on a separate logical interface. One of these advantages is not,
however, the ability to easily deal with connections from remote nodes
with dynamic addresses.  I've experimented with using stf(4) and then
transport-mode ipsec of the v6 packet for this, and then tunnelling
again inside the v6 packet, but it just gets hairy fast.

One further improvement might be on the accept path, to do a check in
the reverse direction against the routing table (or whatever) to make
sure the envelope address matches the expected source of the internal
address.

> One can think of multi-destination gif as Ethernet-like, where
> point-to-point gif is like, well, a point-to-point interface.
> The set of all multi-destination gif machines on the Internet form a
> NBMA subnet for exchanging packets.  This is like stf(4), except that
> stf(4) has the mapping rules built-in instead of getting them from the
> routing table.

Exactly what I was thinking, which is why the routing table doesn't
seem such a bad way of representing this (perhaps in some of the
alternate forms you discussed).  Perhaps, like stf(4), it might better
be implemented as a separate interface.

--
Dan.

--ZOudaV4lSIjFTlHv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE//0apEAVxvV4N66cRAqzgAKC4mofAoYg5vNSVecZTBqrapivjmgCeK00r
Ou/SQeLbc8n2Oyl4gybEIhY=
=gVNp
-----END PGP SIGNATURE-----

--ZOudaV4lSIjFTlHv--