[Discussion] IPv6 neighbor discovery with BLE

[elenaf9]

Description

While working on #21574, I noticed that the NIB neighbor cache is always empty when running IP-over-BLE.

The reason is that:
a) RPL control messages are mostly multicast (so just copied onto every unicast link)
b) L2 addresses for unicast are directly resolved from the IP address (reverse RFC 7668 Section 3.2.2)

After some testing & digging through the code, I observed that (at least with BLE) generally no neighbor discovery from RFC 4861/ RFC 6775 is happening:

• The only sent messages are Router Soliciations (RS), which never get a reply because the Router Advertisements (RA) are only sent if authoritative border routers are present. Nodes apparently don't need to know if other nodes are routers or not, they just use RPL DIO info for routing.
• Neighbor Solicitation messages are only sent when trying to resolve an address, which because of b) never happens. And only then a neighbor cache entry would be created and maintained.

Still, in the docs it is stated that IP-over-BLE does support 6LoWPAN neighbor discovery:

RIOT/pkg/nimble/README.ipv6-over-ble.md

Lines 9 to 10 in f7bda59

	**NOTE 2:** Currently, Linux does not support 6LoWPAN neighbor discovery (which
	RIOT uses per default with BLE), so RIOT needs to be compiled to use stateless

My questions are:

• Is my understanding above correct?
• Why is a RA only sent if there are authoritative routers present? From a high level it kinda makes sense, especially because it is redundant with the RPL DIS/DIO messages, but neither RFC 4861 nor RFC 6775 mention anything about it.
• Does RPL implicitly obsolete neighbor discovery?
• Should we maintain a neighbor cache even if a node's L2 address can be resolved directly from the IP address?
  On one hand it might be be redundant because BLE is a connection-oriented link-layer where we know which nodes are reachable and which aren't. And we can perform address resolution directly based on RFC 7668 Section 3.2.2.
  On the other hand is neighbor discovery specified in both IP-over-BLE RFCs (RFC 7668 and RFC 9159)

Sorry for the many questions, I am still new to IP-over-BLE and might be missing something fundamental 😄

// cc @miri64 as author of #7479.

Motivation

As part of #21574, I need to be able to get the IPv6 address of a connected BLE node. Intuitively, this information should be present in the neighbor cache.
This kind of pushed me down the rabbit hole of trying to understand IPv6 neighbor discovery and its interplay with route-over routing protocols like RPL.

Related Issues

• rpl, rpble: handle closed connection to parent(s) #21574

[mcr]

Elena Frank ***@***.***> wrote: The reason is that: a) RPL control messages are mostly multicast (so just copied onto every unicast link) 1. But, DAOs and DAO ACKs ought to be unicast. So while an infant RPL instance might be only multicast, as soon as it picks a parent, or something picks it as a parent, then it ought to result in neigh cache entries. 2. RPL really ought to be looking at the neighbor cache to establish ETX values.

[mcr]

Elena Frank ***@***.***> wrote: b) L2 addresses for unicast are directly resolved from the IP address (reverse [RFC 7668 Section 3.2.2]) I didn't understand this statement at first. While that would make sense when sending across one hop, across two hops, you'd need a route, and I'm not sure if that would obsolete needing L2 address lookup. I think that it ought to skip the ND step, but I think it ought to create a neighbor cache entry anyway. Does RPL implicitly obsolete neighbor discovery? No. It might obsolete router discoveries... this was hotly debated 15 years ago. If all nodes speak RPL, the quite possibly, no RAs needed. But, if there are leaf-nodes that do not speak RPL, then one needs RA and ND. - Should we maintain a neighbor cache even if a node's L2 address can be resolved directly from the IP address? On one hand it might be be redundant because BLE is a connection-oriented link-layer where we know which nodes are reachable and which aren't. And we can perform address resolution directly based on [RFC 7668 Section 3.2.2]. On the other hand is neighbor discovery specified in both IP-over-BLE RFCs ([RFC 7668] and [RFC 9159]) I thought BTLE 4.0+ mesh was less connection oriented.

[elenaf9]

@mcr Thanks for the quick reply!

So I guess one possible solution would be to add during address resolution, even if we can resolve the BLE address directly from the IP address, still the creation of a NC entry and to start the probing process.
Then we'd at least have entries for parents and children, and potentially also other nodes if we have sent a unicast message to them.

I think that it ought to skip the ND step, but I think it ought to create a
neighbor cache entry anyway.

I am not sure what you mean by that. Aren't the two steps coupled with each other, in the sense that we create a NC entry, and then use the mechanism from the ND RFC to maintain that entry?

b) L2 addresses for unicast are
directly resolved from the IP address (reverse [RFC 7668 Section
3.2.2])

I didn't understand this statement at first.
While that would make sense when sending across one hop, across two hops,
you'd need a route, and I'm not sure if that would obsolete needing L2
address lookup.

Sorry, I probably wasn't clear. I was only referring to address lookup for single-hop/ direct messages to nodes that we are connected to.

I thought BTLE 4.0+ mesh was less connection oriented.

My use-case right now targets only BLE multi-hop, not BLE mesh. BLE multi-hop also creates a mesh-topology network, but with connections between the individual nodes. I am using the nimble_autoconnect module for this.

[elenaf9]

I think that it ought to skip the ND step, but I think it ought to create a
neighbor cache entry anyway.

I am not sure what you mean by that. Aren't the two steps coupled with each other, in the sense that we create a NC entry, and then use the mechanism from the ND RFC to maintain that entry?

Ah, I guess what you meant is to use the BLE connection info to create the NC entry and set its state, but don't do the ND probing. That would make sense.