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 https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html. 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 Additional thoughts section at the bottom, as it tries to ask for opinions on a somewhat complex topic of unnumbered point-to-point interfaces in VPP.

On the VPP side, I have a small change (https://gerrit.fd.io/r/c/vpp/+/40482) 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.

In the article above, I mentioned in Approach 3,

One option is to ask Babel to use extended next hop 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).

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 always prefers IPv4 when it's set.

My question: would it be feasible to extend the configuration syntax of extended next hop to also allow keyword always, 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.

I can attempt a patch if the Bird (and Babel) community believes this is a useful behavior.

groet,
Pim