Windows 11 loses IPv4 address one hour after boot

Question

Problem Description

The problem I am observing is that I will lose connectivity with all non-local IPv4 hosts one hour after Windows 11 boots up. This would normally manifest as getting disconnected from my game of Rocket League and cursing at my PC. The problem does not seem to resolve itself in a timely fashion (I think I've waited ~1 hour or less while googling for solutions).

Initial Troubleshooting

I have done some troubleshooting and determined the following:

1. After the issue occurs, if I run ipconfig /all, there will be no IPv4 address listed for my Ethernet interface. It does have an IPv6 address though. Note: I am not using any wireless interfaces.
2. If I run ipconfig /renew then the problem is resolved.
3. My router (Arris Surfboard) is configured to give out DHCP leases that expire 1 hour after grant.

My initial hypothesis was that the Windows DHCP client is somehow failing to renew the lease automatically, even though it is able to do so after manual intervention (ipconfig /renew).

I think it is also relevant that my PC dual boots Linux and Windows. I believe I experience this issue most commonly after switching from Linux to Windows. Because Linux expects the hardware clock in UTC and Windows expects localtime, Windows will always have the incorrect time on boot. Even though NTP is configured, I always need to manually sync the system time after boot. I believe this sync will also reset the hardware clock. I wonder if this is related to my issue, since the DHCP client must rely on a timer to know when to request a lease renewal.

Experiment

I also performed an experiment where I changed the router DHCP configuration to expire leases in 30 seconds. Then I performed the following:

1. Reboot into Linux.
2. Reboot into Windows. Note that the system time is incorrect.
3. Watch the ipconfig /all output for a few minutes and observe that it functions as expected; the IPv4 address is maintained and the lease expiration updates every 15 seconds.
4. Sync the system time with NTP.
5. Repeat step 3. This time the IPv4 address eventually disappears and never returns without manual intervention.
6. Run ipconfig /renew and observe the issue is fixed, seemingly for good.

I have not yet done any kind of UDP packet capture to inspect the DHCP traffic, but I will be doing this shortly.

Update

I performed the same experiment as above while doing a packet capture with Wireshark. As you can see from the DHCP traffic, when I manually synchronized the system time with NTP (via Windows Settings) around 30 seconds into the capture, the client goes silent:

Only after I ran ipconfig /renew did the client start back up with the DHCP Discover packet.

Update 2

This is the NTP Sync button I am using:

Update 3

After performing the experiment with Wireshark running, I am quite certain that this issue results from a bug in the Windows DHCP client. I suspect that when the NTP sync occurs and the RTC is set back in time, the client gets confused and thinks that it has more time on its expired leases. This would explain why the client suddenly goes silent after the NTP sync.

I've created a bug report in the Windows "Feedback Hub" app.

As for workarounds, some users have mentioned switching away from dual booting to virtualization. I may experiment with this, but there are simpler workarounds.

I could also configure Linux to interpret the RTC as local time, or I could configure the Windows registry to interpret RTC as UTC.

I think the simplest workaround is to raise the validity duration of my DHCP leases (in the router config) to 24 hours, so that even after an 8 hour desync, the client will still try to renew its lease before it expires.