The key piece of persisted data in an DHCP server is the lease. A lease is a the mapping between a MAC address and an IP address, limited in time. A Lease typically has a start time and an end time, but can be renewed. Because I am still living in an IPV4 world, I have to deal with arbitrarily small pools of IP addresses. Thus, the design needs to strike the balance between static and dynamic: a machine should generally get back the same IP address each time. However, if addresses get tight, address reuse should be aggressive.

A DHCP server typically works with a Class C network subnet. That means that roughly 250 addresses are managed per server. This is on the low size. For example, the clusters on the Top 500 site often have thousands of nodes. However, they also don’t tend to come up and disappear very randomly

What does happen, however, is that certain pieces of hardware fail and get replaced. When that happens, the new servers need to reclaim leases from the retired ones.

Assuming that the client servers regularly send DHCP packets out to renew their leases, the server should be able to reuse the IP addresses based on the order in which the leases expire.

Rust is very strict about memory ownership. That was giving me a bit of and issue when I was trying to design a data structure to solve the allocation and reallocation of IP addresses. My first thought was for the renewal, I could lookup the lease based on the MAC. This calls for a hashmap where the key is the MAC address and the value is the lease.

But I also want to order the leases by expiry time, which seems to call for a linked-list style collection, where additions are made to one end (newest) and removed from the other (oldest) but also allowing for a reshuffling of the values when a renewal happens. These need to be removed from the middle.

My current thinking is that I can keep the MAC addresses as the primary key for the MAP, but I will also maintain a separate list of the MAC addresses ordered by expiration time.

This last bit is going to be tricky. If it were just renewal time, pushing the value onto the head of the list would be sufficient. If all of the leases are the same duration, then ordering by renewal time is the same as ordering by expiration. If the lease duration can vary, the insertion process is going to require looking up each lease in the map to retrieve the expiration time.

There are various usage patterns for DHCP. Probably the biggest differentiator is whether the addresses are going to be recycled frequently, say in a Coffee shop, or if we expect long term traffic. In an office setting, people expect to come in an get to work, so making sure there is an IP address available for them is paramount. This setting requires longer leases; a few posts I’ve found around suggest a week +1 Day. This makes sense; If you get your address on Monday, and miss renewal for some reason, when you come in the following Monday, you still have your lease.

Some devices get very long term leases. A printer or a server with a public Hostname should probably have something very much approximating a fixed IP address. Since these often need to be on local networks, it means that certain MAC addresses are assigned leases for IP addresses from different pools. This can cause some frustration when initially setting up a machine, as it might get its address from an 8 day pool but the admin wants to give it a long term assignment from a static pool.

A Virtual machine based deployment is going to have an order of magnitude more host than a pure physical data center. The need for new IP address leases is going to also be far more common.

A container based system could potentially have even higher numbers of lease requests than a virtual machine based deployment.

Maybe we should just go with IPv6.

Moving back to hardware provisioning, one pattern that comes up a lot is new-hardware classification. This is the usage where a new MAC address gets a shorter term lease, installs a short lived, inventory-generating Operating system, performs initial registration, and then reboots into its longer term configuration. Again, we have two pools of IP addresses with two different lease durations.

What I think this means is that there is going to be a couple different abstractions required. I do not like the word profile or the word flavor, but something that indicates the class of hardware available in the machine. IP addresses are allocated out of subnets, but finer grained than that will be Pools, which are subsets of the subnet IDs that have common usage. Static , short-lived, and week-long are three examples of pools based on what I wrote above.

Since a machine can move from one pool to another, there should be a link from the lease to the pool. That way the pool used can be determined from the original MAC address.