WAN IPv6 address not renewing after initial dhcp request

[Trinnik]

Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg

Reboot and try again.

I was a bit suspicious of the patch but it's been in Debian too many years to give it a second thought. I don't know the code well enough but maybe the logic condition is wrong (|| vs. &&).


Cheers,
Franco

This fixed the issue for me as well. I'm on Comcast's DOCSIS network.

This is a bit weird:

vltime=34359741968

Otherwise it looks rather normal. Do you use the "prevent release" option?

A note on vltime (for Comcast not sure on others) Comcast states that IPv6 addresses received from DHCPv6 on their network are effectively static. Might be why they set the vltime to max.

[Taunt9930]

I know it doesn't help anyone with an issue, but a useful data point for Franco perhaps- no issues here. Straight upgrade and no issues with IPv6 on a Zen PPPoE UK FTTP  connection.

Been up 24 hours now since a reboot after upgrade, and not an issue at all.

[sammyrose]

Just another +1 for being affected by this issue. I was seeing IPv6 GAs being assigned initially, eventually falling off from the interface. In my case, packet sniffing demonstrated two separate renew packets, the first responding with the GA, and the second responding with my delegated prefix.

Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg

Reboot and try again.

This is what solved the problem for me.

[ccore]

+1 for the issue
+1 for the "solution" (pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg)

WAN IPV6 up again for 14h now.

[matt335672]

I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-

https://github.com/opnsense/dhcp6c/pull/36

[dfw3xam1n3r]

I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-

https://github.com/opnsense/dhcp6c/pull/36

Wondering if my situation over the past couple of weeks could be related, this was working before:

1. WAN pulls IPv6 fine via DHCPv6 client.
2. LAN has a static IPv6 address. Clients pull an IPv6 address via routing advertisement (managed mode) and DHCPv6 server (so I can control the address they receive). This stopped working though I noticed one day on my phone when I saw it didn't pull an IPv6 address.
3. So I dropped back versions of dhcpv6c and opnsense proper ( 24.1.8 ) as stated in the thread. This only allowed me to serve out clients via unmanaged routing advertisements and not via the DHCPv6 server I have running.

So with that background, the question is does anyone think this issue would affect the ability to use the DHCPv6 server to serve out static-mapped addresses with routing advertisements set to managed (not working) instead of unmanaged (working) as it is now?

[matt335672]

Since you've quoted me dfw3xam1n3r, I'll reply as best I can.

On the face of it I can't see a reason for this to be related, but I'm just a random software developer off the internet. This is my first PR for opnsense. I'm best described as an enthusiastic user of opnsense, so my product knowledge level is at best patchy. For example, I don't know how the dataflows for the 'track interface' feature are implemented.

That's the disclaimer. However, you can investigate this yourself as follows, if you're on 24.1.9:-
1) Restart the WAN connection
2) Get up a terminal and investigate the WAN connection with ifconfig -L pppoe0 (assuming you're on PPPoE).

You should see your IPv6 GUA there. After the text vltime there will be a value. This is the number of seconds remaining before your GUA disappears. Your ISP will still believe your GUA is active, as it will be getting regular RENEW requests from you.

When your GUA does disappear, a range of things can happen from 'hardly anything' to 'no IPv6'. This is ISP-dependent to a large extent. However, you have a precise time when this happens, and so with a bit of detective work you should be able to figure out if there is a dependency between events on your network and the GUA disappearing.

BTW, I believe a release which addresses this issue is imminent so this may be moot.