link-local IPv6 address in BGP.next_hop

[Ondrej Zajicek]

On Mon, Jan 27, 2025 at 10:37:13PM +0000, Ponikierski, Grzegorz via Bird-users wrote:
> Hello all!
> 
> I have an interesting case of link-local IPv6 address in BGP.next_hop and I would like to know your opinion about that because I cannot tell with 100% confidence if it’s a bug or a feature. Existence of these link-local addresses causes issues of interoperability between Bird and FRR. I have separate discussion about that with FRR folks. Here I would like to now a Bird perspective. Details below.
> 
> On single router with Bird 2.15 I have multiple IPv4 and IPv6 eBGP sessions, which receives prefixes from the Internet, and IPv4 iBGP session, which forwards these prefixes to BGP collector with FRR, which is separate server somewhere in the Internet many hops away in separate ASN. Session with BGP collector uses both ipv4 and ipv6 channels to send both IPv4 and IPv6 prefixes. IPv6 prefixes received via eBGP have both global IPv6 address and link-local IPv6 address like in an example below:
> 
> 
> On one hand, as per RFC 4271 NEXT_HOP is not changed when prefix is
> passed from eBGP to iBGP so what we see above it expected. But on the
> other hand, as per RFC 2545 link-local address must not be there because
> both sides of iBGP doesn’t share the same IPv6 subnet:
> 
> Who is right here? As far I know, both documents are still current
> standards, and both are implemented by Bird. I don’t see any clear
> guidelines how to make a clear judgement here. Personally, I would tell
> that RFC 4271 should be treated as general rule and RFC 2545 as more
> specific rule so in the end link-local should be removed. After all,
> link-local addresses do not make sense for multihop sessions. However,
> these documents don’t refer to each other and I don’t know if authors of
> these documents knew about each other statements. What do you think?

Hello

BIRD prefers to not change the NEXT_HOP when forwarded to IBGP. There are
some reeasons for this:

I think the condition in RFC 2545 makes sense for EBGP, but not for
IBGP, as IBGP sessions are usually terminated on loopback addresses, so
the BGP speaker cannot evaluate from session endpoints whether the peer
shares a common subnet with the nexthop and the speaker.

The condition specifies 'if and only if', so not sending link-local
next hop to a peer that shares a common subnet is contrary to the
condition in the same way as sending link-local next hop to a peer that
do not share a common subnet.

In practice, it is worse to not send link-local next hop when it should
be used than send it when it should not. As the link-local next hop
address is associated with the global next hop address, routers that do
not share a common subnet would use the global next hop to resolve the
next hop in IGP routing table and ignore the link-local one, only the
routers that shares a common subnet would use the link-local address to
construct the route gateway.


For example, lets assume we have routers R0, R1, and R2 on the same
subnet, R0 and R1 in the same AS and connected with IBGP on loopback
addresses, while R0 and R2 have EBGP session. Here, the R1 should clearly
receive link-local next hop so it could install the route to R2 with
link-local next hop in its routing table in the same manner as R0.

While a route reflector may be many hops away, not sharing the common
subnet, and therefore clearly it should not receive link-local next hop
according to the condition in RFC 2545, i think it is an oversight in RFC
2545 to not consider route reflectors, as the RS could send the route
back to a router that shares a common subnet with the next hop.

Lets assume routers R0, R1, and R2 from the example above, but now
instead of IBGP session between R0 and R1, they will be connected through
IBGP sessions to a RR several hops away. One could argue that R1 should
get the same next hop for R2 like if it was connected directly to R0.


OTOH, it is a question whether a common subnet can be clearly identified
from a global next hop address. I could imagine configurations where this
is not true, but that would break even when RFC 2545 condition is
strictly advered, together with IBGP recursive next hop resolution.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."