--oWj5HoUXCVjyUFuT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Dec 14, 2004 at 07:32:33AM -0800, Jason Thorpe wrote:
> How about using ifmedia to determine the link type to emulate in tun?

I like this idea, and would suggest taking it further if it makes sense.

As I said elsewhere, on a number of occasions I've wished to be able
to bridge(4) between a local ethernet and a gre tunnel, for transport
of layer2 frames across a WAN to a remote site. I can do this with
cisco gear, and it has all sorts of valuable uses I can elaborate upon
request. Being able to do it with NetBSD machines instead, or with
NetBSD at one end and a cisco at the other, would enhance this
usefulness and applicability.

So the current ethfoo/tap/tun/whatever interface semantics are
partially relevant, but don't get me all the way there - I'd still
need some userspace process (or perhaps ipf fastroute hackery?) to
copy the frames from this device to the gre interface and back again.

If instead this "synthetic ethernet" property could be something in
the ifmedia layer, that could be applied equally to tun or gre (or yet
some other example) in a generic fashion, so it would work with
bridge(4), I think we'd have a much cleaner and better solution.

Perhaps these requirements are a little different, and merit a
different solution specifically in gre itself, but if a generic
solution is feasible I'd like to encourage that path.

--
Dan.


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

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

iD8DBQFBv1fqEAVxvV4N66cRArdKAJwJ9lOKdgUbRdvjAaCTh3uOJFJl2wCfRccW
H8nNQYlxG3CdBjOaz4oM/lI=
=Nf4J
-----END PGP SIGNATURE-----

--oWj5HoUXCVjyUFuT--