IPv6 client does not get prefix after internet drops out

This week my ISP was doing maintenance and over 3 days my internet connection was being dropped for up to 2hrs each day. I noticed that backups were failing, these backups rely on IPv6 endpoints for connection. When I went in to Inbox I noticed that I had no IPv6 prefix and as a result my IPv6 pools had all failed.

Performing a /ipv6/dhcp-client/renew ether1allowed the router (hAP ax3) to instantly obtain a new /56 prefix and everything worked again. This happened after each outage.

Shouldn't the IPv6 DHCP client continually try to obtain a prefix after an outage?

Config:

# 2026-07-24 19:01:07 by RouterOS 7.23.2
# software id = 1ZA1-H62T
#
# model = C53UiG+5HPaxD2HPaxD
# serial number = HEK08M4R8JP
/ipv6 address
add address=::10:0:0:0:1 from-pool=telstra interface=vlan10::MGMT
add address=::20:0:0:0:1 from-pool=telstra interface=vlan20::DATA
add address=::30:0:0:0:1 disabled=yes from-pool=telstra interface=vlan30::KIDS
add address=::40:0:0:0:1 from-pool=telstra interface=vlan40::GUEST
add address=::bb:0:0:0:1 from-pool=telstra interface=bridge
add address=fd77:3f60:b788:bb::1 comment=ULA interface=bridge
add address=fd77:3f60:b788:10::1 comment=ULA interface=vlan10::MGMT
add address=fd77:3f60:b788:20::1 comment=ULA interface=vlan20::DATA
add address=fd77:3f60:b788:30::1 comment=ULA interface=vlan30::KIDS
add address=fd77:3f60:b788:40::1 comment=ULA interface=vlan40::GUEST
/ipv6 dhcp-client
add add-default-route=yes default-route-tables=main interface=ether1 pool-name=telstra pool-prefix-length=64 prefix-hint=::/56 rapid-commit=no request=prefix use-interface-duid=yes \
    use-peer-dns=no
/ipv6 dhcp-server option
add code=24 comment="\"sapling\" in HEX" name=DOMAIN value=0x077361706c696e6700
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=fasttrack-connection chain=forward comment="fasttrack LAN traffic only" connection-state=established,related in-interface-list=LAN out-interface=!ether1
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack6" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment=DNS dst-port=53 in-interface-list=INT_VLAN out-interface-list=INT_VLAN protocol=udp
add action=accept chain=forward comment=DNS dst-port=53 in-interface-list=INT_VLAN out-interface-list=INT_VLAN protocol=tcp
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface-list=WAN protocol=tcp tcp-flags=syn
/ipv6 nd
set [ find default=yes ] advertise-dns=yes dns=fd77:3f60:b788:20::3 interface=vlan20::DATA other-configuration=yes ra-interval=20s-1m
add advertise-dns=yes dns=fd77:3f60:b788:30::3 interface=vlan30::KIDS other-configuration=yes ra-interval=20s-1m
add advertise-dns=yes dns=fd77:3f60:b788:10::3 interface=vlan10::MGMT other-configuration=yes ra-interval=20s-1m
add advertise-dns=yes dns=fd77:3f60:b788:40::3 interface=vlan40::GUEST other-configuration=yes ra-interval=20s-1m
/ipv6 settings
# ipv6 neighbor configuration has changed, please restart the device in order to apply the new settings
set accept-router-advertisements=yes allow-fast-path=no

I don't know about that, but how did you manage to butcher your firewall in such a way?

Do you mean that?

I've seen this some years ago in my export as well. It was caused by using WinBox (3.x back then) to disable/enable firewall rules.

The output looks like that probably because the OP used

/ipv6 export verbose

Which is not very helpful when posting config on the forum.

Hah, I did not think of that.
I wanted to look through the config on mobile and was like 'nope'.
I did not experience this kind of behaviour described here anyway.

The state in which the dhcpv6 client was before issuing that renew command would've been helpful, I think.

I had read another post that asked for the verbose output

I had used Winbox to disable the IKE / ipse rules I don't need. I'll just delete them and re-export.

I had to get the connection back up and running and didn't think of exporting this before renewing.

It has too much noise and is very difficult for a human to parse what was changed in your config. A normal export (without verbose) is much better because it only includes the parameters that really deviate from the default values. People on the forum would then be able to spot the issues.

I have edited the original post

More to the point: this usually happens when the Internet connection "drops", i.e. becomes not working, without a link down event. This happens easily if some sort of maintenance or breakage occurs beyond the access layer.

A link down causes the dhcp client to reacquire a lease, but if there is no link down, it will only attempt to renew according to the lease time. It doesn't care one bit whether Internet access is actually working or not.

In your case, manual intervention was the right step. ("Have you tried rebooting your router?") If it's some sort of regular occurrence, some automation like scripting/netwatch would be in order.

The IPv6 / DHCP Client / Prefix was empty when I checked the router, I still had IPv4 connectivity, ie. it had renewed the IPv4 address. I had to manually renew the IPv6 prefix.

Well, you didn't exactly descrbe that in your post. The next two likely things:

Dhcp clients back off if unsuccessful, and there's nothing tying the timers of the ipv4 and ipv6 clients together. Maybe you just haf to wait?

The other is that there is a common programming error, where one forgets to check and recreate the socket. This is a topic for support.

To troubleshoot further, could you sniff DHCPv6 Client traffic on ether1 after the issue reoccurs?

I had a seemingly unrelated issue but I wonder if it hits the same codepath internally: DHCPv6 client’s prefix-hint is ignored on renew and rebind (v7.21.4)

It hasn’t re-occurred since…