<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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:</div><div></div><div>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)<br>2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid route <a href="http://45.91.12.0/24">45.91.12.0/24</a> withdrawn<br></div><div><br></div><div>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.</div><div><br></div><div>So I've been thinking how to avoid the situation we are in and came up with two potential approaches:</div><div><ol><li>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.</li><li>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.</li></ol><div>Currently I only see "require extended next hop" switch, but to my understanding this will tear down the BGP session -- which is undesirable.</div><div><br></div><div>Does anyone have other good ideas?</div><div><br></div><div>BTW: It's not very intuitive to understand from the above error messages that the announcement is egress. :)</div><div><br></div><div>Best wishes,</div><div>André</div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>