Zebra sends Router Advertisements when the extended-nexthop capability is enabled, also without unnumbered BGP

[ichdasich]

Description

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.

Originally posted by @DerEnderKeks in #15994

Version

Confirmed on 9.1.2

How to reproduce

Configure an explicitly addressed neighbor using extended-nexthop capabilities for RFC8950.

Expected behavior

No RAs are sent if extended nexthop is not used with BGP unnumbered

Actual behavior

RAs are being sent, even if BGP unnumbered is not used.

Additional context

This is a serious issue breaking production, as IX ports for affected systems need to be taken down.

The issue was first flagged in May of this year as a discussion point; Filing this as a bug now.

Original discussion: #15994

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[ruben-herold]

After discussion with @ichdasich we found 7738 and 16354. This could fix it

[ichdasich]

Effectively a duplicate of #7738