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
When pinging to a prefix for which there is a prefix list entry on the
node (so no next hop) but a default route, a packet to a non-existent
address under that prefix results in the packet being forwarded to the
default route instead. This fixes it, so the node tries address
resolution on the interface the prefix list entry is associated to.
The reassembly buffer only needs (and stores) the headers *before* the
fragment header (called per-fragment headers in RFC 8200, section 4.5).
Currently, when a subsequent IPv6 fragment is received before the first
fragment the fragment header is however not removed. With this fix it
does.
When the destination address is the loopback address (`::1`) in GNRC
the selected network interface typically is `NULL`, as with GNRC no
loopback interface de facto exists. So the assertion when checking if
the source address is valid if `netif != NULL` fails on that check.
This change fixes that issue by checking if the destination address is
the loopback address, before checking the validity of the source
address.
When the NIB is compiled for 6LN mode (but not a 6LBR), the Stateless
Address Autoconfiguration (SLAAC) functionality is disabled, as it is
typically not required; see `sys/include/net/gnrc/ipv6/nib/conf.h`, ll.
46 and 55. However, if a non-6LN interface is also compiled in (still
without making the node a border router) an auto-configured address will
be assigned in accordance with [RFC 6775] to the interface, just
assuming the interface is a 6LN interface. As it then only performs
duplicate address detection RFC-6775-style then, the address then never
becomes valid, as the duplicate address detection according to [RFC
4862] (part of the SLAAC functionality) is never performed.
As auto-configuring an address without SLAAC doesn't make sense, this
fix makes the interface skip it completely, but provides a warning to
the user, so they know what to do.
[RFC 6775]: https://tools.ietf.org/html/rfc6775#section-5.2
[RFC 4862]: https://tools.ietf.org/html/rfc4862#section-5.4
We want to check if the interface is an interface requiring the 6Lo
adaptation layer, not if it is a 6LN according to RFC 6775 [[1]].
[1]: https://tools.ietf.org/html/rfc6775#section-2
When writing to the IPv6 header the implementation currently doesn't
take the packet with the (potentially) duplicated header, but the
packet with the original one, which leads to the packet sent and then
released in `gnrc_netif_ethernet.c` first and then accessed again in
further iterations of the "writing to the IPv6 header" loop, which
causes access to an invalid pointer, causing a crash.
Fixes#11980
While it is correct to not use an invalid address as a source address,
it is incorrect to assume that addresses not assigned to the interface
(`idx == -1` in the respective piece of code) are invalid: Other than
classic forwarding via a FIB, forwarded packets utilizing a IPv6
routing header will pass this check, like any other packet sent by this
node. The source address for these is not on the given node, so e.g.
source routing is not possible at the moment.
The IPv6 (extension) headers of the first fragment received are re-used
for the reassembled packet, so when receiving a subsequent packet we
need to distinguish, if we just want to release the payload or all of
the packet after the packet data was added to the reassembly buffer.
If an address was pre-configured by the upper layer its validity is
currently ignored. It is neither checked if the address is on the
interface at all nor is it checked if it is valid.
This change provides a fix for that by checking both facts.
When reworking the reception of IPv6 packets I reset a previously set
`ipv6` snip as follows when the IPv6 extension handler returns a
packet (see first hunk of this commit):
```C
ipv6 = pkt->next->next
```
With `gnrc_ipv6_ext` this makes *somewhat* sense, `pkt->next` was
previously equal to `ipv6` and after the function call `pkt->next`
is the marked extension header, while `pkt->next->next` is the IPv6
header. However, since `ipv6` is already write-protected i.e.
`ipv6->users == 1` (see ll. 665-675), any additional call of
`gnrc_pktbuf_start_write()` [won't][start-write-doc] duplicate the
packet. In fact, the only `gnrc_pktbuf_start_write()` in
`gnrc_ipv6_ext` is used to send the *result* to the subscribers of that
extension header type, leaving the original packet unchanged for the
caller. As such `ipv6` remains the pointer to the IPv6 header whether
we set it in the line above or not. So we actually don't need that
line.
However, the extension header handling also returns a packet when
`gnrc_ipv6_ext` is not compiled in. In that case it is just a dummy
define that returns the packet you give provide it which means that
this still holds true: `pkt->next == ipv6`.
So setting `ipv6` in this case is actually harmful, as `ipv6` now
points to the NETIF header [following the IPv6 header][pkt-structure]
in the packet and this causes the `user` counter of that NETIF header
`hdr` to be decremented if `hdr->users > 1` in the write-protection I
removed in hunk 2 of this commit:
```C
/* pkt might not be writable yet, if header was given above */
ipv6 = gnrc_pktbuf_start_write(ipv6);
if (ipv6 == NULL) {
DEBUG("ipv6: unable to get write access to packet: dropping it\n");
gnrc_pktbuf_release(pkt);
return;
}
```
But as we already established, `ipv6->users` is already 1, so we don't
actually need the write protection here either.
Since the packet stays unchanged after the `ipv6` snip, we also don't
need to re-search for `netif_hdr` after the other two lines are
removed.
[start-write-doc]: https://doc.riot-os.org/group__net__gnrc__pktbuf.html#ga640418467294ae3d408c109ab27bd617
[pkt-structure]: https://doc.riot-os.org/group__net__gnrc__pkt.html#ga278e783e56a5ee6f1bd7b81077ed82a7
The `addr` parameter of the NIB's `_handle_dad()` function can come
from anywhere (e.g. in the fallback to classic SLAAC the destination
address of the IP header is used), so putting that pointer in a timer
is not a good idea. Instead we use the version of the address that is
stored within the interface.
`_demux()` might change `pkt->data` in all kind of ways (moving it due
to `gnrc_pktbuf_mark()`, though unlikely; releasing it, because e.g. it
starts with a fragment header that marks a fragmented packet containing
only one fragment, etc.) so accessing the pointer *after* calling
`_demux()` is somewhat playing with fire. This change avoids this by
storing the value of `ext_hdr->nh` (all we are interested in here) in a
temporary variable that then is used to set the out-parameter `nh`.
`protnum` needs to be unchanged before the call to `_demux()` as it was
set by the previous iteration and determines what extension header
actually is handled.
If the interface's link-layer doesn't use link-layer addresses it
obviously doesn't make sense to auto-configure an IPv6 address from it.
Moreover, I think the address `fe80::` is actual illegal, but I
couldn't find any references for it.
According to the documentation of `gnrc_ipv6_nib_get_next_hop_l2addr()`
`pkt` may be `NULL`. However, whenever that function sends an error
message (the methods for that require `orig_pkt` not to be NULL) `pkt`
is not checked, which may lead to failed assertions.
