link-local IPv6 address in BGP.next_hop

[Donatas Abraitis]

> link-local addresses don’t make sense in NEXT_HOP which is highlighted in
RFC 2545.

Correct.

On Tue, Jan 28, 2025 at 4:41 PM Ponikierski, Grzegorz <gponikie at akamai.com>
wrote:

> draft-white-linklocal-capability describes different scenario where BGP
> for point-to-point links can use only link-local addresses in NEXT_HOP
> without need for global addresses. This is nice scenario for data centers.
> However, scenario which I describe refers to multihop sessions across the
> Internet so we don’t have point-to-point links and link-local addresses
> don’t make sense in NEXT_HOP which is highlighted in RFC 2545.
>
>
>
> Regards,
>
> Grzegorz
>
>
>
> *From: *Donatas Abraitis <donatas.abraitis at gmail.com>
> *Date: *Tuesday, 28 January 2025 at 14:38
> *To: *"Ponikierski, Grzegorz" <gponikie at akamai.com>
> *Cc: *"Brandon Z." <Brandon at huize.asia>, bird-users <bird-users at network.cz
> >
> *Subject: *Re: link-local IPv6 address in BGP.next_hop
>
>
>
> All, somehow related topic I see. . Would worth implementing https:
> //datatracker. ietf. org/doc/html/draft-white-linklocal-capability for
> Bird (FRRouting already has it), which might also be a step forward.
> Thanks! On Tue, Jan 28, 2025 at 3: 29
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an Untrusted Sender *
>
> You have not previously corresponded with this sender.
>
> ZjQcmQRYFpfptBannerEnd
>
> All,
>
>
>
> somehow related topic I see.. Would worth implementing
> https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-white-linklocal-capability__;!!GjvTz_vk!VZs3OqGsJcAkeO9NLgeZDp_mULn0oGTqNhX6xk59x0O19JLP4uHExzLrdDs2qtwGg4vy60dkYx7C96kmAp1QlM_D-g$>
> for Bird (FRRouting already has it), which might also be a step forward.
>
>
>
> Thanks!
>
>
>
> On Tue, Jan 28, 2025 at 3:29 PM Ponikierski, Grzegorz via Bird-users <
> bird-users at network.cz> wrote:
>
> 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
> <https://urldefense.com/v3/__http:/23.33.236.254__;!!GjvTz_vk!VZs3OqGsJcAkeO9NLgeZDp_mULn0oGTqNhX6xk59x0O19JLP4uHExzLrdDs2qtwGg4vy60dkYx7C96kmAp3uFzG3gg$>:
> 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
>
> *Error! Filename not specified.*
>
> 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> 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
>
>
>
> --
>
> Donatas
>


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