OpenBMC DHCP Management

[Johnathan Mantey]

OpenBMC DHCPv4 and DHCPv6 management

I wish to solicit input concerning DHCPv6 handling in OpenBMC.

Background:

Some time ago I submitted and merged changes that allowed IPMI and
Redfish to enable IPv6 Routing Advertisement. This permitted Stateful
IPv6 address assignment to occur.

Fast forward to today and the Intel QA group is identifying
misbehavior in how DHCPv6 is controlled, and state reported. Most of
the issues appear in the IPMI stack. I am also certain the Redfish
support is lacking. The phoshpor-network layer does not properly
control the systemd-network DHCPv6 configuration in a way that allows
Stateless DHCPv6.

Issues:

OpenBMC uses the systemd-networkd networking stack. The
phosphor-network code uses D-Bus to get configuration changes from
user space. It updates the systemd.network configuration file to
change the state of the network interface. Within the systemd.network
configuaration file is an entry named "DHCP". This entry, at first
glance, appears to control IPv4 and IPv6 DHCP. It is also the primary
configuration entry for reporting DHCP state back to IPMI/Redfish
about the current DHCP configuration in use by systemd-networkd.

The problem is the "DHCP=" entry does not accurately reflect DHCPv6
state. Even with "DHCP=v6" assigned it is possible DHCPv6 is not
active. This entry can really only accurately describe the DHCPv4
state.

DHCPv6 state is accurately described by the combination of
"IPv6AcceptRA" and the associated "DHCPv6Client" entries. The
IPv6AcceptRA control is exposed via D-Bus, DHCPv6Client is not. The
IPv6 state is reflected in these combinations:
IPv6AcceptRA=true DHCPv6Client=true  : Stateful IPv6
IPv6AcceptRA=true DHCPv6Client=false : Stateless IPv6
IPv6AcceptRA=false                   : DHCPv6 disabled

OpenBMC does not have complete control over these states, nor does it
accurately report the state of DHCPv6. A first attempt to accurately
report DHPCv6 state was made in this commit:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-networkd/+/48040

The commit was not approved, which I agree is the correct
response. The changes bandaged over a larger issue.

Proposal:
I have begun coding a change to address the issues described. My
concern is the changes are going to impact four separate repositories,
specifically:

phosphor-dbus-interfaces
phoshor-network
bmcweb
phosphor-ipmi-host

As such I want to get some feedback on my plan before expending too
much effort.

My current plan:
1. Modify phosphor-dbus-interfaces, changing the DHCPConf entry in
    EthernetInterface. I propose adding two more DHCPConf
    enumearations:
    name: both             # DHCPv4 enabled, DHCPv6 Stateful enabled
    + name: v4v6stateless  # DHCPv4 enabled, DHCPv6 Stateless enabled
    name: v6               # DHCPv4 disabled, DHCPv6 Stateful enabled
    + name: v6stateless    # DHCPv4 disabled, DHCPv6 Stateless enabled
    name: v4               # DHCPv4 enabled, DHCPv6 disabled
    name: none             # DHCPv4 and v6 disabled

    The goal is to permit phosphor-network to take the correct actions
    needed to update the systemd.network file.
2. Deprecate the IPv6AcceptRA boolean. This, in my opinion, leaked too
    much information about how systemd-networkd managed IPv6 dynamic
    addressing.
3. Modify phosphor-network to accept the new DHCPConf entries, and
    update the systemd.network configuration file based on the higher
    level mode.
4. Update BMCWeb to use the new D-Bus configuration values
5. Update phosphor-ipmi-host to use the new D-Bus configuration values

Conclusion:
The changes suggested abstract the reporting and the modification of
DHCPv6, and eliminate implementation specific details from the IPMI
and Redfish clients. They also fill in a gap with Stateless IPv6
assignment.

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220202/9200b06d/attachment.sig>