-
Thomas Haller authored
The order of addresses can matter for source address selection. This is described in RFC 6724 section 5, but if the rules don't determine a clear winner, the order matters. Change the relative order of IPv6 addresses. Previously, we would prefer autoconf6, over DHCPv6, over manual addresses. Now that got reverted to make more sense and be consistent with IPv4. Also, if we had multiple autoconf6 addresses (received at different moments in time), then previously a newly received address would be added with highest priority. Now, the older address will be preferred and that order will be enforced (this can be a problem, see (*) below). For IPv4, it's all simple and sensible. When we add addresses in kernel via netlink, the first address (of a subnet) becomes the primary. Note that we only control the order of addresses of the same subnet. The addresses in ipv4.addresses" are sorted with primary address first. In the same way is the order for addresses in NML3ConfigData and for @known_addresses in nm_platform_ip_address_sync(), all primary-first. Also, manual addresses are sorted with higher priority compared to DHCPv4 addresses (at least since NetworkManager 1.36). That means the way how we merge NML3ConfigData makes sense (nm_l3_config_data_merge()) because we first merge the static configuration, then the DHCPv4 configuration, where we just append the lower priority DHCPv4 addresses. For IPv6, the address priority is messed up. On netlink/kernel, the last added address becomes the preferred one (we thus need to add them in the order of lowest priority first). Consequently and historically, the IPv6 addresses in @known_addresses parameter to nm_platform_ip_address_sync() were lowest priority first. And so they were tracked in NML3ConfigData and in the profile ("ipv6.addresses"). That is confusing. Also, we usually want to merge NML3ConfigData with different priorities (e.g. static configuration from the profile before autoconf6/DHCPv6), as we do with IPv4. However, since internally IPv6 addresses are tracked in reverse order, it means later NML3ConfigData would be appended and get effectively a higher priority. That means, autoconf6 addresses were preferred over DHCPv6 and over manual "ipv6.addresses", respectively. That seems undesirable and inconsistent with IPv4. Change that. This is a change in behavior. Note that changing the order of addresses means to remove and re-add them in the right (inverse) order, with lease important first. This means, when we add a new address with lower priority, we need to remove all higher priority addresses temporarily, before readding them. That is a problem(*). Note that in the profile, "ipv6.addresses" is still tracked in reverse order. This did not change, but might change later.
To find the state of this project's repository at the time of any of these versions, check out the tags.