But it's in the specification, the DHCPv6 server cannot ignore the IAID because it's part of the tuple used to index the client binding. I will link to RFC 9915 because it's the latest but it's the same in the RFC 8415 that it replaces:
https://www.rfc-editor.org/info/rfc9915/#name-dhcp-terminology
A binding (or client binding) is a group of server data records containing the information the server has about the addresses or delegated prefixes in an Identity Association (IA) or configuration information explicitly assigned to the client.
A binding containing information about an IA is indexed by the tuple <DUID, IA-type, IAID> (where IA-type is the type of lease in the IA -- for example, address or delegated prefix).
Identity Association: a collection of leases assigned to a client. Each IA has an associated IAID (see below). A client may have more than one IA assigned to it -- for example, one for each of its interfaces. Each IA holds one type of lease; for example, an identity association for non-temporary addresses (IA_NA) holds addresses, and an identity association for prefix delegation (IA_PD) holds delegated prefixes.
If you think of the bindings managed by the DHCPv6 server like a database, then the IAID is part of the identifying primary key of the records (the key is a tuple with 3 elements, like primary key grouping 3 columns in a database table).
The DUID alone cannot be enough to identify the identity association, because each client device normally only has one DUID (machine wide), but can have multiple network interfaces. Like when you have a laptop with RJ45 port and WiFi and both are used to join the network managed by the same router, the DHCPv6 server on that router needs to be able to assign different addresses / delegate different prefixes for those ethernet and WiFi interfaces of the same laptop.
Also, because IA_TA is now obsolete, a client requiring two different addresses per interface, one temporary for privacy, will now use IA_NA for IA-type and two different IAIDs. Your DHCPv6 server will not be able to serve that if it completely ignores the IAID value.
Another situation is that the client can be a router, that further delegates prefixes to its sub-clients. This router can request multiple bindings to upstream with <its DUID, IA_PD, individual IAID per sub-client> as the IA tuple.
In short: the DHCPv6 server cannot ignore IAID or apply a wildcard to it.
Your client with the random IAID is a broken client that violates the specification (Section 12).
For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client. The client may maintain consistency by either storing the IAID in non-volatile storage or using an algorithm that will consistently produce the same IAID as long as the configuration of the client has not changed.
The client is only allowed to change the IAID for the same identity association if has had some changes in its configuration, not every few minutes with no setting changes! I don't think RouterOS should be modified accommodate specification violators.
But there is?
You can set both the pools to static-only and the DHCPv6 server will only use the static bindings that you've already added to the Bindings table, with hardcoded DUID and IAID of course. And you can require your customer to have to have exactly that IAID or they will not receive any binding. It works, I just re-tested it with a CHR setup.
