We had a discussion during our I-Team meeting that I'm summarizing here for the benefit of everyone interested.
With the new IP tunneling design, there are two ways to create a tunnel: A: The new way. dladm create-iptun is used to create a pseudo datalink, resulting in a DLPI device being creted in /dev/net. ifconfig can then be used to plumb an IP interface over that device. B: The backward-compatible way. ifconfig is used to plumb an IP tunnel interface (e.g., ifconfig ip.tun0 plumb tsrc <foo> tdst <bar> ...). Under the hood, ifconfig realizes that ip.tun0 is a tunnel (because of its name), and calls the libiptun API to create the tunnel datalink before plumbing the IP interface. The discussion centered around B. In the current clearview_iptun gate, there is code within the ifconfig application that handles the magical tunnel datalink creation logic. Instead of having ifconfig do this work, the /dev/net filesystem itself could create the IP tunnel datalink on the fly if someone attempts to open a non-existent device node named "ip.tun#", "ip6.tun#", or "ip.6to4tun#". This would mirror how implicit VLAN creation works, which happens when the /dev/net filesystem realizes that someone is attempting to open a non-existent device node which has a PPA > 1000. There are pros and cons associated with each approach (having the logic within the ifconfig application or within the /dev/net filesystem). Either way, the user sees the correct behavior, which is complete backward compatibility. One deciding factor behind moving the logic into /dev/net is to simplify ifconfig and remove all code specific to individual datalink types out of there. Also, since there's already code in the /dev/net implementation to do implicit datalink creation on open(), this design approach isn't radically new. -Seb
