Add flag for RFC8950 support to networks

[agbcix]

Is your feature request related to a problem? Please describe.

Today many interconnections (transit, PNI, IXP) are using dual-stack (IPv4 and IPv6). While we have plenty IPv6 address space, IPv4 space is scarce. By employing RFC8950 (IPv4 NLRI with IPv6 next-hop; previously RFC5549) we can save IPv4 addresses for transfer networks (and in future IXPs). When looking into PeeringDB, I have no indication whether my partner is able/willing to support RFC8950.

Who is affected by the problem?

All networks operators willing to save on IPv4 address handling for transfer networks.

What is the impact?

More time needed to negotiate how to setup BGP sessions. Networks need to ask peers whether they need to setup IPv4+IPv6 BGP sessions or IPv6 BGP session with extended next-hop capability.

Are there security concerns?

In case of known vulnerabilities affecting BGP implementation in RFC8950 code-path, the information may be used for information gathering.

Are there privacy concerns?

No

Describe the solution you'd like

The API schema for net objects shall be enhanced with a boolean flag "info_ipv4_with_ipv6_nexthop" (I also thought about "info_rfc8950", but RFCs may get deprecated and "info_never_via_route_servers" is of similar length).

In the frontend this flag shall be presented in the "Protocols Supported" section as "IPv4 with IPv6 next hop" with a tool-tip "Network supports RFC8950, Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop".

Do you think this feature will require a formal design?

No. Handling boolean flags and listing those under "Protocols Supported" is well understood.

Describe alternatives you've considered

Since the topic is currently being discussed within the Euro-IX working group with regard to IXP implications, we have also considered extending netixlan object schema (with a flag similar to "is_rs_peer") or ix object schema. Adding it to networks is perceived to be the more generic step -- RFC8950 is even more helpful in PNI scenarios.

Networks with only partial support (e.g. at some PoPs only or all PoP but one) for this feature may or may not want to set the "Protocols Supported" flag. It might be helpful to have a more granular way to express the support. But this issue is true for other protocols.

Could this feature request need support from the Admin Committee?

No, not that I could think of.

What is the proposed priority?

not urgent

Additional context

RFC8950 (and its predecessor RFC5549) have been around. Several networks are using this feature to run BGP unnumbered in their DC fabric. Thus most vendors have implemented support (see test results). So we (Euro-IX RFC8950 working group and other Euro-IX members) believe it's time for a wider adoption for interconnection purposes. The PDB flag may also help in getting awareness.

[arnoldnipper]

+1 .... makes perfect sense to me. And in case of an IX supporting RFC8950, the RS ASN will have the flag turned on. Right?

[agbcix]

And in case of an IX supporting RFC8950, the RS ASN will have the flag turned on. Right?

An IXP fabric does not need to support RFC8950 -- it just needs IPv6 support for bilateral BGP sessions.

And yes, if the IXP route servers support RFC8950 for multilateral peering, the RS ASN shall have this flag enabled.

[paulhoogsteder]

But should this be a network-wide flag? Maybe my routers or provisioning system support this only in certain locations? And I don't see RFC8950 save a single IPv4 address unless exchanges ditch their IPv4 prefix. On PNIs yes it might.

[agbcix]

@paulhoogsteder: I'll try to elaborate on my thought expressed in the initial description.

But should this be a network-wide flag? Maybe my routers or provisioning system support this only in certain locations?

I think this question is very similar to when IPv6 or Multicast were added. Every network will have a different answer to this question. Some will be more conservative than others.

If we had information of every single interconnection router per network in PDB, it would be sensible to attach the information there. But we do not have this information PDB and this question is our-of-scope for this feature request.

Adding the flag to netixlan would not cover PNIs. Adding it to netfac would raise the same question if you have multiple routers in one location.

So I believe a network-wide flag is the best option we have. I am open for other suggestions though.

While thinking about it a bit more, one could use a selection "no", "yes, partly", "yes, mostly", "yes" (or similar) instead of a boolean field. I currently fail to see an added value of the intermediate steps though.

And I don't see RFC8950 save a single IPv4 address unless exchanges ditch their IPv4 prefix.

Short and medium term I totally agree. Thinking 5-10 years ahead, I am positive: Some IXP will outgrow their current IPv4 prefix and need to double the IPv4 space by renumbering. Some might have challenges to afford this (cost or operations wise). If the IXP has a critical mass of RFC8950 enabled peers though, new peers might be able to join RFC8950-only and thus IPv4 is conserved. IXPs are free to use incentives to grow the critical mass -- but this is a different topic.

On PNIs yes it might.

IPv4 conservation is just one feature of RFC8950. It ultimately saves configuration -- one BGP peer instead of two. On PNIs one might even go unnumbered (link-local only, provided the BGP implementations support it). But again, different story.

[martinhannigan]

-1

[as44980]

So while I dont personally see a compelling argument for adding flags in PeeringDB for each potential standard or feature that a peers router may support, it appears that horse has already bolted..

Notably after a proposal to add a BFD flag being reject in 2017, there seems to have been a change of heart in 2023 which resulted in the addition of a BFD flag..

So as RFC 5880 is deserving of its own flag, why not RFC 8950? or perhaps RFC 5082? ;)