Hello Maria, thanks for the info, so here’s the patch attached. I’ve not updated the documentation so far, it’s just the plain diff to proto/radv. To describe the functionality of the patch: Routes that are exported to the RA protocol as optimum routes which are unicast device routes (i.e. attrs->iface != NULL, attrs->dest == RTD_DEVICE, attrs->cast == RTS_UNICAST) are considered as prefixes on the interface that they refer to (with the usual prefix configuration options applied), instead of pushing them as routes in the RA. For all other interfaces (i.e., when radv_iface->iface != attrs->iface), they are considered as normal additional routes to announce in the RA. The functionality of considering device routes as prefixes is independent of propagate routes, i.e. the prefix consideration of routes exported to the radv protocol is always done, whereas propagate routes needs to be enabled as before to fill in additional routes in the RAs. When a device route disappears, the prefix that derives from it is timed out according to the default rules set up for the interface. Additionally, a configuration item (trigger filter <bool>) has been added to make it configurable whether a trigger route which has been set up on the radv protocol causes the trigger route to be filtered from the set of routes that the protocol keeps track of for RA purposes, or whether in addition to being the trigger route, the route should be treated as a normal RA route. The default for this option is on for backwards compatability purposes. With trigger filter on, the route that is the trigger route neither takes part in prefix configuration, nor in additional routes propagated to interfaces. With trigger filter off, it takes part in both. The implementation patches radv to always keep the fib buffer of routes that’s normally only used when propagate routes is on, adding an additional field to the route object whether it’s a prefix route, and the interfaces simply walk over the list to find additional prefixes that are configured as device routes when collecting their prefixes. The packet generation takes care to not add routes from the fib as routes to push when either propagate routes is off, or when the route is a prefix route on the interface the ra is being assembled for. Generally, always collecting all exported routes simplifies some parts of the code, as the protocol doesn’t need to refetch routes when propagate routes changes state. As I said in my original mail, the patch has been working fine in a test environment for me so far. I can split up the patch into several hunks if requested, but I’ve now collapsed it into one for the mail, the complexity shouldn’t be overwhelming, as it’s actually not that much code difference. Thanks for any feedback and if there’s interest in this functionality to be included upstream, I’d be grateful! Heiko. Von: Maria Matějka <maria.matejka@nic.cz> Gesendet: Freitag, 11. September 2020 22:18 An: bird-users@network.cz; Gehrkens.IT GmbH | Heiko Wundram <heiko.wundram@gehrkens.it>; bird-users@network.cz Betreff: Re: Where to post patches to bird for making radv more useful? Hello! This list is generally the right place to post your patches. Thank you for your contribution. Maria On September 11, 2020 10:04:27 PM GMT+02:00, "Gehrkens.IT GmbH | Heiko Wundram" <heiko.wundram@gehrkens.it<mailto:heiko.wundram@gehrkens.it>> wrote: Hey all, I’ve played around with bird a bit (which we use as a routing daemon, mainly for OSPF and BGP), and found the RADV-functionality lacking, as it's currently (at least with the 1.6 release where we're on due to Debian, and also from the documentation of 2.0 this seems not to have changed) impossible to inject additional prefixes into the router advertisement messages than those from the addresses that are set up on the interface that's managed by RA. This is a problem on routers which do radv through bird, as this means that they need an IP address from the corresponding prefixes on every interface that is to have radv enabled and makes their (source) addressing unpredictable with respect to firewall configuration and (e.g.) anycast targets. To remedy this, I thought that I'd just reconfigure the network to just have device routes to the corresponding IPv6 prefixes on their respective interfaces, without actually configuring an address on the gateway, which generally works (! and is also the way that I learnt to set up IPv6), but in this case, bird doesn't pick up the corresponding prefixes anymore which makes radv (rather: SLAAC) unusable. I've patched exactly this functionality (i.e., picking up device routes pushed to the protocol through the export filter and using them to configure prefixes on the interface that they are attached to) and additionally also the possibility to configurably NOT filter the trigger route (which the current implementation always does, and I generally understand the reason, but sometimes you still don't want this) into bird 1.6.8, and AFAICT from my preliminary tests, the patch seems to be stable. To make it available to others (I guess that my experience with radv needing work hasn't been unique), I'd like to upstream the patch. I thought about using Github, but the BIRD repository there doesn't seem to be maintained/synchronized with the actual repository at gitlab.nic.cz (the mirror URL is broken), so I can't push any patches to 1.6.8 there. Additionally, I've registered an account on gitlab.nic.cz, which worked, but it seems I don't have any rights to fork the project (my quot! a is used). So: how do I upstream my patches? 😉 Thanks for any hints and hope that somebody may find this work useful! Heiko. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.