Hmm, bridging VRRP interfaces with their parent interface (I hope I got it right) sounds somehow dangerous. Did you test it? I'd be affraid that it would mess up the whole thing.
No, you got it wrong, but my wording wasn't a prototype of clarity either
"To use a bridge between the VRRP and the physical uplink interface" is actually as simple as creating a bridge, making it a carrier (parent) interface for all the vrrp ones instead
of the physical uplink interface (which presumably was their carrier interface before), and then make the physical uplink interface a single slave port of that bridge.
This way it works as such but it is useless for the intended purpose because I haven't realized one thing, DHCPDISCOVER and DHCPREQUEST contain the client MAC address as a mandatory L7 field, i.e. not an Option like the client-id
is, and you cannot change the contents of this field using /interface bridge nat
rules nor using any other means.
So the only advantage of using the bridge is that you can prevent the VRRP multicast packets from leaking out from the 'Tik, but you stay left with just 255 MAC addresses for all clients of this type for the whole area served by the same client database at ISP side.
Regarding use of IPv6, the only advantage is that, as you wrote, you don't have to use a bunch of IPv4 addresses to be statically assigned to the individual VRRP interfaces to allow them to get up, and that you get another pool of 255 MAC addresses to use - 00:00:5E:00:02
xx is used for IPv6 VRRP.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.