[RFC] Unnumbered BGP automatic peering based on IPv6 ND

[Maria Matejka]

Hello Matteo!

See inline and below please. TL;DR: We want this but in a different way.

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.

On Mon, Nov 17, 2025 at 11:31:17AM +0100, Matteo Perin wrote:

> Dear BIRD dev-team and community,
> 
> 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.

Indeed it is not.

[...]

> 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).

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.

[...]

> 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.
> 
> 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).
> 
> 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.
> 
> 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.

First of all, there is an interest in having this feature upstream,
please do it, unless you are too scared.

Second, there is a _heavy_ 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.

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.

There is also a BGP Hello draft[1] but it's kinda dusty. That _might_ be
a way to go in future but not now.

Well, how to do this now?

We have an actual interest in receiving the RA's systematically.
With that, the desired path would be:

- update the RAdv protocol so that it can also read RAs
- create route-like objects from the RA contents
- store these objects into a table
- add a new channel type to BGP, probably named like `peers from`
- exporting to that BGP channel (allowed only in dynamic BGP)
  would trigger spawning of a new session
- RA expiration would withdraw the object from the table, possibly
  triggering the BGP session shutdown (unless configured otherwise with
  something like `persist` in the `peers` channel)

This would allow:

- inspecting the received RAs
- filtering them
- using the received RAs for different purposes later on
- implementing different sources for peer discovery later on

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.

Is that a journey you are willing to pursue?

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.

Thank you again for your query.  
Looking forward to hearing from you again.

Maria

[1] https://datatracker.ietf.org/doc/html/draft-xu-idr-neighbor-autodiscovery

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20251118/4e0e220e/attachment.htm>