Broadcast entries in eBPF maps

Currently, we are only using broadcast link-layer addresses in the fast-forwarding plane implemented using eBPF programs. This causes a number of issues. Namely:

• tracepath is impossible because no ICMPv6 messages are being sent in response to packets delivered by broadcast ll addresses
• TCP is not working because SYN, ACK packets are discarded if delivered by broadcast ll addresses.

The following approaches exist to solve the problem:

1. Utilize link-local neighbor cache of the vanilla Linux networking functionality:
   • establish mapping: Underlay-Neighbor-ID --> link-local IPv6, (source ll address, destination ll address)
   • Save link-local IPv6 address as destination inside the eBPF maps.
   • retrieve ll addresses via bpf_fib_lookup by specifying the link-local IPv6 as destination.
2. Utilize neighbor cache of the vanilla Linux networking functionality for node-id IPv6-addresses:
   • setup routes for all node-ids utilized by the forwarding via a discovered link-local IPv6.
   • retrieve ll addresses via bpf_fib_lookup.
3. Manage an exclusive neighbor cache and write information inside eBPF maps instead of the placeholder broadcast address used now.
   • establish mapping: Underlay-Neighbor-ID --> (link-local IPv6), source ll address, destination ll address using an IP-Cache on receiving messages
   • use Underlay-Neighbor-ID instead of Node-ID in the forwarding tables interfaces by the routing functionality
   • write source/destination ll addresses into eBPF maps to be accessible by the eBPF programs directly.

Approach 1 would allow us to directly communicate to underlay neighbors without any interference by the KIRA forwarding, but this would not enable us to drop support for one-hop overlay paths since they would not be covered by the native Linux networking functionality because of the potential disjoint of next overlay hop and final destination.

Approach 2 is similar to approach 1 but leaks information about the forwarding functionality to the user. Also, the routing daemon is then incapable of deciding to use two different links for the same neighbor if desired. Crucially, the via routes need to be kept up-dated and in sync if the link-layer information changes.

Approach 3 leverages the eBPF maps the most and offers the greatest flexibility on how to store the forwarding information. It is the only solution that offers the ability for flat forwarding tables without any indirections on the cost of increased memory usage. In general approach 1 and 2 at least require one indirection more because of the required kernel fib lookup.