Actually, only the .h file is missing, .cc is already mentioned :)

(In reply to comment #0)
> I tried to use loopback-net-device, and turns out it's not actually compiled in
> although it is documented in Doxygen. src/internet-stack/wscript doesn't have
> any reference to loopback-net-device.h or .cc. 
> 
> Weird part though is that the code resides in the internet-stack in the first
> place - I'd think better place is src/devices.

The history of this class is that there used to be no LoopbackNetDevice class; it was fully implemented in the Internet stack module as a special kind of device with no underlying NetDevice.  

As part of the routing rework, this was refactored to be a layer-2 device.  I left it in internet stack, but upon reviewing it tonight, I agree that there is nothing internet-specific left in the definition and might be of use outside of internet.

Regarding the missing .h file, again this is just a policy issue about whether this is public API to be exported.  However, regardless of whether we decide to export loopback-net-device.h (I would be OK with that), I see that we are not effectively blocking the Doxygenation of private API such as that class.  It seems that neither the use of the \internal keyword (e.g. UdpSocketFactoryImpl) nor the absence of the header file in the list of headers exported (e.g. LoopbackNetDevice) leads to the class being omitted in Doxygen.

Ok - I ran into the issue when I was trying to create a, well, loopback netdevice and for some reason #include <ns3/loopback-net-device.h> wouldn't work. 

Example slash32-static-routing uses csmanetdevices, but this failed for me when attempting to create socket for it since it wouldn't stay up (considering it's not connected to anything, it's actually quite accurate). 

  Ptr<CsmaNetDevice> deviceC = CreateObject<CsmaNetDevice> ();
  deviceC->SetAddress (Mac48Address::Allocate ());            
  nC->AddDevice (deviceC);                                    

After I changed this to loopback netdevice and after making the loopback device .h available things started to work. Anyway, if you have a router or any other multi-interface node, you often bind it's "identity" to a loopback device (e.g. OSPF router ID) so might be good idea to make this public - it's pretty standard to bind a socket to a loopback device with routable IP - then the packet is sent out via loopback, comes right back to node and is routed onwards - but with the loopback's IP as source.

this was fixed in changeset 7fd20c798a7d (bug 742)