Hi This is surprising but documented behavior: The prefix definition matching is done in the first-match style, when interface-specific definitions are processed before global definitions. As expected, the prefix definition is matching if the network prefix is a subnet of the prefix in prefix definition. It is first-match, not longest-match, as one might expect. The network prefix 2001:910:1320::1/128 matches the first prefix definition 2001:910:1320:0::/64 and thus skips the second definition. You could make it work by specifying the prefixes in reverse order: interface "eth0" { prefix 2001:910:1320::1/128 { skip yes; }; prefix 2001:910:1320:0::/64 { autonomous on; }; ... }; OTOH, i am not sure if announcing anything other than /64 is even valid per RFC 4861/4862, so perhaps it is a bug in BIRD to even consider /128 prefix for announcement. On Sat, Oct 17, 2026 at 06:58:51PM +0200, Arnaud Gomes-do-Vale via Bird-users wrote:

Hi,

I have a Linux machine (Devuan excalibur running in a LXC container if this matters) with the following IPv6 configuration:

2: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0 inet6 2001:910:1320::1/128 scope global valid_lft forever preferred_lft forever inet6 2001:910:1320::252/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1:c0ff:fe04:243/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 5: net6@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0 inet6 2001:910:1320:6::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2e:e2ff:fe18:2a46/64 scope link proto kernel_ll valid_lft forever preferred_lft forever

This machine is running BIRD with a radv protocol set up as follows:

protocol radv { interface "eth0" { prefix 2001:910:1320:0::/64 { autonomous on; }; prefix 2001:910:1320::1/128 { autonomous no; onlink no; skip yes; valid lifetime 0; preferred lifetime 0; }; min ra interval 30; max ra interval 90; solicited ra unicast; }; interface "net6" { link mtu 1420; prefix 2001:910:1320:6::/64 { autonomous on; }; solicited ra unicast; rdnss { ns 2001:910:1320:0:XXXXXXX; ns 2001:910:1320:0:YYYYYYY; }; dnssl { domain "glou.org"; }; }; }

No matter what exact combination of options I pass to the radv protocol, the RAs BIRD sends on interface eth0 still advertise prefix 2001:910:1320::1/128, with both valid and preferred lifetimes set to 86400 seconds.

This is not an issue in general except for NetBSD client machines which interpret this advertisment literally and grab address 2001:910:1320::1; of course this tends to cause issues on the network.

Tested with BIRD 2.17.5 from up-to-date Devuan excalibur and with latest 2.20.0 package.

Is there a way to prevent BIRD from advertising the /128 subnet and only have it advertise the /64, or is this a bug in BIRD?

-- Arnaud

-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."