Hello, any progress on this issue? I'm seeing this my all my devices Mac OS X 10.15.4, iPhone 13.4, and iPadOS 13.3. None of my Ubuntu 16.04 and 18.04 desktops, and laptops, and none of my numerous Android 9 and 10 devices have any issues at all with ipv6 
Hi all,
For some unknown reason, my macOS 10.15 set the following sysctls:
net.inet6.ip6.rtexpire: 10
net.inet6.ip6.rtminexpire: 10
This caused my default gateway to expire within 10 secs.
The standard value should be 1h.
After sysctl net.inet6.ip6.rtexpire=3600 everything workd fine again.
Did Apple change the default? Or what else could have changed it?
1 Like
Interesting - I wonder if that is the complete answer? Does anyone have a macOS 10.14 system to check those sysctl values before Catalina? I did raise a case to Apple (FB7431553) so I've added a note to that with your finding of the sysctl, @stv0g!
I updated my systctl per your suggestion, but I also thought to check the IPv4 version - even stranger value "41" in there?!
iMac-2017:~ michthom$ sudo sysctl -a | grep rtexpire
net.inet.ip.rtexpire: 41
net.inet6.ip6.rtexpire: 3600
1 Like
@michthom I just the sysctl after a reboot again and got 62 as a value back..
I cant figure our how macOS determines this value.
Stranger still - this isn't a Catalina exclusive. My Mojave 10.14.6 system has rtexpire also set to 10, and after I manually set the value on my Catalina 10.15.4 system yesterday, checking it this morning it was back at 10! So this is being managed dynamically somewhere / somehow...
And now I think about the events described above, I'll be surprised if the value does NOT change after the Mac goes into sleep mode:
the Mac was stable while it stayed awake (12 hours with no problems at all) but after I let it sleep the old problem returned after it woke
Aha - progress in my understanding. I found the following interesting comment here:
A dynamic process is in place to modify the value of net.inet.ip.rtexpire if the number of cached routes grows too large. If after an expiration run there are still more than net.inet.ip.rtmaxcache unreferenced routes remaining, the rtexpire value is multiplied by 3/4, and any routes which have longer expiration times have those times adjusted. This process is damped somewhat by specification of a minimum rtexpire value (net.inet.ip.rtminexpire), and by restricting the reduction to once in a ten-minute period.
I have
iMac-2017:~ michthom$ sudo sysctl -a | fgrep ip6.rt
net.inet6.ip6.rtexpire: 1600
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.rtmaxcache: 128
(note already reduced from the 3600 I started with 18 minutes ago!) but
iMac-2017:~ michthom$ netstat -rna | fgrep W3 | wc -l
235
So - is my problem that rtmaxcache is set too low? I shall try upping that to 256 and see what happens...
iMac-2017:~ michthom$ sudo sysctl net.inet6.ip6.rtmaxcache=256
net.inet6.ip6.rtmaxcache: 128 -> 256
iMac-2017:~ michthom$ sudo sysctl net.inet6.ip6.rtexpire=3600
net.inet6.ip6.rtexpire: 1600 -> 3600
iMac-2017:~ michthom$ sudo sysctl -a | fgrep ip6.rt
net.inet6.ip6.rtexpire: 3600
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.rtmaxcache: 256
Reading all this again, I'm struck that the mechanism that's trimming routes is all about unused cached routes, so I suspect the deeper root cause needs a network guru to explain - right at the beginning my Mac was working fine with a cloned route ('W' flag) so long as the gateway was set to 'link#4' but as soon as the gateway was the MAC address of that interface, it broke. But the failing route is also cloned, so this feels like a red herring?
I am seeing the same problem here on macOS interface en0, the route to the public prefix address of the openwrt interface being dropped. The ULA prefix route to openwrt is still there and you can ping that address without problems.
Interestingly you can restore the public prefix route to openwrt immediately by pinging the public prefix IP address of the openwrt interface that is talking to the mac.
My understanding is that the client should be able to get an RA with the route on demand if it tries to communicate across the local link, but I am no expert how this works and why it fails to work with macos.
Did apple not come up with a solution?
I am running OpenWRT 19.07.3 and Catalina 10.15.6, here are the sysctl values:
net.inet6.ip6.rtexpire: 62
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.rtmaxcache: 128
I started to use 'Always announce default router' enabled today on the internal interfaces (LUCI > Network> Interfaces > > DHCP Server > IPv6 settings). Since then the upstream route was not dropped by my mac.
I am not sure if that solves the problem, but you might also want to try it.
Justin, thanks for the "announce default router" tip - I shall give that a try. I confess I'd given up and disabled IPv6 as I'd not made any headway. This might be just what I needed all along!
I hope it helps. It is still working for me.