Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As I said before I don't care that much what the policy is but I do
care very much that Fedora keeps changing it.

Twice now I have had to go and reconfigure my networks after a Fedora
upgrade has changed the MAC assignment policy.

My vote is therefore to leave it as it is so that I don't have to go
and change everything again!

Basically I don't care what the MAC of a machine is but I care very
much if it changes because I have to update DHCP so that it can
continue to issue the correct IPs and DNS for IPv6 addresses which
change when the MAC changes.

Tom

On 25/06/2022 20:06, Vipul Siddharth wrote:
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

The `systemd-udev` package installs
`"/usr/lib/systemd/network/99-default.link"`,
which sets `Link.MACAddressPolicy=persistent`. This proposal is to
change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address.
This is particularly important for bridge and bond devices.

This change can either only apply to bridge/bond devices, or to
various software devices. That is to be discussed.

== Owner ==

* Name: [[User:thaller|Thomas Haller]] (NetworkManager)
* Email: <thaller@xxxxxxxxxx>
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: <dmabe@xxxxxxxxxx>


== Detailed Description ==

On Fedora, udev by default changes the MAC address of a wide range of
software devices.
This was introduced by systemd 242 in early 2019 (Fedora 31), when
`MACAddressPolicy=` was
extended to affect more types of devices.

With `MACAddressPolicy=persistent` udev's aim is to provide a stable
MAC address, otherwise
the kernel will assign a random one. However, that can cause problems:

Firstly, software devices are always created by some tool that has
plans for the device. The tool may not
expect that udev is going to change the MAC address and races against
that. The best solution
for the tool is to set the MAC address when creating an interface.
This will prevent
udev from changing the MAC address according to the MACAddressPolicy.
Otherwise, the tool should wait for udev to initialize the device to
avoid the race. In theory, a
tool is always advised to wait for udev to initialize the device.
However, if it were not for MACAddressPolicy,
in common scenarios udev doesn't do anything relevant for software
devices to make that necessary.

Secondly, for interface types bridge and bond, an unset MAC address
has a special meaning
to the kernel and the MAC address of the first port is used. If udev
changes the MAC
address, that no longer works.
Now the generated MAC address is not directly discoverable as it is
based on `/etc/machine-id`
([https://www.man7.org/linux/man-pages/man5/machine-id.5.html
machine-id(5)]), among
other data. Even if there were a tool to easily calculate the MAC
address, it could be cumbersome
to use it without logging into the machine first. The MAC address can
directly affect the
assigned IP address, for example when using DHCP. When booting a new
virtual machine, the user might
know the MAC address of the (virtual) "physical" interfaces. When
bonding/bridging those
interfaces, the bond/bridge would get one of the well known MAC
addresses. `MACAddressPolicy=persistent`
interferes with that.

The goal of persistent policy is to provide a stable MAC address. Note
that if the
tool or user who created the interface would want a certain MAC address, they
have all the means to set it already. That applies regardless whether
the tool is
iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor
systemd-networkd
rely on udev's MACAddressPolicy for setting the MAC address. This
behavior is mostly
useful for plain `ip link add`, but it's unclear which real world user
wants this behavior.

Of course, the user is welcome to configure the MAC address in any way
they want. Including,
dropping a link file that sets `MACAddressPolicy=persistent`. The
problem is once udev sets a MAC address,
it cannot be unset. Which makes this problematic to do by default.

While Fedora inherited this behavior from upstream systemd, RHEL-9
does not follow this behavior
([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e694bfbc2b02a456c1056f252e/0028-udev-net-setup-link-change-the-default-MACAddressPol.patch#L43
centos9],
[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For
RHEL-8, this doesn't
apply because the systemd there is too old to change the MAC address
of most software devices.

This could be either implemented by patching
`/usr/lib/systemd/network/99-default.link`
to have a different policy, or by dropping a link file with higher
priority. In the latter
case, that override could be shipped either by udev or even by NetworkManager.

Another option is to change the scope of this proposal to only change to
`MACAddressPolicy=none` for the device types where this causes the most issues
(bridge/bond/team).


== Feedback ==

This was also discussed on upstream systemd mailing list
[https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html
here].
The upstream systemd maintainers' opinion is that the current udev
behavior is desirable, but accepts that distributions (or network
stacks such as NetworkManager) may choose to change the default
depending on their needs
([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html
reference]).
The goal here is to find out what the Fedora community thinks is the
most appropriate default.

The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094
[rh#1921094]].


== Benefit to Fedora ==

Pros:

- Consistent behavior with RHEL8 and RHEL9.

- Avoid race of udev and the tool that creates the interface.

- Bridge and bond interfaces can get the MAC addresses from their first port.

In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will
get a MAC related to one of its physical NIC devices. In the case of
provisioning
new systems (especially in a large datacenter) information about the server
can be used to configure the network environment (DHCP, Firewall, etc) before
the server is ever even powered on. This does mean that you may have to update
your network environment configuration if you replace a NIC (con), but that you
won't have to update your network environment configuration if you re-install
your server (pro), which is what you'd have to do now with
`MACAddressPolicy=persistent`.

Cons:

- Deviate from upstream systemd.

It is desirable that RHEL and Fedora behaves similar. A possible outcome
could be the current behavior stays and RHEL 10 would change behavior. On the
other hand, different distributions (or even Fedora spins) have different
uses and needs. Deviating might be fine. In the same vein, there is also
a desire to stay close to upstream systemd behavior. But the uses of systemd
project go beyond Fedora/RHEL, so deviating here may also be fine.


== Scope ==

* Proposal owners:
The main goal of this request is to generate productive discussion and
find the desired behavior.
The implementation/changes are either way very simple.

* Other developers:
Other projects that wish a certain MAC address are welcome to
set it for their devices. Including using udev's MACAddressPolicy.

* Release engineering:
Not needed for this change.

* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==

After the change, the MAC address for the affected device types changes.


== How To Test ==

1) Create a software device two times, for example `ip link add type
bridge`. Note
that the MAC address is either stable or random, depending on the
`MACAddressPolicy=`.

2) Note that if the software device has the MAC address set initially,
udev does not
change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on
`/sys/class/net/$dev/addr_assign_type`.

3) Create a bridge/bond interface without setting the MAC address.
Note that if `MACAddressPolicy=none`,
the MAC address is random at first. Note that attaching the first port
will update the controller's MAC address.
On the other hand, with `MACAddressPolicy=persistent`, the MAC address
of the controller is fixed
and not inherited from the port.

4) Run

   ip monitor link &
   while : ; do
     ip link del xxx
     ip link add name xxx type dummy \
     && ip link set xxx addr aa:00:00:00:00:00 \
     && ip link show xxx | grep -q aa:00:00:00:00:00 \
     || break
   done

to reproduce the race between a simple tool and udev changing the MAC address.


== User Experience ==

Bond/bridge devices would again get assigned the MAC address of the
first NIC added to the device.
If we chose to not limit the scope of this change to just
bonds/bridges then all software devices would get randomly assigned
MAC addresses.


== Dependencies ==

None.


== Contingency Plan ==

If the change is rejected, nothing needs to be done. The change
itself will be simple to implement.
Contingency deadline: beta freeze
Blocks release? No


== Documentation ==

TODO.

== Release Notes ==



--
Tom Hughes (tom@xxxxxxxxxx)
http://compton.nu/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux