Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring <alex.aring@gmail.com>]

Hi,

On Sun, Apr 24, 2016 at 10:05:28PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Fri, Apr 22, 2016 at 02:28:16PM +0200, Alexander Aring wrote:
> > On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
> ...
> > > 
> > > @Alex as you joined the discussion: I also have a question regarding the Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I observed that Linux still does NS for link-local address via the nodes scoped multicast address, instead of using 6lo 'shortcut' by extracting LL/MAC-address from the link-local IP. Is this fixed in some recent version?
> > > 
> > 
> > There are currently pending patches for introducing neigh_ops, which is
> > a callback strucuture for send/recv NS/NA. After this is mainline it
> > should be easily to change this behaviour, or? What do you think?
> > See [3] - function "lowpan_ndisc_send_ns".
> > 
> 
> I think, I know what you mean. There is some NS with src as unspecified
> addr "::" and dest is some "multicast node scope".
> 
> RFC 6775 says [0]:
> 
> An unspecified source address MUST NOT be used in NS messages.
> 
> Additional to the pending patches I added:
> 
> diff --git a/net/6lowpan/ndisc.c b/net/6lowpan/ndisc.c
> index d088295..c6207cd 100644
> --- a/net/6lowpan/ndisc.c
> +++ b/net/6lowpan/ndisc.c
> @@ -386,8 +386,11 @@ static void lowpan_ndisc_send_ns(struct net_device *dev,
>                 saddr = &addr_buf;
>         }
>  
> +       /* RFC6775:
> +        * An unspecified source address MUST NOT be used in NS messages.
> +        */
>         if (ipv6_addr_any(saddr))
> -               inc_opt = false;
> +               return;

Question would here also, if we really wants to drop it or use ?link-local?
saddr then.

>         if (inc_opt) {
>                 optlen += ndisc_opt_addr_space(dev, dev->addr_len);
>                 optlen += lowpan_ndisc_802154_short_addr_space(dev);
> 
> 
> This will not sending NS with "::" addresses as source address.
> 
> However, it's a little bit ugly we should prevent to calling this
> callback when source address is "::".
> 
> This patch should be fine at first but can maybe optimized in future.
> 

I think what you ask is the complete ARO stuff support and I can't
follow the:

"by extracting LL/MAC-address from the link-local IP." in case of
destination address and sending NS. What I found is the "Sending NS"
section of rfc6775 [0], which doesn't say anything about different
destination address.

Also I found a bootstrapping example in case of 6LN -> 6LR, [1]. But they
meant there the GP64 and link-local is defined as LL64.

...

I think I need to look deeper into that to say something related to
6LoWPAN-ND. :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-5.5.1
[1] https://tools.ietf.org/html/rfc6775#section-10.2.1