Bug 2097293
| Summary: | fix order/priority for IPv6 addresses configured by NetworkManager in [rhel-9.1] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Thomas Haller <thaller> |
| Component: | NetworkManager | Assignee: | Thomas Haller <thaller> |
| Status: | CLOSED ERRATA | QA Contact: | Vladimir Benes <vbenes> |
| Severity: | unspecified | Docs Contact: | Jaroslav Klech <jklech> |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | bgalvani, desktop-qa-list, jklech, lrintel, nm-team, rkhan, sukulkar, till, vbenes |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.39.7-2.el9 | Doc Type: | Bug Fix |
| Doc Text: |
.The `NetworkManager` utility enforces correct ordering of manually added IPv6 addresses
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. This update fixes the problem and the ordering priority now reflects this logic: `manual` > `dhcpv6` > `autoconf6`. Also, the order of addresses under the `ipv6.addresses` setting was reversed so that the address added first has the highest priority.
|
Story Points: | --- |
| Clone Of: | 2097270 | Environment: | |
| Last Closed: | 2022-11-15 10:50:05 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: | 2097270 | ||
| Bug Blocks: | |||
|
Description
Thomas Haller
2022-06-15 11:32:32 UTC
note there is a difference between what we will do in rhel-9.1 (this bug) and rhel-8.7 (bug 2097270). on 9.1+, we will follow fully upstream behavior. on 8.7+, we will have a downstream patch, so that the order of "ipv6.addresses" is reversed, as it used to be (see https://bugzilla.redhat.com/show_bug.cgi?id=2097270#c5). An order should now be similar to upstream (we got rid of the reverse order of IPv6 addresses) https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/blob/main/features/scenarios/ipv6.feature#L1055 the bug 2097293 (RHEL-9.1) and bug 2097270 (RHEL-8.7) are very similar. Various aspects changed, regarding the order of addresses. Maybe start by saying why the order matter: it affects the priority for source address selection (e.g. when you make an outgoing TCP connection). RFC 6724 section 5 describes and kernel implements which address to select, and only as last resort -- when all parameters are equal -- the order that you see in `ip -6 addr` matters. What now changed, is that manual addresses are preferred over DHCPv6 addresses, which are preferred over autoconf6 addresses. Well, actually, there was a lot of back and forth over this. So, strictly speaking older verions (<= 8.5) had that partly too. In any case, now it's rectified, tested, and all good. The only difference between RHEL-8 and RHEL-9 is, that in the past, if you have `ipv6.addresses=a:b::1/64 a:b::2/64`, then `a:b::2/64` was preferred. That was inconsistent with `ipv4.addresses`. On RHEL-8 (bug 2097270) that is still the case, and manual addresses are in unexpected(?) but unchanged order. With RHEL-9.1+, the order is now fixed/reversed. about the doctext: - maybe start by saying why the order of addresses matters at all. - just say, that previously, the relative order/priority of IPv6 addresses between manual/dhcpv6/autoconf6 addresses was wrong, and it's now fixed (to prefer manual>dhcp>autoconf). - on rhel-9.1, also say that the order of `ipv6.addresses` was reversed (to refer the first address as highest priority). On rhel-8.7 that didn't change, but maybe drop a sentence about that fact. doctext lgtm. thanks Jaroslav! 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:8265 *** Bug 2079851 has been marked as a duplicate of this bug. *** |