[IPv4] VRRP v3 - rfc5798bis and checksum calculation

[nser77]

Hi all, while interacting with other repositories, I found the following IETF draft which differs from RFC 5798 as can be seen in section 1.1 of the draft.

While reading the draft, I noticed a breakpoint related to the checksum calculation for a VRRP version 3 IPv4 packet sended(/checked) from keepalived and the commit #2234 ; this results in keepalived not compliant with the VRRP version 3 standard by default.

I know we did a "workaround" by adding the v3_checksum_as_v2 config option, but the default behavior of keepalived is still not compliant and seems not well documented, it says:

[...]

    # Some manufacturers (e.g. Cisco) interpret RFC5798 5.2.8 as applying
    #  only to IPv6, since the pseudo-header in RFC2460 is specified only
    #  for IPv6. Keepalived by default uses a pseudo-header for VRRPv3 IPv4
    #  as well. Setting this option turns off including the pseudo-header
    #  in the checksum calculation for VRRPv3 IPv4.
    v3_checksum_as_v2 [<BOOL>]

[...]

IETF RTGWG says that upon draft-ietf-rtgwg-vrrp-rfc5798bis becoming RFC it will obsolete RFC5798 so seems that keepalived doesn't correctly interpret the standard by default; if someone needs to run keepalived with other vendors, as per default behavior it will result in something like "ok, keepalived doesn't work with cisco/juniper/.." and the v3_checksum_as_v2 option doesn't seem like the best way to clarify that behavior.

As the same v3_checksum_as_v2 option says and the draft-ietf-rtgwg-vrrp-rfc5798bis confirms, both IPv4 VRRP v2 and IPv4 VRRP v3 do not have the IPv4 pseudo header in the checksum calculation, but keepalived implements it only for VRRP V3 that is a bit hard to understand for me.

In this case, my questions are:
Should keepalived calculate the checksum for a VRRP version 3 IPv4 packet without the pseudo header as default behavior?
We should also change the v3_checksum_as_v2 option to something like vrrp3_ipv4_checksum_with_ph if we want to maintain backward compatibility and document it as well?

Finally, thanks to the IETF RTGWG and the SONiC community for the input.