2

I am working on an old code that used to connect different IPv6 devices over a different kind of network (a powe line netwrok, PLC, which is quite similar to 802.15.4). To do that, it created Linux tun/tap interfaces on each device (Tun actually, not the Tap) with C code, which can receive egress packets from tun and deliver them to the PLC and on the other direction it can read ingress packets from PLC and inject into the tun interface.

The system works basically fine, but only I found the NDP function seems not working correctly. Firstly I noticed, with two such devices, I cannot ping each other by their IPv6 link local address (fe80::.../10). I then used tcpdump to monitor the tun traffics and found there is no Neighbor Solicitation/Advertisement message at all. Another strange thing I found is that, there is Route Advertisement sent out from one device of the network (the master PLC device which is so-call coordinator node), but not from any other device in the network.

I want to understand what's the correct behavior I should expect from such kind of network according to IPv6 NDP and how to make it happen.

Will appreciate if someone give me some idea.

-woody

Woody Wu
  • 191
  • 8

1 Answers1

2

Expected behavior is that NDP is used on TAP interfaces but not on TUN interfaces.

TAP emulates Ethernet, so the kernel will deliver Ethernet frames to your code and expect Ethernet frames from your code. As such it has to first do NDP to know which destination MAC address to use for the IP packets it hands over to your code.

TUN on the other hand does IP without an Ethernet layer. Your code will receive IP packets with no additional headers and it will expect to receive IP packets from your code. Optionally it can be configured to have a small header in front of the IP packet to distinguish IPv4 and IPv6 packets, you can however also use the IP version field to distinguish (unless you are using a very outdated kernel version).

I would expect link-local addresses to work on both kinds of interfaces. As with other addresses NDP will be used on TAP but not on TUN interfaces.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • I wonder how similar to IEEE 802.15.4 it is because that is nothing like ethernet frames. – Ron Maupin Jan 20 '19 at 14:57
  • @RonMaupin TAP is intended to be pretty much exactly like Ethernet. It's similar enough that bridging between TAP and physical Ethernet should work. You could use the TAP interface to implement an Ethernet VPN and on each end bridge it to a physical interface such that you could make a single Ethernet segment span different locations far apart. And to the rest of the network the only giveaway that it isn't a direct connection is the higher latency. TUN is nothing like Ethernet. It is either plain IP packets or IP packets with an extra 4 byte header consisting of flags and a protocol field. – kasperd Jan 20 '19 at 15:06
  • I understand, but I'm wondering about using a protocol so very different from ethernet with an ethernet-type interface. – Ron Maupin Jan 20 '19 at 15:09
  • Using TAP was really something I guessed should be a correct solution in my mind before I asked question. Now your answer seems like it got confirmed. But anyway, the program had already written with TUN not TAP. Currently, I can assign link local address to the TUN interfaces, and if I manually add router entries the TUN interfaces indeed can ping each other (without seeing any neighbor solicitation or neighbor advertisement messages exchanged), is this what you mean 'link-local addresses work on both kinds of interfaces'? – Woody Wu Jan 20 '19 at 15:52
  • I in further has a question about using of the TAP, I think if I use it, the purpose in my application is just to trigger the kernel to send out neighbor solicitation and advertisement, right? Because anyway after my program get the Ethernet frame inside from the TUN, it still have to get rid of the Ethernet header because the underlying network is not Ethernet at all. Be more precise, the underlying network is a G3-PLC network which is defined in G.9903, which used a lot of IEEE 802.15.4 frames and protocols and also defined a adapter layer connecting IPv6 and IEEE 802.15.4. – Woody Wu Jan 20 '19 at 15:53
  • The program which talks to TUN input/output on the other side talks to this G.9903 adapter layer API in which there is no Ethernet and no MAC at all. I think this is the reason why the author choose to use TUN instead of TAP. – Woody Wu Jan 20 '19 at 15:53
  • And, also important: how do you explain why currently there is only one device that sends out RA? I guess there must be some settings that lost from my eye but did not find what it is. Do you have a clue? – Woody Wu Jan 20 '19 at 15:56
  • @RonMaupin In that case I am not sure what your question is. – kasperd Jan 20 '19 at 16:26
  • @WoodyWu If you use a TUN interface the kernel will hand over all packets destined for that interface to your code. If the underlying protocol you are implementing in your code isn't a point-to-point protocol and needs additional information to route the packets you always have the option to implement that part of the routing in your own code. Whether to use TUN or TAP depends on the protocol you need to implement, and I don't know enough about the specific protocol you are implementing to answer that question. Does that layer use MAC addresses? – kasperd Jan 20 '19 at 16:31
  • @WoodyWu Even if there was some way to get the kernel to send neighbor solicitations on a TUN interface (which I don't think there is), those neighbor solicitations would serve no purpose. Nothing the kernel is going to do with the packets on a TUN interface depends on the neighbor advertisements, which is why the kernel doesn't send neighbor solicitations in the first place. If the protocol layer implemented by your code depends on the neighbor advertisements, your code should be generating the neighbor solicitations. – kasperd Jan 20 '19 at 16:37
  • @kasperd The underlying G3-PLC network (defined by IUT-T G.9903) after got an IPv6 packet (through our tun user program), it will from it's destination IPv6 address to deduce a link layer address. The lowest 64bit of the IP address actually encoded much like EUI-64 in a standard IPv6 MAC mapping, just it the imaginary MAC does not come from any real Ethernet adapter, it was composed from a PAN id and a PLC device ID, these two fields add up to 64 bit, very much like a MAC. The PLC network then has its own MAC layer logic to delivery the its packet according to the what PAN and what device ID. – Woody Wu Jan 22 '19 at 05:34
  • My original exception to a neighbor solicitation message is I hope that message would bring the between link-local address ping works. But now, I found even without this message exchanging, the ping in deed worked, I just need to append a scope ID after the addresses I used for ping. So this seems say, that the neighbor solicitation is not necessary to ping, right? – Woody Wu Jan 22 '19 at 05:40
  • But the 'ip neighbor show' command still not give out the right information. I think this is because even our PLC network can delivery the packets with only link-local addresses, but because there is no actual neighbor solicitation did, so there is not neighbor information available in the Linux stack. Is this thinking right? – Woody Wu Jan 22 '19 at 05:40
  • Beside those above questions, what most concerns me is that in our network, only one device (the so-called coordinator node) is sending out Route Solicitation. I desired to know what difference may this device work differently? I checked /proc/sys/net/ipv6/conf/all/* and have not figured out any real difference between this coordinator device and other devices. Hope someone can give me a hint? May be the answer should hidden somewhere in the basic logic that what config or event should trigger Linux to send out RA. – Woody Wu Jan 22 '19 at 05:44
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/88616/discussion-between-kasperd-and-woody-wu). – kasperd Jan 22 '19 at 11:16