Hello André!

First, I'm curious to know which BGP daemons and vendors exhibit the behavior you mentioned.
When I read it, I assumed it was something quite old behavior.

Also, while reading, looking at the relationship between IPv6/IPv4 and MAC, I had some intrusive thoughts like:
"Wouldn't EVPN have some use here?" But I quickly erased that from my mind. #BaDumTis

Now thinking about a workaround, assuming the IPv4 MAC will be the same as the IPv6 MAC, couldn't we force the rewriting of this next-hop with some hard-police-routing enforcement?

Em qui., 21 de ago. de 2025 às 10:29, André Grüneberg <andre.grueneberg@bcix.de> escreveu:

Hi,

We have lately enabled RFC8950 (BGP IPv4 routes with IPv6 nexthop) on (one of) our route servers. We did this for all the connected peers.

This means two things: We added ipv4 channels to "protocol bgp"s with an IPv6 neighbor and we enabled "extended next hop" in these channels. This will announce IPv4 and the respective extended next hop capability in BGP OPEN.

In an ideal world all existing peers would only have IPv6 AFI enabled on their IPv6 BGP sessions. Unfortunately some BGP implementations by default have proxy-arp^WIPv4 AFI enabled for all neighbors. So we ended up with some peers announcing IPv4 AFI but not "extended next hop".

Obviously Bird now tries to send those peers all the IPv4 routes it has in the routing table. Since the route server is transparent, the routes have an IPv6 next-hop and thus we get the following error messages:
2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid NEXT_HOP attribute - mismatched address family (2001:7f8:19:1:0:3:48d2:1 for ipv4)
2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid route 45.91.12.0/24 withdrawn

Of course I'll try to educate people to correct their configuration to get closer to the ideal world above. At the same time, I'd love to avoid those error messages.

So I've been thinking how to avoid the situation we are in and came up with two potential approaches:
Since all session are configured in passive mode, the neighbors should send their BGP OPEN first. So upon receiving IPv4 AFI without receiving "Extended next hop - IPv6 nexthop: ipv4" we will remove IPv4 AFI from our BGP OPEN answer.
If we had the negotiated protocol capabilities available in the export filter, we could filter IPv4 routes with IPv6 nexthop in case extended next hop is not negotiated.
Currently I only see "require extended next hop" switch, but to my understanding this will tear down the BGP session -- which is undesirable.

Does anyone have other good ideas?

BTW: It's not very intuitive to understand from the above error messages that the announcement is egress. :)

Best wishes,
André

--
André Grüneberg, Managing Director
andre.grueneberg@bcix.de
+49 30 2332195 42
BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany
Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B