RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1743161 - [RFE] Expose ipv6.addr-gen-mode option to the global config
Summary: [RFE] Expose ipv6.addr-gen-mode option to the global config
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.7
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-19 08:58 UTC by Edward Haas
Modified: 2022-06-29 06:21 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Expose ipv6.addr-gen-mode option to the global config Reason: In some scenarios, it is useful to consistently get the same IP address from the DHCP server and/or router. One example, is when a bridge is created over an existing interface that has a dynamic IP and the bridge is expected to get the same IP address its port had. ipv6.addr-gen-mode and ipv6.dhcp-duid are used to control this. However, unlike ipv6.dhcp-duid, ipv6.addr-gen-mode cannot be set globally (in the NM config). It would be useful to set this value at the global level in order to give the system admin the ability to control the system defaults. Result:
Clone Of:
Environment:
Last Closed: 2022-01-26 07:27:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Edward Haas 2019-08-19 08:58:49 UTC
Description of problem:
In some scenarios, it is useful to consistently get the same IP address from the DHCP server and/or router. One example, is when a bridge is created over an existing interface that has a dynamic IP and the bridge is expected to get the same IP address its port had.

ipv6.addr-gen-mode and ipv6.dhcp-duid are used to control this.
However, unlike ipv6.dhcp-duid, ipv6.addr-gen-mode cannot be set globally (in the NM config).

It would be useful to set this value at the global level in order to give the system admin the ability to control the system defaults.

Version-Release number of selected component (if applicable):
NM 1.20

How reproducible:
100%

Steps to Reproduce:
1. Define in the NM config file:
   [connection]
   ipv6.addr-gen-mode=0
   ipv6.dhcp-duid=ll
2. Define a NIC with ipv6 auto and make sure IPv6 addresses are assigned.
3. Create a bridge and attach the NIC to the bridge + define IPv6 auto on the bridge.
4. Check that on the bridge, the same IPv6 addresses have been assigned.

Actual results:
The IPv6 addresses posix are different.

Expected results:
Identical IPv6 addresses.

Additional info:

Comment 1 Thomas Haller 2019-08-19 13:35:05 UTC
note that global defaults in `NetworkManager.conf` are useful, and they are not.

For a user/admin, they are useful because you can override default policies.

However, for an application (like nmstate) they are not useful because:

 - it can only be configured via configuration files, there is no real API for doing that.

 - if you have a connection profile with a certain property set to the default (which allows fallback to the global default), then you cannot see the effective value from the D-Bus API. In fact, you don't know which and whether the default value is configured.

Hence, this is not good for an application to rely on in any way. It may be useful for the user, who is in control of the entire system. But an application usually does not own the entirety of NetworkManager configures (note that global defaults apply to all profiles).



So, while the feature request might be mildly interesting. I don't see how that would be useful for nmstate at all.


Can you elaborate more on the use-case where this would be useful?


Note that we commonly don't advertise users to set global defaults because of these short comings. In most cases it's better to configure the value per-profile, for which there is an D-Bus API and where the scope is well defined (it only affects the profile that you supposedly "own" for modification).

Comment 2 Edward Haas 2019-08-20 10:44:24 UTC
(In reply to Thomas Haller from comment #1)

It is useful for a system wide requirement and applications like nmstate may require the system to behave in a certain way.
But, the actual need comes from users of nmstate, like VDSM, which require the behaviour mentioned on the system as a whole.

We have been using initscripts so far (in VDSM) and this was the expectation from DHCPv4 and DHCPv6.
We need this at the host/system level.

We can add it to nmstate as its own default and when asked to change it, to introduce a key in the schema for it.
But we could avoid that by letting the admin or one of the applications to set the NM conf (on install).

Comment 3 Thomas Haller 2019-08-20 11:03:03 UTC
The problem is that such settings are in the end per-device configuration options.

Now, on Linux we usually struggle to name a device uniquely across reboot. That means, while the host is running, each interface has a unique and clear identifier: the ifindex. But after reboot, the ifindex gets reassigned anew. So, we commonly match a per-device settings somehow differently, for example via the interface-name or the MAC address.

But it's not uniformly clear how to identify a device. Do you want by interface-name? That's probably a good idea, nowadays with predictable interface-names. Do you want per-MAC address? Then after replacing the hardware, the setting no longer matches, etc. It depends on what you want!


NM's connection profiles (like ifcfg-files) solve that by allowing to match the profile to a device by setting one or several of these parameters. There is an API in NetworkManager to create profiles.

But global defaults don't have a D-Bus API and can only be set by the user typing an .conf file (or a program dropping such configuration snippets). But that is not a suitable API that a program could use, since it's not settable via D-Bus. How could a D-Bus API for such global defaults look like? In a way, they would be like connection profiles in that they have settings for configuring the network, and then they have specifiers how the match to a device. They would require their own D-Bus objects, and a sensible manner how regular profiles can be merged/augmented with such global-default-profiles upon device activation. All of this sounds horribly complicated, even to concevie how that would work. Which strongly indicates that it's a bad idea to do it.

Just set the per-profile values accordingly.



> It is useful for a system wide requirement and applications like nmstate may require the system to behave in a certain way.
But, the actual need comes from users of nmstate, like VDSM, which require the behaviour mentioned on the system as a whole.

It's not clear to me why that is useful, or how it would work in detail. When activating a device, you need a connection profile. Set all the relevant profiles according to the desired settings. Where do you need a way for setting a default?

> We have been using initscripts so far (in VDSM) and this was the expectation from DHCPv4 and DHCPv6.

What are initscripts doing? You mean having addr-gen-mode=eui64? Well, then set addr-gen-mode=eui64 per-profile. The profile is under nmstate's full control, you certainly should not rely on defaults if you want addr-gen-mode=eui64, but set it explicitly -- in all the profiles where it applies.

Comment 4 Edward Haas 2019-08-20 18:06:48 UTC
The lazy users prefer not to define all parameters and use defaults. Making the defaults programmable rather than static is useful for admins (and apps), allowing to define their expected behaviour without having to explicitly mention it per profile.
Not imposing the defaults in nmstate (or NM) statically allows the users to control this and adjust the logic per their needs.
How to do it through d-bus? I am not an expert, but I guess having a default profile or just a NM level entity that makes it editable sounds reasonable to me. If a parameter is not defined by the user, it resolves to the global default and then if missing there as well, to the static defaults (I guess the existing conf can be loaded to the programmatic global default DB as part of the init).
But I do not really look for a generic solution at the moment. I am looking to allow the IPv6 ability to control the DHCP identifier at the global level the same way IPv4 is available.

> It's not clear to me why that is useful, or how it would work in detail. When activating a device, you need a connection profile. Set all the relevant profiles according to the desired settings. Where do you need a way for setting a default?

I want VDSM to define the expected behaviour by setting these globals. This allows nmstate to be used for both VDSM and other usages that may not want these defaults.
Obviously we can define a conf file or API for nmstate to control it, however, nmstate does not include at the moment a persistent storage (DB, file), it used NM for that. I am also not that inclined to model defaults in nmstate, especially when something exists on NM. Said that, we can do it in nmstate if we will have no other choice.

At the moment, we do not see the enterprise users who are interested in managing this per profile/interface, therefore I prefer not to expose it in nmstate, but it may come in in the future, I cannot say.

Comment 5 Thomas Haller 2019-08-21 08:19:37 UTC
> The lazy users prefer not to define all parameters and use defaults. Making the defaults programmable rather than static is useful for admins (and apps), allowing to define their expected behaviour without having to explicitly mention it per profile.

That's why the default is the more sensible one: ipv6.addr-gen-mode=stable-privacy. If that default is not suitable for a certain user, they can change it. No default is every going to be perfect for every user.




> How to do it through d-bus?

currently you cannot.

> I am not an expert, but I guess having a default profile or just a NM level entity that makes it editable sounds reasonable to me.

well, sure it's doable. But for high complexity. Not only to implement, but somebody has to understand how this works and make use of it.

People struggle to understand the difference between a connection profile and a device's runtime configuration. It's so simple, but causes endless confusion.

gnome-control-center likes to present the network configuration not in terms of devices, not profiles. Likewise, nmstate prefers to think in terms of devices, and less in terms of profiles. So these two go the other way and try to abstract profiles away and pretend there is only one configuration for a device. Now you request that one profile is split into multiple bits of configurable settings, that get merged somehow.

How would such "super" profiles (that augments regular profiles with default values) work? Just imagine how that would be presented to the user in nm-connection-editor. If you cannot come up with a sensible way that the user can make use of that, then it's likely so complex that nobody is going to use it.



> I want VDSM to define the expected behaviour by setting these globals.

VDSM should not define globals for NetworkManager profiles. It does not own all settings, it owns a subset of connection profiles only. If VDSM would set global properties affecting all profiles, it would be wrong.

That could be solved by having such "super" profiles and a way how the are allowed to match/augment regular profiles. Like a tag (or an "include" directive). So VDMS could tag its own super profiles in a particular way, so that they only match with regular connection profiles owned by VDSM. But ... the sheer complexity indicates that it's a bad idea. 


> Obviously we can define a conf file or API for nmstate to control it, however, nmstate does not include at the moment a persistent storage (DB, file), it used NM for that. I am also not that inclined to model defaults in nmstate, especially when something exists on NM. Said that, we can do it in nmstate if we will have no other choice.

why would you need to persist anything outside of the input JSON/YAML? If you wish, you can have defaults there and are optinally provided. Of course, if they are not provided, it's like leaving the property unspecified.

{
  "defaults": {
     "ipv6": { "addr-gen-mode": "eui64" }
  },

  "profiles": {
     "profile1" : {
        "type": "ethernet",
        /* inherits default */
     }
     "profile2" : {
        "type": "ethernet", 
        "ipv6": { "addr-gen-mode": "stable-privacy", }
     }
  }
}     



> But I do not really look for a generic solution at the moment. I am looking to allow the IPv6 ability to control the DHCP identifier at the global level the same way IPv4 is available.

connection defaults in NetworkManager.conf are not a suitable solution, because there is no D-Bus API and because nmstate couldn't tag the defaults correctly to match only with profiles that it is concerned with. So, it certainly requires a larger new feature.


Maybe this is a nice feature. Maybe a connection could have an "connection.include=UUID" setting, that tell how to merge multiple profiles together... but so complicated...

Comment 7 Petr Horáček 2020-08-30 14:15:54 UTC
This BZ looks quite stale. Are there any plans to address it?

Comment 8 Thomas Haller 2020-08-31 08:23:18 UTC
(In reply to Petr Horáček from comment #7)
> This BZ looks quite stale. Are there any plans to address it?

I guess not.

- there are no plans to introduce something like "super profiles" / "default settings", which can be configured via D-Bus and where you can configure the profiles to which the defaults apply. Not because it wouldn't be doable, but because hardly anybody would grasp or use such a feature.

- nmstate should not configure systemwide defaults in NetworkManager. Doing so means that all profiles (that don't explicitly set addr-gen-mode) get a behavior imposed by nmstate. We want that different applications can use NetworkManager API together and thereby integrate (on a most basic level). nmstate (or any other NetworkManager client) should not impose a behavior for the entire system, but only for the profiles that it manages/owns. Yes, you might have a system we 100% of the profiles are controlled by nmstate, but it should be possibly to still add a profile with another tool and not being affected by nmstate's decision.

The solution is simple. Use the API that NetworkManager provides: connection profiles. And that implies that you configure your connection profiles with all the values that you care about (including addr-gen-mode, if that applies).



Global connection defaults in NetworkManager.conf are useful for special cases. IMO I don't think that nmstate should use that feature, if it would exist for addr-gen-mode.


Thus, closing.


If you still have a problem that cannot be solved, we need to understand the problem better. Please reopen then, but I don't think that global -connection defaults will be the solution.

Comment 9 Ryan Goodfellow 2021-03-01 18:15:03 UTC
So let's summarize this .... RedHat has decided to shove a network management platform designed for laptops onto servers, and now when a feature request for user configurable global defaults comes in, something ANY respectable server management platform is expected to have, the answer is, due to the way the laptop-driven abstractions have been designed, the complexity of doing this within NM would be too high and the answer is to force everything to look like a laptop and leak the complexity of managing a bunch of abstractions that have no place in the server domain onto the developers and operators of server systems that have to run RHEL. Great. 

Concrete use case: BGP unnumbered peering with loopback /32s following RFC 5549. The expectation in this setting is for EUI64 addresses in order to be able to connect the dots from the kernel's neighbor tables to a viable FIB target. So the need is for a global setting, or at least an aggregate setting for ipv6.addr-gen-mode=eui64, which is precisely the ask of the OP. Since NM seemingly takes over every device it sees, what this effectively means is that the complexity of implementing a default within YOUR software, interface by interface, in the very awkward 'connection profile' oriented way your software has chosen to organize things, is now up to OUR software.

Comment 10 Thomas Haller 2021-03-03 11:25:10 UTC
(In reply to Ryan Goodfellow from comment #9)

> in the very awkward 'connection profile' oriented way your software has chosen to organize things

Initscripts use ifcfg-files, and systemd-networkd uses .network, .link and .netdev files. These are profiles too and there is no fundamental difference here. Which is also evident because NetworkManager stores its profiles in ifcfg format...


The bug was closed due to lack of priority, but also because the solution is not clear -- aside the several options that you already have.


More use-cases are useful to better understand how a better solution could look like. So thanks for providing a use-case.



The setting "ipv6.addr-gen-mode" is part of (each) profile, and it is set according to how it was created.

How do you create the profiles? How many do you have? Why is it a problem to choose the right value, when you create the profile.

Presumably, you have multiple profiles, so are these profiles mostly identical otherwise? Don't they have different IP address settings? (aside connection.id, connection.uuid, connection.interface-name). How do they differ otherwise? If they are mostly identical, can you use one profile with "connection.multi-connect=multiple" setting and activate it on all devices?

There are few cases where NetworkManager itself creates a profile. Actually, only the auto-default profiles which are named like "Wired connection 1" (you can disable those by setting "no-auto-default" in NetworkManager.conf). Are you using those profiles and have no means to modify them? You can also modify these profiles, but can you for some reason not do that?

Comment 11 Dusty Mabe 2021-07-26 15:39:31 UTC
Another potential use for having a global configuration value would be in setting defaults for different classes of computer.

For example the ipv6.addr-gen-mode=stable-privacy setting applies well to a workstation/laptop model, but not so much for a server model where you may want IPv6 addresses to be more stable.

In Fedora if we had a global setting we could set the default to eui64 for "server-like" variants (Fedora Server, Fedora Cloud, Fedora IoT, Fedora CoreOS) and set it to "stable-privacy" for more "desktop-like" variants (Fedora Workstation, Fedora Silverblue, etc..). https://github.com/coreos/fedora-coreos-tracker/issues/907

In Fedora CoreOS land we are currently hitting an issue where our openstack images are getting different IP addresses than what is displayed in the openstack console. We'd like to be able to set the system to use eui64 in this case without having the user create connection profiles with that setting in it.

Should we reconsider being able to set a default for this at a higher level?

Comment 14 Pepijn Oomen 2021-08-16 18:12:11 UTC
This issue bleeds over into OKD4 when using OVNKubernetes.

In that case the script generating the bridge-interfaces is not specifying ipv6.addr-gen-mode resulting in stable-privacy, which in turns prevents OpenStack access since the IPv6 address is not the one that OpenStack is aware off.

As mentioned earlier, the default of stable-privacy is ok for workstations, but is a really bad choice for servers.

Comment 15 Thomas Haller 2021-08-16 21:01:28 UTC
> In that case the script generating the bridge-interfaces is not specifying ipv6.addr-gen-mode resulting in stable-privacy, which in turns prevents OpenStack access since the IPv6 address is not the one that OpenStack is aware off.

If an ifcfg-file (or a keyfile) does not explicitly specify addr-gen-mode, then the default (for such a profile that gets read from file) is supposed to be eui64.

You claim here something else.

   echo "DEVICE=eth0" > /etc/sysconfig/network-scripts/ifcfg-xxx
   nmcli connection load /etc/sysconfig/network-scripts/ifcfg-xxx
   nmcli connection show /etc/sysconfig/network-scripts/ifcfg-xxx | grep 'ipv6.\(method\|addr-gen-mode\)'

and... you are right. It's a bug in the reader, which fails to process addr-gen-mode, if the IPv6 method is ignore/disabled.

That's a bug here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/b57c1af81448a8e7b57f56d910d2354e2a247c87/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c#L2377

Can you show the ifcfg file that you created?


Anyway, that problem is mostly separate from this rhbz.

Comment 16 Dusty Mabe 2021-08-16 21:09:18 UTC
Hey Thomas,

The user is using OKD4 (which uses Fedora CoreOS), so this is likely an extension of https://github.com/coreos/fedora-coreos-tracker/issues/907#issuecomment-886817668

Note that in FCOS we don't actually have any nmconnection profiles written to disk by default, so we're using the autogenerated "Wired Connection 1", which defaults to "stable-privacy". What we'd like to do in FCOS (and maybe other server like editions in Fedora) is be able to drop down a config setting to make our nodes default to eui64.

Comment 17 Thomas Haller 2021-08-16 21:24:00 UTC
(In reply to Dusty Mabe from comment #16)
> Hey Thomas,
> 
> The user is using OKD4 (which uses Fedora CoreOS), so this is likely an
> extension of
> https://github.com/coreos/fedora-coreos-tracker/issues/907#issuecomment-
> 886817668

I think not. The problem of comment 15 is a bug in the ifcfg-reader.
CoreOS only uses keyfile settings plugin, so that same problem does not exist there.

Comment 18 Pepijn Oomen 2021-08-17 06:14:21 UTC
> If an ifcfg-file (or a keyfile) does not explicitly specify addr-gen-mode, then
> the default (for such a profile that gets read from file) is supposed to be
> eui64.

My case is not using any ifcfg files, but is using nmcli to configure the OVS bridge:

    nmcli c add type ovs-bridge \
        con-name br-ex \
        conn.interface br-ex \
        802-3-ethernet.mtu ${iface_mtu} \
        802-3-ethernet.cloned-mac-address ${iface_mac} \
        ipv4.route-metric 100 \
        ipv6.route-metric 100 \
        ${extra_brex_args}

This results in ovs-bridge having stable-privacy, which results in non-functional IPv6 when running in OpenStack with port security enabled. This is just to show how the reasoning behind the original request of this report might help to mitigate the effect of the default of stable-privacy for ipv6.addr-gen-mode.

Comment 19 Thomas Haller 2021-08-17 06:38:37 UTC
> My case is not using any ifcfg files, but is using nmcli to configure the OVS bridge:

I see. Thanks for elaborating.

It's entirely nmcli's choice to set addr-gen-mode to one mode or another. In this case, the default is "stable-privacy".

No default choice is right for all cases, so when you call nmcli and you don't like that choice, then you need to explicitly tell it otherwise.

Compare to `ipv4.route-metric`, which nmcli defaults to -1 which means to use the global default in NetworkManager.conf (which this RFE asks for, for addr-gen-mode).
It's often desirable to explicitly specify the desired value per-profile, instead of relying on a default that affects potentially other profiles. Which is what your tool does.

For the same reason, explicitly setting `ipv6.addr-gen-mode eui64` might be the better solution than hoping/ensuring that the default is what Openstack wants.


Anyway, the bug is reopened, and it should be done (to make the default configurable) -- even if that is probably not the right solution for this Openstack script.

Comment 21 Dusty Mabe 2021-08-17 13:25:16 UTC
(In reply to Thomas Haller from comment #19)

> 
> For the same reason, explicitly setting `ipv6.addr-gen-mode eui64` might be
> the better solution than hoping/ensuring that the default is what Openstack
> wants.
> 


I agree with Thomas here. Pepijn can you update the script that calls nmcli
(or open a bug against the software that does) to make it specify what
addr-gen-mode it requires?

I believe we do want to change the global default for RHCOS/FCOS (when it's
supported to do so), but there's no reason to wait for that in the script
that is being used to call nmcli today.

Comment 22 Pepijn Oomen 2021-08-17 18:54:15 UTC
https://github.com/openshift/okd/issues/817

Comment 28 Gris Ge 2022-01-18 07:36:35 UTC
We don't have capacity to ship this feature for RHEL 8.6 and the code design of this is not yet decided.

Postponed to RHEL 8.7 for further discussion.

You could configure this option via nmcli or nmstate as workaround.

Comment 29 Gris Ge 2022-01-18 07:38:27 UTC
Acceptance criteria: NetworkManager provide a way to define global default method of IPv6 addr_gen_mode. Connection level configuration should be able to override global configure.

Comment 30 RHEL Program Management 2022-01-26 07:27:10 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 31 Thomas Haller 2022-05-09 20:20:52 UTC
This was re-reported as bug 2082682. I am hopeful that this time it will be done...

It seems better to leave this discussion alone, and comment on the new bug if you have anything to add. Thank you.

Comment 32 Thomas Haller 2022-06-29 06:21:54 UTC
follow up:

this is now implemented upstream with https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e6a33c04ebe1ac84e31628911e25bdfd7534dd3c


Note You need to log in before you can comment on or make changes to this bug.