bpf clatd.c - refix RFC6145 - really use low 16 bits of IPv6 frag id
To quote: https://www.rfc-editor.org/rfc/rfc6145
4.1 Identification:
The low-order 16 bits copied from the Identification field in
the IPv4 header. The high-order 16 bits set to zero.
5.1.1 Identification:
Copied from the low-order 16 bits in the Identification field in
the Fragment Header.
The RFC does not mention endianness. But I'm assuming it thinks
of things as network, ie. big, endian.
This matches userspace external/android-clat/translate.c:214
ip_targ->id = htons(ntohl(frag_hdr->ip6f_ident) & 0xffff);
This takes the 3rd and 4th byte of the 32-bit ipv6 frag ident field:
see also line 195:
frag_hdr->ip6f_ident = htonl(ntohs(old_header->id));
and
packages/modules/Connectivity/bpf_progs/bpf_net_helpers.h
// Android only supports little endian architectures
#define htons(x) (__builtin_constant_p(x) ? ___constant_swab16(x) : __builtin_bswap16(x))
#define htonl(x) (__builtin_constant_p(x) ? ___constant_swab32(x) : __builtin_bswap32(x))
#define ntohs(x) htons(x)
#define ntohl(x) htonl(x)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie4eed30cfd0e3e3e4dfa6c1a54751dcae1f9972b
diff --git a/bpf_progs/clatd.c b/bpf_progs/clatd.c
index 22726ac..fc10d09 100644
--- a/bpf_progs/clatd.c
+++ b/bpf_progs/clatd.c
@@ -111,8 +111,9 @@
return TC_ACT_PIPE;
const struct frag_hdr *frag = (const struct frag_hdr *)(ip6 + 1);
proto = frag->nexthdr;
- // Per RFC6145 use bottom 16-bits of 32-bit IPv6 ID field for 16-bit IPv4 field.
- ip_id = frag->identification;
+ // RFC6145: use bottom 16-bits of network endian 32-bit IPv6 ID field for 16-bit IPv4 field.
+ // this is equivalent to: ip_id = htons(ntohl(frag->identification));
+ ip_id = frag->identification >> 16;
// Conversion of 16-bit IPv6 frag offset to 16-bit IPv4 frag offset field.
// IPv6 is '13 bits of offset in multiples of 8' + 2 zero bits + more fragment bit
// IPv4 is zero bit + don't frag bit + more frag bit + '13 bits of offset in multiples of 8'