insomniacslk/dhcp: a Go library for DHCPv4 and DHCPv6

One Go module carrying two protocol stacks and four support packages

The repository is a single Go module named github.com/insomniacslk/dhcp, and the project documentation splits it into named parts rather than advertising a single entry point. dhcpv6 covers DHCPv6 packet, client and server code. dhcpv4 covers the same three things for the older protocol. netboot provides network booting wrappers on top of both. iana holds IANA constants and helpers shared by the two protocol packages, rfc1035label is a simple implementation of RFC1035 labels used by both, and interfaces is described as a thin layer of wrappers around network interfaces. The documentation is explicit about which ones you normally import: most projects need dhcpv6 and/or dhcpv4 explicitly, and the rest arrive as dependencies when they are needed. That split is a useful design for a library that otherwise mixes wire formats, boot protocols and host abstractions in one tree, because the protocol packages stay usable without dragging in the boot layer.

The install line names only the two protocol packages

Getting the library takes one command, and it deliberately names the two protocol trees rather than the module root. The brace expansion covers both in a single invocation:

go get -u github.com/insomniacslk/dhcp/dhcpv{4,6}

The -u flag asks the Go tool to update the module, which matters because the project publishes no tagged GitHub releases, so the version resolved into your go.mod is a pseudo-version tied to a commit rather than to a release name. The go.mod file at the root of the repository declares the module path and a go directive of 1.25.0:

module github.com/insomniacslk/dhcp

go 1.25.0

Your toolchain therefore has to be at Go 1.25 or newer before anything here will build. If you also need the boot helpers, the RFC1035 label support or the interface wrappers, you import those packages directly and the module graph resolves them for you.

The example tree covers DHCPv6 while the DHCPv4 entries are still TODO

Three example directories are pointed at from the project documentation: examples/client6/, examples/server6/ and examples/packetcrafting6/. Two of them carry descriptive links, a dhcpv6 client and a dhcpv6 server, and the third is a DHCPv6 packet crafting example. The DHCPv4 side of the list reads differently. It lists a TODO for a dhcpv4 client, a TODO for a dhcpv4 server and a TODO for dhcpv4 packet crafting, in that form. So the tree ships reference code for one protocol and leaves the other as a marked gap sitting in the same list. The documentation also points outside the repository to a separate example repository, https://github.com/insomniacslk/exdhcp, for more example code. For a team writing a DHCPv4 client today, that gap is the detail to weigh, because dhcpv4 is the older half of the module and the worked reference for it is still unwritten.

netboot sits on both stacks for machines with no local disk

netboot is the layer that turns the two packet stacks into something a machine can boot from. It is described as network booting wrappers on top of dhcpv6 and dhcpv4, and that thin description is worth taking literally. It is not presented as a boot manager, a PXE server or an image store. It is presented as wrappers, sitting on the same code that handles the address exchange, so a client with no local operating system can still obtain configuration over the network. The distinction matters when you evaluate fit. If your requirement is to serve addresses on an ordinary network, you are in dhcpv4 and dhcpv6 territory and netboot is extra surface area to carry. If your requirement is firmware or provisioning code that must complete an address negotiation with no disk and no OS present, then netboot is the part of the module that speaks to that constraint, and the fact that it is built on the same packet code means the two concerns share one wire format implementation rather than two.

The dependency list points to raw sockets, netlink and simulated transports

The go.mod requirements say what kind of work the library does. github.com/mdlayher/packet and github.com/mdlayher/netlink are there for raw packet and netlink access, github.com/jsimonetti/rtnetlink gives access to rtnetlink, github.com/hugelgupf/socketpair provides socket pairs for tests, and github.com/u-root/uio handles binary reading and writing. golang.org/x/net and golang.org/x/sys provide the platform networking and system call layers underneath. The practical reading is that this is not a pure data structure library. It opens sockets, talks to the kernel, and expects to run on a host with the network privileges a server side needs. The presence of a socket pair dependency and stretchr/testify among the requirements also points at a test suite that exercises the wire format against simulated transports rather than against live hardware. Whether that translates into a smooth first run on your own network is something the project does not document.

The public user list splits into load testing, embedded systems and servers

The list of public projects that use the library is the fastest way to judge what kind of code gets written against it. Facebook's DHCP load balancer dhcplb appears first, then Systemboot, a LinuxBoot distribution that runs as system firmware, Router7, a pure-Go router implementation for fiber7 connections, Beats from ElasticSearch, Bender from Pinterest, a library for load-testing, FBender from Facebook, a tool for load-testing based on Bender, CoreDHCP, a fast, multithreaded, modular and extensible DHCP server, u-root, an embeddable root file system, Talos, a modern OS for Kubernetes, Smee, the network boot service in the Tinkerbell stack, and Spinifex, an AWS-compatible control plane for bare-metal and edge deployments that uses the library for DHCP on provisioned compute instances. Read as a list, it separates into three groups: load and traffic testing, embedded and firmware work, and servers and provisioning platforms. Every one of those is infrastructure software that already owns its own deployment story, which tells you the library sits underneath systems rather than competing with them.

No tagged releases, so the upgrade cost lands on your module graph

The repository is not archived and the last push was on 2026-10-14, so the code is moving. There is a tension in that, though. The repository has no GitHub releases, so there is no versioned artifact to adopt and no changelog attached to a tag. Upgrade cost therefore lands on your own module graph: you track upstream through the pseudo-version that Go writes into go.mod, and you learn what changed by reading commits on master, which is the default branch. The tree does carry signals about its own test state, with a build status badge wired to a GitHub Actions workflow on master, a coverage badge and a Go Report Card badge. The license is BSD-3-Clause, which is permissive and short, with the usual obligation to retain the copyright notice and license text. Whether a particular use of your build counts as distribution is a question for your own legal review.

Where the library stops short of a complete DHCP deployment

Two constraints show up when you read the project documentation carefully. First, there is no configuration story. The library ships packet codecs, client and server building blocks and boot wrappers, but nothing in the documentation describes a configuration file format, a lease database, an address pool policy or a persistence layer. A server built on dhcpv4 has to make those choices itself, and a team expecting a ready DHCP daemon will not find one here. Second, the DHCPv4 examples are unfinished, as the TODO list makes plain. Neither point makes the library unusable, but together they mark it as a component rather than an application. The projects listed as users are mostly infrastructure products that own those concerns themselves, and that is the shape of use that fits the module best.

Editorial conclusion

Adopt insomniacslk/dhcp if you are writing Go code that has to speak DHCPv4 or DHCPv6 on the wire and you already own the operational questions a daemon would answer. Do not adopt it expecting a turnkey server, since the project documentation describes no lease persistence, no address pool policy and no configuration format. Before you commit, compare the unfinished DHCPv4 examples against the dhcpv4 package you actually need, confirm your toolchain is at Go 1.25.0 or newer, and pin a specific commit in go.mod, because the project publishes no tagged releases.

Frequently asked questions

Official sources

1. insomniacslk/dhcp on GitHub
2. Issues
3. License: BSD-3-Clause
4. README