IPv6 neighbor solicitation fail

[smlng]

The IPv6 NDP is not working when compiling with USEMODULE += gnrc_ipv6_default . Problem is, that RIOT does not add the solicited-node multicast address (see https://tools.ietf.org/html/rfc2461#page-12 ) to its network interfaces. When compiling with: USEMODULE += gnrc_ipv6_router_default it works.

I am using RIOT on a atmel samr21-xpro to communicate with a Raspberry PI (open labs 802.15.4 transceiver) running Raspian-Linux. The RasPI sends a neighbor solicitation to the solicited-node multicast address of the samr21 but gets no answer.

[miri64]

That is intentional (see RFC 6775). In 6LoWPANs you need at least one router that is organizing the address registration.

[smlng]

To clarify: this behavior is expected in 6lowpan networks, i.e. no multicast NS but using RA/RS to maintain neighbor caches? So RIOT is behaving right but (Raspian-)Linux does not comply with RFC 6775 when using a 6lowpan interface? I found it counter intuitive to compile with USEMODULE += gnrc_ipv6_router_default when my RIOT node is just a client and should not route/forward anything (at the moment).

[miri64]

To clarify: this behavior is expected in 6lowpan networks, i.e. no multicast NS but using RA/RS to maintain neighbor caches?

Not completely right: A 6LoWPAN host (6LH) always searches a 6LoWPAN router (6LR), even if that is just the border router (6LBR) (which is required for Internet communication, so you need to configure your Raspian to be a border router). It achieves that by periodically multicasting RS to fe02::2 (all-routers). A 6LR will answer these of course. This gives the 6LH the address to the router to start address registration (required for duplicate address detection): The 6LH sends out a NS with it's L2 address in the SLLAO as well as an ARO to register itself to the 6LR (which in turn MAY [currently not implemented in RIOT] use DAMs to verify the address to further upstream routers). The 6LR than uses an ARO in its NA answering the 6LH's NS to notify the 6LH weather the registration was successful or not. Find a more detailed description of the Host bootstrapping in section 10.2 of the 6LoND RFC.

So RIOT is behaving right but (Raspian-)Linux does not comply with RFC 6775 when using a 6lowpan interface?

A 6LHs and 6LRs MAY (see RFC 2119 for terminology) not add the solicited-nodes MC address (to save memory), but sure can. The 6LBR MUST add it, but not expect the 6LR to answer for it.

I found it counter intuitive to compile with USEMODULE += gnrc_ipv6_router_default when my RIOT node is just a client and should not route/forward anything (at the moment).

If you are not using any routers, global unicast addresses are meaning less. 6LoWPAN assumes for link-local unicast addresses to be reachable under the link-layer address their IID was generated from. So why don't you use link-local addresses for your communication if you don't have internet communication anyway.

[smlng]

Thanks for so much background info - I will (re)check my setup and config on both sides: RIOT and Raspian.

Anyway, basically I try to do what you suggested without any Internet connectivity required:

So why don't you use link-local addresses for your communication if you don't have internet communication anyway.

And it works fine when sending data from RIOT-node to the RasPi using link-local address of the PI. However, when the PI tries to answer using the link-local address of the RIOT-node, the PI first sends a NS to the solicited-node multicast address (ff02::1:) which the RIOT-node will not answer because this mc-address is not associated with its network interface when compiling with gnrc_ipv6_default only.

TL;DR: using link-local addresses works to communicate between RIOT-nodes and from RIOT to Linux, but not from Linux to RIOT. It seams that Linux always uses mcast to run NDP ...

[miri64]

@OlegHahm you tested RIOT-Raspbian communication for the release. Did you experience similar results?

[OlegHahm]

I mostly tested with RIOT acting as a 6LR, but I'm not surprised by these results. 6lo-ND is in a pretty bad shape on the Linux side. Maybe @alexaring can shed some more light on this.

[miri64]

So how do we proceed? Introduce some special behavior (i.e. one more flag) to interact with Linux or leave it as be and hope that Linux fixes its issues?

[smlng]

From what I learned here (from you), RIOT is following the standards regarding 6lowpan NDP and the issue is with Linux. IMHO compiling RIOT with gnrc_ipv6_router_default is a viable workaround for now, nevertheless it took me some time to figure it out.

But as I said before, I will carefully review my setup and do some further testing on this.

[miri64]

Great, thank you @smlng. Keep us posted so we can maybe fix issues on our side. For now I would like to close this issue as invalid, if you don't mind.

[smlng]

Sure, fine with me and thank you @authmillenon so far.

[alexaring]

For clarification: we have currently support nothing from rfc6775 and also no short address handling for 802.15.4 6LoWPAN under Linux.

[miri64]

Thanks, @alexaring. Are there plans to adapt them?

[alexaring]

Our plans are currently:

• Yes, of course we want to support it.

Maybe @Stefan-Schmidt does know more about our plans.

All these neighbor discovery stuff needs runtime changes inside the IPv6 stack ndisc cache implementation. These need to go through the netdev community.

Also for ICMPv6 message types which are not handled by kernel needs an userspace API to offers things e.g. context table entries for (RA, 6CO option field).

I also must admit I haven't take a closer look into rfc6775 and currently working on IPHC stateful compression support.

For short address handling:
This is even more complicated, the whole netdev API works with one type of mac address and one address length with cannot be changed at runtime. The neighbor discovery cache also handle address like that. One of the IPv6 maintainers already offers to add some linklayer private data to each neighbor, see:

http://www.spinics.net/lists/netdev/msg291845.html

This thread is really old, nothing happend then because other issues. Nowadays there exists several ideas to solve the short-address handling. I don't want to go deeper into the details now.

What I think is that solving the short address handling has a higher priority than doing rfc6775. Without short address handling we can even not support parts from rfc6775 and simple say: short address handling isn't support. This will make the issue about short address handling bigger, because we have more holes where we have missing short address handling.

Nevertheless the users want support for rfc6775. Maybe we should solve the short address handling and supporting rfc6775 at the same time. Then I can also sleep better...

Nevertheless everybody is welcome to send-patches and explain about plans to add such handling. :-)

[Stefan-Schmidt]

This really looks like something we are doing wrong on our side. As Alex already pointed out we basically miss almost all of rfc6775 just yet. We want to support it though. Progress is just slow because most of the time its only Alex and myself working on ieee802154/6lowpan on Linux and none of us full time.

Its good to get informed about problems on our side so please keep doing that. We are working on more and better support on all 6lowpan relevant RFCs but not as fast as you folks do I fear. :)

[OlegHahm]

Thanks for the info!