I have a /48 global IPv6 addresses on a public RouterOS router (A), and I wanted to allocate a /64 range to another RouterOS router (B) with only IPv4 connectivity to WAN.
Here is what I did:
- Set up a SSTP tunnel between 2 routers
- on A, add a new IPv6 route, set dst-address=xxxx::/64, gateway=sstp-server-binding
- on B, add a new IPv6 route, set dst-address=::/0, gateway=sstp-client
- on B, added an ip address xxxx::1/64 with interface=bridge, advertise=yes
Expected result
A traceroute to any public IP from router B should show correct routes.
Actual result
Any traceroute from B or devices behind B stops at A.
Traceroute from A to public IP shows correct result.
Other notes
A is running RouterOS v6.39.2 CHR (x86_84) and B is running RouterOS v6.39.2 (mipsbe).
I’ve tried disabling all IPv6 firewall rules in both A and B but the result is the same.
Dynamic link-local IPv6 address exist for SSTP link.
IPv4 inside SSTP works.
I’ve never been a fan of interface based nexthops. While MikroTiks’ documentation is weak on detail for IPv6 routing. In IPv4 routes with interface based gateways are not used for next hop calculations and you “may” be relying on proxy ARP to make magic pixie dust to keep you up. Without ARP in IPv6 you get a no-workie situation.
While, not required (you should be able to route with link-locals) you need a way to tell the router which device is a router. By default, forwarding, the MikroTik is set to ignore RA’s. Changing that setting (/ipv6 settings) may get you working. A more robust solution would be to either setup a routing protocol over a tunnel like GRE. I’m not sure if SSTP supports multicast, that said OSPF with static neighbors likely would work or BGP. Alternatively, apply addressing to the SSTP interfaces and use those for gateways or just for testing statically enter the link-local with % I believe to specify which interface to use. Regardless that’s the problem I imagine.
OK I’ve found the answer. My IPv6 provider uses ND only so I have to use link-local address in routing table everywhere… But that is another story. The solution to the specific problem described above is that I wrote a wrong routing filter (didn’t enable prefix length option causing it to be an exact match), so data from devices behind SSTP has src IP that is not accepted by my upstream. However the router itself has static IPv6 address so traceroute from router still works.
Thanks for your reply.