>I used this to build an emulator that could be glued in for real
>traffic.  IMHO the big differentiator of the new interface is the
>ability to control far more about how the interface behaves than tun
>currently lets you do.  But having implemented this, I don't see any
>obvious reason tun could not be extended instead - it could simply
>default to tun-like behavior if none of the special ioctls are called.
>
>The tricky part is having interfaces be able to change type.  But,
>since tun is a create/destroy interface already, one can augment the
>create call to pass in the tunnel/ethernet flag and the mac address,
>and not allow type changing once created.  It would be good for this
>to be extensible, since one might want to add the ability to say
>e.g. 'this is an 802.11 interface'.

since "extending" the creat/destroy interface might be a little
tricky, how about asserting that all programs must go through three
phases:

	open /dev/tun#

	set required options, specify link layer, etc

	set interface to "up" and begin operating

and then merely require that the interface, once up, is considered
"immutable", and must be closed before any of the settings/options can
be changed.  that way the users of the original tun interface would
get what they expect, and new userspace tunnel types can be slid in
"easily".

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."