I am experiencing a very specific and reproducible IPv6 routing issue in a pure RouterOS (v7.23.2) environment (both Upstream Server and Downstream Client are MikroTik devices).
When configuring a Stateful DHCPv6-only network (M=1, O=1, A=0, L=1) using a standard /64 prefix, the downstream RouterOS client successfully obtains the IPv6 address via DHCPv6, but fails to install the Connected / DAC route for that prefix.
Interestingly, a Windows or Ubuntu client placed in the exact same downstream broadcast domain works flawlessly, instantly creating a /64 on-link interface route.
1. Test Topology & Software Version
Upstream Router (DHCPv6 Server & RA Issuer): RouterOS v7.23.1)
This is the correct behavior if the clients only get IA_NA addresses (which are /128) from the DHCPv6 server. It would be totally wrong and a nightmare otherwise.
Imagine that you have your DHCPv6 server setup with multiple /80 pools, one for each of your VLANs, giving out /128 individual addresses. You would certainly NOT WANT that the DHCPv6 clients automatically install /64connected routes for the /128 they receive, because they would then be unable to reach the other clients in the other VLANs that are part of different /80 but inside the same /64!
And neither do Windows nor Linux automatically add /64 connected routes for /128 received IA_NA addresses:
This is not related to DHCPv6, but is the result of you having added this:
If you set that to prefix=none, then you'll see that both Windows and Linux clients will no longer add the /64 connected routes. In fact, if you add an /ipv6 nd prefix entry with other prefix length, totally unrelated to the DHCPv6 one, with autonomous=no, those OSes will also add corresponding connected routes:
The difference to RouterOS is that RouterOS ignores received prefixes in RA (not related to DHCPv6) with autonomous turned off, because it has no use for them (no SLAAC). RouterOS does not install connected routes when it has no corresponding address assigned to the interface under /ip address or /ipv6 address, with the same prefix length as the address. If it only has a /128 address assigned to it under /ipv6 address, you won't see any dynamic /64 connected routes appearing.
I understand that DHCPv6 doesn't create a /64 (or any other length) connected route. However, as you mentioned, I've specified an on-link prefix in the ND prefix, so I feel a connected route should be set up for it.
Otherwise, consider this scenario: different hosts in the same VLAN obtain /128 addresses via DHCPv6. How would they communicate directly with each other? Without a connected route, all their traffic would have to go through a router, right? Of course, the router might send ICMPv6 Redirect messages...
For each assigned address that does not have any associated reachability information (see the definition of "on-link" in Section 2.1 of [RFC4861]), in order to avoid the problems described in [RFC4943], the client MUST NOT assume that any addresses are reachable on-link as a result of receiving an IA Address option (see Section 21.6). Addresses obtained from an IA Address option MUST NOT be used to form an implicit prefix with a length other than 128
However, in OPs case, it does not strictly apply because of add autonomous=no interface=ether5 prefix=240e:1:2:3::/64 on-link=yes. Through DHCPv6 Client RouterOS acts in capacity of a host and thus RFC 5942 applies:
The reception of a Prefix Information Option (PIO) with the L-bit set [RFC4861] and a non-zero valid lifetime creates (or updates) an entry in the Prefix List. All prefixes on a host's Prefix List (i.e., those prefixes that have not yet timed out) are considered to be on-link by that host.
If there is ambiguity here because of mixed use (CPE is both router and host) then RouterOS ought to provide a setting to explicitly control that.
The IPv6 CE router MUST follow the recommendations in Section 4 of [RFC5942], and in particular the handling of the L flag in the Router Advertisement Prefix Information option.
A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] (as modified by this document) or via manual configuration.
The client-side implementation of RA in RouterOS currently only installs a default route (when the received RA Lifetime is positive), and setup /ipv6 address assignments from received prefixes with the A flag. It's the address assignment that produces the connected route. For RouterOS connected routes are tied to that existence of an address assignment: Routing Decision | RouterOS Manual.
MikroTik would need to extend this client implementation to add the routes for the other received prefixes, not as connected routes, but as the ones with the g flag. So, you'll need to fill a feature request as @Kentzo said.
It could also be that they kept their implementation of the RA client part minimal (only recently was the ability added to selectively pick the interfaces to accept those RA messages).
IIRC if you switch to DHCPv6 Prefix Delegation (IA_PD) then it should work. This is most likely what you will want down the road anyway.
Now I wonder, whether the advertised prefix is fully ignored or it's only ignored for routing purposes but is respected for packets originated from the host/router.
