I've changed my MAC address via
This new MAC seems to be used for the DHCPv4 client. However, for creating the DUID for DHCPv6, still the original MAC address is used.
Is there any way to work around that? I need to change the DUID in order to get a new/larger v6 subnet via PD

I've had exactly the same issue. The DUID generated by ROS was done using another interface's mac address as the one I used to created my PPPOE session to my ISP. I've had to change mac addresses on the interfaces to make the DHCPv6 Request work.

It would be really nice if one could force reset the DUID value in ROS.

What should work (learned from MikroTik support) is to factory reset the device. If you restore the text backup (RSC file), the DUID is regenerated first time you use DHCPv6. Not sure what happens with a binary backup though.

What should work (learned from MikroTik support) is to factory reset the device. If you restore the text backup (RSC file), the DUID is regenerated first time you use DHCPv6. Not sure what happens with a binary backup though.

This works but still doesn't address the case where you have to set up an arbitrary DUID like when you're hosted at Online.net as described here : viewtopic.php?f=2&t=114389&p=620446#p620446
Which is also my problem…

It seems that RFC 3315 says you should not change the DUID (viewtopic.php?f=2&t=57582&p=509167&hilit=duid#p294781), but what harm would it actually cause to let us change that setting ?

Arnaud

Are you using Comcast? When you first set a prefix-hint on their service, a strange thing happens. Packet captures show that the primary server gives you the same /64 you already had, and the backup server gives a /60, but since it replies later than the primary, the Mikrotik router will have already bound the /64 offered by the primary. The only fix I've seen with them is to just disable DHCPv6 for a couple of days while your lease expires. After that, the primary server will honor the /60 in prefix-hint when you re-activate the dhcpv6 client.

(They may have fixed this by now but I haven't tried messing around to see whether this is the case or not)

As stated in the thread, the DUID is intended to be a unique identifier for your device and shouldn't be changed. Honestly, I think people should complain to Comcast but doubt that's going to budge them any - most tech support people I've talked to don't even know about IPv6 at all.

No, I'm not using Comcast, I'm using Online.net, a french hosting company : https://www.online.net/en
They chose to implement IPv6 PD the following way : https://documentation.online.net/en/ded ... pv6/prefix
Unfortunately, I cannot change the DUID in RouterOS, so I had to change the interface mac address in vmware.
But even then, with the proper DUID, I can't find the correct settings and never get an address !

Any news on this ? SFR, a french ISP, need a specific DUID. I don't want to factory reset my router, then change the mac adress (of eth1 since RoS seems to use this one event if it's not connected...), and then enable ipv6, only for that... A simple duid variable in the dhcpv6 client would do the trick. Ubuiquiti ERL's are allowing that... Come on Mikrotik...

Can we at least have the option to reset the duid, from a chosen eth interface, without having to factory reset the whole thing, please ?

Alright, so I did a reset configuration, then change the ether1 mac address, the create a dhcp6 client, and still, it's the original mac from ether1 who is used for the duid.

The factory reset isn't working anymore ?

Thx in advance.

Edit : ok, I had to disable dhcp and IPv6 package, reboot, reset conf, reboot, change the mac, reboot, activate package, reboot, and then the new duid for ipv6 was generated based on eth1.

Just forget it. If you don't sell their products by the thousands, Mikrotik will just ignore you.
Not only won't they add new knobs to give you more control, but they won't even fix any of their bugs.
8 months that I reported Dude's SNMPv3 breakage and non conformance to RFCs.
I never used it before so perhaps it has always been broken.
Still no progress on the issue and no flags to warn other users of the problem.
Just buy their products and hit a brick wall.
They tell me developpers are too busy.
Probably working on ROSv7.... Who knows.
Anyway, you can't rely on any feature they announce, you have to apply zero-trust principles and test for yourself.
Or buy other products where the guys are serious about the feature sets they actually support.

Want some more proof : read viewtopic.php?f=14&t=122446
The fix is easy : just move your whole datacenter from ESX to hyper-v.

Yeah, it's pretty bad...

It's strange, some problems they fix in a few RC releases, and other are not fixed for years...

In my mind, I really hope it's because RoS6 is a "mess" to work with, and V7 will be more flexible and a lot of bugs will be fixed by it... But I'm 35, I wonder If I'll live to see V7....

Still not fixed?
i have router hap ac2 wich generates strange DUID, while my provider requests other. and i can`t fix it

RFC states:

The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server - that is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware.

The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID.

It is quite ridiculous, that service provider is forcing vendors to violate RFC just because it simplifies their job.

But it would be useful to have configurable DUID.

If ISP links my config (specific prefix) to it and my router burns up, it would allow me to replace it with another, without ISP even noticing anything. Even if they are cooperative and would update my config for new DUID, they won't react immediatelly. It's similar to IPv4 where they often want to register MAC address, many ISPs do that. So every router allows to manually configure MAC address for WAN interface and it saves a lot of unnecesary support calls. Configurable DUID would be the same thing.

Btw, if length of DUID used by RouterOS is the same as required by ISP (there are different DUID types with different lengths), it can be hex-edited in backup and restored back to router. For now, until MikroTik "fixes" it with some integrity checks for backups.

I found an easier way to change it.
Backup you conf, download the backup file, search for you duid in it (I found mine at offset 0x9954), then upload the modified backup and restore from it.

Is there a supported workaround for DUID-EN types? The length of the DUID I need isn't the same as generated by the router, so changing it in the backup doesn't actually work for me.

Hi there,
It is very difficult that every time I change a router to have to change the ipv6 network of my environment. Come on Mikrotik just allow the change of duid

I found an easier way to change it.
Backup you conf, download the backup file, search for you duid in it (I found mine at offset 0x9954), then upload the modified backup and restore from it.

Thank you very much. I followed your recommendation and it seems it worked.