mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-05-18 19:48:08 +02:00
4a548423b9
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.
|
||
|---|---|---|
| .. | ||
| tests | ||
| wifi | ||
| wpan | ||
| meson.build | ||
| nm-linux-platform.c | ||
| nm-linux-platform.h | ||
| nm-netlink.c | ||
| nm-netlink.h | ||
| nm-platform-private.h | ||
| nm-platform-utils.c | ||
| nm-platform-utils.h | ||
| nm-platform.c | ||
| nm-platform.h | ||
| nmp-base.h | ||
| nmp-netns.c | ||
| nmp-netns.h | ||
| nmp-object.c | ||
| nmp-object.h | ||
| nmp-route-manager.c | ||
| nmp-route-manager.h | ||
| README.md | ||
libnm-platform
A static helper library that provides NMPlatform and other utils.
This is NetworkManager's internal netlink library, but also contains
helpers for sysfs, ethtool and other kernel APIs.
NMPlaform is also a cache of objects of the netlink API: NMPCache
and NMPObject. These objects are used throughout NetworkManager
also for generally tracking information about these types. For example,
NMPlatformIP4Address (the public part of a certain type of NMPObject)
is not only used to track platform addresses from netlink in the cache,
but to track information about IPv4 addresses in general.
This depends on the following helper libraries