<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-PL" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="PL" style="font-size:11.0pt">Hello all!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="PL" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> via 2600:1488:6080::8 on ae2<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> Type: BGP univ<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.origin: IGP<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.as_path: 3356<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.med: 4294967294<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.local_pref: 60<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">However, prefixes forwarded via iBGP to BGP collector also have both global and link-local addresses like below:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> via 2600:1488:6080::8 on ae2<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> Type: BGP univ<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.origin: IGP<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.as_path: 3356<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.med: 4294967294<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.local_pref: 60<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) (21357,600)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="PL" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">“””<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><span style="font-size:11.0pt"> The link-local address shall be included in the Next Hop field if and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> only if the BGP speaker shares a common subnet with the entity<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> identified by the global IPv6 address carried in the Network Address<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> of Next Hop field and the peer the route is being advertised to.</span><span lang="PL" style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> In all other cases a BGP speaker shall advertise to its peer in the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Network Address field only the global IPv6 address of the next hop<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> (the value of the Length of Network Address of Next Hop field shall<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> be set to 16).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">“””<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Anyway, when BGP collector with FRR
</span><span style="font-size:11.0pt;color:black">8.5.2</span><span style="font-size:11.0pt;color:black">
</span><span lang="EN-US" style="font-size:11.0pt">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 (</span><span style="font-size:11.0pt">UPDATE Message Error/Invalid Network Field</span><span lang="EN-US" style="font-size:11.0pt">) and session goes down. I cannot rule out implementation bug in FRR version that I use, and I discuss it with
FRR folks already.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">What do you think? It’s a bug or a feature?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;color:black;mso-ligatures:none;mso-fareast-language:EN-GB">Regards,</span><span style="font-size:11.0pt;color:black;mso-ligatures:none;mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black;mso-ligatures:none">Grzegorz</span><o:p></o:p></p>
</div>
</body>
</html>