link-local IPv6 address in BGP.next_hop

[Ondrej Zajicek]

On Tue, Jan 28, 2025 at 06:17:10PM +0000, Ponikierski, Grzegorz wrote:
> Ondrej, does it mean that I can make statement as below?
> 
> Statement: FRR should accept update with both global address and
> link-local address in NEXT_HOP without any error and put it into
> Adj-RIB-In. If link-local address is reachable (peer-to-peer link) then
> link-local address should be used as next hop in RIB. Otherwise, global
> address should be used. This logical can be reversed with FRR route-map
> action “set ipv6 next-hop prefer-global” which is equivalent of Bird
> channel option “next hop prefer global”.
> 
> Would you agree with such statement? Or I miss some nuances?

The global next hop is used to resolve IGP route, and only when
it is resolved to direct/interface route, it (or link-local one) is used
as a next hop in RIB, otherwise the indirect route next hop is used in
RIB. So i would formulate it this way:

FRR should accept an update with both global address and link-local
address in NEXT_HOP without any error and put it into Adj-RIB-In.
The global address should be used to resolve an IGP route. When it is
resolved to an direct/interface route, the link-local address (or
the global address [*]) should be used as next hop in RIB. When it is
resolved to an indirect IGP route, the next hop from the IGP route should
be used as next hop in RIB (and the link-local address in NEXT_HOP is
ignored).

[*] The global address should be used as next hop in RIB when link-local
address is not available or when it is preferred with FRR route-map
action “set ipv6 next-hop prefer-global” which is equivalent of Bird
channel option “next hop prefer global”.




> From: Ondrej Zajicek <santiago at crfreenet.org>
> Date: Tuesday, 28 January 2025 at 18:32
> To: "Ponikierski, Grzegorz" <gponikie at akamai.com>
> Cc: bird-users <bird-users at network.cz>
> Subject: Re: link-local IPv6 address in BGP.next_hop
> 
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
>   This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
> 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."