[Ns-developers] Tap/Tun NetDevice

[Gustavo Carneiro]

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

> Gustavo Carneiro wrote:
>
>>
>>
>> 2009/6/6 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>
>>
>>    Gustavo Carneiro wrote:
>>
>>
>>
>>        2009/6/5 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>
>>        <mailto: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>
>>               <mailto: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.
>>
>
> OK
>
>     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 am fine with any of those; if no one else cares about the name, I suggest
> you just pick one of those.


In that case, I will pick VirtualNetDevice.  It is the name I always liked
best, for whatever reason, and it is ambiguous enough that we don't need to
constantly argue whether it is TUN or TAP, it is neither and it is both :-)


>
>
>
>>
>>
>>
>>
>>           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 :-)
>>
>
> OK, I am fine with it then; maybe just clean up some of the topology
> comments that are no longer aligned with the actual script, and leave a
> comment that "this example shows UDP-IP-UDP-IP encapsulation, but other
> tunnel types are possible"


OK.


>
>
> Thanks,
> Tom
>



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