Mercados Municipales y Centrales de Abasto

So the BOOTP client broadcasts the BOOTPREQUEST message to the network. Now what? A BOOTP server listens for bootprequests being broadcast on UDP port 67. When the BOOTP server receives a BOOTPREQUEST, it performs a few checks on the message before processing it.

The first check is to determine whether the client specified a server name. If no server name was specified or if the server name matches the BOOTP server's hostname, it continues to process the packet. If a server name was specified and does not match the BOOTP server's hostname, it discards the packet.

The BOOTP database located on the BOOTP server is simply a static text file containing MAC addresses and their corresponding IP configuration information. Example 2.1 gives a sample BOOTP database file.

Example 2.1. Example BOOTP Database File # bootptab: database for bootp server

# Blank lines and lines beginning with '#' are ignored. #

# Legend: #

# first field -- hostname #

# hd -- home directory # bf -- bootfile

# ds -- domain name servers # gw -- gateways

# ha -- hardware address # ht -- hardware type # ip -- host IP address # sm -- subnet mask

# to -- time offset of local time from GMT (seconds) # ts -- time servers # # # <devicename>:ht=ethernet:ha=<MACaddress>:ip=<ipaddress>:sm=<subnetmask> :gw=<gatewayaddress>:ds=<DNSserver> # BOOTPCLIENT1:ht=ethernet:ha=00105A897960:ip=192.168.0.20:sm=255.255.255.0 :gw=192.168.0.1:ds=192.168.0.10 BOOTPCLIENT2:ht=ethernet:ha=00C0A8358A12:ip=192.168.0.21:sm=255.255.255.0 :gw=192.168.0.1:ds=192.168.0.10 BOOTPCLIENT1:ht=ethernet:ha=00E0293642FE:ip=192.168.0.22:sm=255.255.255.0 :gw=192.168.0.1:ds=192.168.0.10

After checking the server name, the BOOTP server attempts to look up the client's MAC address in the server's BOOTP database. If the BOOTP server finds the address, the server places the corresponding IP address in the yiaddr field of the BOOTPREPLY message (see Figure 2.5, callout 2). If no match is found, the server discards the packet.

Next, the server checks the BOOTPREQUEST message to see if the client specified a boot file. If it was specified, the server uses the requested filename along with the IP address (from the previous lookup) to perform a database lookup. If there is a match, or if there is a generic

file specified in the BOOTP database, the server places the fully qualified filename in the

file field of the BOOTPREPLY.

Figure 2.5. Packet trace of a BOOTPREPLY message

Finally, the server checks for any requested vendor-specific options. If there are any, it places the data in the vend field of the BOOTPREPLY.

Now that the BOOTP server has looked up the requested information and placed it in the appropriate fields of the BOOTPREPLY message, the server finishes the message. It sets the

op field to BOOTPREPLY (see Figure 2.5, callout 1) and places its IP address in the siaddr

field (see Figure 2.5, callout 2). 2.4.3 Sending the BOOTPREPLY

Sending the BOOTPREPLY back to the client causes a dilemma: how does the server send a reply to a client that does not know its IP address? The server performs a few operations before trying to transmit the BOOTPREPLY.

First, if the original BOOTPREQUEST's ciaddr field was nonzero, the server sends the

packet just like any other packet: directly to the corresponding IP address. Once the client receives it, it reconfigures its IP stack using the newly supplied IP address and configuration data.

If the client does not know its IP address, it will not be able to respond to ARP requests from the BOOTP server. In the case, there are two possibilities:

1. The server can create an ARP cache entry using the client's MAC address and the IP address the server just assigned.

2. The server can simply address the packet as a broadcast (255.255.255.255) (see Figure 2.6, callout 2).

In later implementations of BOOTP, the flags field is used to specify whether the reply

should be sent as a unicast or broadcast message. The flag field is 2 octets long (16 bits), out

of which only the first bit is used. If the bit is 1, the message should be sent as a broadcast. If the bit is 0, the message should be sent as a unicast. Since only the client knows whether or not it can receive unicast messages at this point, the client is responsible for setting this bit in the original BOOTPREQUEST packet.

Figure 2.6. Packet trace of a BOOTPREPLY message

After the server determines how and where it will transmit the packet, the BOOTPREPLY message is sent on UDP port 68 with the source port set to 67 (see Figure 2.6, callout 3). 2.4.4 Receiving the BOOTPREPLY

The BOOTP client continues to listen for the BOOTPREPLY on UDP port 68. When the BOOTP client receives a BOOTPREPLY, it configures its IP stack with the information

provided in the BOOTPREPLY. It finds its IP address in the ciaddr field and default

gateway address in the giaddr field (see Figure 2.5, callout 2).

2.5 Summary

RARP and BOOTP were simply the first steps in figuring out a method to deliver IP configuration information. After RARP was developed, it became apparent that it had a couple of major shortfalls. First, a RARP server could only operate on a single subnet. Second, it lacked the critical ability to provide any IP configuration information other than the IP address.

Although BOOTP provided a vast improvement over RARP, it also suffered some serious shortfalls. First, the BOOTP database was a static text file. This meant that administrators needed to maintain the file by hand as changes were made to the network. A simple change like replacing a host's network interface card required the administrator to update the BOOTP database file. Another shortfall was the inability to dynamically allocate and distribute IP addresses. In the age of depleted IP address space, dynamic IP addressing was a critical feature.

Seeing this, the IETF started work to create a new protocol that would overcome these shortfalls: Dynamic Host Configuration Protocol (DHCP).