The comment exists since the introduction of the [original
implementation], but its meaning is unclear and misleading, as the code
doesn't do anything with link-local.
[original implementation]: https://github.com/RIOT-OS/RIOT/pull/3561
Rule 2 of the source address algorithm outlined in [RFC6724] states the
possible source addresses must also be compared among each other:
> Rule 2: Prefer appropriate scope.
> If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
> otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
> Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Our current implementation doesn't do that. It just checks if the scope
of a possible source is lesser than the scope of the destination
(which involves the second "If" in the rule).
This fix grants points according to the scope of an address. If the
scope matches, they get the highest points, ensuring that the selected
source will always be reachable from the destination.
[RFC6724]: https://tools.ietf.org/html/rfc6724
`_match_to_idx()` was removed from source address selection (which was
the only one setting the filter parameter to a non-NULL value), so it
is the parameter is not needed anymore.
When source address selection is done, both RFC and comments in the code
state, that a longest prefix match should *only* be used as a
tie-breaker between more than one viable candidate. If there is only one
address, there is
a) no need for a tie-breaker
b) in the case of either the destination address or the single remaining
address being ULAs ([which are considered to be of global scope]
[RFC4193]) possibly not matching, as `fd00::/7` and e.g. `2001::/8`
do not have a common prefix.
(b) in fact causes the match function to return -1, causing the source
address selection to return -1, causing the outer function to return the
first address it found (which most often is the link-local address),
causing e.g. a ping to an ULA to fail, even is there is a global
address.
[RFC4193]: https://tools.ietf.org/html/rfc4193
Similar as with #12513, when the NIB is compiled in 6LN mode (but not
6LR mode), the address-resolution state-machine (ARSM) functionality is
disabled in favor of the more simpler address resolution proposed in RFC
6775.
However, if a non-6LN interface is also compiled in (without making it
a router or border router) it will never join the solicited-nodes
multicast address of addresses added to it, resulting in address
resolution to that interface to fail.
If the interface is not a 6LN (which in case 6LN mode is disabled is
always false), a warning is now printed, encouraging the user to
activate the ARSM functionality if needed.
The functions now are semantic distinct:
- gnrc_netif_is_6lo(): the interface is a 6Lo interface
- gnrc_netif_is_6ln(): the interface is using Neighbor Discovery
according to RFC 6775
A received packet is outputted in DEBUG _after_ it was already parsed,
but with a reference to the already parsed header. The result is that
there can be some garbage in the output and the packet is not dumped in
total. As without parsing we do not have access to the header yet, we
use the `gnrc_netif_addr_to_str()` helper function instead of parsing
the destination address by hand.
The following functions can now be wrapped around the more generalized
approach:
- gnrc_netif_ipv6_iid_from_addr()
- gnrc_netif_ipv6_iid_to_addr()
- gnrc_netif_ndp_addr_len_from_l2ao()
- gnrc_netif_eui64_from_addr()
With `DEVELHELP` activated all required options required by GNRC are
now checked at interface initialization, so that developers of new
link-layer protocols or device drivers notice as soon as possible that
something is missing.
