Add support for dhcp-options on dhcp ipam

[theodiem]

Hello,
As I use macvlan plugin in netavark with podman along the dhcp driver, I would like to be able to specify certain dhcp options when creating containers.

The reasoning behind is that I can have different "conditions" based on "what" is requesting an IP address from my network. Examples (that I use) are:

• shorter lease time
• specific range of ip address within my network

While developing/testing, its very easy to spam your network DHCP with requests, exhausting available IP addresses or causing different issues (for example when your DHCP server registers the hostname into your DNS). Most DHCP servers allows to have specific conditions and usually that is selected by vendor-class-identifier. For example, to have different lease options in case of a DHCP request during PXE boot .

Of course, having the option to send just vendor-class-identifier would be enough for me, but a more generic implementation would be to allow to send arbitrary DHCP options like in the CNI implementation, as I'm using in my K3S setup:

                "ipam": {
                  "type": "dhcp",
                  "daemonSocketPath": "/run/cni/dhcp.sock",
                  "request": [
                  ],
                  "provide": [
                    {
                      "option": "host-name",
                      "fromArg": "K8S_POD_NAME"
                    },
                    {
                      "option": "vendor-class-identifier",
                      "value": "containers"
                    }
                  ]
                }

If anyone is curious, this can be implemented on dnsmasq (which kinda runs on any openwrt router) - what I currently use - as follows:

dhcp-match=set:k3s,option:vendor-class,containers
dhcp-range=tag:k3s,172.20.0.33,172.20.0.159,255.255.255.0,1h
dhcp-option=k3s,option:mtu,9000

Creating an issue since the feature itself is different but similar thing was mentioned in a different (open) issue:

Is there a specific reason that you have to set dhcp-vendor-class-identifier? We can consider adding this as feature if you need it.

Originally posted by @Luap99 in #695

[theodiem]

Maybe (if its easy/handy/doesn't pollute) something similar can be added on how netavark sends hostname/client identifier/etc .. for example by making "arguments" passed to IPAM which on its config you can use it, like in the example above I use for host-name.

Examples:

• send container-id as a different option?
• send the host machine name in a option? Example:

"provide": [
  {
    "option": 224,
    "value": "mynode01"
  },

[Luap99]

ipam_options is a generic string->string map so the options would have to go there.

So the question would be we need the request/provide stuff? I think it would be easiest to just add support for specific keys to the map.

Second our DHCP lib doesn't expose setting vendor-class-identifier or arbitrary options for that matter so this would need to be implemented first.

[theodiem]

Thanks for the quick reply.
The request/provides thing is put on the DHCP request, in case (example) if you have multiple DHCP servers and if one cannot provide a lease with what was requested, it doesn't generate a lease. I don't think the "request" part is needed (unless someone have a use for it, even in considerable deployments, I never filtered out servers this way)

The provides is a section of "what the client is providing". I think its there only to differentiate the options your client is sending to the server (provides) from the ones your client is expecting the server to give back in the lease (requests).

Regarding the options, its nice to have the "string" version of the options, but also there should be a way to use their numeric values as its pretty common to use it (and not having to make a feature request for any additional mapping if its something used in a specific deployment). For example in my dnsmasq.conf I have:

dhcp-option=k3s,option:mtu,9000
dhcp-option=k3s,option:router
dhcp-option=k3s,6

The option 6 is the dns-server (which I use to clear it, in this case). Since my setup (might have changed with later version) didn't allow me to use the string "option:dns-server" because that gets parsed differently (not allowing me to set it to empty). The reasoning isn't relevant to this request, just that it is quite common/nice to be able to use the numeric identifier of the option when the string version isn't implemented.

If i remember correctly, the options are encoded anyways with option_number,string_len,encoded_string in the packet.

[Luap99]

Well the issue is a how to define arbitrary option name then in our map and it doesn't change the fact that our DHCP lib does not support setting other options, yet alone arbitrary options by their number.

[Luap99]

To be clear I am not against adding such functionality if the libs support it and we agree on a sane design around the option names.

[theodiem]

Understandable.
I just thought that would be simple if the option name can be converted to an int, just pass it instead of doing the resolution name->int . From what i've noticed with different deployments is that each dhcp software calls the options what they want, as long as their number means the same with the RFC. Even in my current setup, its vendor-class in one side and vendor-class-identifier on the other.

Since two years passed since the issue quote i've mentioned and my request for this feature, it doesn't seems many people use it.
To me, implementing just the vendor-class-identifier would suffice and would be a "framework" for others to request other options to be added.

[Luap99]

Well these are open source projects and we gladly accept contributions if anyone really wants to implement this. I doubt I find time for this.

[Aakarsh133]

Hey hey @Luap99 @theodiem , i am trying to work on this issue.

[Aakarsh133]

Hey sorry for the delay, to the best of my understanding netavark already sends system related DHCP info but not custom user specified dhcp options, so one way of looking at the problem is to add a functionality of sending dhcp_options from client/container side as well. Currently a JSON file under etc/container/networks/dum_biryani.json (rootful) may look like this ->

     "name": "dum_biryani",
     "id": "2fbc34f7db10beeaf34ad7379e961b8bbbd5ad5252b21087ff5c6de93e6e1fb9",
     "driver": "macvlan",
     "network_interface": "enp43s0",
     "created": "2025-08-18T02:41:38.632795414+05:30",
     "subnets": [
          {
               "subnet": "192.168.1.0/24",
               "gateway": "192.168.1.1"
          }
     ],
     "ipv6_enabled": false,
     "internal": false,
     "dns_enabled": false,
     "ipam_options": {
          "driver": "host-local"
}

For what I understand after our implementation it might look something like ->

     "name": "dum_biryani",
     "id": "2fbc34f7db10beeaf34ad7379e961b8bbbd5ad5252b21087ff5c6de93e6e1fb9",
     "driver": "macvlan",
     "network_interface": "enp43s0",
     "created": "2025-08-18T02:41:38.632795414+05:30",
     "subnets": [
          {
               "subnet": "192.168.1.0/24",
               "gateway": "192.168.1.1"
          }
     ],
     "ipv6_enabled": false,
     "internal": false,
     "dns_enabled": false,
     "ipam_options": {
          "driver": "host-local"
          "options": {
      "vendor_class_identifier": "containers"
    }
}

As mentioned, a core functionality we need to work on is adding support in DHCP libs to actually be able to work with these options, another aspect of the problem is deciding on how the user can actually pass these arguments in Podman CLI, I believe I must leave this design choice on maintainers, so based on what I can infer best with the ideas I would suggest this sample CLI command after the feature is implemented which may look this ->

podman network create \
  --driver macvlan \
  --ipam-driver dhcp \
  --ipam-opt vendor-class-identifier=containers \
  mynet

However rolling back to the core issue of DHCP libs not supporting the options initially, I propose the following changes in early phases ->

I would suggest initially testing it by by only implementing vendor-class-identifier in the initial phases, I would have started with adding another field string vendor-class-identifier = 9 under message NetworkConfig{} in src/proxy/protohowever this takes into consideration that only vendor-class-identifier will be implemented but a more generic implementation would be

message DhcpOption {
    uint32 code = 1;   // numeric DHCP option
    bytes value = 2;   // raw value to send
} 

under message NetworkConfig{}.

After which i believe I would need to make changes in src/network/dhcp.rs adding corresponding fields expanding NetworkConfig as ->

vendor_class_identifier: ipam.vendor_class_identifier.clone().unwrap_or_default(),
For a generic implementation ->
options: ipam.raw_dhcp_options.clone().unwrap_or_default()

And subsequently additional similar fields need to be added in IPAMAddr->

pub vendor_class_identifier: Option<String>,
 pub raw_dhcp_options: Option<Vec<DhcpOption>>, // generic

And subsequently especially for generic options, I need to figure our parsing methods

Following which I need to figure out changes to be implemented under src/dhcp_proxy/dhcp_service.rs so that when a new dhcp_options field is read, it can interact with mozim accordingly.

I have taken in consideration that ipam_options is already a string->string map, this makes it easier to define new arbitary options like dhcp_options.

Currently I thought of only implementing vendor-class-identifier for Phase 0 or a minimal PR, however I strongly implementing generic implementation which can support multiple dhcp_options on the grounds of something like

podman network create \
  --driver macvlan \
  --ipam-driver dhcp \
  --ipam-opt vendor_class_identifier=containers \
  --ipam-opt dhcp_option_77=myuserclass \
  mynet

Now finally, from a user's perspective if me or any other developer would need to test this, it is yet not implemented in Podman CLI, something I am definitely planning to implement once DHCP lib can support it, so for what I suggest is I can manually edit the JSON configuration file, instead of relying on Podman to do the work, I understand it can be a little hectic initially and is definitely not a permanent fix for any feature but I believe I can test small commits with this especially on my local setup.
I would make sure this phase is minimal and remains backward-compatible

@Luap99 @theodiem I have provided you with my understanding of the issue and my proposed plan which I wish to continue with, I would appreciate your feedback, especially regarding design choices and testing.

Thanks

[theodiem]

Hello @Aakarsh133 ,
Thank you for picking up this request.
To me, your design sounds solid.

As someone which doesn't know the workings of the dhcp libs used neither the netavark source code, I have one question regarding your proposed implementation for Phase 0:

The DHCP option vendor-class-identifier is the DHCP option 60. So according to your proposal, implementing it wouldn't be the "same" as implementing dhcp_option_60? (according to your example of --ipam-opt dhcp_option_77=myuserclass)

It is not a criticism to your proposed implementation. As I'm not familiar with the source code/rust in question, my understanding was that pub vendor_class_identifier could "simply" call pub raw_dhcp_options, passing 60 and its own data to it.

I am indifferent to how it is actually implemented as I have no skills to judge the insights and details for your reasoning. I'm happy either way.
There are options that can require different encoding than a simple string, like encoding IP addresses list (example code 64) or encoding of numeric formats (example code 38, which uses a 32bit int) but to be honest, I would disconsider those from the scope as I doubt this will ever be requested/needed for netavark, hence my reasoning behind my question of vendor_class_identifier->dhcp_option_60

Just for additional information in case you didn't came across it: the DHCP option codes are governed by IANA (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml) and the specific vendor-class-identifier is at RFC 2132

Once again, thank you for working on this.

[Luap99]

@Aakarsh133 I think it is important to keep the GRPC proto generic so we don't have to expand the GRPC types ever time for each new option we support. So the generic DhcpOption option approach seems fine.

Using the ipam_options map for this sounds good, we can simply parse the option name such as vendor-class-identifier on the netavark setup side and then convert to the number and then just send this via GRPC to the proxy part.

As for the podman UI we can worry later about it, the --ipam-opt flag sounds good though. I am a podman maintianer so generally if we add new json options I make sure we wire them always back to podman network create cli, I never expect users to edit the json directly outside of testing stuff.

[Aakarsh133]

Hey @theodiem, actually i am not treating vendor-class-identifier as anything special or different than other dhcp options, given parsing implementations, I may not implement all dhcp_options at once but over as long as i am working on the issue I would try to implement the important ones that I can.
And thank you for quoting reference material for DHCP option codes it has been useful in my further research.

Thanks