From Fedora Project Wiki

< Changes
Revision as of 14:50, 22 June 2022 by Thaller (talk | contribs) (Created page with "<!-- {{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}} --> <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> = MAC Address Policy none <!-- The name of your change proposal --> = {{Change_Proposal_Banner}} == Summary == <!-- A sentenc...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


MAC Address Policy none

This is a proposed Change for Fedora Linux.
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

systemd-udev package installs "/usr/lib/systemd/network/99-default.link", which sets Link.MACAddressPolicy=persistent. This proposal is to change that and set Link.MACAddressPolicy=none to stop changing the MAC address.

Owner


Current status

  • Targeted release: Fedora Linux 37
  • Last updated: 2022-06-22
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

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.

Udev's aim here is to provide a stable MAC address, otherwise 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 kernel and the MAC address of the first port is used. If udev changes the MAC address, that no longer works. The generated MAC address is not directly discoverable as it is based on /etc/machine-id (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/briding 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 (centos9, rh#1921094). RHEL-8's systemd 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. The override could also limit MACAddressPolicy=none to certain device types only, like bridge, bond and team interfaces.


Feedback

This was also discussed on upstream systemd mailing list [here]. The upstream systemd maintainers' opinion is that the current udev behavior is desirable.

The RHEL-9 bug is [rh#1921094].

Benefit to Fedora

Pros:

- Consistent behavior with RHEL8 and RHEL9.

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

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

Cons:

- Deviate from upstream systemd.

It is desirable that RHEL and Fedora behaves similar. A possibly 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 vain, 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 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

The MAC address of software devices would again be random.


Dependencies

None.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/MAC_Address_Policy_none&oldid=648159"