Back in 6.38 an issue was resolved where “if you enabled IPv6 Forwarding when using IPv6 ND or SLAAC IP Addressing, then the ND/SLAAC assigned IPv6 address stopped working”
What’s new in 6.38rc52 (2016-Dec-21 10:44):
*) ipv6 - fixed “accept-router-advertisements” behaviour;
This appears to be an issue again in in 7.1.
With IPv6 Forwarding turned off I can ping my IPv6 address which is assigned by SLAAC, but as soon as I turn IPv6 Forwarding on I can no longer ping this address.
Downgrade to 6.49.2 and it all starts working again.
Assigning IP addresses to a router using ND/SLAAC is always a bit of a niche case. I think in best practices it is “not done”.
Even in v6 it causes funny behavior (like addresses and routes not visible in the configuration interface).
It’s not just SLAAC, AFAIK even DHCPv6 clients are supposed to get gateway from RA (see my DHCPv6 client and default gateway thread and you’re welcome to chime in), which is currently broken.
And SLAAC can be useful too, for example as backup connection for administration, now that policy routing works for IPv6. Funny hidden addresses and gateway should of course be fixed and made visible. And it should be configurable per interface.
Currently I am using only static addresses and “from pool” (obtained with DHCPv6-PD) and I have no issues other than the known problem of using the wrong config for dhcpv6 client (set default route, where default route was already set by PPPoE)…
It’s not a niche case. This is how ISPs in Japan hand out IPv6 addresess. That’s a country of 120 million people.
I’ve seen people claiming that RFC-4862 says that SLAAC should not be performed by routers. That is a misinterpretation of what is actually written. RFC-4862 simply says the configuration of router interfaces are out of its scope.
Is it really SLAAC, i.e. addresses, not just gateway? In other words, don’t they provide prefixes? That would be terrible approach, because how would you do multiple LAN subnets with that?
Also in some cases your router has to get an IP from SLAAC on the WAN uplink port in order to get connectivity. MikroTik added into the DHCPv6 client the ability to “add default route”, however DHCPv6 server doesn’t have a way to provide a default route to the client. What actually happens is MikroTik assumes that the DHCPv6-PD server IP is actually the default gateway. This works great until you get a DHCPv6 relay involved and now the MikroTik adds a default route with a next hop to some DHCPv6 server on some other network and so you lack a valid default route. In such a case you can only get the default route via SLAAC, and so this function must work.
They really should not provide an “add default route” option in the DHCPv6 client, but they do this as a courtesy as 95% of the time it is true that the default gateway will also be the DHCPv6 server address. For the other 5% of the time where they do not match, you still need to be able to discover the gateway using SLAAC, even for a router.
I think it’s good that it’s available, the more tools you have the better. But it would be good to point out more clearly that it’s just workaround when ISP does it wrong.
But DHCPv6 client manual (https://help.mikrotik.com/docs/display/ROS/DHCP-client) has only one very subtle hint, and that’s the fact that default is add-default-route=no. But pretty much everyone will enable it, because a) everyone wants default gateway and they are used to IPv4 where it’s provided by DHCP, and b) RouterOS doesn’t accept gateway from RA by default, so it also pushes user towards enabling add-default-route.
I’m hoping that the new “IPv6 stack” as MikroTik described it means that they can have a better solution for a router getting an address via SLAAC, which would probably mean them creating a SLAAC client themselves instead of relying on the one built into the underlying Linux OS. In this case we could see the address and the route in the router like normal when received via SLAAC.
They probably don’t need to reinvent the wheel. Linux has per-interface config with several options (see e.g. https://sysctl-explorer.net/net/ipv6/, accept_ra_* options), “ip” command can see both autoconfigured address and gateway, … so it seems to me that RouterOS just needs to expose this to users, and we’ll live happily ever after.
Yes, I asked them about that before and they made it seem like it was impossible for whatever reason. They didn’t explain why to me. I hope they have a better solution for this in RouterOS v7 because it seems like everything else can do this, just not RouterOS. I don’t really care what solution they come up with, but the RouterOS v6 “solution” of having a secret IPv6 global address and default route that isn’t actually shown to you is not a good solution.
There is no reason whatsoever why the existing Linux SLAAC/ND client would not be able to have the obtained addresses and routes visible in the configuration (with a D label of course).
I have several devices running Linux and using SLAAC and they show their address and route just fine when using “ip -6 addr” and “ip -6 route”.
(including the lifetime as configured in the MikroTik router)
Keep in mind that IPv6 in ROSv6 was only slightly better than nothing and wasn’t in MT’s focus. So they probably threw together some bare minimum and left to attend other business. Lack of fast-track v6 does illustrate this. Let’s hope that things will get much better in ROSv7 … soon. Fast track v6 was mentioned to be on to-do list, hopefully that will include other improvements of IPv6 implementation as well.
Yes, that’s what I would have thought too, and is why I asked them way back in 2018, but for some reason it was not so simple. They said “unfortunately this behavior will stay in current RouterOS versions”, which does potentially leave things open for v7.
ISP provides two addresses to me:
Primary IPv6 Address: 2404:9400:4:0:216:3eff:fee1:7681
IPv6 Routed 2404:9400:4176:8100::/56
Previously I could not ping the primary ipv6 address when I have forwarding turned on, and because of that I think everything else was also broken.
But since 7.2 can ping the primary IPv6 address and everything in the routed /56 works fine.
The assigned addresses still don’t show in /ipv6/address, which is annoying, but they are definitely there and working.