
<html><head></head><body>Hello!<br>This list is generally the right place to post your patches.<br>Thank you for your contribution.<br>Maria<br><br><div class="gmail_quote">On September 11, 2020 10:04:27 PM GMT+02:00, "Gehrkens.IT GmbH | Heiko Wundram" <heiko.wundram@gehrkens.it> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Hey all,<br><br>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 (!<br> 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.<br><br>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!<br> a is used). So: how do I upstream my patches? 😉<br><br>Thanks for any hints and hope that somebody may find this work useful!<br><br>Heiko.<br><br></pre></blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>