IPv6 preferred_lft address behaviour

Project Discussion
, ,
1

Hi everyone, I would like to hear your thoughts on changing the default behaviour of Fedora when it comes to multiple preferred IPv6 addresses.

TLDR: When there are multiple IPv6 addresses with a preferred lifetime > 0, Fedora seems to not pick the newest one but keeps on trying to use an old one with a preferred lifetime > 0, which won’t work. This behaviour leads to problems in networks where the ISP gives out non-persistent IPv6 prefixes. Android seems to prefer always the newest prefix and works without a problem in such an environment.

Long Story: There are ISPs, mine is one of them, who do not give their customers a persistent IPv6 prefix, but give out a new prefix together with a new IPv4 address on reconnects. The router will get this new prefix via DHCPv6. The Router will then send Router Advertisement packages to tell the devices in the different subnets that there is a new prefix for which they should generate an IPv6 address and it will also send Router Advertisement packages with the old IPv6 prefix and the preferred lifetime of this prefix set to 0, effectively disabling the old prefix so that only the new one will be used by the devices. This works fine with Fedora, since there always is only one IPv6 address that is preferred and will therefore be used.

But there is one scenario when Fedora has a real problem (and Alma Linux 10, which I have tested, most probably also RHEL, which I have not tested): If the Router gets rebooted or looses power and then restarts, it will reconnect to the ISP and will get an new IPv6 prefix. It will then send this prefix to the devices in its networks via Router Advertisement. But some Routers only keep the old prefixes in memory, which is lost at reboot, and therefore can not invalidate the old prefix after boot. Mikrotik is one of these Routers that behaves like this. Which leads to Fedora having two (or more) IPv6 addresses that are “preferred”. Fedora will then try to use an old one, which will not work, since the ISP will route only the newest one, effectively leaving Fedora without IPv6 connectivity until the preferred lifetime of the old IPv6 has run out.
Here is how that looks like:

$ ip a
…
inet6 2a02:3100:47cd:2804:d54a:5224:6b9d:cd4d/64 scope global dynamic noprefixroute 
   valid_lft 239059sec preferred_lft 152659sec
inet6 2a02:3100:3c90:d904:7c5c:44f6:255b:74f6/64 scope global dynamic noprefixroute 
   valid_lft 239170sec preferred_lft 152770sec
inet6 2a02:3100:3f5e:b104:55ba:fcbd:1388:e964/64 scope global dynamic noprefixroute 
   valid_lft 2573075sec preferred_lft 585875sec
…
$ ping 2606:4700::6810:85e5
PING 2606:4700::6810:85e5 (2606:4700::6810:85e5) 56 data bytes
^C
— 2606:4700::6810:85e5 ping statistics —
6 packets transmitted, 0 received, 100% packet loss, time 5118ms

If I delete now the two older Adresses it works again:

# ip -6 a del 2a02:3100:47cd:2804:d54a:5224:6b9d:cd4d/64 dev eno1
# ip -6 a del 2a02:3100:3c90:d904:7c5c:44f6:255b:74f6/64 dev eno1
# ip a
…
inet6 2a02:3100:3f5e:b104:55ba:fcbd:1388:e964/64 scope global dynamic noprefixroute
valid_lft 2572734sec preferred_lft 585534sec
…
# ping 2606:4700::6810:85e5

PING 2606:4700::6810:85e5 (2606:4700::6810:85e5) 56 data bytes
64 bytes from 2606:4700::6810:85e5: icmp_seq=1 ttl=59 time=9.28 ms
64 bytes from 2606:4700::6810:85e5: icmp_seq=2 ttl=59 time=8.65 ms
64 bytes from 2606:4700::6810:85e5: icmp_seq=3 ttl=59 time=9.21 ms
^C
— 2606:4700::6810:85e5 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 8.647/9.045/9.276/0.282 ms

And here is more information on this topic from RIPE: https://www.ripe.net/publications/docs/ripe-690/#5-end-user-ipv6-prefix-assignment-persistent-vs-non-persistent

So, my suggestion is that Fedora should always use the newest IPv6 address it has available. In my tests, this is what Android seems to do as well. But maybe there is a good reason why Fedora does it the way it is now (?) and it is solely the responsibility of the router manufacturers to remember old IPv6 prefixes after reboot and keep invalidating them.

Thoughts?

2

Since the issue is not Fedora specific, it is best to report upstream:
Issues · NetworkManager / NetworkManager · GitLab

As a workaround, you can create a dispatcher script that deprecates older prefixes:
NetworkManager-dispatcher: Dispatch user scripts for NetworkManager | Man Page | System Administration | NetworkManager | ManKier

2 Likes
3

Will do :+1:

EDIT: Anyone interested can find the upstream ticket here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/work_items/1927

1 Like
4

This is not even NM specific. This is more of a IETF RFC problem. IPv6 is a complex beast. It allows you to have multiple /64 prefixes but how the node chooses which prefix and which router is not well-defined. Most netadmins just avoid having multiple GUAs in the same L2. You could fiddle with route preferences in RA, but even that field is optional so you can’t expect it to work on every implementation.

It’s a defect in v6 specs. Fedora people can’t help you. Neither could IETF guys because I don’t think anyone at IETF thinks that this is a serious problem thus far. Just don’t allow multiple /64 GUA prefixes in the same L2. Period. If you still want some sort of active-backup L2 set up, try segmenting the VLAN and having multiple routers doing DHCP-PD.

Fedora has nothing to do with it. It should be done in the kernel.

Next time, I’d advise revealing your /64 prefixes for privacy reasons.

Edit: Design Clinic: Small-Site IPv6 Multihoming « ipSpace.net blog

5

This is not even NM specific. This is more of a IETF RFC problem.

If there is a need to blame someone, it would be the ISP in my opinion. IPv6 is designed in a way where you should get a static subnet from your ISP, since there is no need for a shared IP address pool between customers like with IPv4.

IPv6 is a complex beast. It allows you to have multiple /64 prefixes but how the node chooses which prefix and which router is not well-defined.

Yes, and since it is not well defined it is up to us to do the most sane thing by default. That’s why I posted this in “Project Discussion”, so that the default setting in Fedora could be changed (if deemed desirable and possible). But changing this upstream is also a good idea from @vgaetera , so I opened the ticket there. And since what I suggested is what Android already does, I suppose there isn’t a huge reason not to.

It’s a defect in v6 specs.

I don’t think it is a defect. It’s just how IPv6 works and I don’t see a problem with it. The problem is my ISP treating it like it is IPv4 and throwing around non-persistent subnets.

Fedora people can’t help you.

Interestingly, I am trying to help Fedora.

Neither could IETF guys because I don’t think anyone at IETF thinks that this is a serious problem thus far.

And I also don’t think it is a problem on part of the IETF. I think the problem is just the way it is handled by default by NetworkManager. And of course on part of my ISP, but there are so many ISPs that some will always do weird things and we have to be prepared anyway for that. And going on from there, it could also be argued that it is a problem with my Mikrotik router for only storing the old prefixes in RAM instead of writing them to disk to be able to invalidate them with router advertisements after reboot if there is a new prefix from the provider. This is also what RIPE suggests in the link I have posted. But again, there will always be routers that do things in less optimal ways and we should be prepared for that.

Just don’t allow multiple /64 GUA prefixes in the same L2. Period. If you still want some sort of active-backup L2 set up, try segmenting the VLAN and having multiple routers doing DHCP-PD.

Well thank you. I don’t intend to. I suppose you have only read the TLDR and not the rest where I describe exactly what is happening and why, so that there is no need for you to just make something up.

Next time, I’d advise revealing your /64 prefixes for privacy reasons.

I assume you’ve meant to write “redacting” instead of revealing. And I don’t care.
First of all, I get a new one every day (and I wish I wouldn’t).
Second, I would love for people to do a quick whois on the IP so that I can subtly shame the provider without having to name him. Actually, now that I have said that, it isn’t so subtle anymore.
And third, I post here with my full name. You can find my E-Mail address in pretty much all my git commits. You can look up my current IP address by just resolving any of my domains. So really, I decide what I want to keep private and what I want to post online and I have decided to not scramble up the terminal output unnecessarily when I don’t consider that information private at all.

Anyway, I will just assume that you tried to be constructive instead of venting a gripe you have with IPv6. And you can assume that I have given you feedback on how to be even more constructive next time.

6

Don’t know why took that personally. Well, if you don’t know how to filter DHCP-PD, you’re as clueless as your ISP is.

Good bye.

1 Like