link-local IPv6 address in BGP.next_hop

Wed Jan 29 18:39:16 CET 2025

I’m convinced with your statement. I will share it with my FRR friend and see if it is convincing also to FRR.

Thanks :)

Regards,
Grzegorz

From: Ondrej Zajicek <santiago at crfreenet.org>
Date: Tuesday, 28 January 2025 at 19:49
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 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<mailto:santiago at crfreenet.org>>
Date: Tuesday, 28 January 2025 at 18:32
To: "Ponikierski, Grzegorz" <gponikie at akamai.com<mailto:gponikie at akamai.com>>
Cc: bird-users <bird-users at network.cz<mailto: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<mailto:santiago at crfreenet.org>)
"To err is human -- to blame it on a computer is even more so."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250129/a1de618c/attachment.htm>