Hoi folks, By means of context, I am working on allowing VPP and Bird2/Babel to program the routing table with IPv6 nexthops for IPv4 destinations. 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 <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 -- Pim van Pelt PBVP1-RIPE -https://ipng.ch/