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

[Gustavo Carneiro]

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

> Gustavo Carneiro wrote:
>
>>
>>
>> 2009/6/5 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>
>>
>>    Gustavo Carneiro wrote:
>>
>>        2009/5/23 Mathieu Lacage <mathieu.lacage at sophia.inria.fr
>>        <mailto: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]
>>
>
> I see your point about the net device API, but it seems like that is a
> detail that is not really important to users of the device.  I was looking
> at it from the perspective of the user-space user of the device, who if they
> read man 4 tap will expect the packet to have an Ethernet header.  I also
> saw that you were setting the default flags PointToPoint and NeedsArp like a
> TUN device.  IsPointToPoint is hard coded to true (although it is a virtual
> method).


TapNetDevice provides both the Ethernet header (not a header per se, but all
the fields of the header are there as parameters), and a separate IPv4
packet.  So you have both L2 information and L3 information.  Also keep in
mind that TapNetDevice works with any L3 procotol, not only IPv4.  That
reason alone is enough for me to exclude TUN from the device name.


>
>
>
>> 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 still think that TapNetDevice is probably not a good name, because it is
> not working with Ethernet frames.
>
> from the tun/tap faq:
>
> 1.6 What is the difference between TUN driver and TAP driver?
>  TUN works with IP frames. TAP works with Ethernet frames.
>
> I would still be OK with TunNetDevice but if that makes you uncomfortable I
> would be OK with your original proposal of VirtualNetDevice (which seems to
> be the generic name that tun/tap project uses) or UserNetDevice.


I am still not OK with TunNetDevice, I'm sorry :-)

VirtualNetDevice or UserNetDevice are fine by me.  TunTapNetDevice would
also be fine.


>
>
>
>>
>>    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.
>>
>
> yes, but the example is not IPX tunneling; I don't see what the
> functionality of double UDP is giving here.


OK, bad example then.  But I recently helped someone build a UMTS simulation
network, and UMTS uses GTP/UDP/IP tunneling.  For a UDP application, the
full stack is then UDP/IP/GTP/UDP/IP at a certain segment of the UMTS
network; it may seem strange, but I am not kidding :-)

Regards,

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