[Ns-developers] Tap/Tun NetDevice

[Tom Henderson]

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.

> 
> 
> 
> 
> 
>            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"

Thanks,
Tom