Add support for translating IPv4/UDP packets with zero checksum, leaving the checksum as zero.

[jivanpal]

RFC 8200 section 8.1 cites RFC 6936, making an exception for the treatment of IPv4 packets containing a UDP datagram with zero checksum, when such packets are to be translated to IPv6. In particular:

As an exception to the default behavior, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode must follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].

Tayga has recently (about a year ago, in version 0.9.5) implemented this as the option udp-cksum-mode-fwd, permitting use cases such as the routing of zero-checksum IPv4/UDP datagrams (such as used in VoWiFi ePDG tunnels/encapsulation) over 464XLAT connections where Tayga acts as the PLAT.

It may be desirable to add a similar option to Jool, e.g. called forward-udp-checksum-zero (named analogously with the existing option amend-udp-checksum-zero), perhaps taking a list of UDP port numbers as an argument.

[ydahhrk]

Ok, so... if I understand this properly,

• It's IPv4 to IPv6 only
• It's UDP only
• When you say "port," you're only referring to the destination port.
• The checksum is not going to be recomputed; it's going to stay as zero.
• What happens when both amend and forward are enabled, and the port matches the forward list?

[jivanpal]

It's IPv4 to IPv6 only

No, it needs to be both. The primary use case in practice is when an IPv4 node sends an IPv4 packet containing a UDP datagram that encapsulates another IP packet, and that outer IPv4 packet is sent over a 464XLAT network, meaning it will be translated to IPv6 and back again before reaching its IPv4 destination, with at least one of those translators being Jool.

As such, in situations where Jool is the PLAT, if we only allow/forward zero-checksum datagrams when going from IPv4 to IPv6, then IPv4 packets from the server (e.g. an ePDG endpoint operated by a cellular carrier) would be correctly translated by Jool; but IPv4 packets from the client (e.g. outgoing VoIP packets encapsulated for sending over an ePDG tunnel) would be handled incorrectly, as these are liable to have zero-checksum datagrams too, and would reach the Jool PLAT as translated IPv6 packets.

The situation is reversed in cases where Jool is the CLAT: packets from clients would be handled correctly, but packets from servers would not be.

It's UDP only

That's correct.

When you say "port," you're only referring to the destination port.

No, we need to check both, whether the source and/or destination port of a datagram match any in the list, similarly to why we need to do this for both IPv4 and IPv6 packets arriving at Jool. If we only check the destination port, then if we're the PLAT, only IPv4 packets sent by the client, which have the relevant port number (e.g. 500 or 4500) as their destination port number, and which may have zero checksum and would arrive at Jool as IPv6 packets, would be correctly forwarded; whereas IPv4 packets sent by the server, which have the relevant port number (e.g. 500 or 4500) as their source port number, would not. Again, the situation is reversed if we're the CLAT.

The checksum is not going to be recomputed; it's going to stay as zero.

That's correct.

What happens when both amend and forward are enabled, and the port matches the forward list?

I would expect/want forward to take precedence, e.g. if forward is used for ports 500 and 4500, and amend is also enabled, then an incoming UDP packet with source port and/or destination port in {500, 4500} and with zero checksum would be forwarded with zero checksum, otherwise the checksum would be amended.

[oskar456]

I would like to second to this issue. In my opinion, listing only specific UDP ports is unnecessary complex, I would be happy just with forward-udp-checksum-zero being mutually exclusive with amend-udp-checksum-zero and it would also forward fragmented packets. In scenarios like 464XLAT, where both endpoints are speaking IPv4, it does not really matter that the UDPv6 checksum along the path was zero or that the packets were fragmented.

But in any case, when translating UDP from IPv6 to IPv4 and the incoming UDPv6 checksum is zero, Jool should just emit UDPv4 with the checksum of zero. Right now Jool will just apply the checksum correction which means the outgoing IPv4 UDP checksum would be non-zero and incorrect. I think this part should be unconditional, because I don't see a scenario where current behaviour makes sense.

[ydahhrk]

Progress in issue446 branch.

As requested, the configuration key is forward-udp-checksum-zero, and at the moment, it's a boolean. Available in both SIIT and NAT64 flavors. In SIIT, it takes precedence before amend-udp-checksum-zero.

jool_siit global update forward-udp-checksum-zero true
jool global update forward-udp-checksum-zero true

I think it does everything except for the port list. Can you test it?

Please note:

According to kernel comments, there are some NICs that verify certain checksums on ingress, which suggests a zero UDP checksum could be dropped before the packet is handed to the kernel. This feature might have to be disabled for zero checksum translation to work. I didn't have to do it in my test box, but presumably, it would be done with ethtool.

I'll try implementing the port list either tomorrow or next weekend.

[Dando-Real-ITA]

No, it needs to be both. The primary use case in practice is when an IPv4 node sends an IPv4 packet containing a UDP datagram that encapsulates another IP packet, and that outer IPv4 packet is sent over a 464XLAT network, meaning it will be translated to IPv6 and back again before reaching its IPv4 destination, with at least one of those translators being Jool.

This seems to match a problem I was having when moving a docker swarm - that uses VXLAN - over an ipv6 network. I did setup on each server a 464XLAT in a namespace with EAMT for the server IPs and pool6 for internet (matching NAT64 at the edge), and host to host communication was working with ipv4 addresses, but communication over swarm containers was broken. Host/Container to internet was working. It seemed to be checksum related

I resolved with ipip6 for inter-host connection, while leaving jool for internet access, maybe in these days I'll test if this patch makes the connection work without ipip6

[ydahhrk]

There are two new commits in issue446: a0c67c8, 6c8a496