Appendix A. Modifying the DHCP Server Configuration File
Appendix B. Supporting Non-Dynamic IP Clients
Appendix C. Defining DDNS Support
Appendix D. Specifying nsupdate Logging
Appendix E. Specifying DHCP Options
Appendix G. DHCP Server Configuration Files
This information describes using Dynamic IP to centralize and simplify administration of Internet Protocol (IP) networks. Topics include planning, configuring, and maintaining a DHCP network.
This section describes:
This information is intended for use by the system administrator who plans, configures, and maintains a DHCP network. As a system administrator, you can use the DHCP Server Configuration program to centralize and automate administration of IP addresses leased to BootP clients as well as mobile and non-mobile DHCP clients on multiple subnets.
This information contains:
Syntax descriptions in this information use highlighting or special characters to indicate:
For example, a Subnet statement with required and optional variables is:
subnet subnet_address [subnet_mask] range
The following function is new in this release:
This section lists other DHCP and Dynamic IP information, Request for Comment (RFC) documents that apply to DHCP or DHCP options, and how to obtain RFCs.
IBM's Dynamic IP allows you to define network host configuration parameters at a central location and to automate configuration of IP hosts. Dynamic IP is the integration of the Dynamic Host Configuration Protocol (DHCP), which provides configuration information to IP hosts, and the Dynamic Domain Name System (DDNS), which provides dynamic host name-to-IP address (and IP address-to-host name) mapping for the Dynamic IP clients.
For more information about:
DHCP protocols and options are described in IETF Request for Comment (RFC) 2131 and 2132.
The Internet is governed by protocols, which are defined in Internet Engineering Task Force (IETF) Request For Comments (RFC) documents. RFCs outline existing protocols, suggest new protocols, and establish standards for the Internet protocol suite. Internet drafts are proposals, techniques, and mechanisms that document IETF work in progress. Online copies of RFCs and Internet drafts are available from the InterNIC.
To access RFCs or Internet drafts, point your Web browser at this URL, which goes to the Internet Documentation and IETF Information home page.
http://ds1.internic.net/ds/dspg0intdoc.html
You can transfer RFCs and Internet drafts by pointing your browser at this URL:
ftp://ftp.ds.internic.net
Alternatively, you can use FTP to connect to ds.internic.net. Then, you can transfer the files from the RFC directory using this format:
RFCnnnn.TXT RFCnnnn.PSwhere:
In the RFC directory, the format for the RFC index is:
RFC-INDEX.TXT
Note:
Many RFCs are available only in text format. Before requesting a PostScript file, first check the RFC Index to make sure the RFC is available in that format.
You can also request online copies of RFCs through electronic mail, from the automated InterNIC mail server, by sending a message to mailserv@ds.internic.net. You must include one of these commands in the body of your note:
SEND RFCnnnn.TXT SEND RFCnnnn.PSwhere:
For example, to request the text format of RFC 812, you would specify this command in the body of your note:
SEND RFC812.TXT
To request an online copy of the RFC index, include this command in the body of your note:
SEND RFC-INDEX.TXT
Dynamic IP centralizes and simplifies administration of Internet Protocol (IP) networks. Dynamic IP uses a combination of the Dynamic Host Configuration Protocol (DHCP), which provides configuration information to the client, and the Dynamic Domain Name System (DDNS), which provides dynamic domain naming service and address mapping for the network.
Major benefits of Dynamic IP include:
DHCP (Dynamic Host Configuration Protocol) is a client/server protocol that enables you to centrally locate and dynamically distribute configuration information, including IP addresses.
DHCP is based on the Bootstrap Protocol (BootP) and adds the capability of automatically allocating reusable network addresses and distributing additional host configuration options. DHCP clients and servers can use existing BootP relay agents.
DHCP defines IP address allocation policies that include:
DHCP provides the following lease policies for IP addresses:
Dynamic Domain Name System servers allow secure mappings of client host name-to-IP address and IP address-to-host name on the network. Other clients and TCP/IP applications query DDNS servers to translate a host name or IP address, or to obtain information about a host or domain.
For more information on configuring DDNS support from an IBM DHCP server, see Defining Dynamic DNS Support.
For more information about the Dynamic DNS server, see DNS Administration. For an overview of the relationship between DHCP and DDNS, see DHCP and Dynamic IP Introduction.
DHCP allows clients to obtain IP network configuration information, including an IP address, from a central DHCP server. DHCP servers control whether the addresses they provide to clients are allocated permanently or are "leased" for a specific time period. When a client receives a leased address, it must periodically request that the server re-validate the address and renew the lease.
The processes of address allocation, leasing, and lease renewal are all handled by the DHCP client and server programs and are transparent to end-users.
To further explain how DHCP works, let's look at some frequently asked questions:
DHCP allows DHCP clients to obtain an IP address and other configuration information through a request process to a DHCP server. DHCP clients use RFC-architected messages to accept and use the options served them by the DHCP server. For example:
The server checks the configuration file to see if it should assign a static or dynamic address to this client.
In the case of a dynamic address, the server selects an address from the address pool, choosing the least recently used address. An address pool is a range of IP addresses to be leased to clients. In the case of a static address, the server uses a Client statement from the DHCP server configuration file to assign options to the client. Upon making the offer, the IBM DHCP server reserves the offered address.
To DHCP clients that request options, the DHCP server typically provides options that include subnet mask, domain name server, domain name, static route, class-identifier (which indicates a particular vendor), and user class.
However, a DHCP client can request its own, unique set of options. For example, Windows NT 3.5.1 DHCP clients are required to request options. The default set of client-requested DHCP options provided by IBM includes subnet mask, domain name server, domain name, and static route. For option descriptions, see Specifying DHCP Options.
The DHCP client keeps track of how much time is remaining on the lease. At a specified time prior to the expiration of the lease, usually when half of the lease time has passed, the client sends a renewal request, containing its current IP address and configuration information, to the leasing server. If the server responds with a lease offer, the DHCP client's lease is renewed.
If the DHCP server explicitly refuses the request, the DHCP client may continue to use the IP address until the lease time expires and then initiate the address request process, including broadcasting the address request. If the server is unreachable, the client may continue to use the assigned address until the lease expires.
One benefit of DHCP is the freedom it provides a client host to move from one subnet to another without having to know ahead of time what IP configuration information it needs on the new subnet. As long as the subnets to which a host relocates have access to a DHCP server, a DHCP client will automatically configure itself correctly to access those subnets.
In order for DHCP clients to reconfigure to access a new subnet, the client host must be rebooted. When a host restarts on a new subnet, the DHCP client tries to renew its old lease with the DHCP server which originally allocated the address. The server refuses to renew the request since the address is not valid on the new subnet. Receiving no server response or instructions from the DHCP server, the client initiates the IP address request process to obtain a new IP address and access the network.
With DHCP, you can make changes at the server, re-initialize the server, and distribute the changes to all the appropriate clients. A DHCP client retains DHCP option values assigned by the DHCP server for the duration of the lease. If you implement configuration changes at the server while a client is already up and running, those changes are not processed by the DHCP client until the client attempts to renew its lease or until it is restarted.
To assist you in setting up your DHCP system, refer to:
Before you implement DHCP in your network, there are some decisions that you need to make:
The number of servers that you need will depend largely on the number of subnets you have, the number of DHCP clients you plan to support, whether your routers are enabled with BootP Relay, and the lease time you choose. Keep in mind that the DHCP protocols do not currently define server-to-server communication. Thus, they cannot share information, nor can one DHCP server perform as a "hot backup" in the case the other one fails.
DHCP clients send broadcast messages. By design, broadcast messages do not cross subnets. To allow the client's messages to be forwarded outside its subnet, your routers must be configured to forward DHCP requests using a BootP Relay agent. Otherwise, you will need to configure a DHCP server on each subnet.
If you choose to use a single DHCP server to serve hosts on a subnet, consider the effects if the single server fails. Generally, the failure of a server will affect only DHCP clients that are attempting to join the network. Typically, DHCP clients already on the network will continue operating unaffected until their lease expires. However, clients with a short lease time may lose their network access before the server can be restarted.
To avoid a single point of failure, you can configure two or more DHCP servers to serve the same subnet. If one server fails, the other can continue to serve the subnet. Each of the DHCP servers must be accessible either by direct attachment to the subnet or by using a BootP Relay agent.
Because two DHCP servers cannot serve the same addresses, address pools defined for a subnet must be unique across DHCP servers. Therefore, when using two or more DHCP servers to serve a particular subnet, the complete list of addresses for that subnet must be divided among the servers. For example, you could configure one server with an address pool consisting of 70% of the available addresses for the subnet and the other server with an address pool consisting of the remaining 30% of the available addresses.
Using multiple DHCP servers decreases the probability of having a DHCP-related network access failure, but it does not guarantee against it. If a DHCP server for a particular subnet fails, the other DHCP server may not be able to service all the requests from new clients which may, for example, exhaust the server's limited pool of available addresses.
However, you can bias which DHCP server exhausts its pool of addresses first. DHCP clients tend to select the DHCP server offering more options. To bias service toward the DHCP server with 70% of the available addresses, offer fewer DHCP options from the server holding 30% of the available addresses for the subnet.
If you already have BootP clients and servers in your network, you may want to consider replacing your BootP servers with DHCP servers. DHCP servers can optionally serve BootP clients the same IP configuration information as current BootP servers.
If you cannot replace your BootP servers with DHCP servers and want to have both serve your network:
A DHCP server allocates a permanent IP address to a BootP client. In the event that subnets are renumbered in such as way that a BootP-assigned address is unusable, the BootP client must restart and obtain a new IP address.
You may have hosts which have individual or special administrative needs, such as:
You can assign permanent leases to designated hosts by specifying an infinite lease time. Also the DHCP server will allocate a permanent lease to BootP clients that explictly request it as long as support for BootP clients is enabled. The DHCP server will also allocate a permanent lease to DHCP hosts that explicitly request it.
You can reserve a specific address and configuration parameters for a specific DHCP (or BootP) client host on a particular subnet.
You can allocate specific configuration information to a client regardless of its subnet.
You should explicitly exclude addresses from DHCP subnets for existing hosts that do not use DHCP or BootP for configuring their IP network access.
Although DHCP servers and clients automatically check to see if an IP address is in use before allocating or using it, they will not be able to detect addresses of manually-defined hosts that are turned off or temporarily off the network. In that case, duplicate address problems may occur when a manually-defined host reaccesses the network, unless its IP address is explicitly excluded.
The default lease time is 24 hours. The lease time you choose depends largely on your needs, including:
Keep in mind that the DHCP lease time you choose can affect your network operation and performance.
For complex networks that need to support a combination of host leasing requirements, you can use DHCP classing. For more information, see Defining Classes.
Dynamic DNS servers are a superset of today's BIND (Berkeley Internet Name Domain) DNS servers. The dynamic enhancements enable client hosts to dynamically register their name and address mappings in the DNS tables.
In Dynamic IP, A records (resource records that map a host's name to its IP address) are owned and updated automatically by client hosts containing a DDNS client program.
In Dynamic IP, DHCP servers own and update PTR (IP address-to-host name) record mappings in the Dynamic DNS server. For clients without DDNS capability, the DHCP server can make A record updates on behalf of the client.
Using the DHCP server to update A records and PTR records at the Dynamic DNS server includes creating both security keys and dynamic reverse domains. For more information on configuring an IBM DHCP server to perform record updates, see Defining Dynamic DNS Support.
The IBM DHCP server provides configuration information to clients based on statements contained in the server's configuration file and based on information provided by the client. The server's configuration file defines the policy for allocating IP addresses and other configuration parameters. The file is a "map" that the server uses to determine what information should be provided to the requesting client.
Before you start the DHCP server, use the DHCP Server Configuration program to create or modify the DHCP server configuration file.
Once the DHCP server is running, you can also make dynamic changes to the configuration by modifying the configuration file and using the DHCP Server Maintenance program to re-initialize the DHCP server. For more information on DHCP server initialization, see Re-initializing the Server.
You create a hierarchy of configuration parameters for a DHCP network by specifying some configuration values that are served globally to all clients, while other configuration values are served only to certain clients. Serving different configuration information to clients is often based on network location, equipment vendor, or user characteristics.
Depending on your configuration, you can specify subnets, classes, vendors, and clients to provide configuration information to different groups of clients:
Parameters specified for a subnet, class, or client are considered local to the subnet, class, or client. A client defined within a subnet inherits both the global options and the options defined for that subnet. If a parameter is specified in more than one level in the network hierarchy, the lowest level (which is the most specific) is used.
For more information on obtaining information for a DHCP client, see Maintaining the DHCP Server.
The concept of scoped statements in a DHCP server configuration file is
shown by the following example:
In this example:
For example, requesting clients are served the following options and values:
It is recommended that you use the DHCP Server Configuration program, a graphical user interface, to create, modify, and validate configuration files for your IBM DHCP servers. To simplify configuration debugging, data validation occurs for each configuration entry as you make it.
Attention: Although you may edit the DHCP server configuration file directly, there are significantly fewer safeguards:
For more information on editing the server configuration file, see Modifying the DHCP Server Configuration File. For more information on using the DHCP Server Configuration program, click online help.
To start the DHCP server, do one of the following:
Attention: Do not run the Microsoft DHCP server at the same time as you run the IBM DHCP server. Starting the Microsoft DHCP server and then starting the IBM DHCP server causes the IBM DHCP server to stop and write a message to the event log.
The dhcpsd command allows you to:
To display information about the command syntax without starting the server, use the following form of the dhcpsd command:
dhcpsd -?
To display the DHCP server banner (which includes the version number) without starting the server, use the following form of the dhcpsd command:
dhcpsd -b
To start the DHCP server, use the following form of the dhcpsd command:
dhcpsd [ -q | -v] [configFile]
To maintain a running DHCP server, IBM provides equivalent function in both the DHCP Server Maintenance program and the dadmin command.
Note:
When you start the DHCP Server Maintenance program, you will need to enter the administrator password. When you use the dadmin command, you might need to enter the administrator password. If you have forgotten the administrator password or want to change it, use the TCP/IP Administrator Password program.
The remainder of this section describes using the dadmin command. For more information about the DHCP Server Maintenance program, see the online help provided with the program.
Use the dadmin command to:
Notes:
To display information about the command syntax, enter:
dadmin -?
If you make changes to the configuration file, you will need to re-initialize the running server to implement the changes. To re-initialize the server, use the following form of the dadmin command:
dadmin [ -hhost] -i [ -v] -upassword| -x| -a
To display information for a client ID, use the following form of the dadmin command:
dadmin -cvalue [ -v] -upassword| -x| -a
To display information for one IP address, use the following form of the dadmin command:
dadmin -qn.n.n.n [ -v] -upassword| -x| -a
To display information for a pool of IP addresses, use the following form of the dadmin command:
dadmin -pn.n.n.n [ -v] -upassword| -x| -a
To start and stop tracing on the DHCP server, use the following form of the dadmin command:
dadmin -tvalue [ -v] -upassword| -x| -a
To display statistics information about the pool of addresses administered by the server, use the following form of the dadmin command:
dadmin [ -hhost] -nvalue [ -v] -upassword| -x| -a
Statistics include:
For more information on defining statistics snapshots, see Defining Server and Lease Parameters.
If you find that an assigned lease is not being used and you want to make the IP address available for allocation, you can delete the lease. You can only delete one lease at a time. You will be prompted to confirm deletion of the lease. To delete the lease, use the following form of the dadmin command:
dadmin [ -f] [ -v] [ -hhost] -dip_address -upassword| -x| -a
You may configure the DHCP server by using the DHCP Server Configuration program or by manually editing the DHCP server configuration file. This section will help you understand the output file created by the DHCP Server Configuration program. The DHCP Server Configuration program also automates the creation of Dynamic DNS security keys. For more information about the Dynamic DNS server, see DNS Administration. For an important warning, see Configuring the DHCP Server.
Attention: Although you may edit the DHCP server configuration file directly, there are significantly fewer safeguards:
The DHCP server configuration file resides in the directory specified by the ETC environment variable. A sample server configuration file called DHCPSD.CFG is located in the \TCPIP\SAMPLES directory.
You can create a hierarchy of configuration parameters by nesting statements within the DHCP server configuration file. This allows you to specify the scope of some configuration values that are served to all clients, while other configuration values are served only to certain clients. The statement used and its position in the file determines what information is supplied to the clients.
When editing the DHCP server configuration file:
subnet 9.67.48.0 255.255.240.0 9.67.48.1-9.67.48.15 (alias=mysubnet
Assign global values such as Class, Subnet, Option, Client, or Vendor statements by placing the statement outside any braces.
The DHCP-BootP protocol provides a way to supply vendor-specific information to a DHCP client using RFC-architected options 60 and 43:
For IBM clients, the vendor name is IBMWARP_4.1. The IBM-supplied vendor class for clients is specified at the client in the \DHCPCD.CFG file in the directory specified by the ETC environment variable. You should not change the value. The IBM DHCP client always sends option 60 requesting the IBMWARP_4.1 vendor information.
For more information, see descriptions of option 60 in Specifying DHCP Options.
For the IBM DHCP server, option 43 is configured using the Vendor statement in the configuration file.
No IBM-supplied Vendor statement for vendor IBMWARP_4.1 is defined at this time. Instead, IBM-specific information is provided in options 192 and 200 as specified in the default DHCPSD.CFG file in the directory specified by the ETC environment variable.
The Vendor statement is defined at the global level of the configuration file. A vendor statement within a Subnet, Class, or Client statement is ignored by the DHCP server.
The Vendor statement has two formats:
vendor vendor_name hex value
hex"01 02 03"
vendor vendor_name { option x hex "01 02" option y "ASCII string" }
Note:
For information on the format of hexadecimal strings, see RFC 2132.
An alternative to using the Vendor statement to provide vendor-specific information is to use the user-defined options (options 128-254). For example, the IBM DHCP server uses options 192 and 200 to provide IBM-specific options to IBM DHCP clients.
The Subnet statement specifies configuration parameters for an address pool administered by a server. An address pool is a range of IP addresses to be leased to clients. The task of configuring subnets also allows you to set lease time and other options for clients using the address pool. Lease time and other options can be inherited from a global level.
The Subnet statement can be used to define a subnet or a subnet group. The format of the Subnet statement used to define a subnet is:
subnet subnet_address [subnet_mask] range [( alias=name DDNSServer=ip_address]
Parameters to the right of a left parenthesis are used only by the DHCP Server Configuration program. A space must precede the left parenthesis. The DHCP server parses statements to the right of a left parenthesis as comments.
A subnet mask can be expressed either in dotted-decimal notation, or as an integer between 8 and 31. For example, enter a subnet mask as a dotted decimal notation of 255.255.240.0 or an integer format of 20. In subnet 9.67.48.0, a mask of 255.255.240.0 implies an address range from 9.67.48.001 to 9.67.63.254. The value 20 is the total number of 1s in a mask expressed in binary as 11111111.11111111.11110000.00000000.
Although not required, in most configurations the DHCP server should send option 1, subnet mask, to DHCP clients. Client operation may be unpredictable if the client receives no subnet mask from the DHCP server and assumes a subnet mask that is not appropriate for the subnet.
If not specified, the client uses the following default subnet masks:
Notes:
Parameters to the right of a left parenthesis are used only by the DHCP Server Configuration program. A space must precede the left parenthesis. The DHCP server parses statements to the right of a left parenthesis as comments.
The parameter alias=name immediately after a left parenthesis contains the symbolic name, which appears in the DHCP Server Configuration program graphic display of the server configuration. If no name is entered, the subnet IP address is used to identify the subnet in the DHCP Server Configuration program display.
To define a subnet group, use label:value[/priority]] in the Subnet statement:
subnet subnet_address [subnet_mask] range [ label:value[/priority]]
The subnet_address, subnet_mask, and range parameters are described in Defining Subnets. The parameters that define subnet groups include:
For example, the following two subnets are on the same wire:
inOrder subnet 9.67.49.0 255.255.240.0 9.67.49.1-9.67.49.100 label:WIRE1/2 subnet 9.67.48.0 255.255.240.0 9.67.48.1-9.67.48.50 label:WIRE1/1
To specify the policy by which IP addresses are served from multiple subnets, an inOrder or balance statement is required. Enter the following additional statements at a global level:
The labelslist is a list of labels in which each label identifies a subnet group. Each listed group is processed in order within that group. The subnet address pool with the highest priority within that group is completely exhausted before the subnet address pool with the next highest priority is used.
The labelslist is a list of labels in which each label identifies a subnet group. The server provides the first IP address from the subnet that is first in the priority list, and subsequent IP addresses from each lesser-priority subnet, repeating the cycle until addresses are exhausted equally from all subnets.
The following is an example of inOrder processing of two subnet groups. Requests for subnet group WIRE1 exhaust addresses in subnet 9.67.48.0 (WIRE1/1) first, followed by subnet 9.67.49.0 (WIRE1/2). WIRE1 and WIRE3 are not related. Requests for subnet group WIRE3 exhaust addresses in subnet 9.67.50.0 (WIRE3/1) first, followed by subnet 9.67.51.0 (WIRE3/2) and then 9.67.50.0 (WIRE3/3), which has the same subnet address as WIRE3/1, but specifies a higher address range:
inOrder: WIRE3 WIRE1 subnet 9.67.49.0 255.255.240.0 9.67.49.1-9.67.49.100 label:WIRE1/2 subnet 9.67.48.0 255.255.240.0 9.67.48.1-9.67.48.50 label:WIRE1/1 subnet 9.67.51.0 255.255.240.0 9.67.51.1-9.67.51.50 label:WIRE3/2 subnet 9.67.50.0 255.255.240.0 9.67.50.1-9.67.50.50 label:WIRE3/1 subnet 9.67.50.0 255.255.240.0 9.67.50.51-9.67.50.100 label:WIRE3/3
The following balance statement exhausts IP addresses equally in WIRE1/3 and WIRE1/4:
balance: WIRE1 subnet 9.67.49.0 255.255.240.0 9.67.49.101-9.67.49.200 label:WIRE1/3 subnet 9.67.48.0 255.255.240.0 9.67.48.201-9.67.48.300 label:WIRE1/4
A sequence of inOrder or balance statements is cumulative. For example, the statements:
inOrder: WIRE1 inOrder: WIRE3have the cumulative effect of the single statement:
inOrder: WIRE1 WIRE3
Note:
To disable multiple subnets, comment out either the balance or inOrder processing statement or the priority.
To assign additional configuration parameters, use the Option statement. All clients inherit all globally-defined options. A client defined within a Subnet statement inherits global options and options defined for that address pool. To assign configuration parameters for all clients in a subnet, follow the Subnet statement with option statements surrounded by braces. For information about specifying options, see Specifying DHCP Options.
To migrate previous subnet configuration files that contain Network statements, you can manually edit existing DHCP server configuration files:
For 802.3 clients, use the canonical keyword to instruct the DHCP server to transform MAC addresses to canonical (byte starts with least significant bit) form. In most cases, you do not want the DHCP server to transform canonical addresses. MAC addresses of 802.3 clients are normally in canonical format on an 802.3 network. When 802.3 MAC addresses are transmitted across a transparent bridge, the bridge reformats the bits that identify an 802.3 client MAC address to a non-canonical (byte starts with most significant bit) form. When the bridge returns the MAC address to an 802.3 network, the bridge again reformats MAC addresses.
To cause the DHCP server to transform MAC addresses, use:
canonical value
The Class statement specifies configuration parameters for a user-defined group of clients administered by a server. The scope of the Class statement is allowed at a global or subnet level. When the Class statement is specified within a Subnet statement, the server will only serve clients in the class that are both located in the specified subnet and request the class.
For example, to create a class called "accounting" so member hosts can use the LPR server (option 9) at 9.67.123.2:
When the client requests configuration information, the server sees that it belongs to the accounting class and provides configuration information that instructs the client to use the LPR server at 9.67.123.2. DHCP clients use option 77 to indicate their class to DHCP servers.
The format of the Class statement is:
class class_name [range]
At a global level, a class cannot have a range. A range is allowed only when a class is defined within a subnet. The range can be a subset of the subnet range. Or the range can be the same as the subnet range; that is, the whole subnet is reserved for a single class.
A client that requests an IP address from a class which has exhausted its range, is offered an IP address from the subnet range, if available. The client is offered the options associated with the exhausted class.
To assign configuration parameters such as a lease time for all clients in a class, follow the Class statement with Option statements surrounded by braces. For more information on options, see Specifying DHCP Options.
The Client statement is used to:
For more information on excluding addresses, see Excluding an IP Address for a DHCP Client.
Parameters to the right of a left parenthesis are used only by the DHCP Server Configuration program. A space must precede the left parenthesis. The DHCP server parses statements to the right of a left parenthesis as comments.
To configure options for a specific DHCP client, follow the Client statement with Option statements surrounded by braces. For a specific client, the following statement reserves the static address 9.67.99.149 and also specifies a lease time (option 51) of 12 hours (43200 seconds) and a subnet mask (option 1):
client 6 10005aa4b9ab 9.67.99.149
{
option 51 43200
option 1 255.255.255.0
}
The format of the Client statement is:
client hw_type clientID ipaddr [( alias=name]
For more information about DHCP options, see Specifying DHCP Options.
To specify options, but allow the DHCP server to choose the address from the subnet the DHCP client is in, use the ANY parameter. Do not specify an IP address. For example, to allow any IP address to be assigned to a specific client, but make sure that the lease time is a specific value such as 12 hours (43200 seconds) and the mask is 255.255.255.0, specify:
client 6 10005aa4b9ab ANY
{
option 51 43200
option 1 255.255.255.0
}
If you do not want your DHCP server to accept requests from a particular client ID, you can exclude the client ID from service. The Client statement is allowed at global, subnet, or class levels. To exclude a client from service, specify the Client statement as follows:
client hw_type clientID NONE
For example:
client 6 10005aa4b9ab NONE
To exclude one or more IP addresses from the pool of addresses available for lease, specify the Client statement:
client 0 0 9.67.3.123
client 0 0 9.67.3.222
In this case, the hardware type and the client ID are 0. IP addresses 9.67.3.123 and 9.67.3.222 are excluded. Specify a separate statement for each address to be excluded.
You can also exclude a range of IP addresses from the pool of addresses available for lease by specifying many Client statements.
Note:
Using the DHCP Server Configuration program, it is recommended that each range of excluded addresses not contain more than 10 addresses. Each excluded address results in a separate Client statement in the configuration file. To exclude larger numbers of addresses, define subnets that do not include the addresses to be excluded. For example, to exclude addresses 50-75 in subnet 9.67.3.0, specify:inOrder: WIRE1 subnet 9.67.3.0 255.255.240.0 9.67.3.1-9.67.3.49 label:WIRE1/1 subnet 9.67.3.0 255.255.240.0 9.67.3.76-9.67.3.100 label:WIRE1/2
Use the Client statement to provide a permanent IP address to BootP clients. Note, however, that only BootP options will be served. Any DHCP options specified will be ignored, such as option 51 in this example:
client 1 03a5ca4b23cd 9.37.3.415
{
option 51 43200
option 1 255.255.255.0
}
If you provide IP addresses to BootP clients, remember to change the value of supportBootP from NO (the default) to YES.
To specify whether the DHCP server specifies a bootstrap server for clients, use:
bootStrapServer value
The value is the IP address or the host name of the bootstrap server for the BootP client.
This statement can appear at the global level, or within Subnet, Class, or Client statements.
At a server level, you can define global parameters, including lease length, which clients are served, and additional server parameters, such as statistics snapshots and BootP support.
To specify the default lease duration for the leases issued by this server, use:
leaseTimeDefault value
The value is a decimal integer followed by a space and a unit of time, which can be years, months, weeks, days, hours, minutes, or seconds. The default is minutes.
To apply a global lease time for all addresses issued by this server, specify this statement outside braces. To override this statement for a set of clients, use option 51 (IP address lease time) for a specific client, class of clients, or subnet.
To specify the interval at which the lease condition of all addresses in the address pool is examined, use:
leaseExpireInterval value
The value is a decimal integer optionally followed by a space and a unit of time, which can be years, months, weeks, days, hours, minutes, or seconds. If the value is not followed by a unit, minutes are assumed. The value specified should be less than the value for leaseTimeDefault to ensure that expired leases are returned to the pool in a timely manner.
To specify the maximum amount of time the server holds an offered address in reserve while waiting for a response from the client, use:
reservedTime value
The value is a decimal integer optionally followed by a space and a unit of time, which can be years, months, weeks, days, hours, minutes, or seconds. If the value is not followed by a unit, minutes are assumed.
Before the server allocates an IP address, it PINGs the address to make sure it is not already in use by a host on the network. The server places an in-use address in a special pool and allocates a different address.
To specify the interval a DHCP server holds an in-use address in a special pool before returning the address to the active pool available for assignment, use:
usedIPAddressExpireInterval value
The value is a decimal integer optionally followed by a space and a unit of time, which can be years, months, weeks, days, hours, minutes, or seconds. If the value is not followed by a unit, minutes are assumed.
Before assigning an IP address, the DHCP server tests to be sure the IP address is not already in use. To specify the interval between multiple pings (pingTime keyword) in this test, use:
pingTime value
The value is a decimal integer optionally followed by a space and a unit of time. Only seconds is allowed as a unit. If the value is not followed by a unit, the maximum value is assumed.
To specify whether the server responds to requests from BootP clients, use:
supportBootP [ YES | NO]
The default is NO. If this statement is not specified, or if any value other than YES is specified, the server will not respond to requests from BootP clients.
If this server previously supported BootP clients and has been reconfigured not to support BootP clients, the address binding for any BootP clients that was established before the reconfiguration will be maintained until the BootP client sends another request (when it is restarting). At that time, the server will not respond, and the binding will be removed.
This statement should be specified outside braces and, therefore, is used for all addresses issued by this server.
To specify whether the server responds to requests from DHCP clients other than those whose client IDs are specifically listed in this configuration file, use:
supportUnlistedClients [ YES | NO]
The default is YES. If you specify NO, the server will respond only to requests from DHCP clients that are listed (by client ID) in the configuration file.
For example:
client 6 10005aa4b9ab ANY
client 6 10a03ca5a7fb ANY
If this statement is not specified, or if you specify YES, the server will respond to requests from any DHCP client. This option can be used to limit access to addresses issued by this DHCP server. Listing the client IDs for all acceptable clients may be time consuming.
This statement should be specified outside braces and, therefore, is used for all addresses issued by this server.
To specify whether the server broadcasts replies in bridged or Token Ring environment, use:
allRoutesBroadcast [ YES | NO]
The default is NO. If the value is NO, server replies are sent either by the routing information field in the packet or by single-route broadcast. If the value is YES, server replies are broadcast on all routes on a bridged token-ring network that is directly attached to the server interface and that implements a spanning-tree algorithm.
To specify the number of intervals that expire before the DHCP server takes a snapshot of statistics, use:
statisticSnapshot value
The length of each interval is determined by the leaseExpireInterval keyword. For example, a value of 3 will collect statistics after a span of three intervals, where each interval has a length specified by the leaseExpireInterval keyword. If no value is specified, the server takes a snapshot of statistics at the end of every lease expire interval. For more information on server statistics, see Displaying Server Statistics.
To enable logging by the server, all of the following must be specified:
Specify the number of log files maintained, using:
numLogFiles value
Notes:
Specify the size of the log file, using:
logFileSize value
Name the log file, using:
logFileName file_path
If no directory is specified, the default is the directory specified by the ETC environment variable. If the specified path is not valid, the DHCP client continues to operate but does not log any information. If no log file name is specified, the logged information is displayed on the screen.
Specify information types to log, using:
logItem object
SYSERR
Errors at the interface to the operating system
OBJERR
Errors between objects in the process
PROTERR
Protocol errors between the client and server
WARNING
Warnings that warrant the user's attention
EVENT
Events in the process
ACTION
Actions taken by the process
INFO
Useful information
ACNTING
Accounting information, such as who was served and when
TRACE
Trace information
STAT
Statistics information at each DHCP server garbage collection interval
The DDNS proxy A-record update feature supports clients that do one of the following:
The proxyARec update feature allows non-Dynamic IP clients (clients which have DHCP client capability but not DDNS capability) to effectively participate in the Dynamic IP system. This alternative is well-suited for network environments where client hosts are not mobile or do not change administrative domains.
New keywords in the DHCP server configuration file instruct the DHCP server how to interact with the DDNS server using A records on behalf of DHCP clients. The new keywords are:
For more information on enabling DHCP server A record updates, see Enabling Dynamic A Record Updates
For more information on enabling A record updates, see Specifying the Keyword for A Record Updates
For more information on enabling PTR record updates, see Specifying the Keyword for PTR Record Updates
Once the DHCP server reads the configuration file and is instructed how and when to perform a DDNS proxy A record update, the following rules of precedence are used to derive the host name data to be used:
The data used in the DDNS update packet is derived using one or more of the above means until a fully-qualified host name data is established. For example, in the case of Microsoft Windows 3.11+ and Windows 95 clients, only option 12, the Microsoft Windows client computer name, is included in DHCP lease requests. In this case, the administrator can define an option 15, domain name, to use with the host name provided by a client's option 12 to obtain the host's fully-qualified name.
The proxy A-record update feature works with any client which is capable of including host name info in option 81 and/or options 12 and 15. Otherwise, the DHCP client host, as identified by its LAN adapter's MAC address, and its host name information can be specified entirely in the DHCP server's configuration file.
Note:
If you use DDNS proxy A record support for subnets which include some hosts capable of updating their own DDNS A-records such as IBM OS/2 Warp Dynamic IP clients, you may wish to disable those client's own DDNS update feature by commenting out updateDNSA and UpdateDNSTxt keywords in the client's DHCPCD.CFG configuration file. If you do not disable the dynamic A record updates at the clients, the proxy A record updates attempted at the DHCP server for those clients will fail because the DHCP client, rather than the DHCP server, will own the client's entry on the DDNS database.
Specify the proxyARec keyword to enable the DHCP server to dynamically update an A record mapping (host name-to-IP-address) on a DDNS server for clients unwilling or unable to update their A records.
The format of the proxyARec keyword is:
proxyARec [ PROTECTED | STANDARD]
The default is PROTECTED if this keyword is generated by the DHCP Server Configuration program. The default is STANDARD if the proxyARec keyword is entered in the DHCP server configuration file without a value. (If no value is specified, STANDARD is assumed.) If the value of proxyARec is PROTECTED, the DHCP server updates a client's A record for a particular host name only if the client's client ID has not changed since the last time the host name was updated. If the value is STANDARD, the DHCP server performs updates of the client's A record regardless of the client's client ID value.
Note:
The administrator can allow selected clients to be exempt from having their client ID checked when the proxyARec keyword is specified in PROTECTED mode. The administrator must manually create an HINFO RR for each selected client, placing a special value of all in both fields of the client's HINFO RR. In this case, the client ID is not checked for changes since the last time the host name was updated. The nsupdate program allows any client ID to match the client ID in the HINFO RR and will never delete the HINFO RR. For more information on the HINFO RR, see the DNS Administration.
The proxyARec keyword is required to be enabled globally or within the subnet, class, or client level. The updateDNSA keyword must also be specified. If the proxyARec keyword is not specified, clients will not have their A records updated.
Specify the proxyARec statement within braces to indicate the information applies only to the subnet, class, or clients that meet the criteria of the preceding conditional statement. To globally assign proxyARec, specify the keyword outside any braces.
To specify how the server updates A records for a non-IBM IP client, use keyword:
updateDNSA command_string
The following is a typical updateDNSA string issued by the DHCP server:
updateDNSA "nsupdate -f -h%s -d%s -s"d;a;*;a;a;%s;s;%s;3110400;q""
This default string is normally adequate. Typical changes to the command string are to modify the value of an expiration time (such as 3110400 seconds) beyond the A record expiration. Assuming proxyARec is specified, this example instructs the DDNS name server to delete all A records for this host name and add a record that maps the host name to the specified IP address for the specified lease time.
The command string includes:
Delete all A (host name-to-IP-address) records for this host.
Add an A record using an IP address (%s) provided by the server, where %s indicates string substitution.
Send a lease time (%s) (value provided by the server for the IP address), where %s indicates string substitution.
The effect of this value is to reserve the host name for an additional time interval after the A record expiration. In this case, an interval of 36 days (3110400 seconds) is added to the A record expiration time. This value works to preserve a user's host name during times when the name-to-address mapping might expire, such as holidays, vacation, or other times of inactivity.
Quit delimiter for the command string
For more information on client control of A record updates for non-dynamic DHCP clients, see client option81 in Specifying DHCP Options.
Use the releaseDNSA keyword at a global level as a template which tells the DHCP server how to release a client record, when the client requests release. The template is adequate for normal purposes, but may be modified if necessary.
The keyword is:
releaseDNSA string
The following is an example of a releaseDNSA string:
releaseDNSA "nsupdate -f -h%s -s"d;a;%s;s;%s;0;q""
The command string includes:
Delete the A (host name-to-IP-address) record for this host.
Send a lease time (%s) (value provided by the server for the IP address).
An additional time interval added to the normal expiration of the host name beyond the expiration of the A resource record. In this case, the value is zero because the A resource record is deleted.
Quit delimiter for the command string
DHCP servers "own" the PTR records and can update DDNS servers with a PTR record (resource records that map an IP address to a host name) for each address allocated to a host that identifies itself with DHCP options 12 (host name) and 15 (domain name), or with option 81, Client DHCP-DNS.
To enable DHCP server PTR record updates, use:
updateDNSP command_string
The following is a typical updateDNSP string issued by the DHCP server:
updateDNSP "nsupdate -f -r%s -s"d;ptr;*;a;ptr;%s;s;%s;0;q""
This default string is normally adequate. Typical changes to the command string are to modify an the name expiration extension time such as 0. This example instructs the DDNS name server to delete all PTR records for this address and add a record that maps the IP address to the new host name for the specified lease time. The updateDNSP command is issued when the DHCP client is assigned an address.
The command string includes:
Delete all PTR (IP-address-to-host name) records for this IP address.
Add a PTR record which maps the IP address to the host name (%s) provided by the server.
Send a lease time (%s) (value provided by the server).
The effect of this value is to reserve the IP address entry this many seconds beyond when the IP address-to-host name mapping expires. In this case, no additional time is added.
Quit delimiter for the command string
Note:
The updateDNSP keyword is equivalent to the updateDNS keyword in earlier releases. The updateDNS keyword continues to be supported.
For more information on how a non-dynamic IP client updates its A and PTR records, see customizing DHCP client operation in DHCP and Dynamic IP Introduction. For more information about the nsupdate command and its other parameters, see DNS Administration.
Use the releaseDNSP keyword at a global level as a template which tells the DHCP server how to release the client PTR record, when the client requests release. The template is adequate for normal purposes, but may be modified if necessary. For example, this DHCP server keyword enables immediate release of a PTR record when a mobile client's lease is terminated.
The DHCP server command is:
releaseDNSP string
The following is an example of a releaseDNSP string:
releaseDNSP "nsupdate -f -r%s -s"d;ptr;%s;s;%s;0;q""
The command string includes:
Delete the PTR record for this address.
Send a lease time (%s) (value provided by the server for the IP address).
An additional time interval added to the normal expiration of the PTR resource record beyond the expiration of the PTR resource record. In this case, the value is zero because the record is deleted.
Quit delimiter for the command string
To specify whether the DHCP server should append a domain name to client responses that omit a domain name, use:
appendDomainName [ YES | NO]
The default is YES. If the value of appendDomainName is YES, the server appends a domain name to a host name received from a client that does not send a domain name.
Note:
If a client does provide a domain name, the client-supplied domain name is used.
If the value is NO, or no value is specified at the DHCP server in option 15, the client is required to provide a value for option 12, host name, and option 15, domain name, or option 81, Client DHCP-DNS. This statement may appear at the global level, or within Subnet, Class, or Client statements.
Defining DDNS support also includes ensuring the DHCP domain is recognized at the DDNS server and setting up the necessary security for making updates to the DDNS server. To enable A record and PTR record dynamic update support in your DHCP server:
Additionally, you can define Specifying nsupdate logging.
The DDNS.DAT file contains the security key pairs to be used for processing IP address-to-host name and host name-to-IP-address updates for the specified addresses which are sent to the corresponding primary DDNS server. The file must contain at least one entry per primary DDNS server.
You can use the DHCP Server Configuration program to create the DDNS.DAT file. If you prefer to create the file manually, run the nsupdate command on the server to add entries to the file. The format of the nsupdate command for creating security key pairs for updating PTR records in the DDNS.DAT file is:
nsupdate -f -hinverse_ip_address -g -pprimary_ddns_server
For example:
nsupdate -f -g -h *.33.37.9.in-addr.arpa -p ns-updates.company.com
The wild card (*) allows aggregate entries such as *.33.37.9.in-addr.arpa to represent all addresses beginning with the three octets 9.37.33.
The format of the entry in the DDNS.DAT file for a DHCP server is:
inverse_ip_address primary_ddns_server private_key public_key
The inverse_ip_address and primary_ddns_server are explained above.
The private_key and public_key are used to provide fail-save authentication for updates submitted by this DHCP server. As stored in the DDNS.DAT file, the private key is encrypted.
Note:
The DDNS.DAT file is an ASCII file. It is recommended that you not edit the file because most editors cannot accomodate the line length of the file. If any line of the file is split or truncated, your DDNS updates will fail.
The format of the nsupdate command for creating security key pairs for updating A records in the DDNS.DAT file is:
nsupdate -f -g -hfully_qualified_host_name -pprimary_ddns_server
For example:
nsupdate -f -g -h *.city.company.com -p ns-updates.company.com
You can specify a specific host, such as myhost, or use a wild card to allow aggregate entries such as *.city.company.com to represent all hosts in the zone.
To configure nsupdate logging, edit the \NSUPDATE.CNF file. A log of updates to the DNS nameserver is stored in the \NSUPDATE.LOG file, in the directory specified by the ETC environment variable.
DHCP allows you to specify options, also known as BootP vendor extensions, to provide additional configuration information to the client. RFC 2132 defines the options that you can use. Each option is identified by a numeric code.
Architected options 0 though 127 and option 255 are reserved for definition by RFCs. The DHCP server, the DHCP client, or both server and client use options in this set. Some architected options can be modified by the administrator. Other options are for exclusive use by the client and server.
Note:
Hexadecimal values are not allowed for architected options with known formats.
Options that the administrator cannot or should not configure at the DHCP server include:
Options 128 through 254 represent user-defined options that can be defined by administrators to pass information to the DHCP client to implement site-specific configuration parameters. Additionally, IBM provides a set of IBM-specific options such as option 192, TXT RR.
The format of user-defined options is:
Option code value
code can be any option code 1 through 254.
value must always be a string. At the server, it can be an ASCII string or a hexadecimal string. At the client, however, it always appears as a hexadecimal string as passed to the processing program.
The server passes the specified value to the client. You must, however, create a program or command file to process the value.
This section describes:
Additional help information is available when you use the DHCP Server Configuration program to input data for DHCP options. RFC 2132 defines the following data formats for DHCP options:
There are 7 option categories:
Following are the base options provided to the client:
This option is specified only at the DHCP server.
The client's subnet mask, specified in 32-bit dotted decimal notation.
Although not required, in most configurations the DHCP server should send option 1, subnet mask, to DHCP clients. Client operation may be unpredictable if the client receives no subnet mask from the DHCP server and assumes a subnet mask that is not appropriate for the subnet.
If not specified, the client uses the following default subnet masks:
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
The offset (in seconds) of the client's subnet from Coordinated Universal Time (CUT). The offset is a signed 32-bit integer.
Configuration file format: Long
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the routers on the client's subnet.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the time servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the IEN 116 name servers available to the client.
Note:
This is not the Domain Name Server option. Use Option 6 to specify a Domain Name Server.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Domain Name System servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the MIT-LCS UDP Log servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Cookie, or quote-of-the-day servers available to the client.
Configuration file format: IP addresses
This option can be specified at both the DHCP client and DHCP server. However, if specified only at the DHCP client, the configuration will be incomplete.
IP addresses (in order of preference) of the line printer servers available to the client. Option 9 eliminates the need for the client to specify the LPR_SERVER environment variable.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Imagen Impress servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Resource Location (RLP) servers available to the client. RLP servers allow clients to locate resources that provide a specified service, such as a domain name server.
Configuration file format: IP addresses
This option can be specified at both the DHCP client and DHCP server. If the DHCP client does not provide a host name, the DHCP server does nothing with option 12.
Host name of the client (which may include the local domain name). The minimum length for the host name option is 1 octet and the maximum is 32 characters. See RFC 1035 for character set restrictions.
Configuration file format: String
This option is specified only at the DHCP server.
The length (in 512-octet blocks) of the default boot configuration file for the client.
Configuration file format: Unsigned short
This option is specified only at the DHCP server.
The path name of the merit dump file in which the client's core image is stored if the client crashes. The path is formatted as a character string consisting of characters from the Network Virtual Terminal (NVT) ASCII character set. The minimum length is 1 octet.
Configuration file format: String
This option can be specified at both the DHCP client and DHCP server. For more information on the DHCP server appending a domain name if the DHCP client does not provide a domain name, see Appending Client Domain Names.
Domain name that the client uses when resolving host names using the Domain Name System. The minimum length is 1 octet.
Configuration file format: String
This option is specified only at the DHCP server.
IP address of the client's swap server.
Configuration file format: IP address
This option is specified only at the DHCP server.
Path that contains the client's root disk. The path is formatted as a character string consisting of characters from the NVT ASCII character set. The minimum length is 1 octet.
Configuration file format: String
This option is specified only at the DHCP server.
The extensions path option allows you to specify a string that can be used to identify a file that is retrievable using Trivial File Transfer Protocol (TFTP).
The minimum length is 1 octet.
Configuration file format: String
Following are the options that affect the operation of the IP layer on a per host basis:
This option is specified only at the DHCP server.
Enable (1) or disable (0) forwarding by the client of its IP layer packets.
Configuration file format: Boolean
This option is specified only at the DHCP server.
Enable (1) or disable (0) forwarding by the client of its IP layer datagrams with non-local source routes. The length is 1 octet.
Configuration file format: Boolean
This option is specified only at the DHCP server.
IP address-net mask pair used to filter datagrams with non-local source routes. Any datagram whose next hop address does not match one of the filter pairs is discarded by the client. The minimum length for the policy filter option is 8 octets.
Configuration file format: IP address pair
This option is specified only at the DHCP server.
Maximum size datagram the client will reassemble. The minimum value is 576.
Configuration file format: Unsigned short
This option is specified only at the DHCP server.
Default time-to-live (TTL) the client uses on outgoing datagrams. TTL is an octet with a value between 1 and 255.
Format: Unsigned byte
This option is specified only at the DHCP server.
Timeout in seconds used to age Path Maximum Transmission Unit (MTU) values discovered by the mechanism that is described in RFC 1191.
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
Table of MTU sizes to use in Path MTU discover as defined in RFC 1191. The minimum MTU value is 68. The minimum length for the path MTU plateau table option is 2 octets. The length must be a multiple of 2.
Configuration file format: Unsigned shorts
Following are the options that affect the operation of the IP layer on a per interface basis. The client may issue multiple requests, one per interface, when configuring interfaces with their specific parameters.
This option is specified only at the DHCP server.
Maximum Transmission Unit (MTU) to use on this interface. The minimum MTU value is 68.
Configuration file format: Unsigned short
This option is specified only at the DHCP server.
Client assumes (1) or does not assume (0) all subnets use the same Maximum Transmission Unit (MTU). A value of 0 means the client assumes some subnets have smaller MTUs.
Configuration file format: Boolean
This option is specified only at the DHCP server.
Broadcast address used on the client's subnet.
Configuration file format: IP address
This option is specified only at the DHCP server.
Client performs (1) or does not perform (0) subnet mask discovery using Internet Control Message Protocol (ICMP).
Configuration file format: Boolean
This option is specified only at the DHCP server.
Client responds (1) or does not respond (0) to subnet mask requests using Internet Control Message Protocol (ICMP).
Configuration file format: Boolean
This option is specified only at the DHCP server.
Client solicits (1) or does not solicit (0) routers using router discovery as defined in RFC 1256.
Configuration file format: Boolean
This option is specified only at the DHCP server.
Address to which a client transmits router solicitation requests.
Configuration file format: IP address
This option is specified only at the DHCP server.
Static routes (destination address-router pairs in order of preference) the client installs in its routing cache. The first address is the destination address and the second address is the router for the destination. Do not specify 0.0.0.0 as a default route destination.
Configuration file format: IP address pairs
Following are the options that affect the operation of the data link layer on a per-interface basis:
This option is specified only at the DHCP server.
Client negotiates (1) or does not negotiate (0) the use of trailers when using Address Resolution Protocol (ARP). For more information, see RFC 893.
Configuration file format: Boolean
This option is specified only at the DHCP server.
Timeout in seconds for Address Resolution Protocol (ARP) cache entries.
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
For an Ethernet interface, client uses IEEE 802.3 (1) Ethernet encapsulation described in RFC 1042 or Ethernet V2 (0) encapsulation described in RFC 894.
Configuration file format: Boolean
Following are the options that affect the operation of the TCP layer on a per-interface basis:
This option is specified only at the DHCP server.
Default time-to-live (TTL) the client uses for sending TCP segments.
Configuration file format: Unsigned byte
This option is specified only at the DHCP server.
Interval in seconds the client waits before sending a keep-alive message on a TCP connection. A value of 0 indicates the client does not send keep-alive messages unless requested by the application.
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
Client sends (1) or does not send (0) TCP keep-alive messages that contain an octet of garbage for compatibility with previous implementations.
Configuration file format: Boolean
Following are options that can be used to configure miscellaneous applications and services:
This option is specified only at the DHCP server.
The client's Network Information Service (NIS) domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. The minimum length is 1 octet.
Configuration file format: String
This option is specified only at the DHCP server.
IP addresses (in order of preference) of Network Information Service (NIS) servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of Network Time Protocol (NTP) servers available to the client.
Configuration file format: IP addresses
Option 43 is specified only at the DHCP server, which returns this option to a client that sends option 60, Class Identifier.
This information option is used by clients and servers to exchange vendor-specific information, which is specified in the vendor definition.
Considerations in using option 43 to encapsulate vendor information are:
Servers that cannot interpret the vendor-specific information sent by a client must ignore it.
Clients that do not receive desired vendor-specific information should attempt to operate without it. Refer to RFC 2131 and RFC 2132 for additional information about this option.
Note:
Because of these considerations, IBM instead uses options 192 and 200 for IBM-specific options.
Configuration file format: String
This option is specified only at the DHCP server.
IP addresses (in order of preference) of NetBIOS name servers (NBNS) available to the client.
This option is specified only at the DHCP server.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of NetBIOS datagram distribution (NBDD) name servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
Node type used for NetBIOS over TCP/IP configurable clients as described in RFC 1001 and RFC 1002.
Values to specify client types include:
Configuration file format: Unsigned byte
This option is specified only at the DHCP server.
NetBIOS over TCP/IP scope parameter for the client, as specified in RFC 1001/1002. The minimum length is 1 octet.
Configuration file format: Unsigned byte
This option is specified only at the DHCP server.
IP addresses (in order of preference) of X Window System font servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of systems running X Window System Display Manager available to the client.
Configuration file format: IP addresses
Following are the available options that are specific to DHCP.
This option is specified only at the DHCP client. The DHCP server can refuse a DHCP client request for a specific IP address.
Allows the client to request (DHCPDISCOVER) a particular IP address.
Configuration file format: N/A
This option can be specified at both the DHCP client and DHCP server. The DHCP client can use option 51 to override the defaultLeaseInterval value the DHCP server offers.
Allows the client to request (DHCPDISCOVER or DHCPREQUEST) a lease time for an IP address. In a reply (DHCPOFFER), a DHCP server uses this option to offer a lease time.
This option may be specified in a network, subnet, or class of client definition. Use 0xffffffff to indicate an infinite (permanent) lease.
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
Interval in seconds between the time the server assigns an address and the time the client transitions to the renewing state.
Configuration file format: Unsigned long
This option is specified only at the DHCP server.
Interval in seconds between the time the server assigns an address and the time the client enters the rebinding state.
Configuration file format: Unsigned long
This option is sent by the DHCP client. This information is generated by the client and does not have to be specified.
Type and configuration of the client, supplied by the client to the server. For example, the identifier may encode the client's vendor-specific hardware configuration. The information is a string of n octets, interpreted by servers. For example:
hex"01 02 03"
Servers not equipped to interpret the class-specific information sent by a client must ignore it. The minimum length is 1 octet.
Configuration file format: N/A
This option is specified only at the DHCP server.
Netware/IP Domain Name.
The minimum length is 1 octet and the maximum length is 255.
Configuration file format: String
This option is specified only at the DHCP server.
A general purpose option code used to convey all the NetWare/IP related information except for the NetWare/IP domain name. A number of NetWare/IP sub-options will be conveyed using this option code.
The minimum length is 1 and the maximum length is 255.
Configuration file format: String
This option is specified only at the DHCP server.
Network Information Service (NIS)+ V3 client domain name. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. Its minimum length is 1.
Configuration file format: String
This option is specified only at the DHCP server.
IP addresses (in order of preference) of Network Information Service (NIS)+ V3 servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
Trivial File Transfer Protocol (TFTP) server name used when the "sname" field in the DHCP header has been used for DHCP options
Configuration file format: String
This option is specified only at the DHCP server.
Name of the boot file when the 'file' field in the DHCP header has been used for DHCP options. The minimum length is 1.
Note:
Use this option to pass a boot file name to a DHCP client. The boot file name is required to contain the fully-qualified path name and be less than 128 characters in length. For example:option 18 c:\path\boot_file_name
This file contains information that can be interpreted in the same way as the 64-octet vendor-extension field within the BOOTP response, with the exception that the file length is limited to 128 characters by the BootP header.
Configuration file format: String
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the mobile IP home agents available to the client. The option enables a mobile host to derive a mobile home address, and determine the subnet mask for the home network. The usual length will be four octets, containing a single home agent's home address.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Simple Mail Transfer Protocol (SMTP) servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Post Office Protocol (POP) servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Network News Transfer Protocol (NNTP) servers available to the client. For example:
option 71 "9.24.112.2"
An OS/2 client stores the updated option value in the TCPOS2.INI file.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the World Wide Web (WWW) servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Finger servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the Internet Relay Chat (IRC) servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the StreetTalk servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP server.
IP addresses (in order of preference) of the StreetTalk Directory Assistance servers available to the client.
Configuration file format: IP addresses
This option is specified only at the DHCP client.
DHCP clients use option 77 to indicate to DHCP servers what class the host is a member of. The user class must be manually entered in the \DHCPCD.CFG file as the value for option 77 in order to receive parameters defined for the class at a DHCP server. The DHCPCD.CFG file is located in the directory specified by the ETC environment variable.
Configuration file format: string
This option is specified only at the DHCP server.
The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. In certain other instances they may need to discover the correct scope and naming authority to be used in conjunction with the service attributes and URLS which are exchanged using the Service Location Protocol.
A directory agent has a particular scope, and may have knowledge about schemes defined by a particular naming authority.
Configuration file format: IP address
This option is specified only at the DHCP server.
This extension indicates a scope that should be used by a service agent, when responding to Service Request messages as specified by the Service Location Protocol.
Configuration file format: string
This option is specified only at the DHCP server.
This extension indicates a naming authority (which specifies the syntax for schemes that may be used in URLs for use by entities with the Service Location Protocol.
Configuration file format: string
This option is specified only at the DHCP client.
A non-dynamic IP client allows the DHCP server to update (1) the client's A record. The client can also decline (0) to have the server update the A record. In either case, the client includes its fully-qualified domain name (FQDN) in a DHCPREQUEST.
A client that updates its own A record and also releases a lease prior to the lease expiration interval, should delete the A record associated with the leased address before sending a DHCPRELEASE message.
Configuration file format: string
IBM provides a set of IBM-specific options by defining options within the user-defined range (128-254). These options are used instead of defining a vendor option (option 43) for IBM.
It is recommended that you not redefine these options.
This option can be specified at both the DHCP client and DHCP server. If this option is specified at the DHCP server, the DHCP client user is required to complete the fields.
This option provides up to four required text labels and entry fields the system administrator can specify, such as the name of a user, the user's phone number, or other fields that prompt the DDNS Client configuration user for additional information. These fields allow the system administrator to identify the actual person who configured the host name or other data. The DDNS configuration user does not see these fields unless the system administrator specifies them.
The pairs of field labels and data are required to fit within a single TXT resource record. The space available is divided evenly between the pairs. For example:
option 192 "Name;Office;Building;Phone"
The value is updated in file DDNSCLI.CFG, which is saved on the DDNS server.
Configuration file format: String
This option is specified only at the DHCP server.
Eliminates the need for the client to specify the LPR_PRINTER environment variable, which can be the name of a device such as LPT1 or a printer name (queue name) such as Printer.
For example:
option 200 "lpt1"
An OS/2 client stores the updated option value in the TCPOS2.INI file.
The length is 1 octet.
Configuration file format: String
IBM provides a REXX command script, DHCPLPR.CMD, with the DHCP client to configure the default LPR server using DHCP option 9, and the default LPR printer using DHCP option 200.
Option code 200 is a user-defined option.
The following options were previously supported by the command script DHCPIBM.CMD, but are no longer shipped or supported:
Additionally, DHCPLPR.CMD no longer supports option 205, Default SOCKS Server.
Possible hardware types are:
The following files are used to manually configure a DHCP server:
logFileName test1.log logFileSize 100 numLogFiles 4 logItem SYSERR logItem ACNTING logItem OBJERR logItem EVENT logItem PROTERR logItem WARNING logItem INFO logItem TRACE logItem ACTION updateDNSP "nsupdate -f -r%s -s"d;ptr;*;a;ptr;%s;s;%s;0;q"" releaseDNSP "nuspdate -f -r%s -s"d;ptr;%s;s;%s;0;q"" updateDNSA "nsupdate -f -h%s -s"d;a;*;a;a;%s;s;%s;3110400;q" -q" releaseDNSA "nsupdate -f -h%s -s"d;a;%s;s;%s;0;q"" supportBOOTP yes supportUnlistedClients yes option 15 raleigh.ibm.com inOrder: network1 proxyARec protected # Addresses 8.67.112.24 through 8.67.112.25 do not inherit # options defined for 8.67.112.26 through 8.67.112.30 subnet 8.67.112.0 255.255.255.0 8.67.112.24-8.67.112.25 label:network1/1 (alias=network1 subnet 8.67.112.0 255.255.255.0 8.67.112.26-8.67.112.30 label:network1/2 (alias=network1 { Option 1 255.255.255.0 Option 3 8.67.112.1 Option 6 8.67.112.10 Option 33 8.0.0.0:8.67.72.1 8.67.112.0:8.67.72.1 8.67.96.0:8.67.72.1 8.67.112.98.67.72.1 8.67.96.10:8.67.72.1 8.67.112.19:8.67.72.1 }
Second Edition (September 1997)
The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you.
This publication might include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time.
This publication was developed for products and services offered in the United States of America. IBM may not offer the products, services, or features discussed in this document in other countries, and the information is subject to change without notice. Consult your local IBM representative for information on the products, services, and features available in your area.
Requests for technical information about IBM products should be made to your IBM reseller or IBM marketing representative.
© Copyright International Business Machines Corporation 1995, 1997. All rights reserved.
Note to U.S. government Users -- Documentation related to restricted rights -- Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
IBM is required to include the following statements in order to distribute portions of this document and the software described herein.
__________________________________
The TCP/IP client and server software included herein contains network security technology licensed from RSA Data Security, Inc. This technology is licensed solely for use with software using technology previously licensed from RSA Data Security, Inc.
References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program or service is not intended to state or imply that only IBM's product, program, or service may be used. Subject to IBM's valid intellectual property or other legally protectable rights, any functionally equivalent product, program, or service may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, programs, or services, except those expressly designated by IBM, are the user's responsibility.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation 500 Columbus Avenue Thornwood, NY 10594 U.S.A.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Department LZKS, 11400 Burnet Road, Austin, TX 78758, U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
TCP/IP for OS/2 incorporates compression code by the Info-ZIP group. There are no extra charges or costs due to the use of this code, and the original compression sources are freely available from Compuserve in the OS2USER forum and by anonymous ftp from the Internet site ftp.uu.net:/pub/archiving/zip.
The following terms are trademarks of the IBM Corporation in the United States or other countries or both:
The following terms are trademarks of other companies:
Microsoft, Windows, and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation.
Other company, product, and service names which may be denoted by a double asterisk (**), may be trademarks or service marks of others.