BOOTP and DHCP
LESSON 23

Bootstrap Protocol
(BOOTP):

• BOOTP (Bootstrap Protocol):
  • Is a protocol that allows a diskless workstation to determine it’s IP address (and other information) without using RARP.
• BOOTP is a client / server program where a BOOTP agent requests bootstrap information from designated BOOTP servers.
• It uses UDP and IP, so it can be implemented in an application, thus client / server.
• RARP has three drawbacks:
  • Lower-level, requiring direct access to hardware (difficult access for the average application programmer).
  • RARP only supplies IP address and not other possible information.
  • Cannot be used on networks that dynamically assign hardware addresses.
• BOOTP handles these inefficiencies.

BOOTP Efficiency Enhancements:

• BOOTP is more efficient because a single message contains many startup items including:
  • IP addresses.
  • Address of default gateway to use.
  • Address of bootstrap image server.
  • Vendor-specific hardware information and subnet masks.

Handling Service Problems

• It places all responsibility for reliable communication of the BOOTP message on the client program.
• Since the BOOTP configuration information must be transferred quickly, clients are often connectionless.
• BOOTP handles connectionless service problems by:
  • Requiring UDP to use checksums.
  • Requests and replies are sent with the ‘DON’T FRAGMENT’ bit set (for clients that have too little memory for reassembly).
  • Constructed to accept multiple replies and only processes the first one (handles duplicates).
  • Using time-out and retransmission techniques.

BOOTP:
Message Format

• The BOOTP Message Format contains fixed length fields, where bootstrap requests and replies use the same format.
• BOOTP and DHCP protocols also share the exact same format with the exception of the OPTION FIELD (same as VENDOR-SPECIFIC AREA in BOOTP).

• OP (8-bits):
  • Operation requested (Request or Reply).
• HTYPE (8-bits):
  • Hardware type (Ethernet = 1).
• HLEN (8-bits):
  • Length of the hardware address in octets (Ethernet = 6).
• HOPS (8-bits):
  • Allows bootstrapping across multiple gateways.
• TRANSACTION ID (32-bits):
  • A number the client uses to match requests with replies.
• SECONDS (16-bits):
  • Number of seconds since the client started to boot.
• Client IP Address (32-bits):
  • Client that knows it’s IP address, places it here.
• Your IP Address (32-bits):
  • If client IP address is zero in request, it is placed here in the response.
• Server IP Address and
  Router IP Address (32-bits each):
  • Filled in if the client already knows these addresses.
• All other fields are filled by the client with as much information about the server as it knows.
• A client pads the fields with zero if it does not know.

Bootstrap Procedure:

• Two-step Bootstrap Procedure:
  • BOOTP provides the client with information needed to obtain a bootstrap configuration image.
  • The client uses the Trivial File Transfer Protocol (TFTP) to obtain the image from the specified server.
• Separation of configuration and storage allows:
  • Memory images to be stored on machines that are not BOOTP servers
  • And for administrators to configure sets of machines to act independently or exactly the same.

BOOTP:
Specific Areas of the Message

• Client Hardware Address (16-octets):
  • If the client’s hardware address can be manually configured, it will be included in this area.
• Server Host Name (64-octets):
  • Filled in by the client if it knows the servers name.
  • If not, the server will respond to a request and fill in this field.
• Boot File Name (128-Octets):
  • Allows the use of generic names to request specific boot images.
  • A database maps this simple name to a specific machine architecture name.
• Vendor-Specific Area (64-Octets):
  • Magic cookie is contained in the first 4 octets.
  • It defines the format of the remaining items found within the vendor-specific area.
• Form of the Magic Cookie:
• [1-octet TYPE, optional 1-octet LENGTH, multi-octet VALUE]
• Ex.
  • [99.130.83.99] (specifies the standard format)
• Extensions are added to BOOTP to allow for different configuration fields and values.

Vendor-Specific Information Items:

Dynamic Host Configuration Protocol
(DHCP):

• Dynamic Host Configuration Protocol (DHCP) - Designed to:
  • Supply hosts with configuration parameters.
  • Lease dynamically allocated IP addresses.
  • Interoperate with BOOTP (acts as an enhancement to BOOTP).
• The original definitions for DHCP can be found in RFC-1531, RFC-1533, and RFC-1534
• DHCP supports three mechanisms for IP address allocation:
  • Automatic - assigns a permanent IP address.
  • Dynamic - the IP address is assigned for a limited time.
  • Manual - a network administrator assigns the address and DHCP conveys the address to the host.

DHCP Message Format:

• The frame format is based on BOOTP’s to capture the BOOTP relay agent behavior.
• This is also to promote the interoperability of existing BOOTP clients with DHCP servers.
• The only two fields that differ are:
  • Flags (16-bits) = Not Used in BOOTP
  • Options (Variable) = Vendor-Specific area has been extended beyond 64 bytes to handle more options.

Difference Between BOOTP and DHCP:

• Two primary differences between BOOTP and DHCP:
  • A client can be assigned an IP addresses for a fixed time-lease and then that address can be reassigned again at a later time.
  • DHCP provides the mechanism for the client to acquire ALL IP configuration parameters it needs to be fully functional.

DHCP Functionality:

• How it works:
  • A client needing an IP address sends a DHCPDISCOVER broadcast message over the network which contains the client’s MAC address (hardware).
  • Any DHCP server (may be several offers) can respond with a DHCPOFFER unicast message to the client’s MAC address offering an:
    • IP address
    • Subnet mask
    • IP address of the DHCP server
    • Expiration time of the lease.
  • Client selects an offer by sending a DHCPREQUEST unicast message to the appropriate DHCP server and accepts the offered configuration information.
  • The DHCP server responds with a DHCPACK unicast message to the client and officially assigns the address to the client node.
  • It then provides DNS and/or WINS (Windows Internet Name Service) server addresses, the default gateway IP address, etc.

What is WINS?

• Windows Internet Naming Service (WINS):
  • Microsoft has it’s own domain name service for use on many of it’s TCP/IP networks.
  • WINS is not an official Internet name service, but is commonly used with many LANs.
  • WINS, in part, allows a client node to identify and connect to another windows machine.
  • Windows 95, NT, and Windows for Workgroups all use WINS servers.

Configuration and Compatibility Issues:

• DHCP currently:
  • Does not handle the registration of newly configured hosts with the DNS
  • Nor is it intended for use in configuring routers.
• DHCP must provide service to existing BOOTP clients, to ensure their interoperability and coexistence.
• Administrators setup scopes (ranges) of IP addresses available on each subnet for dynamic allocation by DHCP.
• Configuration options are defined either globally or per scope as appropriate.
• When the DHCP service assigns IP addresses and configuration options to a client, it does so based on the scope of the subnet on which the client resides.
• This can differ for each network in an autonomous system.

Address Leasing in DHCP:

• Deciding efficient lease times is a key issue for DHCP:
  • Choosing times which are too short can cause unneeded overhead on a machine, the network, DHCP servers, and possibly administrators.
  • Choosing times which are too long can waste valuable IP addresses (to be used with other machines) and disrupt routers which try to send packets to an unused address.
• The lease renewal process used with DHCP begins when 50% of the lease period has expired.
• This occurs long before the lease expires, which gives the machine and the user time to request and allocate another.

Problems and Concerns of DHCP:

• Dynamic configuration is highly desirable for large corporate environments.
• Name registration problems still haunt DHCP’s wide-spread acceptance, but the issue is currently being investigated.
• This will probably change with the acceptance of IPv6.

Acceptance of a New Standard:

• The IETF has defined several RFC documents which detail the DHCP protocol.
• Changes are also being made to handle the current short-comings of DHCP.
• Many vendors (AT&T, Microsoft, etc.) currently support or plan to support DHCP.

Last Modification: (Sunday, August 25, 1996)

All work was written, produced, and is copyrighted by Daniel Z. Tabor Jr.
Page created by Daniel Z. Tabor Jr. Copyright ©1996 Illusion Industries Inc.