Tunnel adapters?

I can see them with ipconfig /all

Also, I read about them
"TUN and TAP are virtual-network kernel devices. "
“TAP (as in network tap) simulates a link layer device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.”
(http://en.wikipedia.org/wiki/TUN/TAP)

I don’t understand:
a) If somebody implements a tunneling protocol, does he need a tunnel adapter as well?
If the encapsulation & decapsulation of packets is done in drivers, what does one need a tunnel adapter for? Or the tunnel adapter is an alternative to implementing a packet forwarding driver?

b) How is a tunnel adapter created (win api / wdk)?

Thanks!

> a) If somebody implements a tunneling protocol, does he need a tunnel adapter as well?

The tunnel is presented to IP as either Ethernet (in which case we say TAP) or as PPP (in which case with say TUN).

Wikipedia article seems to be bad.

So, with your tunneling protocol, you should decide whether the tunnel is represented as Ethernet to IP above it (like OpenVPN) or as PPP (like PPTP).

Then write either virtual Ethernet or virtual PPP link (physical layer of PPP) driver.

If the encapsulation & decapsulation of packets is done in drivers, what does one need a tunnel
adapter for?

To represent the tunnel to IP above it.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Adding to and extending Max’s comments:

> a) If somebody implements a tunneling protocol, does he need a tunnel
adapter as well?
The tunnel is presented to IP as either Ethernet (in which case we say TAP)
or as PPP (in which case with say TUN).

While exposing a virtual interface (adapter) is definitely one way to create
the endpoint of a tunnel protocol it is not the only one. There are tunnel
protocols that do not require an interface (think IPSec). The need to have
an interface has more to do with routing and address space (projection) than
the encapsulation.

So, with your tunneling protocol, you should decide whether the tunnel is
represented as Ethernet to IP above it (like OpenVPN) or as PPP (like PPTP).
Then write either virtual Ethernet or virtual PPP link (physical layer of
PPP) driver.

The choice (in Windows) to develop either a virtual adapter as
connectionless or WAN is driven by how you want to manage tunnel
establishment and ‘call control’. If you chose to create a VPN WAN
Miniport (like PPTP/L2TP/PPPoE etc.) you are essentially deciding that your
tunnel protocol is a “remote access” mechanism and integrating it as a VPN
link type with RAS. You need not encapsulate with PPP - you can get ‘raw’
IP frames and encapsulate as you see fit but the ‘control’ of the tunnel is
now entirely up to RAS. If you chose to expose your tunnel endpoint as a
connectionless virtual adapter, you now have to control the entire show
including managing that adapter. The adapter need not specifically be
“Ethernet” though that is common. At least in NT6 NDIS & TCPIP now
understand some connectionless media types that are far friendlier to
tunnels for IPv4 and IPv6 than pseudo-Ethernet.

> If the encapsulation & decapsulation of packets is done in drivers,
>what does one need a tunnel adapter for?
To represent the tunnel to IP above it.

Specifically, to represent the tunnel as a separate interface/link to IP so
that traffic will be directed (via the forwarding process) into the ‘tunnel’
as a separate link. As I imply above, if your tunnel topology does not
require this behavior, you are not required to use it (just as IPSec does
not).

Good Luck,
Dave Cattley