TCP/IP Information

DHCP Server Administration

DHCP Server Administration

Table of Contents

About This Information

  • Who Should Use This Information
  • What This Information Describes
  • Conventions Used in This Information
  • What Is New in This Release
  • For More Information
  • DHCP and Dynamic IP Information
  • DHCP RFC Information
  • Request for Comments (RFC) Documents
  • What Is Dynamic IP?

    What Are DHCP and DDNS?

    How Does DHCP Work?

  • How Is Configuration Information Acquired?
  • How Are Leases Renewed?
  • What Happens When a Client Moves Out of its Subnet?
  • How Are Changes Implemented in the Network?
  • Getting Started with DHCP

  • Planning for DHCP
  • How Many DHCP Servers Do You Need?
  • Do You Already Have BootP Servers in Your Network?
  • Do You Have Hosts with Special Requirements?
  • What Is a Reasonable Lease Time?
  • Do You Want to Use Dynamic DNS Servers?
  • Generating DHCP Server Keys for Use with DDNS
  • Setting Up a DHCP Network
  • Creating a Scoped Network
  • Defining Scoped Statements
  • Configuring the DHCP Server
  • Starting the DHCP Server
  • DHCPSD Command
  • Maintaining a Running DHCP Server
  • Displaying dadmin Command Syntax
  • Re-initializing the Running Server
  • Displaying Client Information
  • Displaying IP Address Information
  • Querying an Address Pool
  • Controlling Server Tracing
  • Displaying Server Statistics
  • Deleting Leases
  • Appendix A. Modifying the DHCP Server Configuration File

  • Defining Global Values
  • Defining Vendors
  • Defining Subnets
  • Defining Subnet Groups
  • Defining Additional Options
  • Migrating the Network Statement
  • Transforming Canonical Addresses
  • Defining Classes
  • Defining Clients
  • Configuring Options and an IP Address for a DHCP Client
  • Configuring Options for a DHCP Client, Allowing Any IP Address
  • Excluding a Client ID
  • Excluding an IP Address
  • Excluding a Range of IP Addresses
  • Reserving Values for a Specific BootP Client
  • Specifying the Next Bootstrap Server
  • Defining Server and Lease Parameters
  • Defining Lease Length
  • Checking for Expired Leases
  • Specifying Offering Hold Time
  • Querying In-use Addresses
  • Specifying Intervals Between Pings for IP Addresses
  • Specifying DHCP Server Responses to BootP Requests
  • Specifying DHCP Server Responses to Unregistered Clients
  • Specifying DHCP Server Replies
  • Specifying Statistics Snapshots
  • Defining DHCP Log Files
  • Defining the Number of DHCP Log Files
  • Defining the Size of DHCP Log Files
  • Naming DHCP Log Files
  • Specifying Information Types to Log
  • Appendix B. Supporting Non-Dynamic IP Clients

  • Enabling Dynamic A Record Updates
  • Specifying the Keyword for A Record Updates
  • Releasing a Client A Record
  • Specifying the Keyword for PTR Record Updates
  • Releasing a Client PTR Record
  • Appending Client Domain Names
  • Appendix C. Defining DDNS Support

  • Defining DDNS Key Files for the PTR Record
  • Defining DDNS Key Files for the A Record
  • Appendix D. Specifying nsupdate Logging

    Appendix E. Specifying DHCP Options

  • Configuration File Option Data Formats
  • Option Categories
  • Base Options
  • Option 1, Subnet Mask
  • Option 2, Time Offset
  • Option 3, Router
  • Option 4, Time Server
  • Option 5, Name Server
  • Option 6, Domain Name Server
  • Option 7, Log Server
  • Option 8, Cookie Server
  • Option 9, LPR Server
  • Option 10, Impress Server
  • Option 11, Resource Location Server
  • Option 12, Host Name
  • Option 13, Boot File Size
  • Option 14, Merit Dump File
  • Option 15, Domain Name
  • Option 16, Swap Server
  • Option 17, Root Path
  • Option 18, Extensions Path
  • IP Layer Parameters per Host Options
  • Option 19, IP Forwarding
  • Option 20, Non-Local Source Routing
  • Option 21, Policy Filter
  • Option 22, Maximum Datagram Reassembly Size
  • Option 23, Default IP Time-To-Live
  • Option 24, Path MTU Aging Timeout
  • Option 25, Path MTU Plateau Table
  • IP Layer Parameters per Interface Options
  • Option 26, Interface MTU
  • Option 27, All Subnets are Local
  • Option 28, Broadcast Address
  • Option 29, Perform Mask Discovery
  • Option 30, Mask Supplier
  • Option 31, Perform Router Discovery
  • Option 32, Router Solicitation Address
  • Option 33, Static Route
  • Link Layer Parameters per Interface Options
  • Option 34, Trailer Encapsulation
  • Option 35, ARP Cache Timeout
  • Option 36, Ethernet Encapsulation
  • TCP Parameter Options
  • Option 37, TCP Default TTL
  • Option 38, TCP Keep-alive Interval
  • Option 39, TCP Keep-alive Garbage
  • Application and Service Parameter Options
  • Network Information Service Domain Option 40
  • Option 41, Network Information Servers
  • Option 42, Network Time Protocol Servers
  • Option 43, Vendor-Specific Information
  • Option 44, NetBIOS over TCP/IP Name Server
  • Option 45, NetBIOS over TCP/IP Datagram Distribution Server
  • Option 46, NetBIOS over TCP/IP Node Type
  • Option 47, NetBIOS over TCP/IP Scope
  • Option 48, X Window System Font Server
  • Option 49, X Window System Display Manager
  • DHCP Extensions Options
  • Option 50, Requested IP Address
  • Option 51, IP Address Lease Time
  • Option 58, Renewal (T1) Time Value
  • Option 59, Rebinding (T2) Time Value
  • Option 60, Class-Identifier
  • Option 62, NetWare/IP Domain Name
  • Option 63, NetWare/IP
  • Option 64, NIS Domain Name
  • Option 65, NIS Servers
  • Option 66, Server Name
  • Option 67, Boot File Name
  • Option 68, Home Address
  • Option 69, SMTP Servers
  • Option 70, POP3 Server
  • Option 71, NNTP Server
  • Option 72, WWW Server
  • Option 73, Finger Server
  • Option 74, IRC Server
  • Option 75, StreetTalk Server
  • Option 76, STDA Server
  • Option 77, User Class
  • Option 78, Directory Agent
  • Option 79, Service Scope
  • Option 80, Naming Authority
  • Option 81, Client DHCP-DNS
  • IBM-Specific Options
  • Option 192, TXT RR
  • Option 200, LPR Printer
  • Using Command Script DHCPLPR.CMD
  • Appendix F. Hardware Types

    Appendix G. DHCP Server Configuration Files

    Appendix H. Notices

  • Copyright Notices
  • Disclaimers
  • Acknowledgments
  • Trademarks

  • About This Information

    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:


    Who Should Use This Information

    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.


    What This Information Describes

    This information contains:


    Conventions Used in This Information

    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


    What Is New in This Release

    The following function is new in this release:


    For More Information

    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.

    DHCP and Dynamic IP Information

    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 RFC Information

    DHCP protocols and options are described in IETF Request for Comment (RFC) 2131 and 2132.

    Request for Comments (RFC) Documents

    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.PS
    
    where:
    nnnn
    Is the RFC number
    TXT
    Indicates text format
    PS
    Indicates PostScript format

    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.PS
    
    where:
    nnnn
    Is the RFC number
    TXT
    Indicates text format
    PS
    Indicates PostScript format

    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
    

    What Is Dynamic IP?

    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:


    What Are DHCP and DDNS?

    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:

    Dynamic
    A DHCP server assigns an IP address to a requesting bootP or DHCP client from a range of available addresses

    Static
    A DHCP server administrator assigns a static, pre-defined address reserved for a specific bootP or DHCP client

    DHCP provides the following lease policies for IP addresses:

    Temporary
    An IP address is temporarily "leased" to a bootP or DHCP client. A DHCP client that does not have a permanent lease must periodically request the renewal of its lease on its current IP address in order to keep using the address. The process of renewing leased IP addresses occurs dynamically as part of the DHCP protocols and is not generally visible to end-users.

    Permanent
    An IP address is leased for an infinite period of time to a bootP or DHCP client. No process of lease renewal is required.

    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.


    How Does DHCP Work?

    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:


    How Is Configuration Information Acquired?

    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:

    1. The client broadcasts a message (containing its client ID) announcing its presence and requesting an IP address (DHCPDISCOVER message) and desired options such as subnet mask, domain name server, domain name, and static route.

    2. Optionally, if routers on the network are configured to forward DHCP and BootP messages (using BootP Relay), the broadcast message is forwarded to DHCP servers on the attached networks.

    3. Each DHCP server that receives the client's DHCPDISCOVER message sends a DHCPOFFER message to the client offering an IP address. The DHCP server checks for duplicate IP addresses on the network before issuing an offer.

      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.

    4. The client receives the offer message(s) and selects the server it wants to use. When the IBM DHCP client receives an offer, it makes note of how many of the requested options are included in the offer. The DHCP client continues to receive offers from DHCP servers for a period of 4 seconds after the first offer is received, making note of how many of the requested options are included in each offer. At the end of that time, the DHCP client compares all offers and selects the one that meets its criteria.

    5. The client broadcasts a message indicating which server it selected and requesting use of the IP address offered by that server (DHCPREQUEST message).

    6. If a server receives a DHCPREQUEST message indicating that the client has accepted the server's offer, the server marks the address as leased. If the server receives a DHCPREQUEST message indicating that the client has accepted an offer from a different server, the server returns the address to the available pool. If no message is received within a specified time, the server returns the address to the available pool. The selected server sends an acknowledgment which contains additional configuration information to the client (DHCPACK message).

    7. The client determines whether the configuration information is valid. Upon receipt of a DHCPACK message, the IBM DHCP client sends an Address Resolution Protocol (ARP) request to the supplied IP address to see if it is already in use. If it receives a response to the ARP request, the client declines (DHCPDECLINE message) the offer and initiates the process again. Otherwise, the client accepts the configuration information.

    8. Accepting a valid lease, the client enters a BINDING state with the DHCP server, and proceeds to use the IP address and options. If configured to do so, the DHCP client notifies the Dynamic Domain Name Server of its host name-to-IP address mapping.

    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.


    How Are Leases Renewed?

    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.


    What Happens When a Client Moves Out of its Subnet?

    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.


    How Are Changes Implemented in 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.


    Getting Started with DHCP

    To assist you in setting up your DHCP system, refer to:


    Planning for DHCP

    Before you implement DHCP in your network, there are some decisions that you need to make:

    How Many DHCP Servers Do You Need?

    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.

    Using a Single DHCP Server

    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.

    Using Multiple DHCP Servers

    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.

    Do You Already Have BootP Servers in Your Network?

    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.

    Do You Have Hosts with Special Requirements?

    You may have hosts which have individual or special administrative needs, such as:

    What Is a Reasonable Lease Time?

    The default lease time is 24 hours. The lease time you choose depends largely on your needs, including:

    For complex networks that need to support a combination of host leasing requirements, you can use DHCP classing. For more information, see Defining Classes.

    Do You Want to Use Dynamic DNS Servers?

    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.

    Generating DHCP Server Keys for Use with DDNS

    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.


    Setting Up a DHCP Network

    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.

    Creating a Scoped Network

    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:

    For more information on obtaining information for a DHCP client, see Maintaining the DHCP Server.

    Defining Scoped Statements

    The concept of scoped statements in a DHCP server configuration file is shown by the following example:
    * Figure hierarc not displayed.

    In this example:

    For example, requesting clients are served the following options and values:

    Client K, if located on subnet Y and requesting class R
    Receives options and option values:

    A
    3

    B
    2

    C
    8

    E
    7

    F
    7

    Client K, if located on subnet X
    Receives options and option values:

    A
    3

    B
    2

    C
    6

    E
    5

    Client K, if located on subnet X and requesting class P
    Receives options and option values:

    A
    3

    B
    2

    C
    6

    D
    6

    E
    1

    Client K, if located on subnet X and requesting class P and Vendor V
    Receives options and option values:

    A
    3

    B
    2

    C
    6

    D
    6

    E
    1

    Vendor option A
    6

    Vendor option E
    3

    Vendor option G
    4

    Client K, if located on subnet Y and requesting class Q
    Receives options and option values:

    A
    3

    B
    2

    C
    3

    Client J, if located in subnet Y
    Receives options and option values:

    A
    1

    B
    2

    C
    3

    F
    7

    Client J, if located in subnet X
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    D
    7

    E
    11

    H
    10

    Client J, if located in subnet X and requesting class P, and vendor V
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    D
    7

    E
    11

    F
    not served

    H
    10

    Vendor option A
    6

    Vendor option E
    3

    Vendor option G
    4

    Client J, if located in subnet X and requesting class Q, and vendor V
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    D
    7

    E
    11

    F
    9

    G
    8

    H
    10

    Vendor option A
    6

    Vendor option E
    3

    Vendor option G
    4

    Client J, if located in subnet X and requesting class R
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    D
    7

    E
    11

    H
    10

    Any client other than J or K located in subnet X
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    E
    5

    Any client other than J or K located in subnet Y
    Receives options and option values:

    A
    1

    B
    2

    C
    3

    F
    7

    Any client other than J or K located in neither subnet X nor subnet Y
    Receives no options or option values.

    Any client other than J or K located in subnet X, requesting class P and Vendor V
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    D
    6

    E
    1

    Vendor option A
    6

    Vendor option E
    3

    Vendor option G
    4

    Any client other than J or K located in subnet X, requesting class Q and Vendor V
    Receives options and option values:

    A
    1

    B
    2

    C
    6

    E
    5

    F
    9

    G
    8

    Vendor option A
    6

    Vendor option E
    3

    Vendor option G
    4

    Any client other than J or K located in subnet Y, requesting class Q
    Receives options and option values:

    A
    1

    B
    2

    C
    3

    F
    7

    Any client other than J or K located in subnet Y, requesting class R
    Receives options and option values:

    A
    1

    B
    2

    C
    8

    E
    7

    F
    7

    Configuring the DHCP Server

    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.


    Starting the DHCP Server

    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.

    DHCPSD Command

    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 -?

    Displaying Information About the Server Program

    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

    Starting the DHCP Server

    To start the DHCP server, use the following form of the dhcpsd command:

    dhcpsd [ -q | -v] [configFile]

    -q

    Starts the server in quiet mode, which means that no banner is displayed when the server starts.

    -v

    Starts the server in verbose mode.

    configFile

    The name of the DHCP server configuration file. By default, the server searches for a file called DHCPSD.CFG in the directory specified by the ETC environment variable.

    Maintaining a Running DHCP Server

    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:

    1. This DHCP server release does not support earlier versions of dadmin clients. A new dadmin client which will communicate with both previous and current releases of the DHCP server is provided with this release.

    2. Verbose mode provides additional information for debugging purposes. Verbose mode is allowed on any of the following dadmin command instances. Verbose is shown as a parameter in those instances where additional, more detailed information is of particular value.

    Displaying dadmin Command Syntax

    To display information about the command syntax, enter:

    dadmin -?

    Re-initializing the Running Server

    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

    -hhost

    Specifies either the IP address or the host name of the DHCP server. If no server is specified, the local server is assumed.

    -i

    Re-initializes the specified server.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Displaying Client Information

    To display information for a client ID, use the following form of the dadmin command:

    dadmin -cvalue [ -v] -upassword| -x| -a

    -c

    Requests information for one or more clients that match this client ID.

    value

    The client ID is a MAC address. For example, enter 004ac77150fc. Information is returned for any matching hardware type.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Displaying IP Address Information

    To display information for one IP address, use the following form of the dadmin command:

    dadmin -qn.n.n.n [ -v] -upassword| -x| -a

    -q

    Requests the IP address information.

    n.n.n.n

    The IP address of the client.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Querying an Address Pool

    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

    -p

    Requests the address pool information.

    n.n.n.n

    The IP address of the address pool.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Controlling Server Tracing

    To start and stop tracing on the DHCP server, use the following form of the dadmin command:

    dadmin -tvalue [ -v] -upassword| -x| -a

    -t

    Specifies server tracing.

    value

    The value is ON to start tracing or OFF to stop tracing.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Displaying Server Statistics

    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

    -hhost

    Specifies either the IP address or the host name of the DHCP server. If no server is specified, the local server is assumed.

    -n

    Requests statistics for the server specified as host.

    value

    The value is a decimal integer indicating the number of intervals from 0 to 100. For example, a value of 3 returns a summary record that includes totals information, the current interval record, and the 3 most recent history records. A value of 0 returns a summary record of activity since the last summary.

    -v

    Executes the command in verbose mode.

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Statistics include:

    For more information on defining statistics snapshots, see Defining Server and Lease Parameters.

    Deleting Leases

    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

    -f

    Forces deletion of the lease without prompting.

    -v

    Executes the command in verbose mode.

    -hhost

    Specifies either the IP address or the host name of the DHCP server. If no server is specified, the local server is assumed.

    -d

    Deletes the lease for the specified IP address.

    ip_address

    The IP address for the lease to be deleted

    -upassword

    Specifies the administrator password. If the DHCP server is local, this parameter is not required. If the password contains blanks, you must enclose the password in double quotes.

    -x

    Specifies that the DHCP server is at a level prior to TCP/IP for OS/2 Version 4.1. Access is controlled by the RHOSTS file on the DHCP server, which requires either a HOSTS file or DNS name resolution.

    -a

    Specifies that no administrator password checking is to be done. This parameter is used for DHCP servers that are not running on TCP/IP for OS/2 Version 4.1 or on IBM eNetwork Network Station Manager TCP/IP for Windows NT.

    Appendix A. Modifying the DHCP Server Configuration File

    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:


    Defining Global Values

    Assign global values such as Class, Subnet, Option, Client, or Vendor statements by placing the statement outside any braces.


    Defining Vendors

    The DHCP-BootP protocol provides a way to supply vendor-specific information to a DHCP client using RFC-architected options 60 and 43:

    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:

    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.


    Defining Subnets

    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.

    subnet_address

    The address of this subnet, specified in dotted-decimal notation (for example, 9.67.48.0).

    subnet_mask

    The mask for the subnet in dotted decimal notation or in integer format. A subnet mask divides the subnet address into a subnet portion and a host portion. If no value is entered for the subnet mask, the default is the class mask appropriate for an A, B, or C class network.

    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:

    range

    All addresses to be administered to this subnet. Enter the addresses in dotted-decimal notation, beginning with the lower end of the range, followed by a hyphen, then the upper end of the range, with no spaces in between; for example, 9.67.48.1-9.67.48.128. Ranges should not overlap.

    Notes:

    1. In the range of addresses, do not include the address of the subnet and the address used for broadcast messages. For example, if the subnet address is 9.67.96.0 and the subnet mask is 255.255.240.0, do not include 9.67.96.0 and 9.67.111.255 in the range of addresses.

    2. Use the Client statement to exclude an IP address in the range that the server should not administer. For example, exclude an address that has been permanently assigned to a host. For more information on client statements, see Defining Clients.

    ( alias=name

    A symbolic name for ease in identifying a subnet.

    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.

    DDNSServer=ip_address

    The IP address of the DDNS server to which DHCP client PTR record update requests (updateDNSP keyword) are sent by the DHCP server in the subnet. For more information on updating PTR records, see Specifying the Keyword for PTR Record Updates.

    Defining Subnet Groups

    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:

    label:

    Identifies subnets grouped together on the same wire.

    value[/priority]

    A string of 1 to 64 alphanumeric characters that identifies the subnet, followed by the priority in which this subnet's address pool is used. No spaces are allowed in labels. More than one subnet can have the same identifier. Priority is a positive integer, where 1 is a higher priority than 2. If no priority is specified, the highest priority is assigned. If two subnets have identical priority, the subnets within a label are processed based on the physical position in the configuration file.

    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
    

    Using Subnet Group Processing Statements

    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 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: WIRE3
    
    have 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.

    Defining Additional Options

    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.


    Migrating the Network Statement

    To migrate previous subnet configuration files that contain Network statements, you can manually edit existing DHCP server configuration files:


    Transforming Canonical Addresses

    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

    value

    The value is either NO (the default) or YES. NO prevents the DHCP server from transforming MAC addresses. YES causes the DHCP server to transform MAC addresses.

    Defining Classes

    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]

    class_name

    The user-defined label that identifies the class. The class name is an ASCII string of up to 255 characters (for example, accounting). If the class name contains spaces, it must be surrounded by quotes.

    range

    To specify a range of addresses, enter addresses in dotted-decimal notation, beginning with the lower end of the range, followed by a hyphen, then the upper end of the range, with no spaces in between. For example, enter 9.17.32.1-9.17.32.128.

    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.


    Defining Clients

    The Client statement is used to:

    Configuring Options and 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]

    hw_type

    The hardware type of the client computer, required to decode the MAC address. For more information on hardware types, see Hardware Types.

    clientID

    The hexadecimal MAC address, or a string such as a domain name, or a name assigned to the client, such as the host name. If you specify a string, you must enclose it in quotes and specify zero as the hardware type.

    ipaddr

    The DHCP client's IP address, in dotted-decimal notation.

    ( alias=name

    A symbolic name for ease in identifying the client. Enter alias=name immediately after a left parenthesis. This symbolic name appears in the display of the server configuration. If no name is entered, the MAC address is used.

    For more information about DHCP options, see Specifying DHCP Options.

    Configuring Options for a DHCP Client, Allowing Any IP Address

    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
    }

    Excluding a Client ID

    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

    hw_type

    A number representing the hardware type, as defined in RFC 1530. The hardware type is needed to correctly interpret a clientID that is a MAC address.

    clientID

    Either the hexadecimal MAC address or a name assigned to the client, such as the host name. If you specify a name, you are required to enclose it in quotes and specify 0 for the hardware type.

    NONE

    NONE specifies no IP address and no options are served to the specified client ID.

    For example:

    client 6 10005aa4b9ab NONE

    Excluding an IP Address

    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.

    Excluding a Range of IP Addresses

    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
    

    Reserving Values for a Specific BootP Client

    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.


    Specifying the Next Bootstrap Server

    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.


    Defining Server and Lease Parameters

    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.

    Defining Lease Length

    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.

    Default interval:
    24 hours (1440 minutes)

    Default unit:
    minute

    Minimum:
    180 seconds

    Maximum:
    -1, which is infinity

    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.

    Checking for Expired Leases

    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.

    Default interval:
    1 minute

    Default unit:
    minute

    Minimum:
    15 seconds

    Maximum:
    12 hours

    Specifying Offering Hold Time

    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.

    Default interval:
    5 minutes

    Default unit:
    minute

    Minimum:
    30 seconds

    Maximum:
    -1, which is infinity

    Querying In-use Addresses

    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.

    Default interval:
    1000 seconds

    Default unit:
    minute

    Minimum:
    30 seconds

    Maximum:
    -1, which is infinity

    Specifying Intervals Between Pings for IP Addresses

    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.

    Default interval:
    1 second

    Minimum:
    1 second

    Maximum:
    30 seconds

    Specifying DHCP Server Responses to BootP Requests

    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.

    Specifying DHCP Server Responses to Unregistered Clients

    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.

    Specifying DHCP Server Replies

    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.

    Specifying Statistics Snapshots

    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.


    Defining DHCP Log Files

    To enable logging by the server, all of the following must be specified:

    Defining the Number of DHCP Log Files

    Specify the number of log files maintained, using:

    numLogFiles value

    value

    The maximum number of log files maintained.

    Notes:

    1. If the value for numLogFiles is 0 or the statement is omitted, no logging occurs.

    2. If a new log file is created after the maximum number is reached, the oldest log file is removed.

    3. The maximum number of files is specified by the file system. For example, 999 files is the maximum value on a FAT file system.

    4. If the value for numLogFiles is greater than 1, when the size of the most current log file reaches the maximum size, it is renamed by removing the initial filetype of LOG and appending an integer as the filetype to the log file name. A new log file is created as the current log. All older files are renamed by incrementing the previously appended integer filetype by 1. The larger the file type extension, the older the log file. For example, DHCPLOG.003 is an older log file than DHCPLOG.001.

    Defining the Size of DHCP Log Files

    Specify the size of the log file, using:

    logFileSize value

    value

    Maximum log file size in kilobytes. The minimum size is 1KB.

    Naming DHCP Log Files

    Name the log file, using:

    logFileName file_path

    file_path

    The fully-qualified name that you assign to the current log file. The file name is a maximum of 8 characters. A file type is allowed for a DHCP log file.

    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.

    Specifying Information Types to Log

    Specify information types to log, using:

    logItem object

    object

    Types include:

    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


    Appendix B. Supporting Non-Dynamic IP Clients

    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:


    Enabling Dynamic A 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:

    1. As a first priority, option 81 is included in the DHCP client request and indicates that an A record update should be performed at the DDNS server on behalf of the client.

    2. Either option 12 or option 15, or both, are included in a DHCP client request.

    3. Either option 12 or option 15, or both, are defined in the DHCP server configuration file.

    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.

    Specifying the Keyword for A Record Updates

    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:

    nsupdate

    The name of the DDNS client program, which updates the DDNS database

    -f

    The request originates from a DHCP server

    -h

    Client host name (value is substituted by the DHCP server)

    -d

    Client dynamic domain name (value is substituted by the DHCP server)

    -s

    Indicates that the command should be run in command-line mode and all subcommands are included within the quotation marks that follow. The following command string is appropriate for most cases. The string contains:

    For more information on client control of A record updates for non-dynamic DHCP clients, see client option81 in Specifying DHCP Options.

    Releasing a Client A Record

    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:

    nsupdate

    The name of the DDNS client program, which updates the DDNS database

    -f

    The request originates from a DHCP server

    -h%s

    Client host name (value is substituted by the DHCP server)

    -s

    Information in the command string releases the DHCP client's A record at the DDNS server. The command string is appropriate for most cases. The string contains:

    Specifying the Keyword for PTR Record Updates

    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:

    nsupdate

    The name of the DDNS client program, which updates the DDNS database

    -f

    The request originates from a DHCP server

    -r%s

    The IP address which is to be mapped to the new host name

    -s

    The command should be run in command-line mode and all subcommands are included within the quotation marks that follow. The command string is appropriate for most cases. The string contains:

    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.


    Releasing a Client PTR Record

    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:

    nsupdate

    The name of the DDNS client program, which updates the DDNS database

    -f

    The request originates from a DHCP server

    -r%s

    The IP address substituted by the DHCP server

    -s

    Information in this command string releases the DHCP client's PTR (IP-address-to-host-name mapping) record at the DDNS server. The command string is appropriate for most cases. The string contains:

    Appending Client Domain Names

    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.


    Appendix C. Defining DDNS Support

    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.


    Defining DDNS Key Files for the PTR Record

    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

    -f

    The request originates from a DHCP server.

    -h

    The inverse IP address(es) for which keys are generated.

    inverse_ip_address

    The format of the inverse_ip_address is the IP address in reverse with in-addr.arpa appended. For example, 9.67.149.111 as an inverse_ip_address entry is 111.149.67.9.in-addr.arpa. You can use a wild card to expand the scope of the entry. For example, if you want this entry to apply to all hosts whose IP address begins with 9.67, you could specify *.67.9.in-addr.arpa. If you want this entry to apply to all hosts, you could specify *.in-addr.arpa.

    -g

    A key pair should be created for this entry.

    -p

    The primary DDNS server

    primary_ddns_server

    The host name or IP address of the primary DDNS server for the specified addresses

    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.

    Defining DDNS Key Files for the A Record

    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

    -f

    The request originates from a DHCP server.

    -h

    The host name(s) for which keys are generated.

    fully_qualified_host_name

    The format of the fully_qualified_host_name is the host name followed by the full-qualified domain name or a wild card to allow aggregate entries.

    -g

    A key pair should be created for this entry.

    -p

    The primary DDNS server

    primary_ddns_server

    The host name or IP address of the primary DDNS server for the specified addresses

    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.


    Appendix D. Specifying nsupdate Logging

    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.


    Appendix E. Specifying DHCP Options

    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:


    Configuration File Option Data Formats

    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:


    Option Categories

    There are 7 option categories:


    Base Options

    Following are the base options provided to the client:

    Option 1, Subnet Mask

    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

    Option 2, Time Offset

    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

    Option 3, Router

    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

    Option 4, Time Server

    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

    Option 5, Name Server

    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

    Option 6, Domain Name Server

    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

    Option 7, Log Server

    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

    Option 8, Cookie Server

    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

    Option 9, LPR Server

    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

    Option 10, Impress Server

    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

    Option 11, Resource Location Server

    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

    Option 12, Host Name

    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

    Option 13, Boot File Size

    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

    Option 14, Merit Dump File

    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

    Option 15, Domain Name

    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

    Option 16, Swap Server

    This option is specified only at the DHCP server.

    IP address of the client's swap server.

    Configuration file format: IP address

    Option 17, Root Path

    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

    Option 18, Extensions Path

    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


    IP Layer Parameters per Host Options

    Following are the options that affect the operation of the IP layer on a per host basis:

    Option 19, IP Forwarding

    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

    Option 20, Non-Local Source Routing

    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

    Option 21, Policy Filter

    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

    Option 22, Maximum Datagram Reassembly Size

    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

    Option 23, Default IP Time-To-Live

    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

    Option 24, Path MTU Aging Timeout

    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

    Option 25, Path MTU Plateau Table

    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


    IP Layer Parameters per Interface Options

    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.

    Option 26, Interface MTU

    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

    Option 27, All Subnets are Local

    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

    Option 28, Broadcast Address

    This option is specified only at the DHCP server.

    Broadcast address used on the client's subnet.

    Configuration file format: IP address

    Option 29, Perform Mask Discovery

    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

    Option 30, Mask Supplier

    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

    Option 31, Perform Router Discovery

    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

    Option 32, Router Solicitation Address

    This option is specified only at the DHCP server.

    Address to which a client transmits router solicitation requests.

    Configuration file format: IP address

    Option 33, Static Route

    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


    Link Layer Parameters per Interface Options

    Following are the options that affect the operation of the data link layer on a per-interface basis:

    Option 34, Trailer Encapsulation

    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

    Option 35, ARP Cache Timeout

    This option is specified only at the DHCP server.

    Timeout in seconds for Address Resolution Protocol (ARP) cache entries.

    Configuration file format: Unsigned long

    Option 36, Ethernet Encapsulation

    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


    TCP Parameter Options

    Following are the options that affect the operation of the TCP layer on a per-interface basis:

    Option 37, TCP Default TTL

    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

    Option 38, TCP Keep-alive Interval

    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

    Option 39, TCP Keep-alive Garbage

    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


    Application and Service Parameter Options

    Following are options that can be used to configure miscellaneous applications and services:

    Network Information Service Domain Option 40

    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

    Option 41, Network Information Servers

    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

    Option 42, Network Time Protocol Servers

    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, Vendor-Specific Information

    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

    Option 44, NetBIOS over TCP/IP Name Server

    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

    Option 45, NetBIOS over TCP/IP Datagram Distribution Server

    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

    Option 46, NetBIOS over TCP/IP Node Type

    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:

    Value
    Node Type
    0x1
    B-node
    0x2
    P-node
    0x4
    M-node
    0x8
    H-node

    Configuration file format: Unsigned byte

    Option 47, NetBIOS over TCP/IP Scope

    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

    Option 48, X Window System Font Server

    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

    Option 49, X Window System Display Manager

    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


    DHCP Extensions Options

    Following are the available options that are specific to DHCP.

    Option 50, Requested IP Address

    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

    Option 51, IP Address Lease Time

    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

    Option 58, Renewal (T1) Time Value

    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

    Option 59, Rebinding (T2) Time Value

    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

    Option 60, Class-Identifier

    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

    Option 62, NetWare/IP Domain Name

    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

    Option 63, NetWare/IP

    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

    Option 64, NIS Domain Name

    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

    Option 65, NIS Servers

    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

    Option 66, Server Name

    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

    Option 67, Boot File Name

    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

    Option 68, Home Address

    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

    Option 69, SMTP Servers

    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

    Option 70, POP3 Server

    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

    Option 71, NNTP Server

    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

    Option 72, WWW Server

    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

    Option 73, Finger Server

    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

    Option 74, IRC Server

    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

    Option 75, StreetTalk Server

    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

    Option 76, STDA Server

    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

    Option 77, User Class

    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

    Option 78, Directory Agent

    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

    Option 79, Service Scope

    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

    Option 80, Naming Authority

    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

    Option 81, Client DHCP-DNS

    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-Specific Options

    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.

    Option 192, TXT RR

    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

    Option 200, LPR Printer

    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

    Using Command Script DHCPLPR.CMD

    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.


    Appendix F. Hardware Types

    Possible hardware types are:

    Type
    Description

    0
    Unspecified. If you specify a symbolic name for the client ID, specify 0 for the hardware type.

    1
    Ethernet (100Mb)

    6
    IEEE 802 Networks (which includes 802.5 Token Ring)

    Appendix G. DHCP Server Configuration Files

    The following files are used to manually configure a DHCP server:

    \DHCPSD.CFG
    Used for DHCP server configuration. The following configuration provides short lease intervals, causing rapid lease renewal for test purposes:
    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
    }
    

    \DHCPSD.LOG
    DHCP log(s), used to collect logging information. DHCPSD.LOG is specified by the logFileName statement in the DHCPSD.CFG file.

    Appendix H. Notices

    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 Notices

    © 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.


    Disclaimers

    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.


    Acknowledgments

    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.


    Trademarks

    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.