I had the lab open and figured I’d take a crack at this.
I get unexpected behavior also, although in a slightly different way. Whether I use synchronize=no or synchronize=yes plus a static tie-down route, the 1.2.3.0/24 address does show up in /routing bgp advertisements for me. All is not well, though, as it shows up with a next hop of 0.0.0.0. This is even with /routing bgp peer set nexthop-choice=force-self configured. It just ignores it.
Because RouterOS doesn’t to my knowledge actually have a way to show you the RIB-IN for a peer, I decided to just modify your otherwise trivial routing filters to just log the prefixes and accept them. When the peer comes up, log messages on the sender capture that both the IPv4 and IPv6 prefixes trigger the tnl-out match and get sent to the peer. On the other side, though, only the IPv6 prefix triggers the tnl-in match and get processed and installed into the table.
Upon further inspection, a packet capture of the BGP TCP session reveals that the UPDATE for the 1.2.3.0/24 NLRI does actually get advertised, including the NEXT_HOP of 0.0.0.0. Whether or not an all zeroes NEXT_HOP field has defined behavior in the RFCs is a level of esoterica that I wasn’t able to figure out, but it might make sense that RouterOS would simply discard such an UPDATE as malformed and it would never hit the RIB-IN and consequently never the filters to be logged.
For reference, this is on 6.49.2 stable (two CHRs). What version did you test this on?
Either way, I’m at a bit of a loss and hopefully someone from support notices this or you can start a case and point them here.
Redistributing static routes produces a similar result where expected behavior occurs with IPv6 routes but not with IPv4 routes. The one eligible tie-down static for 1.2.3.0/24 makes it through the out filter but not the in filter on the other side. The packet capture witnesses it go out with a 0.0.0.0 nexthop again.
For laughs I gave it a shot in v7.1stable. The BGP configuration is a little bit foreign to me still. The good news is that if you redistribute static, both v4 and v6 prefixes get advertised correctly and received correctly. I’m having trouble originating anything through the new routing bgp connection set output.network= method, though. Even if it works, I’m not sure how that’s going to work in this case because ip firewall address-list and ipv6 firewall address-list are different. I’m not sure if it lets you specify multiple. Specifying one though, it doesn’t appear to advertise the prefix even though the tie-down route is present. Mysterious, but I’m less confident that it’s not a configuration issue than I would be with v6.
I was doing this pretty late at night and think I was a bit sleep deprived. Thinking about it with a clearer head in the morning, of course there’s no IPv4 NEXT_HOP because there’s no configured IPv4 address to use.
Does your configuration have at least one IPv4 address configured to use as transport?
edit: Yep, that was it. Also, if you use nexthop-choice=force-self you do also need to make sure to have an installed route to the next hop. I’m learning a lot about Mikrotik’s BGP implementation in terms of how frustrating it is to not be able to examine the RIB-IN directly
eduplant, did you get this working in the context of the purported support for RFC5549? I have afi4 over an IPv6 peering, but routes don’t go active. I can manipulate the gw / gw-interface using route filters, but only static IPv4 routes with IPv6 nexthops will go active. Any pointers? Thanks.
RFC8950 - Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
As of today 2025-03-13 in 7.18.2 it is not possible to route IPv4 over an IPv6 BGP connection.
Routes will be displayed on each other router, but is unreachable because of lack of routing via inet6.
In Linux you could do that via
$ ip route default via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 src 169.265.0.30