Clients are capable of pinging the IPv6 domain with no issues.
PS > ping checkipv6.dedyn.io
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=239ms
I can’t find the problem. Any idea of why IPv6 pings are not reachable from the router itself?
You’re doing IPv6 addressing wrong. Your router doesn’t really need GUA (global) address on WAN port. However you do need a prefix to make enabling IPv6 on your LAN subnets possible. So instead of your DHCPv6 client config you should use something like this:
(note: the construct “address= from-pool=” will come up with different addresses for different interfaces, pool will hand out different addresses each time it’s asked even though the construct looks like it’ll end up with same IPv6 address)
Next: routing info in IPv6 is supposed to be derived from Router Advertisements (RAs). The DHCPv6 client option add-default-route=yes is MT’s work around and tries to set default route to DHCPv6 server’s IPV6 address (or, as seen in your case, to interface … which is wrong for point-to-multipoint interfaces). So instead you should configure your router like this:
/ipv6 settings
set accept-router-advertisements=yes
This should make your router to receive RAs from your ISP …
After some testing, I’ve realized that the IPv6 default route wasn’t set up properly.
The default gateway should be set dynamically by the DHCP client for the WAN interface.
The “add-default-route” option is set to “yes”, but the route was not being added after a reboot.
By simply re-enabling the DHCP client, the dynamic default gateway was set up as the ISP’s next-hop link-local.
[@MikroTik] [rout]> ipv6/route/print
DST-ADDRESS GATEWAY DISTANCE
DAd ::/0 fe80::662:73ff:fee4:a419%ether1_WAN 1
The “accept-router-advertisements=yes” option did not solve the issue, so I returned it to its default.
Then, I changed the request option for the DHCP client: “request=address,prefix”, and, finally, the correct default route was added.
That seems to solve the problem.
But the question remains…
Even when the “add-default-route” option is set to “yes”, why would the DHCP client not add the correct IPv6 default route if it only requests an address and not a prefix?
Because DHCPv6 protocol doesn’t support passing routing information to client. And it doesn’t matter if client requests address or prefix.
So whatever ROS does when add-default-route is enabled is just guess-work by ROS since whatever it comes up with is not configured by ISP. ROS may guess correctly but it may also fail miserably.
There’s another thing to it: upstream router eventually has to know where to forward traffic for delegated prefix. And that info is only available from DHCPv6 server. Client’s WAN IPv6 address can be ULA (which is constructed from interface’s MAC address and that is information which DHCPv6 server does know because it’s needed for unicast communication, used in later stages of DHCPv6 handshake). Client’s WAN IPv6 address can also be GUA (for routing that’s technically not required) and if DHCPv6 client requests both address and prefix in single handshake, then DHCPv6 server can hand out both at the same time and are thus linked to the same device.
Note that this part only makes possible to properly route packets in direction from internet towards client LAN. To route traffic in the opposite direction, client gateway has to know what should be next hop. As I already wrote, this information is available from RAs (but reception of them has to be enabled). But one can also set the before mentioned DHCPv6 client option and ROS then sets default gateway to address of DHCPv6 server. It seems that MT is not the only vendor to do it, so many ISPs somehow tolerate such misuse of their DHCPv6 server. If clients accept at least ICMPv6 Neighbor Redirect messages, then the poor DHCPv6 servers are not hammered too much by misdirected traffic.
To route traffic in the opposite direction, client gateway has to know what should be next hop. As I already wrote, this information is available from RAs (but reception of them has to be enabled).
Because DHCPv6 protocol doesn’t support passing routing information to client. And it doesn’t matter if client requests address or prefix.
So whatever ROS does when add-default-route is enabled is just guess-work by ROS since whatever it comes up with is not configured by ISP. ROS may guess correctly but it may also fail miserably.
So, you’re saying that the “add-default-route” option doesn’t matter. ROS takes the DHCPv6 info and just guesses the gateway from the DHCPv6 server.
RA is the one that provides the next-hop information. Right?
Still, after a reboot, it will only add a proper default route if the DHCPv6 request has the “prefix” option set.
As I understand it, the IPv6 settings are set not to accept RAs since “forward” is set to “yes”.
However, if I go back to my initial configuration where “request=address”, and set “accept-router-advertisements=yes”, ROS does not add the correct default route after a reboot.
and if DHCPv6 client requests both address and prefix in single handshake, then DHCPv6 server can hand out both at the same time and are thus linked to the same device.
Yes, I guess that is what I ended up doing with “request=address,prefix”.
This way we see that there is a SLAAC (g) and a DHCP (d) route, which are identical.
Only when the the DHCP route is set with the next-hop does the routing actually work.
IMO when having two identical routes, either should work (and flags don’t matter, they are metadata not routing information). It’s good to see that “DHCPv6 client default route mock-up” ends up with correct setting in your case. So, if using that DHCPv6 client option works for you, keep on using it.
There’s another thing to be aware of: RAs are in principle broadcast “occasionally”, and time interval between occurrences can be minutes. Device can, when getting interface UP, ask for RA to be sent (out of usual intervals) to get necessary information sooner. But if it doesn’t (or if router ignores request), then it can take a while before IPv6 connectivity gets established. So when configuring IPv6 things, sometimes one has to wait a while to see, if settings have any effect or not.