<!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>