Why does Zebra send Router Advertisements when the extended-nexthop capability is enabled?

[DerEnderKeks]

When enabling the extended-nexthop capability, Zebra sends Router Advertisements on the related interfaces. This seems to be intentional:

frr/bgpd/bgpd.c

Lines 4916 to 4933 in b3600d8

	/*
	* For the extended next-hop encoding flag we need to turn RAs
	* on if flag is being set, but only turn RAs off if the flag
	* is being unset on this peer and if this peer is a member of a
	* peer-group, the peer-group also doesn't have the flag set.
	*/
	if (flag == PEER_FLAG_CAPABILITY_ENHE) {
	if (set) {
	bgp_zebra_initiate_radv(peer->bgp, peer);
	} else if (peer_group_active(peer)) {
	if (!CHECK_FLAG(peer->group->conf->flags,
	flag) &&
	!peer->conf_if)
	bgp_zebra_terminate_radv(peer->bgp,
	peer);
	} else
	bgp_zebra_terminate_radv(peer->bgp, peer);
	}

I'm curious why this is done, as it causes issues with SLAAC clients when something else also sends RAs (like radvd). Specifically this has been plaguing me on my VyOS router (related issue: https://vyos.dev/T4923), where it's causing clients with mediocre IPv6 stacks (Android) to loose their IPv6 connectivity periodically.

I couldn't really find anything explaining why FRR sends its own RAs. RFC5549 doesn't seem to mention RAs either.

[ton31337]

Because of BGP unnumbered. They use RAs.

[ichdasich]

Unnumbered is not strictly necessary for v4 with v6 nexthop. As such, RA should only be sent if extended nexthop is configured with unnumbered.

[ichdasich]

Filed as an issue: #17051