link-local IPv6 address in BGP.next_hop

[Brandon Z.]

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://huize.asia/>| www.ixp.su | Twitter

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250128/cc3e07e3/attachment.htm>