[Ns-developers] Tap/Tun NetDevice (Was: release update)

[Gustavo Carneiro]

2009/6/5 Tom Henderson <tomh at tomh.org>

> Gustavo Carneiro wrote:
>
>> 2009/5/23 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
>>
>>  hi,
>>>
>>> It's been a while, and we are getting closer to our original target
>>> release date of june 15th.
>>>
>>> Tom, Craig, and I had a phone conversation on wednesday to talk about
>>> the status of the ipv4 rework. Tom plans to merge his ns-3-ip-routing
>>> tree in ns-3-dev on monday. This tree appears to contain the crux of the
>>> API changes we wanted with a couple of implementation issues to sort
>>> out. Given the tight schedule, we agreed to aim for a 2-week
>>> stabilization and bug fixing period after the merge, and then, to freeze
>>> ns-3-dev around june 15th, hence, targeting june 21st or early july for
>>> a final release.
>>>
>>> Current items still on the table for merging:
>>>  - the tag rework: maybe it can make it after ip-routing is in
>>>  - the virtual net device: gustavo, do you have interest in pushing
>>> this forward with the name change (TapNetDevice) suggested by tom ?
>>>
>>
>>
>> The name is OK with me.  I took the old code, renamed a few things,
>> rebased
>> against ns-3-dev, and added a bit more documentation.  Should be ready to
>> merge.  The only thing missing is an example, I guess.
>>
>>    http://code.nsnam.org/gjc/ns-3-tap-netdevice/
>>
>>
> Gustavo,
> Although I suggested the name TapNetDevice, in reviewing this today, I
> noticed that it is really behaving like a Tun device instead of a Tap device
> (i.e. it is not adding an Ethernet header).
>
> So, would you be amenable to naming it TunNetDevice instead?


I don't think you are seeing it right.  The analogy between Linux and NS-3
does not fit perfectly simply because the NetDevice API of NS-3 is slightly
different from the netdevice API of Linux.  See [1].  Linux's transmission
API takes a single sk_buff of a packet with header already applied, while
NS-3 Send/SendTo takes a Packet, ethertype, source-addr, dest-addr, and is
the responsibility of the NetDevice to add the correct header(s).  [but I
think the NS-3 API is better than the Linux one]

If you keep that mismatch in mind, it is only natural that TapNetDevice
takes Packet and L2 information as separate parameters, but it only does it
to keep in line with NetDevice API.  It is still a L2 device, it is still a
TAP device.  It seems to me that an equivalent to a TUN device would be a
replacement for Ipv4Interface that would delegate transmission to a user
callback.

That being said, I believe that TapNetDevice can also be subverted to
fulfill a role similar to TUN.  To make IP tunnels, one needs to create a
TapNetDevice configured with IsPointToToint=true, NeedsArp=false, and then
transmit packets via a IP raw, UDP, or TCP socket, depending on the type of
tunnel you need.  On the receiving side, it needs to listen to a similar
socket and inject the packet by calling Receive() or PromiscReceive() with
IP ethertype (0x0800) and empty src/dst addresses (the IPv4 stack will not
care about the addresses in any case).

With this in mind, I would agree with renaming to something else, but not
TunNetDevice.  My first choice was VirtualNetDevice because that name is
ambiguous enough that it can cover both tun and tap functionality.  Another
possible name I could suggest would be UserNetDevice.


> I also thought that the example was a bit unusual because the TunNetDevice
> handler is creating a Udp socket to send the datagram out, instead of just a
> raw socket.  What do you think about changing it to a raw socket?


I do not agree it is unusual.  See this example in the FAQ [2]:

1.5 How does Virtual network device actually work ?
>  Virtual network device can be viewed as a simple Point-to-Point or
>  Ethernet device, which instead of receiving packets from a physical
>  media, receives them from user space program and instead of sending
>  packets via physical media sends them to the user space program.
>
>  Let's say that you configured IPX on the tap0, then whenever
>  kernel sends any IPX packet to tap0, it is passed to the application
>  (VTun for example). Application encrypts, compresses and sends it to
>  the other side over TCP or UDP. Application on other side decompress
>  and decrypts them and write packet to the TAP device, kernel handles
>  the packet like it came from real physical device.
>


[1] http://lxr.linux.no/linux+v2.6.29/include/linux/netdevice.h#L470
[2] http://vtun.sourceforge.net/tun/faq.html

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert