<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<style>
html {
line-height: 1.2;
font-family: serif;
font-size: 0.9em;
color: black;
background-color: white;
}
body {
margin: 0;
margin-right: auto;
max-width: 36em;
padding: 1em;
hyphens: auto;
overflow-wrap: break-word;
text-rendering: optimizeLegibility;
font-kerning: normal;
}
@media print {
body {
background-color: transparent;
color: black;
font-size: 11pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
p {
margin: 1em 0;
}
a {
color: black;
}
a:visited {
color: black;
}
img {
max-width: 100%;
}
h1, h2, h3, h4, h5, h6 {
margin-top: 1.4em;
}
h5, h6 {
font-size: 1em;
font-style: italic;
}
h6 {
font-weight: normal;
}
ol, ul {
padding-left: 1.7em;
margin-top: 1em;
}
li > ol, li > ul {
margin-top: 0;
}
blockquote {
margin: 0.5em;
padding-left: 0.5em;
border-left: 2px solid #e6e6e6;
color: #444;
}
code {
font-family: 'Lucida Console', monospace;
font-size: 95%;
margin: 0;
}
pre {
margin: 1em 0;
overflow: auto;
max-width: unset;
width: fit-content;
}
pre code {
padding: 0;
overflow: visible;
overflow-wrap: normal;
max-width: unset;
white-space: pre-wrap;
}
pre code span {
white-space: pre;
}
.sourceCode {
background-color: transparent;
overflow: visible;
}
code.diff span.kw,
code.diff span.dt {
font-weight: bold;
}
code.diff span.va {
background-color: rgba(192, 255, 192, 64);
color: rgb(0, 64, 0);
}
code.diff span.st {
background-color: rgba(255, 192, 192, 64);
color: rgb(64, 0, 0);
}
pre.diff {
background-color: rgb(240, 240, 240);
padding: 0.4em;
border: 1pt solid grey;
}
hr {
background-color: black;
border: none;
height: 1px;
margin: 1em 0;
}
table {
margin: 1em 0;
border-collapse: collapse;
width: 100%;
overflow-x: auto;
display: block;
font-variant-numeric: lining-nums tabular-nums;
}
table caption {
margin-bottom: 0.75em;
}
tbody {
margin-top: 0.5em;
border-top: 1px solid black;
border-bottom: 1px solid black;
}
th {
border-top: 1px solid black;
padding: 0.25em 0.5em 0.25em 0.5em;
}
td {
padding: 0.125em 0.5em 0.25em 0.5em;
}
header {
margin-bottom: 4em;
text-align: center;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
q { quotes: "„" "”" "»" "«"; }
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
</head>
<body>
<p>Hello Matteo!</p>
<p>See inline and below please. TL;DR: We want this but in a different
way.</p>
<p>Thank you so much for writing this meesage. This is exactly the right
way to go when implementing something new which needs a design
process.</p>
<p>On Mon, Nov 17, 2025 at 11:31:17AM +0100, Matteo Perin wrote:</p>
<blockquote>
<p>Dear BIRD dev-team and community,</p>
<p>By looking at the project code (and corroborated by this [0] earlier
RFC) it seems that currently the feature of auto-discovering BGP
neighbors leveraging the IPv6 ND protocol is not currently fully
supported by BIRD. I would like to start working on a patch proposal to
close this gap.</p>
</blockquote>
<p>Indeed it is not.</p>
<p>[…]</p>
<blockquote>
<p>There is also the dynamic BGP implementation which seems useful for
the purpose of achieving dynamic connections based on received RAs. The
problem is that dynamic BGP works in a passive/reactive model only, as
it waits for peers within a specified range to connect, an idea would be
to integrate with this implementation but also trigger a peer connection
on a RA arrival (after checking if the advertised IP is within the
desired range).</p>
</blockquote>
<p>Well, the dynamic BGP implementation is kinda already hack-ish
itself, and this seems to be kinda hack-hack-ish. It would probably work
the way you propose, yet we don’t like mixing RAdv into BGP.</p>
<p>[…]</p>
<blockquote>
<p>This idea for the implementation is the one that reuses as much of
the current codebase while introducing as little new procedures as
possible that I could come up with, but I think it can still be refined
with more insight with the internals.</p>
<p>One thing that I am not sure about is the introduction of a new
socket and connected logic on the BGP module, but I cannot really find
an alternative. There is already an implementation of a packet engine
for RAs that could maybe be reused for the processing of the ICMPv6
packets, but I think it will be easier to decouple the logic and
implement everything on the BGP state machine (even if it will mean some
code duplication, which is not ideal).</p>
<p>Another variant could be establishing a connection for every
discovered address, as in the case of incoming connections for the
dynamic BGP implementation. Maybe this is a more general solution, but
since the current implementation expects an incoming request it will
maybe introduce too much logic to try and fit it in.</p>
<p>Let me know your opinion on if and if it seems a proper way to
proceed (and, of course, if there is any interest in having this feature
upstream). Thank you in advance for your time and feedback.</p>
</blockquote>
<p>First of all, there is an interest in having this feature upstream,
please do it, unless you are too scared.</p>
<p>Second, there is a <em>heavy</em> interest in having this feature
RFC’d, and as Molly wrote, there are already FRR and Nokia
implementations. For me, it looks like it is a good way to go on the
network side, at least for now.</p>
<p>I’m also going to ping the FRR people about possibly RFC-ing this
behavior, but that’s out of scope of this e-mail.</p>
<p>There is also a BGP Hello draft[1] but it’s kinda dusty. That
<em>might</em> be a way to go in future but not now.</p>
<p>Well, how to do this now?</p>
<p>We have an actual interest in receiving the RA’s systematically. With
that, the desired path would be:</p>
<ul>
<li>update the RAdv protocol so that it can also read RAs</li>
<li>create route-like objects from the RA contents</li>
<li>store these objects into a table</li>
<li>add a new channel type to BGP, probably named like
<code>peers from</code></li>
<li>exporting to that BGP channel (allowed only in dynamic BGP) would
trigger spawning of a new session</li>
<li>RA expiration would withdraw the object from the table, possibly
triggering the BGP session shutdown (unless configured otherwise with
something like <code>persist</code> in the <code>peers</code>
channel)</li>
</ul>
<p>This would allow:</p>
<ul>
<li>inspecting the received RAs</li>
<li>filtering them</li>
<li>using the received RAs for different purposes later on</li>
<li>implementing different sources for peer discovery later on</li>
</ul>
<p>I would suppose that this machinery might be better to do in BIRD 3
only, considering that the dynamic spawning has seen some changes
between 2 and 3. Also, in BIRD 3 the channel can be unidirectional, in
this case export only for BGP and import only for the RAdv protocol.</p>
<p>Is that a journey you are willing to pursue?</p>
<p>Feel free to ask more questions or request clarifications. There are
definitely some rough corners one would need to navigate, and I have not
checked the whole path for dangerous elements. No refactoring should be
needed, though.</p>
<p>Thank you again for your query.<br />
Looking forward to hearing from you again.</p>
<p>Maria</p>
<p>[1]
https://datatracker.ietf.org/doc/html/draft-xu-idr-neighbor-autodiscovery</p>
<p>–<br />
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</body>
</html>