There is no guarantee that the part of the packet we want to read or
write via direct packet access is linear. From the documentation of
bpf_skb_pull_data():
For direct packet access, testing that offsets to access are within
packet boundaries (test on skb->data_end) is susceptible to fail if
offsets are invalid, or if the requested data is in non-linear parts
of the skb. On failure the program can just bail out, or in the case
of a non-linear buffer, use a helper to make the data available. The
bpf_skb_load_bytes() helper is a first solution to access the
data. Another one consists in using bpf_skb_pull_data to pull in
once the non-linear parts, then retesting and eventually access the
data.
See: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2107#note_3288979
Reported-by: DasSkelett <dasskelett@dasskelett.dev>
Avoid the additional function call and perform the needed checks
directly in clat_handle_v4() and clat_handle_v6(). It will make easier
to check that the packet is linear is the next commit.
Convert IPv6 fragments into IPv4.
The PLAT fragments IPv4 packets larger than the IPv6 MTU size into
smaller IPv6 packets. The safest IPv6 MTU value to configure on a PLAT
is the minimum IPv6 MTU, 1280. Therefore, we can expect IPv6 fragments
to be quite common.
When running a traceroute for an IPv4 address, the nodes before the
NAT64 gateway return ICMPv6 Time Exceeded messages with a source IPv6
address not belonging to the NAT64 prefix. Such messages would be
normally dropped by the CLAT because the source address can't be
translated. This behavior complicates troubleshooting.
Follow the recommendation of
draft-ietf-v6ops-icmpext-xlat-v6only-source-01 and translate the
source address to the dummy IPv4 192.0.0.8.
bpf_redirect_neigh() looks up the next hop in the routing table and
then redirects the packet to the given ifindex. The problem is that
the routing table might contain a default route with lower metric on a
different device; in that case the FIB lookup returns a next hop on
the other device, and the packet can't be delivered.
Use bpf_redirect() instead; the IPv4 already has the right L2
destination because the IPv4 default route points to the IPv6 gateway.
Reported-by: DasSkelett <dasskelett@dasskelett.dev>
ICMPv6 error messages contain a copy of the original packet that
caused the error. In a 464XLAT deployment, this inner packet is an
IPv6 packet (as translated by the PLAT), while the local host expects
to see the original IPv4 packet it generated.
Without translation, the local host can't match the error to an active
socket. This breaks functionality like Path MTU Discovery (PMTUD),
traceroute, and error reporting for connected UDP sockets.
This commit implements the translation of the inner headers from IPv6
to IPv4 for incoming ICMPv6 errors.
Some implementation notes:
- this only handles incoming ICMPv6; outgoing ICMPv4 is not yet
implemented, but it seems less important.
- the program uses different functions for rewriting the outer and
inner header. I tried using recursion but the verifier didn't seem
to like it.
- after rewriting the inner headers, the ICMP checksum is
incrementally updated based on difference of all the individual
modifications done to the inner headers. This has the advantage
that all the operations are fixed-size. But probably it would be
easier and faster to just calculate the checksum from scratch.
The program only needs to know the local IPv4 address, the local IPv6
address and the PREF64. There is no need to create multiple maps for
that, just pass a global configuration struct containing those 3
fields.
Improve the code style and consistency of some functions:
- declare only one variable per line
- add "const" keyword to read-only function arguments
- remove unneeded function arguments
- rename variables holding headers on the stack with the "_buf"
suffix
Avoid using pointer arithmetic in the BPF program, so that it requires
only CAP_BPF and not CAP_PERFMON. In this context "pointer arithmetic"
means adding a variable value to a packet pointer. This means that the
program no longer tries to parse variable-size headers (IPv4 options,
IPv6 extension headers). Those were already not supported before. It
also doesn't parse VLAN tags, but there should be no need for that. If
we use fixed offset, we can avoid using the parsing helpers from
libxdp.
There are 3 possible results from clat_translate_v6():
1. the packet didn't match the CLAT IPv6 address and must be
accepted;
2. the packet matches but it is invalid and so it must be dropped;
3. the packet matches and it is valid; clat_handle_v6() should
translate the packet to IPv4;
Before, the function returned TC_ACT_SHOT for both 2 and 3. Therefore,
clat_handle_v6() tried to rewrite also invalid packets.
Fix that by returning TC_ACT_UNSPEC for valid packets, meaning that
there isn't a final verdict yet.
When copying the IPv6 addresses via a direct assignement, the compiler
generates 32-bit operations that the verifier doesn't like:
> 237: (61) r3 = *(u32 *)(r8 +76) ; frame1: R3_w=pkt(r=0) R8=ctx()
> ; .saddr = ip6h->saddr, @ clat.bpf.c:124
> 238: (63) *(u32 *)(r10 -64) = r3
> invalid size of register spill
Use explicit memcpy() for those.
Also, check the packet length before accessing the ICMPv6 header.
