Set 'ipv6: True' on interfaces used for unnumbered IPv6 BGP sessions

[ipspace]

An interface that is used for unnumbered IPv4 EBGP session(s) needs IPv6 LLA (that's how the unnumbered sessions are implemented).

Not a big deal, until someone decides to disable IPv6 by default (I'm looking at you, Cumulus Linux 4.4 container). I "fixed" that SNAFU by enabling IPv6 on interfaces that have role 'external', but it would be much nicer to set ipv6: True on such interfaces within the BGP configuration module.

That might mess up the node address family though (all of a sudden, there would be IPv6 and VPNv6 address families) unless we do it at the very end of the transformation process.

Please note that we have a problem only in IPv4-only environments with interfaces configured either with unnumbered: True or ipv4: True.

The only devices currently supporting unnumbered IPv4 EBGP sessions are Cumulus Linux, FRR, and Nokia SR Linux. Any thoughts on this conundrum @jbemmel @petercrocker?

[jbemmel]

I think the flag should be bgp.unnumbered; if true, it would enable ipv6 on the interface (given the dependency)

I just hit a similar issue through the unnumbered flag; it currently works on frr even with ipv6 absent, because the device templates don't currently disable ipv6 correctly. I'll submit some PRs to fix that (also for Cumulus potentially)

[jbemmel]

See #463

I suspect the reasoning by Cumulus could be that they don't want their devices to do ipv6 unless explicitly configured to do so, for security reasons. In contrast, vanilla FRR enables ipv6 unless forced to disable it (outside of FRR)

[ipspace]

I think the flag should be bgp.unnumbered; if true, it would enable ipv6 on the interface (given the dependency)

I don't want to test yet-another flag in initial configuration (or later) templates. Setting 'ipv6: True' on the interface data gets the job done, but I wouldn't want it to trigger (for example) OSPFv3. Will check what happens if I set that flag late in BGP module.

I just hit a similar issue through the unnumbered flag; it currently works on frr even with ipv6 absent, because the device templates don't currently disable ipv6 correctly. I'll submit some PRs to fix that (also for Cumulus potentially)

The default state depends on the system setting, and as the FRR container serves mostly as a control-plane container (with some of us abusing it as a pure Linux data-plane device), I don't think they would care.

[ipspace]

I suspect the reasoning by Cumulus could be that they don't want their devices to do ipv6 unless explicitly configured to do so, for security reasons. In contrast, vanilla FRR enables ipv6 unless forced to disable it (outside of FRR)

There is no reasoning. IPv6 (LLA) is enabled on all interfaces in Cumulus VX 4.3.0 container and Cumulus VX 4.4.0 VM, but disabled in Cumulus VX 4.4.0 container.