<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div>Hoi folks,<br>
<br>
By means of context, I am working on allowing VPP and Bird2/Babel
to program the routing table with IPv6 nexthops for IPv4
destinations.<br>
<br>
</div>
<div>I finished a few small code changes in VPP to allow
transit-net-less transport of IPv4 and IPv6 in VPP and wrote about
it on <a
href="https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html"
target="_blank"
data-saferedirecturl="https://www.google.com/url?q=https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html&source=gmail&ust=1710101777652000&usg=AOvVaw37oBRHd26W0c5EtaNtzwF8">https://ipng.ch/s/articles/<wbr>2024/03/06/vpp-babel-1.html</a>.
Considering this dataplane has some different idioms than Linux,
it took a bit of work. I thought you might find this VPP + Bird2 +
Babel story from the field interesting. I wanted to ask you to
read the article, and in particular the <i>Additional thoughts</i>
section at the bottom, as it tries to ask for opinions on a
somewhat complex topic of unnumbered point-to-point interfaces in
VPP.<br>
<br>
On the VPP side, I have a small change
(<a class="moz-txt-link-freetext" href="https://gerrit.fd.io/r/c/vpp/+/40482">https://gerrit.fd.io/r/c/vpp/+/40482</a>) that builds support for
point-to-point over Ethernet. With this approach, VPP will copy
the IPv4 and IPv6 address over from a loopback interface to the
ethernet transit networks.<br>
<br>
In the article above, I mentioned in <i>Approach 3</i>,<br>
<br>
<blockquote>One option is to ask Babel to use <code
class="language-plaintext highlighter-rouge">extended next hop</code>
even when IPv4 is available, which would be a
change to Bird (and possibly a violation of the Babel
specification, I should read up on that).<br>
</blockquote>
<br>
I don't think it's a violation of the Babel protocol to use IPv6
next hops when an IPv4 address is present. However, I noticed that
in proto/babel/babel.c function babel_send_update_() the protocol
<i>always</i> prefers IPv4 when it's set.<br>
<br>
My question: would it be feasible to extend the configuration
syntax of <i>extended next hop</i> to also allow keyword <i>always</i>,
in which case the IPv6 nexthop is preferred even if an IPv4
address is present? The logic in proto/babel/babel.c 1039-1950
seems straight-forward to adapt to this case, in a non-intrusive
way. <br>
<br>
I can attempt a patch if the Bird (and Babel) community believes
this is a useful behavior.<br>
<br>
groet,<br>
Pim<br>
<br>
</div>
<pre class="moz-signature" cols="72">--
Pim van Pelt
PBVP1-RIPE - <a class="moz-txt-link-freetext" href="https://ipng.ch/">https://ipng.ch/</a></pre>
</body>
</html>