For the VRRP group running IPv6 you need 'vrrp_version 3' at least in the keepalived config.

The RFC compatibility may be required by some. The behavior for a RFC compatible configuration is to use the MAC address specified in the RFC for the Virtual IP. The ARP entry in other systems on the network segment will be valid also after a failover. Without RFC compatibility the MAC of the interface is used, and the ARP must be changed in the devices on the network. Gratuitous ARP is used to notify the devices on the segment where a failover occurs.

If we want a solution with interop requirements to other systems than VyOS i think we should implement the RFC compatible part.

@aopdal I agree it would be nice to have RFC compatibility, but when it was introduced, it relied upon a kernel hack that never made it into the mainline. If mainline keepalived and kernel do not support it, and we cannot add support for it that can be merged into the mainline, then it's more trouble than it's worth I think.
Cross-vendor VRRP is more of a hypothetical situation than a common setup.

RFC compatibility settings prevents VRRP from working on Hyper-V because of promiscuous on NICs
Without the RFC compatibility this is working fine.

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml The new syntax draft.

I have not included the RFC compatibility option since it still needs research.

An interesting question: should we use VRIDs for group "names", or rather allow arbitrary, descriptive group names and make VRID a separate option?
As per the RFC, VRIDs must be unique within a LAN (i.e. datalink layer segment), but can be reused in different LANs. Assuming keepalived supports non-unique VRIDs (needs testing), what do you think?

Hey @aibanez @csalcedo your input here is welcome :)

for me vrid as option looks more logic, however, we can do description as an option too so no big difference

One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

Fourth, it was only introduced in 1.2.0, so it's highly unlikely that anyone has it in production.