<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Vorformatiert Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLVorformatiertZchn
{mso-style-name:"HTML Vorformatiert Zchn";
mso-style-priority:99;
mso-style-link:"HTML Vorformatiert";
font-family:Consolas;}
span.E-MailFormatvorlage20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hello Maria,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks for any feedback and if there’s interest in this functionality to be included upstream, I’d be grateful!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:Consolas;color:#1F497D">Heiko.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>Von:</b> Maria Matějka <maria.matejka@nic.cz> <br>
<b>Gesendet:</b> Freitag, 11. September 2020 22:18<br>
<b>An:</b> bird-users@network.cz; Gehrkens.IT GmbH | Heiko Wundram <heiko.wundram@gehrkens.it>; bird-users@network.cz<br>
<b>Betreff:</b> Re: Where to post patches to bird for making radv more useful?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hello!<br>
This list is generally the right place to post your patches.<br>
Thank you for your contribution.<br>
Maria<o:p></o:p></p>
<div>
<p class="MsoNormal">On September 11, 2020 10:04:27 PM GMT+02:00, "Gehrkens.IT GmbH | Heiko Wundram" <<a href="mailto:heiko.wundram@gehrkens.it">heiko.wundram@gehrkens.it</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<pre style="margin-bottom:12.0pt">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? <span style="font-family:"Segoe UI Emoji",sans-serif">😉</span><br><br>Thanks for any hints and hope that somebody may find this work useful!<br><br>Heiko.<o:p></o:p></pre>
</blockquote>
</div>
<p class="MsoNormal"><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.<o:p></o:p></p>
</div>
</body>
</html>