The DHCPv6 server also has the following problems:
routes to delegated prefixes are added to routing table with the “Dynamic Static” flags - I’d prefer to have the “Dynamic Connected” flags set (and Static unset) as the entry is not static and can disappear when the client releases the prefix. This would help with redistribution via OSPFv3.
when the DHCPv6 pool prefix and interface prefix overlap, the DHCPv6 server should NOT hand out the prefix assigned to any interface in the system. E.g.: I have 2a01:8c00:ff44:100::/64 assigned to my testing bridge (and WAN iface of the client) and 2a01:8c00:ff44:100::/56 prefix set for DHCPv6 pool (with the length of prefixes handed out set to 64). DHCPv6 server with no worries hands out the 2a01:8c00:ff44:100::/64 prefix to my client, which does not work, as the client cannot have the same prefix on both WAN and LAN interfaces.
In case pool Prefix length is longer than /64 (/63, /62, …), the client actually selects the next /64 prefix for LAN interface, which makes this configuration work - I’d prefer to have the overlapping /64 and “/PrefixLength” not handed out to clients.
…but it’s not a connected route by definition because the router itself doesn’t have an address presence within that prefix. So you can’t use that flag.
True, “DS” seems like an oxymoron on the surface, but I’ve always just tried to think of the “S” as a catch-all category for any prefix that is not a connected route and that the router did not learn via a dynamic routing protocol (OSPF, BGP, etc.). Basically, a “DS” route is just like an “S” route except it was generated by the system instead of by a user.
Changing the flags for IPv6 routes would make things inconsistent within RouterOS. “DS” is also the designation given to IPv4 routes added dynamically by the system (e.g., RADIUS Framed-Route), and I think you’d generally want to treat the redistribution of IPv4 “DS” routes the same as plain “S” routes within OSPF or BGP (I’m hard-pressed to think of an example where you wouldn’t want to do this, actually). So it’s not like there wasn’t precedent for this behavior already set elsewhere in the OS.
Slightly off-topic, but since the subject came up…I have a humble request for ND-based DNS configuration (or “RDNSS-via-RA” as I’m used to calling it).
Right now, if you turn it on (“/ipv6 nd set [find] advertise-dns=yes”), it finds IPv6 addresses for DNS servers from “/ip dns” and advertises those in the RA. I want to have a different place where I can configure which IPv6 address to advertise as a DNS server. Ultimately what I want to do is turn on “/ip dns allow-remote-requests=yes” and then have the router advertise one of its own IPv6 addresses in the RA, so that the router itself is acting as the cacheing DNS server for the v6 prefixes it is advertising.
I can’t do this right now because having “/ip dns set servers=” refer to itself obviously doesn’t work very well.