6LoWPAN (IPv6 over BLE) neighbor discovery

6LoWPAN (IPv6 over BLE) neighbor discovery

[Philipp Blum]

Hey,

I am currently working on a demonstration for the W3C TPAC next month. 
Just wanted to get an update on this topic, since RIOT uses it in IPv6 
over BLE.

best regards
Philipp Blum

Re: 6LoWPAN (IPv6 over BLE) neighbor discovery

[Alexander Aring]

Hi,

On Tue, Aug 9, 2022 at 4:24 PM Philipp Blum <info@desertmonitor.com> wrote:
>
> Hey,
>
> I am currently working on a demonstration for the W3C TPAC next month.
> Just wanted to get an update on this topic, since RIOT uses it in IPv6
> over BLE.
>

Which neighbor discovery are you talking about? Can you be more
specific here? I am not aware that any 6LoWPAN implementation uses any
optimized in-kernel IPv6 neighbor discovery for any low power/lossy
network, we are still using the default IPv6 one which should probably
still work if the other side supports it. In 802.15.4 we tweaked it a
little bit to support the short address into the address option as
RFC4944 describes it [0] that autoconfiguration can use it.

I added linux-bluetooth in cc.

- Alex

[0] https://www.rfc-editor.org/rfc/rfc4944#section-8

Re: 6LoWPAN (IPv6 over BLE) neighbor discovery

[Philipp Blum]

Hi,

 > Which neighbor discovery are you talking about? Can you be more
 > specific here?

Sorry, I cannot, since I am not too familiar with the network stack.
 From my point of view, mostly as a user of the stack, I can't pass down 
IPv6-PDs from my router down to the RIOT RPL network.
I need some workarounds with radvd in order to distribute the PD.
There is a markdown file about it: 
https://github.com/RIOT-OS/RIOT/blob/master/pkg/nimble/README.ipv6-over-ble.md

People in the matrix chat pointed me towards the mailing list.

best regards
Philipp Blum

On 10.08.22 02:17, Alexander Aring wrote:
> Hi,
> 
> On Tue, Aug 9, 2022 at 4:24 PM Philipp Blum <info@desertmonitor.com> wrote:
>>
>> Hey,
>>
>> I am currently working on a demonstration for the W3C TPAC next month.
>> Just wanted to get an update on this topic, since RIOT uses it in IPv6
>> over BLE.
>>
> 
> Which neighbor discovery are you talking about? Can you be more
> specific here? I am not aware that any 6LoWPAN implementation uses any
> optimized in-kernel IPv6 neighbor discovery for any low power/lossy
> network, we are still using the default IPv6 one which should probably
> still work if the other side supports it. In 802.15.4 we tweaked it a
> little bit to support the short address into the address option as
> RFC4944 describes it [0] that autoconfiguration can use it.
> 
> I added linux-bluetooth in cc.
> 
> - Alex
> 
> [0] https://www.rfc-editor.org/rfc/rfc4944#section-8
> 

Re: 6LoWPAN (IPv6 over BLE) neighbor discovery

[Alexander Aring]

Hi,

On Tue, Aug 9, 2022 at 9:41 PM Philipp Blum <info@desertmonitor.com> wrote:
>
> Hi,
>
>  > Which neighbor discovery are you talking about? Can you be more
>  > specific here?
>
> Sorry, I cannot, since I am not too familiar with the network stack.
>  From my point of view, mostly as a user of the stack, I can't pass down
> IPv6-PDs from my router down to the RIOT RPL network.
> I need some workarounds with radvd in order to distribute the PD.

What kind of workarounds? I am curious...

> There is a markdown file about it:
> https://github.com/RIOT-OS/RIOT/blob/master/pkg/nimble/README.ipv6-over-ble.md
>

Okay, if you like you could also try [0] on bluetooth networks... I
never did it on bluetooth. Although I think it does not make any sense
because it makes only sense on a mesh network and so far I understand
this is the difference between bluetooth 4.x vs 5.x/upwards and
currently there is no mesh bluetooth 6lowpan support here (but mesh
bluetooth on link-layer is there). It's a star topology. I guess what
you could try out is ndisc-proxy setup which is mostly the same but no
routing involved and they share the same prefix.

> People in the matrix chat pointed me towards the mailing list.

I see, on this layer it would be linux-wpan and linux-bluetooth.

- Alex

[0] https://github.com/linux-wpan/rpld

Re: 6LoWPAN (IPv6 over BLE) neighbor discovery

[Philipp Blum]

Hi,

sorry, just realized I used the info@ email ^^

 > What kind of workarounds? I am curious...

The radvd workaround to distribute a PD.
Ideally I would like it to be as plug & and play as possible.
Connecting the sensors to my router and passing down the PD 
automatically. At the end of the day, not everyone is a dev.

 > Okay, if you like you could also try [0] on bluetooth networks... I
 > never did it on bluetooth. Although I think it does not make any sense
 > because it makes only sense on a mesh network and so far I understand
 > this is the difference between bluetooth 4.x vs 5.x/upwards and
 > currently there is no mesh bluetooth 6lowpan support here (but mesh
 > bluetooth on link-layer is there). It's a star topology. I guess what
 > you could try out is ndisc-proxy setup which is mostly the same but no
 > routing involved and they share the same prefix.

Btw, I am on Bluetooth 4.2. I had a hard time to even find non audio 
only Bluetooth 5.x USB sticks. Yes, it's only star topology so far. Even 
though, from my understanding, you could theoretically run a RPL network 
behind it.
There are more powerful MCUs that would be able to act as a RPL root.
Even though it probably would be better to use the linux border router 
as root. Puts less pressure on the sensor nodes.
I am not familiar with ndisc-proxy. If you could point me to some 
resources, that would be very helpful. Going to take a look into it.
Sharing the same prefix would be fine for now, since I only run it in a 
star topology anyway.
RPL should be, from my understanding, also work on BLE. RIOT allows 
three concurrent connections for BLE, as I remember.

I don't really understand why rpld only works in a mesh network.
When it runs on 6LoWPAN, it should also run on BLE, or am I missing 
something?

best regards
Philipp

Re: 6LoWPAN (IPv6 over BLE) neighbor discovery

[Alexander Aring]

Hi,

On Wed, Aug 10, 2022 at 7:12 PM Philipp Blum
<philipp-blum@desertmonitor.com> wrote:
>
> Hi,
>
> sorry, just realized I used the info@ email ^^
>
>  > What kind of workarounds? I am curious...
>
> The radvd workaround to distribute a PD.
> Ideally I would like it to be as plug & and play as possible.
> Connecting the sensors to my router and passing down the PD
> automatically. At the end of the day, not everyone is a dev.
>

Setting up a router is considered to be at least an "administrator"
level. You need to at least provide a prefix. The RA message is from
the Linux kernel networking branch considered as a user space message
(on the transmit side, the receive side it's different), I doubt that
this will ever be changed. At the end the user needs to configure
something in any case.

>  > Okay, if you like you could also try [0] on bluetooth networks... I
>  > never did it on bluetooth. Although I think it does not make any sense
>  > because it makes only sense on a mesh network and so far I understand
>  > this is the difference between bluetooth 4.x vs 5.x/upwards and
>  > currently there is no mesh bluetooth 6lowpan support here (but mesh
>  > bluetooth on link-layer is there). It's a star topology. I guess what
>  > you could try out is ndisc-proxy setup which is mostly the same but no
>  > routing involved and they share the same prefix.
>
> Btw, I am on Bluetooth 4.2. I had a hard time to even find non audio
> only Bluetooth 5.x USB sticks. Yes, it's only star topology so far. Even
> though, from my understanding, you could theoretically run a RPL network
> behind it.
> There are more powerful MCUs that would be able to act as a RPL root.
> Even though it probably would be better to use the linux border router
> as root. Puts less pressure on the sensor nodes.
> I am not familiar with ndisc-proxy. If you could point me to some
> resources, that would be very helpful. Going to take a look into it.
> Sharing the same prefix would be fine for now, since I only run it in a
> star topology anyway.

It's also known as arp proxy on IPv4. Just google it, but for IPv6 you
need to have a daemon in the background to make it automatically
configured. Although I recommend at first to try it with a manual
setup by using iproute2.

> RPL should be, from my understanding, also work on BLE. RIOT allows
> three concurrent connections for BLE, as I remember.
>

Sure it works on BLE, but here you have a star topology where RPL
makes really no sense. It is just one parent with leaf-nodes and radvd
will do the same for you. From my point Bluetooth mesh topology is
supported by the kernel right now as link-layer but there is no
6LoWPAN adaptation (speaking on Linux kernel level, IETF has standards
for it) to run 6LoWPAN on BLE mesh topology. What we currently support
is the star topology one which is how Bluetooth works for decades.
Only on a mesh RPL becomes interesting.

> I don't really understand why rpld only works in a mesh network.
> When it runs on 6LoWPAN, it should also run on BLE, or am I missing
> something?
>

I did not say that it does not work, I said it makes no sense to run
it on a link-layer star topology. If it's a mesh it looks different.

Another thing to test would be a 6CO option [0] which will allow
6lowpan to compress non link-layer prefixes. It makes sense to add one
like your prefix destination option in RA. For the arp/ndisc solution
you could simply reach all neighbors by its link-local address. To be
more clear, the arp/ndisc proxy needs to be configured on the device
which was before your "router", then magically all neighbors behind it
can be reachable by its link-local... if you want to access it behind
your local area network, then you indeed need a global prefix and
routing/gateway/etc..

Note that [0] never came upstream (except one patch) because the UAPI
in Linux kernel is not stable, I am working on it right now and my
progress is at about 25% to make the UAPI stable. :)

- Alex

[0] https://github.com/linux-wpan/radvd/commit/562e1b3264ac1f352dcc3521f6256d16057775ba