Estado De Situación Financiera

There is one more protocol in the ARP suite of protocols. The Reverse Address Resolution Protocol (RARP) is used to obtain the IP address of a host based on its physical address. That is, it performs a job that is exactly opposite to that of ARP. An obvious question would be, is this really needed? After all, a host should have the IP address stored on its hard disk! However, there are situations when this is not the case. Firstly, a host may not have a hard disk at all (e.g., a diskless workstation). Secondly, when a new host is being connected to a network for the very first time, it does not know its IP address. Finally, a computer may be discarded and replaced by another computer, but the same network card could be re-used. In all these situations, the computer does not know its own IP address.

RARP works in a very similar way to ARP, but in the exactly opposite direction, as shown in Fig. 3.32.

In RARP, the host interested in knowing its IP address broadcasts an RARP query datagram. This datagram contains its physical address. Every other computer on the network receives the datagram. All the computers except a centralized computer (the server computer) ignore this datagram. However, the server

72

recognizes this special kind of datagram and returns the broadcasting computer its IP address. The server contains a list of the physical addresses and their corresponding IP addresses for all diskless workstations. This is shown in Fig. 3.33.

Fig. 3.32 Reverse Address Resolution Protocol (RARP)

Fig. 3.33 Example of RARP

RARP suffers from the following drawbacks.

n It operates as a low-level broadcast protocol.

n It requires adjustments for various hardware types.

73

n RARP server needs to be configured on every network.

n It provides for only IP address, and nothing else.

3.9 BOOTP

As a replacement for RARP, a new protocol was designed, called as Bootstrap Protocol (BOOTP). BOOTP has the following characteristics.

n It uses UDP, and is hence independent of hardware.

n It supports sending additional configuration information to the client, in addition to its IP address.

n Client and server can be on different networks, thus supports internetworking.

BOOTP works on the following principles.

The BOOTP server maintains mapping between IP and physical addresses. Client sends a request with its physical address, asking for its own IP address. Server looks up physical address of the client in its tables, and returns the IP address. A special well-known port (67) is used for BOOTP UDP requests.

There is a concept of relay agents in BOOTP. This can be explained as follows.

BOOTP is designed to allow the BOOTP server and clients to be on different networks. This centralizes the BOOTP server and greatly reduces the amount of work for system administrators. However, this means the protocol is more complex.

n RARP works at data link layer, so cannot allow clients and server to be on different physical networks.

n The whole point about BOOTP is to allow use of IP, and if IP is used, we should be able to send packets from one network to another arbitrarily! But BOOTP (like RARP) uses broadcasting.

n Client does not know the address of a BOOTP server, and hence sends a broadcast request.

n For efficiency reasons, routers do not route broadcasts—this clogs the network.

n Hence, if client and server are on different networks, server cannot hear the client’s broadcast.

n Hence, we need a Relay Agent.

A BOOTP relay agent sits on a physical network where BOOTP clients may be located and acts as a proxy for the BOOTP server. It relays messages between a client and a server, and hence is called as Relay Agent. It is usually implemented in software on an existing router.

The following is an example of BOOTP in operation.

1. Client creates a BOOTP request and broadcasts it to address 255.255.255.255.

2. Relay agent on the client’s physical network is listening on UDP port 67 on the server’s behalf.

3. Relay agent sends the BOOTP request to BOOTP server.

(a) If the Relay Agent knows the address of the BOOTP server, it would be a unicast transmission.

(b) Otherwise the Relay Agent broadcasts the BOOTP requests on the other interface to which it connects.

4. Server receives the request and creates a BOOTP reply message.

5. Server sends the BOOTP reply to Relay Agent.

6. Relay agent sends the response to the original client as unicast or broadcast.

BOOTP has a big limitation, which is that it does not support dynamic addresses. So, we need a better technology.

74

3.10 DHCP

The Dynamic Host Configuration Protocol (DHCP) is even better than BOOTP. Unlike BOOTP, which considers a mapping table, DHCP can also allocate IP addresses dynamically. It is useful when hosts move, etc. It can work in a static allocation mode, like BOOTP. In this case, the address allocation is done manually.

However, it can also support dynamic allocation. Here, it maintains another table of available IP addresses, from which one can be assigned. This is done automatically. Normally, a DHCP server would check the static database to see if it finds a match on the host so as to return the static address; if not, it returns the dynamic address.

The way DHCP works is as follows.

1. Client creates a DISCOVER message, which contains the client’s own physical address and a unique transaction ID.

2. Client broadcasts this message.

3. Each DHCP server (there can be several of them) on the local network receives this message. It tries to locate the client’s physical address in its mapping tables, and free IP addresses, etc.

4. Servers create DHCPOFFER messages, containing the following.

(a) The IP address to be assigned to the client.

(b) The time for which this IP address is being assigned, etc.

(c) The same transaction ID as was sent by the client.

5. Servers ensure that the same IP address is not in use by sending an ICMP ECHO message (and not getting a response).

6. Servers send the DHCPOFFER messages (unicast/broadcast).

7. Client receives and processes DHCPOFFER messages. Client can decide which one to accept.

8. Client creates DHCPREQUEST message for the selected server. The message contains the following.

(a) The identifier of the server to indicate which one is chosen.

(b) The IP address that the server had assigned to this client.

9. Client broadcasts DHCPREQUEST message.

10. Servers receive and process the DHCPREQUEST message. Servers not selected will simply ignore this message.

11. Selected server sends back DHCPACK or DHCPNAK message to indicate whether the offered IP address is still available.

12. Client receives and processes DHCPACK or DHCPNAK message received from the server.

13. Client checks whether the IP address is in use, by sending an ARP request packet.

14. Client finalizes the allocation.