"
Hello! Nice to see you too!
Tayga's default is the same behavior that Tayga used to do before the configuration was added, but it's also the only behavior which is not optional to implement per RFCs. For this specific case, it would seem that 'fwd' is the best approach for OPNsense, but that is also not RFC compliant, although it's probably the most correct behavior.
Per RFC2460*, IPv6 requires UDP packets to have checksums, although they were optional in IPv4. IPv6 has no checksum, so it relies on the transport layer checksum which includes an IP psuedo-header (for v4 and v6). Arguably, none of these checksums are very good anyway, since IPv4, UDP, and TCP all use the 'Internet Checksum', which is just a one's complement 16-bit sum of words, requires end-around carries on modern two's complement hardware, and is laughably bad at detecting more than the simplest errors and cannot detect mis-ordered words (since they add up to the same number). But it is what has been used for decades.
Option 1 - drop - this drops packets 4->6 which have no UDP checksum, since they would not be valid in IPv6. This impacts protocols which are cheating in IPv4 by not generating checksums, which includes RFC3948 (UDP encapsulation of ESP), which is why we are in this scenario [1].
Option 2 - calc - this calculate a UDP checksum for 4->6 packets, which seems great, except for fragments. Since Tayga does not reassemble fragments (IPv4 fragments get translated into IPv6 fragments, which do exist and are legal but not commonly used), we cannot correctly calculate the checksum of a packet which comes in fragmented. ESP-in-UDP may not hit this case, but I'm guessing it's more likely to suffer from misconfigured MTU within the tunnel which would cause the tunnel overhead to require fragmentation. Tayga can also fragment a packet if it's too large on the IPV6 side but not IPv4 side, but that is done after the checksum would be calculated and is fine. If the packets are fragmented, calc turns into drop. Calc also has a performance impact, 16-bit one's complement addition is not very well optimized, and Tayga is already single-threaded and not very performant.
Option 3 - forward - this forwards the zero-checksum packets as-is, assuming the receiver is compliant enough to not care. If the receiver is doing 6->4 translation anyway, then the receiver must accept it, but if it's doing native IPV6 it may not. This is not an option that RFC7915 [2] allows, however, RFC8200 (IPv6) [3] updated RFC2460 (IPv6) to allow zero checksums for tunneling protocols based on the work done by RFC6936 [4].
Given all of this, I suggest OPNsense set tayga to use 'fwd'
[1] - https://datatracker.ietf.org/doc/html/rfc3948#section-2.1
[2] - https://datatracker.ietf.org/doc/html/rfc7915#section-4.5
[3] - https://datatracker.ietf.org/doc/html/rfc8200#section-8.1
[4] - https://datatracker.ietf.org/doc/html/rfc6936
*RFC8200 changed this guidance to carve-out for ESP-in-UDP, basically
Tayga's default is the same behavior that Tayga used to do before the configuration was added, but it's also the only behavior which is not optional to implement per RFCs. For this specific case, it would seem that 'fwd' is the best approach for OPNsense, but that is also not RFC compliant, although it's probably the most correct behavior.
Per RFC2460*, IPv6 requires UDP packets to have checksums, although they were optional in IPv4. IPv6 has no checksum, so it relies on the transport layer checksum which includes an IP psuedo-header (for v4 and v6). Arguably, none of these checksums are very good anyway, since IPv4, UDP, and TCP all use the 'Internet Checksum', which is just a one's complement 16-bit sum of words, requires end-around carries on modern two's complement hardware, and is laughably bad at detecting more than the simplest errors and cannot detect mis-ordered words (since they add up to the same number). But it is what has been used for decades.
Option 1 - drop - this drops packets 4->6 which have no UDP checksum, since they would not be valid in IPv6. This impacts protocols which are cheating in IPv4 by not generating checksums, which includes RFC3948 (UDP encapsulation of ESP), which is why we are in this scenario [1].
Option 2 - calc - this calculate a UDP checksum for 4->6 packets, which seems great, except for fragments. Since Tayga does not reassemble fragments (IPv4 fragments get translated into IPv6 fragments, which do exist and are legal but not commonly used), we cannot correctly calculate the checksum of a packet which comes in fragmented. ESP-in-UDP may not hit this case, but I'm guessing it's more likely to suffer from misconfigured MTU within the tunnel which would cause the tunnel overhead to require fragmentation. Tayga can also fragment a packet if it's too large on the IPV6 side but not IPv4 side, but that is done after the checksum would be calculated and is fine. If the packets are fragmented, calc turns into drop. Calc also has a performance impact, 16-bit one's complement addition is not very well optimized, and Tayga is already single-threaded and not very performant.
Option 3 - forward - this forwards the zero-checksum packets as-is, assuming the receiver is compliant enough to not care. If the receiver is doing 6->4 translation anyway, then the receiver must accept it, but if it's doing native IPV6 it may not. This is not an option that RFC7915 [2] allows, however, RFC8200 (IPv6) [3] updated RFC2460 (IPv6) to allow zero checksums for tunneling protocols based on the work done by RFC6936 [4].
Given all of this, I suggest OPNsense set tayga to use 'fwd'
[1] - https://datatracker.ietf.org/doc/html/rfc3948#section-2.1
[2] - https://datatracker.ietf.org/doc/html/rfc7915#section-4.5
[3] - https://datatracker.ietf.org/doc/html/rfc8200#section-8.1
[4] - https://datatracker.ietf.org/doc/html/rfc6936
*RFC8200 changed this guidance to carve-out for ESP-in-UDP, basically
