Indeed. That’s why I always use /tool/sniffer and, if necessary, Wireshark.
All what you’ve described here just confirms @tdw’s initial assumption - that the setting at ISP side is a /48 without any routing, not any bug of RouterOS. The ISP’s router sends a Neighbor Solicitation message for any address from the /48. There is nothing wrong about the same device responding to Neighbor Solicitation messages for multiple distinct addresses.
No inter-VLAN routing actually happens, as there is nothing to route - the response packet never made it to your router. And the Neighbor Solicitation ones are a functional equivalent of IPv4 ARP, they are not intended to be forwarded. That’s where the “ND proxy” would come handy, which is an equivalent of ARP proxy - if enabled, the router responds ARP requests for IP addresses towards which it has a route with its own MAC address.
Providing a /127 address for each party alone does not change anything. They would have to also set a static route to the /48 via the /127 to make it all work.
As for “still works” - I suppose the PREFIX::1 is the same for the old (supposingly, /48 on their side) setting and for the new (/127 on their side) one? Or maybe they have added the /127 from within the /48 and kept the original one in place? In either case, they do not care about the source address when responding your Neighbor Solicitation packets and then when routing packets that come from you, so they make it to the destination alright.
So talk to the ISP again and check they have indeed set the route to the whole /48 via your end of the /127.
@mkx: Yeah, the default now is /64 for IPv6 addresses (I was wondering at first as well, when they introduced that), as @sindy also noted. More sensible than /128.
The /127 is a distinct network, not from the /48 to be routed to us. The assumptions about my wording of old/new routing settings are correct.
So… I’ll check again with the ISP. With static routing I would assume they don’t need to start ND for our /48 on their router for inbound traffic. But at the other ISP (where we got a /56) that works with IPv6 they do the ND for any internal address I configure and try to access from outside. However, the NS messages in the ND process refer to the global IPv6 address of the target, and not the solicited-node multicast address. It’s weird. Or my IPv6 knowledge is a bit lacking. Maybe it’s the effect of a properly configured static route on their part?
Wait. By “target” you mean the ultimate destination (a device in subnet in VLAN 2) or the unicast address of the router on the ISP-facing interface (in the subnet in VLAN 10)? If the latter, it is probably OK as they only refresh the alredy existing neighbor record, so there is no need to bother everyone in the subnet by multicasting.
It’s at the other site with a working /56 IPv6 prefix. Target is a newly configured single v6 IP in an internal subnet/VLAN in that environment. You may be right about the ND messages, anyway. OTOH, I asked the ISP of the problematic site to check their static route towards our /48. We’ll see.
I’ve got that, I just used the VLAN numbes from the problematic site as a shortcut. I should have written “WAN VLAN” instead of “VLAN 10” and “LAN VLAN” instead of “VLAN 2” to avoid confusion.
After some ticket tossing back and forth with the ISP, they fixed it. They didn’t say how, if they do, I’ll update this post. Most likely they added the proper static route.
Thanks for all who answered and took their time to help. I wish that general ISP support was this helpful…
EDIT: their answer after some nagging (translation to English): “The problem was caused by a configuration error in the core network that was found and fixed by our IP system engineer.” Take it for what it is.