| BOOTPD(8) | System Manager's Manual | BOOTPD(8) |
bootpd —
DHCP/BOOTP
bootpd |
[options] |
bootpd implements a DHCP/BOOTP server as
defined in RFC951, RFC1542, RFC2131, and RFC2132, as well as a BOOTP/DHCP
relay agent.
bootpd understands and handles requests
that arrive via a DHCP/BOOTP relay agent, allowing the server to be
centrally located, and serve many remote subnets.
The server is normally invoked by
launchd(8) when a request arrives, but
can also be invoked manually. If it is invoked by
launchd(8),
bootpd continues to service requests until it is
idle for a period of 5 minutes, after which it exits to conserve system
resources. If invoked manually, bootpd continues to
run indefinitely.
If bootpd receives a SIGHUP (-1) signal,
it will re-read its configuration and client binding files.
When a request from a client arrives, the server logs an entry to
/var/log/system.log indicating which client made the request, and
logs another entry once a reply is sent. This feature can be turned off
using the -q option described below.
bootpd reads its configuration from
bootpd.plist, a plist that by default is expected to exist as
/etc/bootpd.plist. An alternate path can be specified using the
-f option. There are also a number of command-line
options to change its behavior on the fly. Note in particular that options
DrS can also be controlled via service-control properties. See
Service Controls and
Filters below.
-B-b-D-d-f
filename-I-i
interfacebootpd -i en0 -i en1forces
bootpd to respond only to requests received
on ethernet ports en0 and en1. By default, all interfaces are
enabled.-o
hop_count-q-r
server_ip-S-vbootpd reads its configuration from
bootpd.plist, an XML property list. The root of the property list is
a dictionary. The property list has two main areas:
The root dictionary in bootpd.plist contains properties to
control whether bootpd will respond to a particular
request, There are MAC address filters, DHCP controls, as well as controls
to enable services.
The MAC address filter properties are:
When a packet arrives, bootpd checks
whether the client's MAC address is in the deny list. If it is, the
packet is dropped. Otherwise, if the client's MAC address is in the
allow list, the packet continues to be processed, otherwise it is
dropped. If neither the allow nor the deny property is
specified, the packet continues to be processed.
Allow/deny filtering can be disabled using the ignore_allow_deny property:
The service-control properties are:
For each of the properties dhcp_enabled, bootp_enabled, and relay_enabled, the corresponding service can be enabled or disabled for all interfaces, or enabled for just a specific set of interfaces. To enable or disable globally, use a boolean value true or false respectively. To enable just for a specific set of interfaces, use either a string, for a single interface, or an array of strings, one element for each interface.
For example, to enable DHCP on interfaces en0 and en1, disable BOOTP on all interfaces, and enable relay agent on interface en1, bootpd.plist could contain:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>bootp_enabled</key>
<false/>
<key>dhcp_enabled</key>
<array>
<string>en0</string>
<string>en1</string>
</array>
<key>relay_enabled</key>
<array>
<string>en1</string>
</array>
</dict>
</plist>
Some additional properties are:
bootpd receives a SIGHUP, or exits.bootpd won't respond to the request
until the bp_secs field is at least reply_theshold_seconds. The
default value is 0 (zero).bootpd
will look for static IP address to ethernet address bindings in Open
Directory. The default value is false.The "Subnets" property in bootpd.plist contains an array of dictionaries, each dictionary corresponds to a single subnet entry.
A subnet entry describes a range of IP addresses, and associated information, such as the subnet mask, router, DNS servers, and other option data. A subnet entry also indicates whether the range is an address pool from which to allocate vs. simply an informational range in order to fulfill requests for option information. The informational range is used when the client's IP address binding is static, or the client knows its own IP address and simply wants relevant option information.
A subnet entry is required to supply the DHCP service with pool(s) of IP address(es), and to inform the server of subnet-specific options and parameters. A subnet entry can also be used to convey network topology information via the supernet property described below.
Subnet entries may not overlap in the IP ranges the describe, nor specify values that are inconsistent. Specifically, applying the net_mask value to each of the values in the net_range must yield the net_address value.
Errors in configuration are logged to /var/log/system.log. There may be multiple entries for a given subnet, allowing different configuration values to be specified for a given sub-range of IP addresses within the subnet. For example, part of the range might be used for statically bound clients, and another for a dynamic address pool.
Each subnet entry is encoded as a dictionary with the following properties:
<array> <string>17.202.40.2</string> <string>17.202.43.254</string> </array>This property is required.
The server can also supply clients with the following DHCP option information:
For example:
<key>dhcp_classless_static_route</key> <array> <string>192.168.100.0/22</string> <string>0.0.0.0</string> <string>44.100.100.100/22</string> <string>192.168.100.1</string> <string>129.210.177.132/25</string> <string>1.1.1.1</string> </array>
The first route has destination 192.168.100.0/22 and gateway 0.0.0.0 which means 192.168.100.0/22 is directly reachable on the link. The second route has destination 44.100.100.100/22 and gateway 192.168.100.1. The third route has destination 129.210.177.132/25 and gateway 1.1.1.1.
DHCP options may also be specified using the naming convention:
dhcp_option_option_codereplacing option_code with a numeric value in the range of 1 through 254. For example, to specify option code 128, specify a property named dhcp_option_128.
bootpd has a built-in type conversion
table for many more options, mostly those specified in RFC 2132, and will
try to convert from whatever type the option appears in the property list to
the binary, packet format. For example, if bootpd
knows that the type of the option is an IP address or list of IP addresses,
it converts from the string form of the IP address to the binary, network
byte order numeric value.
If the type of the option is a numeric value, it converts from string, integer, or boolean, to the proper sized, network byte-order numeric value.
Regardless of whether bootpd knows the
type of the option or not, you can always specify the DHCP option using the
data property list type e.g.:
<key>dhcp_option_128</key> <data> AAqV1Tzo </data>
Static IP address to ethernet address bindings are stored in the /etc/bootptab file and in Open Directory. Bindings specified in the /etc/bootptab file take precedence over those in Open Directory.
See bootptab(5) for more information about the /etc/bootptab file.
For Open Directory, bootpd looks at
the /Computers records for the following properties:
If DHCP service is enabled for a client, the server processes the client's packet. The packet may be a request for an IP address and option information (DHCP Discover, DHCP Request) or for just option information (DHCP Inform). The packet might also tell the server that the address is in use by some other host (DHCP Decline), or that the client is done with the IP address (DHCP Release).
The server uses the DHCP client identifier (option 61) if it is present as the unique client identifier, otherwise it uses the htype/hlen/chaddr fields in the DHCP packet.
The DHCP server first tries to find a static binding for the client (see section BOOTP/DHCP STATIC BINDINGS above). If one exists, it uses it. If not, it tries to find an existing dynamic binding from its lease database, stored in /var/db/dhcpd_leases. If one exists and it is applicable to the subnet, the server uses it, otherwise, it tries to allocate an address from one of its address pools. If an address is available, the server uses it, otherwise the packet is discarded.
After a suitable IP address is found for the client, the server attempts to insert as many of the requested DHCP options from the client's request as it can into the reply.
When the server allocates an address dynamically, it automatically excludes addresses that appear in static host entries. For example, if the address range goes from 10.0.0.2 through 10.0.0.10, but there is a static entry that specifies 10.0.0.3, that address is automatically excluded from the pool.
The server tries to give the same address back to a client by remembering the binding even after it has expired. The server removes an expired lease entry only when it runs out of addresses, and needs to reclaim an address in order to fulfill a new request.
When the server receives a DHCP Release packet, it sets the expiration for that lease to now, so that it can immediately reclaim the address if needed.
When the server receives a DHCP Decline packet, it removes the client binding from the IP address, and sets the expiration on the "unbound" lease to 10 minutes from now. That allows the address to return to the address pool again without manual intervention and avoids handing out the same in-use IP address over and over. BOOTP/DHCP STATIC BINDINGS above), or the server must have an applicable dynamic pool of IP addresses, just as with DHCP.
| February 2, 2023 | Mac OS X |