link-local IPv6 address in BGP.next_hop

Tue Jan 28 14:27:19 CET 2025

I see I missed one detail which can be confusing. Problem is with sending link-local address from Bird to BGP speaker on remote side and this link-local doesn’t make sense for remote side because they don’t share common subnet. Belove how it looks like from FRR perspective.

FRR: 2025/01/17 23:27:48 BGP: [PS8NX-WWXPH] 23.33.236.254 sent a v6 LL next-hop and there's no peer interface information. Hence, withdrawing
FRR: 2025/01/17 23:27:48 BGP: [RWQFK-BA2JR][EC 33554488] 23.33.236.254: Attribute MP_REACH_NLRI, parse error - treating as withdrawal
FRR: 2025/01/17 23:27:48 BGP: [QWG8G-NT6EJ][EC 33554455] 23.33.236.254(Unknown) rcvd UPDATE with errors in attr(s)!! Withdrawing route.
FRR: 2025/01/17 23:27:48 BGP: [XC334-3GAQ8][EC 33554455] 23.33.236.254 [Error] Update packet error (wrong prefix length 64 for afi 1)
FRR: 2025/01/17 23:27:48 BGP: [HJP7M-20X19][EC 33554455] 23.33.236.254 [Error] Error parsing NLRI
FRR: 2025/01/17 23:27:48 BGP: [HZN6M-XRM1G] %NOTIFICATION: sent to neighbor 23.33.236.254 3/10 (UPDATE Message Error/Invalid Network Field) 0 bytes

Regards,
Grzegorz

From: "Brandon Z." <Brandon at huize.asia>
Date: Tuesday, 28 January 2025 at 01:58
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

Hi Grzegorz, I don’t quite understand what you mean, but maybe someone else can. It seems like it announced a non-existent local-link address to another router? Best, Brandon Z. HUIZE LTD www. huize. asia | www. ixp. su | Twitter This e-mail and
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Hi Grzegorz,

I don’t quite understand what you mean, but maybe someone else can. It seems like it announced a non-existent local-link address to another router?

Best,
Brandon Z.
HUIZE LTD
www.huize.asia <https://urldefense.com/v3/__https:/huize.asia/__;!!GjvTz_vk!XyivVwgDc3QoWIOFFzClG1jQBYTYBXjPwglViKFx1CYU9iKVGrPgPRPToOkKRYoLldMsfMchRyjWkXIqjQ$> | www.ixp.su<https://urldefense.com/v3/__https:/www.ixp.su/__;!!GjvTz_vk!XyivVwgDc3QoWIOFFzClG1jQBYTYBXjPwglViKFx1CYU9iKVGrPgPRPToOkKRYoLldMsfMchRyg1_-iFlg$> | Twitter
[Image removed by sender.]
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

On Tue, 28 Jan 2025 at 01:44, Ponikierski, Grzegorz via Bird-users <bird-users at network.cz<mailto:bird-users at network.cz>> 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:

::/0                 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i]
                via 2600:1488:6080::8 on ae2
                Type: BGP univ
                BGP.origin: IGP
                BGP.as_path: 3356
                BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d
                BGP.med: 4294967294
                BGP.local_pref: 60
                BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356)

However, prefixes forwarded via iBGP to BGP collector also have both global and link-local addresses like below:

::/0                 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i]
                via 2600:1488:6080::8 on ae2
                Type: BGP univ
                BGP.origin: IGP
                BGP.as_path: 3356
                BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d
                BGP.med: 4294967294
                BGP.local_pref: 60
                BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) (21357,600)

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:

“””
   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.
   In all other cases a BGP speaker shall advertise to its peer in the
   Network Address field only the global IPv6 address of the next hop
   (the value of the Length of Network Address of Next Hop field shall
   be set to 16).
“””

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?

Anyway, when BGP collector with FRR 8.5.2 receives BGP UPDATE for route like presented above, then FRR rejects such UPDATE with treat-as-withdrawn approach but also triggers additional error about invalid prefix length for AFI 1, which finally causes NOTIFICATION (UPDATE Message Error/Invalid Network Field) and session goes down. I cannot rule out implementation bug in FRR version that I use, and I discuss it with FRR folks already.

Working workaround that I tested is to apply `next hop self` on Bird side. Probably `bgp_next_hop = bgp_next_hop` in Bird’s export policy will also work but I must test it yet.

What do you think? It’s a bug or a feature?

Regards,
Grzegorz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250128/80f5667c/attachment.htm>