| // Copyright The Monogon Project Authors. |
| // SPDX-License-Identifier: Apache-2.0 |
| |
| // Package dhcp4c provides a client implementation of the DHCPv4 protocol |
| // (RFC2131) and a few extensions for Linux-based systems. |
| // The code is split into three main parts: |
| // - The core DHCP state machine, which lives in dhcpc.go |
| // - Mechanisms to send and receive DHCP messages, which live in transport/ |
| // - Standard callbacks which implement necessary kernel configuration steps in |
| // a simple and standalone way living in callback/ |
| // |
| // Since the DHCP protocol is ugly and underspecified (see |
| // https://tools.ietf.org/html/draft-ietf-dhc-implementation-02 for a subset of |
| // known issues), this client slightly bends the specification in the following |
| // cases: |
| // - IP fragmentation for DHCP messages is not supported for both sending and |
| // receiving messages This is because the major servers (ISC, dnsmasq, ...) |
| // do not implement it and just drop fragmented packets, so it would be |
| // counterproductive to try to send them. The client just attempts to send |
| // the full message and hopes it passes through to the server. |
| // - The suggested timeouts and wait periods have been tightened significantly. |
| // When the standard was written 10Mbps Ethernet with hubs was a common |
| // interconnect. Using these would make the client extremely slow on today's |
| // 1Gbps+ networks. |
| // - Wrong data in DHCP responses is fixed up if possible. This fixing includes |
| // dropping prohibited options, clamping semantically invalid data and |
| // defaulting not set options as far as it's possible. Non-recoverable |
| // responses (for example because a non-Unicast IP is handed out or lease |
| // time is not set or zero) are still ignored. All data which can be stored |
| // in both DHCP fields and options is also normalized to the corresponding |
| // option. |
| // - Duplicate Address Detection is not implemented by default. It's slow, hard |
| // to implement correctly and generally not necessary on modern networks as |
| // the servers already waste time checking for duplicate addresses. It's |
| // possible to hook it in via a LeaseCallback if necessary in a given |
| // application. |
| // |
| // Operationally, there's one known caveat to using this client: If the lease |
| // offered during the select phase (in a DHCPOFFER) is not the same as the one |
| // sent in the following DHCPACK the first one might be acceptable, but the |
| // second one might not be. This can cause pathological behavior where the |
| // client constantly switches between discovering and requesting states. |
| // Depending on the reuse policies on the DHCP server this can cause the client |
| // to consume all available IP addresses. Sadly there's no good way of fixing |
| // this within the boundaries of the protocol. A DHCPRELEASE for the adresse |
| // would need to be unicasted so the unaccepable address would need to be |
| // configured which can be either impossible if it's not valid or not |
| // acceptable from a security standpoint (for example because it overlaps with |
| // a prefix used internally) and a DHCPDECLINE would cause the server to |
| // blacklist the IP thus also depleting the IP pool. |
| // This could be potentially avoided by originating DHCPRELEASE packages from a |
| // userspace transport, but said transport would need to be routing- and |
| // PMTU-aware which would make it even more complicated than the existing |
| // BroadcastTransport. |
| package dhcp4c |