RouterOS 7.24.4 — EUI-64 link-local randomly absent on VLAN sub-interfaces sharing parent MAC (breaks IPv6 ND / DHCPv6-PD)

RouterOS General
1

Device / Version
Model: CCR1036-8G-2S+
RouterOS: 7.24.4 (stable)

Summary

On a router with many VLAN sub-interfaces created over the same parent interface (all inheriting the parent's MAC address), RouterOS does not generate the automatic EUI-64 link-local address (fe80::/64) on a random subset of those VLANs. The affected subset changes between days/reboots without any config change, and there are no duplicate-address / DAD messages in the log.

This contradicts the documented behaviour ("every IPv6-capable interface automatically generates a link-local address from its MAC (EUI-64) … these addresses are always present - you cannot disable them").

Details / Evidence

6 interfaces share the same MAC 08:55:31:EB:50:1C (the parent uplink plus 5 VLAN sub-interfaces). All would derive the same EUI-64 link-local fe80::a55:31ff:feeb:501c.

At any given moment some VLANs have that address (flag DL, valid) and others have no fe80 at all, even with auto-link-local=yes. On the affected VLANs the router cannot source RA / ND / DHCPv6 unicast replies — DHCPv6-PD bindings stay in status "offered" and never reach "bound"; /ipv6 neighbor shows 0 reachable neighbors on those interfaces.

Workaround attempted (and its limitation)

Adding a unique static link-local per VLAN restores ND:

/ipv6 address add address=fe80::<vlan-id>:1/64 interface=<vlan> advertise=no

However auto-link-local=no is rejected on global addresses ("selected address is not link local") and VLAN interfaces do not accept mac-address= in v7.24.4. So the flapping auto link-local co-exists and appears to still be used as source for RA/DHCPv6 — the problem persists intermittently.

Context / Prior art

The v7.23 stable changelog includes:

interface - show warning when same MAC address is used on more than one virtual interface

This confirms MikroTik is aware that sharing a MAC across multiple virtual interfaces has consequences. However only a diagnostic warning was added; the link-local generation race was not addressed.

Also in v7.23: ipip - disabled IPv6 link-local address generation — the same root cause, resolved there by disabling link-local entirely on ipip interfaces.

Questions

  1. Is it expected that VLAN sub-interfaces sharing the same parent MAC do not all receive their automatic EUI-64 link-local? How does this reconcile with the docs stating the link-local is "always present"?
  2. Is there a planned fix to either guarantee link-local on all VLANs sharing a MAC, or allow auto-link-local=no on global addresses so a clean static link-local can be used?
  3. What is the recommended configuration to guarantee a stable working link-local on each of many VLAN sub-interfaces sharing one parent MAC, given that mac-address is not settable on VLANs in v7.24.4?

Impact: several access routers serving residential clients have IPv6 (DHCPv6-PD) intermittently broken on the affected VLANs.
Support ticket: SUP-224666 (open for 8 days, no response yet).

2

Your ticket might have been addressed already, as there is a fix listed in 7.25