IPv6 address lifetime

Forum|Forum|3 years ago
July 27, 2022
3 replies
4938 views

I have a bit of confusion about IPv6 and SLAAC. I am testing this before trying to use it for our public wifi network.

My problem is with preferred and valid lifetimes which are set as 7 days and 30 days respectively by default. I tested with a Win2019 server. I got basic connectivity working. The current IPv6 setup for this internal interface is this (1:2:3 as replacement for real address and I use IPv4 DNS-servers therefore the other-flag has not been set even though it worked even when this was present but no rdnss set):

config ipv6
set ip6-address 1:2:3:2::1/64
set ip6-allowaccess ping
set ip6-retrans-time 4000
set ip6-send-adv enable
config ip6-prefix-list
edit 1:2:3:2::/64
set valid-life-time 61
set preferred-life-time 60
next
end
end

These short lifetimes I made for testing. Before I tested with valid 600 and preferred 300 and since I noticed loss of connectivity, I lowered these values to get a quicker overview what's happening. And here's how it works: I ping 2606:4700:4700::1111 which works for 60 seconds/pings and then I get "General failure" for the next 315 or 389 or 475 pings (just the last three values that I counted) after which the ping will start working again for 60 seconds and then the General failure follows for some longer amount of number of pings/seconds. When I had 600/300 seconds, the loss of connectivity appeared at some point after the preferred lifetime was already 0 and the valid lifetime was ticking to 0, maybe 70 seconds or so. During the loss of connectivity, there is no public IPv6 address in the list when I checked with "netsh interface ipv6 show address" from PS CLI and that's the cause for "General failure".

I am concerned about it because if the defaults which are 7 days and 30 days are used, does that mean that a computer that is possibly connected all the time will lose the IPv6 connectivity after 7 days or more and then it is lost for who knows how long and the IPv6 sessions get disrupted until the address randomly "appears" again and the user's web browser or OS starts preferring it again?

Of course I can change those lifetimes to something longer but it looks like there's that strange loss of address anyway whatever the configuration. It's FortiOS 6.4.4 and here the onlink and autonomous flags are default so they're not shown in the configuration anymore.

I am thankful if somebody could make sense of this behaviour and give a hint how to prevent the loss of IPv6 address during the address recycling timeframes. Or do the default 7/30 days actually work and the problem is only in this kind of testing with shorter values?

More tests on the next day: using valid/preferred times 3600/120, it behaves similarly. More precisely: after the valid time 120 ticks to zero, the websites don't work anymore with IPv6. Some IPv6 testing sites only say that I don't have IPv6. When opening one site ip6only.me my Chrome browser said DNS_PROBE_FINISHED_NXDOMAIN which is strange because I use IPv4 DNS-resolvers and they definitely resolve this DNS name so there should be a timeout instead; going to the same website's IP https://[2001:4838:0:1b::201]/ worked, it showed my IPv6 address this way. But now I found that after some time the preferred time started countdown again and then websites worked again over IPv6 but after the preferred lifetime went 0 they even continued to work this time. Some times later stopped working again. Also the valid lifetime was updated as for an hour again for some reason. Is this happening when new connections are being made and in the meantime the IPv6 is partly not functioning? I made some new connections as opening a new webpage but they still didn't work over IPv6. At the same time the ping worked all the time because the address was present, even a new ping to another address. Very confusing and I'm not sure how can I trust the longer time periods this way. Maybe it is all OK if the default preferred 7 days depends on users leaving the network at some point during those 7 days and will "renew" their address this way when just reconnecting.

FortiGate

Anthony_E

Staff

Hello echo,

Thank you for using the Community Forum.

I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Regards,

Best Regards

echoAuthor

Explorer II

TL;DR: It may be that I resolved the issue. It was about too short timers. When setting it to 3600/1800 all started working normally.

Here's more for those who want to know the details.

I thought maybe the Win2019 server is not really meant for SLAAC but rather for DHCPv6 or static configuration. I went to the office to test it with two laptops, Windows 10 and Linux Mint. But before that I also checked the lifetimes in my home network behind a smaller Fortigate. There I saw that both a Windows 10 desktop computer and a Linux Mint laptop got 30 minutes preferred and valid lifetimes and these were renewed in time so it never went under 20 minutes and therefore never timed out as well. Besides, I haven't experienced any IPv6 disconnects at home ever since I got it working about a year ago. I think I didn't touch the valid/preferred lifetimes in my home Fortigate but this I need to check later.

In the office behind the big Fortigate things seemed worse. I used wifi for testing. A Windows 10 laptop took the same 3600/120 lifetimes from the Fortigate and when the 120 seconds was over it lost IPv6 connectivity just like the Win2019 server did. But that caused the Windows to start a diagnostic because I saw how the Wifi was shortly disabled and enabled automatically and after that it connected to another wifi network that was preferred (and without IPv6). When I reconnected, it didn't get the SLAAC address, or if it did then after waiting for about 5 or 10 minutes.

The Linux behaved much better in the same WLAN in the same time as I tested with Windows 10 laptop. Initially, it didn't get the SLAAC address at all (why?) but eventually it did. Checking with "ip a" I saw that it also got the preferred and valid timers as specified in the IPv6 config in Fortigate. After the preferred lifetime ticked down to 0 ("ip a" showed it) the valid lifetime was periodically renewed without the preferred time being renewed; still, the preferred lifetime was also renewed periodically, just less often. But I never lost the IPv6 connectivity with this Linux Mint laptop with 3600/120. The valid lifetime never went lower than about 3100 seconds and the IPv6only.me showed my address even when the preferred lifetime was 0 for a while.

So there is dependency on the operating systems how they handle/renew the SLAAC timers given to them.

Then I got an idea: what if the Windows 10 considers 120 seconds as a lifetime which was meant by the network administrator to get rid of the address? That is, it's too short? And in this case it is just the problem with my testing timers only. Because at home it was 30 minutes and with no problems. Also there are some RFC's about it, like this, a good one about timers and considerations regarding networking changes with IPv6:
https://datatracker.ietf.org/doc/html/rfc8978 They propose valid/preferred lifetimes of 90 minutes / 45 minutes.

I changed the valid/preferred timers to 3600/1800, that is, 1h/30m. And there you go: now the preferred lifetime never went under 20 minutes on the Linux Mint laptop and two different Windows 10 laptops that I used to test the IPv6 connection, so it was renewed in time. The Linux Mint also renewed the timer now so it didn't go to 0 anymore, that is, this OS also considers 120 seconds too short but instead of losing connectivity, it survived the disconnect. Win2019 testing server also renews it's preferred lifetime in time. It looks like 20 or 21 minutes is the shortest lifetime to use for setting a preferred lifetime. And also it means that most possibly the long default values work well except when considering cases presented in rfc8978.

Anthony_E

Staff

Thank you for your feedback !

Best Regards

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded