Bug 2097270
Summary: | fix order/priority for IPv6 addresses configured by NetworkManager in [rhel-8.7] | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Thomas Haller <thaller> | |
Component: | NetworkManager | Assignee: | NetworkManager Development Team <nm-team> | |
Status: | CLOSED ERRATA | QA Contact: | Vladimir Benes <vbenes> | |
Severity: | unspecified | Docs Contact: | Jaroslav Klech <jklech> | |
Priority: | unspecified | |||
Version: | 8.6 | CC: | bgalvani, jklech, lrintel, rkhan, sukulkar, till, vbenes | |
Target Milestone: | rc | Keywords: | Triaged | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | NetworkManager-1.39.7-2.el8 | Doc Type: | Bug Fix | |
Doc Text: |
.The `NetworkManager` utility enforces correct ordering of IPv6 addresses from various sources
In general, the ordering of IPv6 addresses affects the priority for source address selection. For example, when you make an outgoing TCP connection. Previously, the relative priority of IPv6 addresses added through the `manual`, `dhcpv6`, and `autoconf6` methods, was not correct. With this update, the problem has been fixed and the ordering priority now reflects this logic: `manual` > `dhcpv6` > `autoconf6`. However, the order of addresses under the `ipv6.addresses` setting did not change and the address added last still has the highest priority.
|
Story Points: | --- | |
Clone Of: | ||||
: | 2097293 (view as bug list) | Environment: | ||
Last Closed: | 2022-11-08 10:10:38 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2079851, 2097293 |
Description
Thomas Haller
2022-06-15 10:20:35 UTC
IPv6 source address selection is defined in rfc6724, and that is what kernel implements https://datatracker.ietf.org/doc/html/rfc6724 It lists 8 rules for sorting/comparing addresses to find a best one. However, in case of a tie, the RFC says: If the eight rules fail to choose a single address, the tiebreaker is implementation-specific. This is what we are talking about, and where the order of IP addresses becomes relevant. Alternative solutions are of course to configure static routes with "src" attribute. For DHCPv4, we will now automatically set the "src" attribute for routes obtained via DHCP. However, DHCPv6 does not provide routes, so this is only a solution for static addresses. It still seems kinda important to prefer DHCPv6 over SLAAC. See also the linked bugs in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/6920b6ceb1c2e7856ad76e118ee5b4dd36130735 (In reply to Thomas Haller from comment #0) > - the order of manual addresses in "ipv6.addresses". On upstream `main` the > first address in the list will be preferred, previously it was the last. I > would also do this change, as part of the bugfix, because the new behavior > makes more sense. Also, because who even configures static IPv6 addresses, > and who configures more of one of them, and who then also cares about their > priority? I'd hope this would affect very few people, but as we already had > broken behavior in 8.6, I would take this opportunity to fix it once and for > all. I agree with the plan, but I'm not sure about changing the quoted part. While for DHCPv6 vs SLAAC vs static there are some addresses that should have more priority than others, for static addresses the order is arbitrarily decided by NM. I wouldn't change this convention in a minor RHEL8 release just because upstream did it. (In reply to Beniamino Galvani from comment #3) > (In reply to Thomas Haller from comment #0) > I agree with the plan, but I'm not sure about changing the quoted part. While > for DHCPv6 vs SLAAC vs static there are some addresses that should have more > priority than others, for static addresses the order is arbitrarily decided > by NM. > I wouldn't change this convention in a minor RHEL8 release just because > upstream > did it. OK, then lets keep that aspect in rhel-8.7+. What about rhel-9.1+? > OK, then lets keep that aspect in rhel-8.7+. Sounds good. > What about rhel-9.1+? For RHEL 9 I think it's fine to adopt the upstream behavior. (In reply to Beniamino Galvani from comment #5) > For RHEL 9 I think it's fine to adopt the upstream behavior. See: https://bugzilla.redhat.com/show_bug.cgi?id=2097293#c6 we still preserve reversed order of IPv6 addresses, but addresses are strictly kept that way and not changing anyhow when we send them in different order later on, we will keep this in rhel8.x https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/blob/main/features/scenarios/ipv6.feature#L1003 doctext lgtm, thanks Jaroslav. If I had a tiny complaint, from "However, the order of addresses under the `ipv6.addresses` setting was not reversed and the address added last has the highest priority." it sounds not very clear that this is a no-change. It was like this, and didn't change (although we changed in rhel-9.1+ and upstream). But good as-is. (In reply to Thomas Haller from comment #12) > doctext lgtm, thanks Jaroslav. > > If I had a tiny complaint, from "However, the order of addresses under the > `ipv6.addresses` setting was not reversed and the address added last has the > highest priority." it sounds not very clear that this is a no-change. It was > like this, and didn't change (although we changed in rhel-9.1+ and > upstream). But good as-is. Thanks Thomas, i updated the text in this bugzilla based on your feedback. I am assuming that the text in bz#2097293 (9.1 counterpart) looks good to you as well? Regards, Jaroslav (In reply to Jaroslav Klech from comment #13) > i updated the text in this bugzilla based on your feedback. lgtm Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:7680 *** Bug 2073032 has been marked as a duplicate of this bug. *** |