diff options
Diffstat (limited to 'usr.sbin/dhcp/server/dhcpd.conf.5')
| -rw-r--r-- | usr.sbin/dhcp/server/dhcpd.conf.5 | 136 |
1 files changed, 115 insertions, 21 deletions
diff --git a/usr.sbin/dhcp/server/dhcpd.conf.5 b/usr.sbin/dhcp/server/dhcpd.conf.5 index f7228b2a45d..b4b44ca8a62 100644 --- a/usr.sbin/dhcp/server/dhcpd.conf.5 +++ b/usr.sbin/dhcp/server/dhcpd.conf.5 @@ -1,7 +1,7 @@ .\" dhcpd.conf.5 .\" -.\" Copyright (c) 1995, 1996 The Internet Software Consortium. -.\" All rights reserved. +.\" Copyright (c) 1995, 1996, 1997, 1998, 1998, 1999 +.\" The Internet Software Consortium. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions @@ -37,7 +37,7 @@ .\" Enterprises, see ``http://www.vix.com''. .TH dhcpd.conf 5 .SH NAME -dhcpd.conf - DHCP server configuration file +dhcpd.conf - dhcpd configuration file .SH DESCRIPTION The dhcpd.conf file contains configuration information for .IR dhcpd, @@ -85,9 +85,9 @@ even if no addresses will be dynamically allocated on that subnet. Some installations have physical networks on which more than one IP subnet operates. For example, if there is a site-wide requirement that 8-bit subnet masks be used, but a department with a single -physical Ethernet network expands to the point where it has more than +physical ethernet network expands to the point where it has more than 254 nodes, it may be necessary to run two 8-bit subnets on the same -Ethernet until such time as a new physical network can be added. In +ethernet until such time as a new physical network can be added. In this case, the \fIsubnet\fR declarations for these two networks may be enclosed in a \fIshared-network\fR declaration. .PP @@ -176,7 +176,7 @@ Figure 2 As you can see in Figure 2, it's legal to specify host addresses in parameters as domain names rather than as numeric IP addresses. If a given hostname resolves to more than one IP address (for example, if -that host has two Ethernet interfaces), both addresses are supplied to +that host has two ethernet interfaces), both addresses are supplied to the client. .PP In Figure 1, you can see that both the shared-network statement and @@ -278,7 +278,7 @@ group { .fi .SH REFERENCE: DECLARATIONS .PP -.B The +.B The .I shared-network .B statement .PP @@ -308,7 +308,7 @@ shared network. The name may have the syntax of a valid domain name (although it will never be used as such), or it may be any arbitrary name, enclosed in quotes. .PP -.B The +.B The .I subnet .B statement .PP @@ -329,7 +329,7 @@ declaration. The .I subnet-number should be an IP address or domain name which resolves to the subnet -number of the subnet being described. The +number of the subnet being described. The .I netmask should be an IP address or domain name which resolves to the subnet mask of the subnet being described. The subnet number, together with the @@ -372,7 +372,7 @@ single address, \fIhigh-address\fR can be omitted. .PP There must be at least one .B host -statement for every BOOTP client that is to be served. +statement for every BOOTP client that is to be served. .B host statements may also be specified for DHCP clients, although this is not required unless booting is only enabled for known hosts. @@ -386,7 +386,7 @@ parameter, or more than one statement may be specified. .PP If client-specific boot parameters must change based on the network -to which the client is attached, then multiple +to which the client is attached, then multiple .B host statements should be used. @@ -493,7 +493,7 @@ should be the maximum length in seconds that will be assigned to a lease if the client requesting the lease asks for a specific expiration time. .PP -.B The +.B The .I hardware .B statement .PP @@ -506,16 +506,16 @@ statement. .I hardware-type must be the name of a physical hardware interface type. Currently, only the -.B Ethernet -type is recognized, although support for -.B token-ring +.B ethernet and +.B token-ring +types are recognized, although support for a .B fddi -hardware types would also be desirable. +hardware type (and others) would also be desirable. The .I hardware-address should be a set of hexadecimal octets (numbers from 0 through ff) -separated by colons. The \fIhardwarefR statement may also be used +seperated by colons. The \fIhardware\fR statement may also be used for DHCP clients. .PP .B The @@ -579,7 +579,7 @@ or more IP addresses. The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time for all leases assigned dynamically to BOOTP clients. Because BOOTP clients do not have any way of renewing leases, and don't know that -their leases could expire, by default dhcpd assigns infinite leases +their leases could expire, by default dhcpd assignes infinite leases to all BOOTP clients. However, it may make sense in some situations to set a cutoff date for all BOOTP leases - for example, the end of a school term, or the time at night when a facility is closed and all @@ -597,7 +597,7 @@ from zero (Sunday) to six (Saturday). YYYY is the year, including the century. MM is the month expressed as a number from 1 to 12. DD is the day of the month, counting from 1. HH is the hour, from zero to 23. MM is the minute and SS is the second. The time is always in -Greenwich Mean Time (GMT), not local time. +Universal Coordinated Time (UTC), not local time. .PP .B The .I dynamic-bootp-lease-length @@ -663,13 +663,107 @@ An \fIoption host-name\fR statement within a host declaration will override the use of the name in the host declaration. .PP .B The +.I authoritative +.B statement +.PP + \fBauthoritative;\fR +.PP + \fBnot authoritative;\fR +.PP +The DHCP server will normally assume that the configuration +information about a given network segment is known to be correct and +is authoritative. So if a client requests an IP address on a given +network segment that the server knows is not valid for that segment, +the server will respond with a DHCPNAK message, causing the client to +forget its IP address and try to get a new one. +.PP +If a DHCP server is being configured by somebody who is not the +network administrator and who therefore does not wish to assert this +level of authority, then the statement "not authoritative" should be +written in the appropriate scope in the configuration file. +.PP +Usually, writing \fBnot authoritative;\fR at the top level of the file +should be sufficient. However, if a DHCP server is to be set up so +that it is aware of some networks for which it is authoritative and +some networks for which it is not, it may be more appropriate to +declare authority on a per-network-segment basis. +.PP +Note that the most specific scope for which the concept of authority +makes any sense is the physical network segment - either a +shared-network statement or a subnet statement that is not contained +within a shared-network statement. It is not meaningful to specify +that the server is authoritative for some subnets within a shared +network, but not authoritative for others, nor is it meaningful to +specify that the server is authoritative for some host declarations +and not others. +.PP +.B The +.I use-lease-addr-for-default-route +.B statement +.PP + \fBuse-lease-addr-for-default-route\fR \fIflag\fR\fB;\fR +.PP +If the \fIuse-lease-addr-for-default-route\fR parameter is true in a +given scope, then instead of sending the value specified in the +routers option (or sending no value at all), the IP address of the +lease being assigned is sent to the client. This supposedly causes +Win95 machines to ARP for all IP addresses, which can be helpful if +your router is configured for proxy ARP. +.PP +If use-lease-addr-for-default-route is enabled and an option routers +statement are both in scope, the routers option will be preferred. +The rationale for this is that in situations where you want to use +this feature, you probably want it enabled for a whole bunch of +Windows 95 machines, and you want to override it for a few other +machines. Unfortunately, if the opposite happens to be true for you +site, you are probably better off not trying to use this flag. +.PP +.B The +.I always-reply-rfc1048 +.B statement +.PP + \fBalways-reply-rfc1048\fR \fIflag\fR\fB;\fR +.PP +Some BOOTP clients expect RFC1048-style responses, but do not follow +RFC1048 when sending their requests. You can tell that a client is +having this problem if it is not getting the options you have +configured for it and if you see in the server log the message +"(non-rfc1048)" printed with each BOOTREQUEST that is logged. +.PP +If you want to send rfc1048 options to such a client, you can set the +.B always-reply-rfc1048 +option in that client's host declaration, and the DHCP server will +respond with an RFC-1048-style vendor options field. This flag can +be set in any scope, and will affect all clients covered by that +scope. +.PP +.B The .I server-identifier .B statement .PP \fBserver-identifier \fIhostname\fR\fB;\fR .PP -The server-identifier statement is now obsolete and is ignored by -the DHCP server. +The server-identifier statement can be used to define the value that +is sent in the DHCP Server Identifier option for a given scope. The +value specified \fBmust\fR be an IP address for the DHCP server, and +must be reachable by all clients served by a particular scope. +.PP +The use of the server-identifier statement is not recommended - the only +reason to use it is to force a value other than the default value to be +sent on occasions where the default value would be incorrect. The default +value is the first IP address associated with the physical network interface +on which the request arrived. +.PP +The usual case where the +\fIserver-identifier\fR statement needs to be sent is when a physical +interface has more than one IP address, and the one being sent by default +isn't appropriate for some or all clients served by that interface. +Another common case is when an alias is defined for the purpose of +having a consistent IP address for the DHCP server, and it is desired +that the clients use this IP address when contacting the server. +.PP +Supplying a value for the dhcp-server-identifier option is equivalent +to using the server-identifier statement. .SH REFERENCE: OPTION STATEMENTS .PP DHCP option statements are documented in the |