Add support for Route Information Option when parsing ICMPv6 Router Advertisements (IDFGH-13888)

[Emill]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

Consider applying this patch:
https://savannah.nongnu.org/patch/?10114

which enables support for Route Information Option when parsing ICMPv6 Router Advertisements and also makes use of these routes when sending IPv6 packets.

Use cases

Needed when ESP device runs on Wi-Fi and it wants to communicate with Thread devices, bridged by a 3rd party border router. The border router communicates over Wi-Fi with the ESP device. The border router will announce the IPv6 prefix of the Thread subnet using the Route Information Option. Without this, we get a ERR_RTE (routing error) error when trying to send a packet to such Thread devices from ESP.

This is needed e.g. when we want to communicate with Thread-Matter devices, see https://github.com/project-chip/connectedhomeip/tree/master/src/lwip/patches#route-information-options-rio. "Required for wifi devices to support communication with a thread device behind an open thread border router."

Alternatives

No response

Additional context

Similar issue for Home Assistant: home-assistant/operating-system#2333

[Emill]

Unfortunately, I think I found some bugs in the patch. Might be worth looking into these first:

nd6_is_prefix_in_netif this function should not treat ip addresses matching the prefix of a route information as on-link

nd6_select_router, just because we have not yet got a NA from the router (ND6_INCOMPLETE) doesn’t mean we should not route packets to it; if there are multiple routers that accept to route packets the same prefix, per RFC 4191 we should first try to use a REACHABLE router and if no such exist, pick a router that is valid but not known to be reachable.

A Route Information entry can be valid longer than the router wants to be a default router. Currently Route Information entries point to a default router entry, which is invalidated when the timeout occurs that the router is no longer a default router. This can cause a null pointer dereference when the "netif" field is read from the default_router_list entry.

When a Route Information entry expires, destination cache entries having this router as the next hop should be invalidated, assuming there is no other still valid Route Information entry for the same router with a prefix matching the address in question.

When a new Route Information entry is added, the destination cache entries affected should be deleted. For example, for some address matching the prefix currently has the next hop as some default router, this destination cache entry must be removed since it should from now on use the specific route.