Hello BIRD team, This patch (for master branch / 2.18) fixes the link-local next hop handling in BGP UPDATE messages sent by BIRD. Currently BIRD includes the link-local address in the IPv6 next hop field unconditionally whenever it is available (on single-hop sessions where the peer is on a directly connected subnet). This affects any address family that carries an IPv6 next hop: IPv6, VPNv6, as well as IPv4 and VPNv4 when using Extended Next Hop encoding (RFC 5549). RFC 2545 Section 3 specifies: "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 practice this causes problems on single-hop sessions where the peer is on a directly connected subnet but the next hop is set to a non-connected address (e.g. a loopback address): some routers reject the UPDATE and close the session when they receive a route carrying a link-local next hop whose global address is not on the shared subnet. This behavior was observed with Cisco IOS XR with VPN SRv6 routes. The fix checks whether the global next hop falls within the connected prefix of the neighbor interface before including the link-local address. Thanks! -- Sébastien