[PATCH 0/4] BGP unnumbered automatic peering based on IPv6 ND

[Matteo Perin]

Dear BIRD dev-team and community,

This is a patch proposal spawned from the discussion in a previous mailing list thread [0], regarding how to achieve automatic BGP peering establishment using the IPv6 Neighbor Discovery mechanism.

Over the last few weeks, I worked on implementing the feature with the outline Maria Matejka kindly provided.
As expected, it proved to be quite challenging, especially when it came to integrate the peer discovery approach with the current dynamic BGP implementation.

To briefly summarize the implemented automatic peering mechanism and added capabilites:

  - The ability for the RAdv protocol to receive and read incoming ICMPv6 RAs was added.
  - Route-like objects, containing RAs data are created, based on advertisments detections. These are stored in a new kind of routing table.
  - Lifetime of the objects in the table is determined by the ICMPv6 RA Router Lifetime field. RA expiration will remove the object from the table.
  - The discovery process is enabled only if a new neighbor discovery option is enabled in the RAdv protocol configuration.
  - A new channel was added to the BGP protocol called peers.
  - When present in the BGP configuration, an export to this BGP channel (allowed only in dynamic BGP) will trigger the spawn of a new session.
  - Withdrawal the object from the peers routing table will trigger the corresponding BGP session shutdown.
  - An automatic BGP session can be made permanent via configuration with a persist option in the peers channel.

To test the main functionality of this feature it I used multiple VMs linked by a bridge with BIRD setup on all of them.
BGP session establishment is successful between all routers even with a very minimal configuration.
I will provide an example, so you can also see the new configuration parameters in action:

  protocol device {
  }

  peer table nd_peers;

  protocol radv radv1 {
      peer {
          table nd_peers;
      };

      interface "enp5s0" {
          max ra interval 60;
          min ra interval 20;

          # Enable neighbor discovery on this interface
          # When enabled, BIRD will parse incoming RAs and store router info
          neighbor discovery yes;
      };
  }

  protocol bgp bgp1 {
      dynamic name "bgp_peer";
      dynamic name digits 3;
      local as 65000;
      neighbor range fe80::/12 external;  # Link-local range for BGP unnumbered

      # Peers channel for importing peer discoveries and spawning sessions
      peers {
          # Interface for BGP session establishment
          from "enp5s0";
          # Persist sessions on route withdrawal
          persist yes;
          table nd_peers;
          import all;
          export all;
      };

      ipv4 {
          import all;
          export all;
      };
      ipv6 {
          import all;
          export all;
      };
  }

Of course, I have some concerns about some design choices and code optimization, I tried to find the best solution that did not involve major refactorings or moving code around and some comments on how to improve rough edges from people more experienced on the current codebase would be really appreciated.
Mostly, the two main points I am not entirely happy about are:
  - How I handled the RAs staleness mechanism based on router lifetime.
    I looked for it but there does not seem to be a per-route staleness mechanism already in place, so I resorted to adding a check for expired entries when the RAdv protocol timer is triggerd, which is not ideal.
  - The mechanism to avoid spawning multiple sessions when both dynamic BGP and this new feature are both configured.
    For now, I try looking for BGP session with the same remote peer address and give precedence to the ones spawned by the dynamic BGP mechanism, but I am quite sure it is possible to find a better solution for this.

I tried to make the commit messages both informative and concise, but please ask if something is unclear or missing.

I am still working on adding documentation and automated testing, but since I think the discussion about the implemetation is more useful with actual code in hand, I decided to send the main bulk of the patch right now and amend this later along with changes addressing incoming reviews.
I hope you will appreciate the work done.

Best Regards,
Matteo

[0] https://bird.network.cz/pipermail/bird-users/2025-November/018482.html

Matteo Perin (4):
  Nest: Add net_peer route type to track discovered peers
  RAdv: Add neighbor discovery based on incoming RAs to RAdv proto
  BGP: Move postponed socket reloop logic from start to start_locked to
    achieve locking requirements
  BGP: Add peers channel and sessions spawn on export to achieve
    automatic peering

 lib/net.c            |  16 ++++
 lib/net.h            |  31 ++++++-
 nest/config.Y        |   3 +-
 nest/proto.c         |   2 +-
 proto/bgp/attrs.c    |  57 +++++++++++++
 proto/bgp/bgp.c      | 187 +++++++++++++++++++++++++++++++++++++++----
 proto/bgp/bgp.h      |  28 ++++++-
 proto/bgp/config.Y   |  15 +++-
 proto/bgp/packets.c  |  11 +++
 proto/radv/config.Y  |   3 +-
 proto/radv/packets.c |  41 +++++++++-
 proto/radv/radv.c    | 163 ++++++++++++++++++++++++++++++++++++-
 proto/radv/radv.h    |   4 +
 13 files changed, 533 insertions(+), 28 deletions(-)

-- 
2.43.0