It seems that (at least on 6.40.1) when I run the DHCPv6 client to acquire a prefix, this fails with “error” in case the interface has issues when coming up, like late sync or issues with autosensing.
DHCPv4 client retries until it gets an IP address, DHCPv6 client simply is stuck with “error”.
Is this intended behaviour?
A manual “renew” immediately assigns a prefix then, so my workaround would be to write a script; however, having some persistency would be good to reliably get an address even after interface issues.
Thanks! I have to RMA my device due to a hardware issue, so not sure if I get a hand on testing before I send it to the distributor - so I’m glad you confirmed.
Moving my configuration over to a fallback router that has no ethernet issues seems to show similar issues - so not sure if DHCPv6 in 6.40.1 isn’t broken generally on first run.
The main issue seems to have been addressed in recent versions
However, today we had a power outage, and the modem and router both rebooted at the same time
That particular cable modem needs 5-10 minutes after boot to hand out a IPv4 and IPv6; IPv4 gets a RFC1918 address until the “real” lese is sent from the CMTS; IPv6 seems to hand out nothing
For IPv4, RouterOS (6.40.4) got the new lease properly
For IPv6, however, it stopped with “error” and never tried again
My proposal is to have the same behaviour for IPv4 and IPv6 - try again in case of errors.
As an interesting side effect, I feel that http://forum.mikrotik.com/t/bug-64-kills-winbox-discovery/111864/1 comes to play here as well. Due to IPv6 being stuck on “error”, the device was not visible within WinBox. As soon as IPv6 was assigned, it could be discovered.
