Non-routing 6LNs do not have to join the solicited nodes address, so
probing for a neighbor using that address may be in vain and only
spamming the LLN with unnecessary messages. RFC 6775 basically assumes
this in section 5.2:
> There is no need to join the solicited-node multicast address, since
> nobody multicasts NSs in this type of network.
In accordance with RFC 6775, section 5.2 an NCE should be set STALE
when an ARO renews the address registration for the address:
> The routers SHOULD NOT garbage-collect Registered NCEs (see
> Section 3.4), since they need to retain them until the Registration
> Lifetime expires. Similarly, if NUD on the router determines that
> the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE
> SHOULD NOT be deleted but rather retained until the Registration
> Lifetime expires. A renewed ARO should mark the cache entry as
> STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave
> like a cache. Instead, it behaves as a registry of all the host
> addresses that are attached to the router.
When `nce` is NULL on the duplicate check, the later re-fetching of the
`nce` might result in an actual NCE entry that then contains a
duplicate, so we need to re-check the EUI-64 again as well.
This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
Using pointer difference already gives us the number of elements of
size of what the pointer is pointing to.
Dividing by size will lead to the wrong (always 0) result.
Add a message bus where threads can listen for nib events.
Currently only the GNRC_IPV6_NIB_EVENT_ADDR_VALID event is
implemented which informs subscribers that an address got
valid.
With multiple 6LoWPAN interfaces the router for the given interface
—the one the triggering RA came over—should be used to register the
address with.
Co-Authored-By: Benjamin Valentin <benpicco@googlemail.com>
In 06aa65e1ba (#10627) a new behavior was
introduced in IPv6 route resolution to try address resolution only at
interfaces that have the prefix of the address to be resolved configured
in the prefix list. This however only makes sense, if the prefix
configured is [on-link], otherwise there is small likelihood of the
address to be resolved being on that link.
For the error case presented for 06aa65e (circular routing at the border
router) this made sense, however within a 6LoWPAN, due to the prefix
being valid for the entire mesh, this leads to the nodes always trying
classic address resolution for in-network addresses instead of just
routing to the default route.
Classic address resolution however fails, as 6LoWPAN hosts typically
[don't join the solicited-node multicast address of their unicast
addresses][6LN-iface-init], resulting in in-network addresses not being
reachable.
As such, to prevent both error cases
- the fallback to address resolution by prefix list must only be used
when the prefix is on-link,
- the prefix configured by DHCPv6/UHCP at the 6LoWPAN border router
must be configured as on-link, but
- the prefix must not be advertised as on-link within the 6LoWPAN to
still be [in line with RFC 6775][RFC-6775-forbidden]
With this change these cases are covered.
[on-link]: https://tools.ietf.org/html/rfc4861#page-6
[RFC 6775]: https://tools.ietf.org/html/rfc6775
[6LN-iface-init]: https://tools.ietf.org/html/rfc6775#section-5.2
[RFC-6775-forbidden]: https://tools.ietf.org/html/rfc6775#section-6.1
