5.1 Introduction
When the system has a local disk boot, generally an IP address read from the configuration file on disk. However diskless machine, such as a diskless workstation or X terminal, you need to use other methods to obtain an IP address.
Each system on the network has a unique hardware address, which is configured by the network interface manufacturer. RARP diskless system implementation process is to read the unique hardware address from the interface card, and then send a RARP request (a data broadcast on the network), in response to a host request to the IP address of the diskless system (in RARP response).
This process is conceptually very simple, but often difficult to implement than the ARP, the reasons described later in this chapter. The formal specification of the RARP RFC 903 [Finlayson et al. 1984].
5.2 RARP packet format
ARP packets and RARP packets form a substantially uniform (see FIG. 4 - 3). The main difference between them is the RARP request or response frame type codes 0 x 8 0 3 5, and RARP request operation code of 3, the response to the operation code 4. Corresponds to the ARP, RARP request is broadcast, and the RARP reply is usually a unicast (unicast) transmission.
5.3 RARP Examples
In the Internet, we can force the host sun to boot from the network, rather than from a local disk. If RARP server program running on the host and the tcpdump bsdi, can be obtained in FIG. 5 - 1 as the output. -E tcpdump command with parameters such that the hardware address printed out:
RARP request is broadcast (line 1), while the second row RARP reply is unicast. Output line 2 represents the atsun RARP reply contains the IP address of the host sun (140. 252. 13. 33).
In line 3, we can see that, once the sun receive an IP address, it sends a TFTP read request (the RRQ) to the file 8 CFC 0 D 2 1. SUN 4 C (TFTP Trivial File Transfer Protocol represented. We described in detail in Chapter 15). File names of the eight hexadecimal digits tables for computing the IP address of the host sun 140. 252. 13. 33. The IP address returned in the RARP response. SUN4C file name suffix denotes the type of guidance system.
tcpdump noted that in line 3 IP datagram length is 65 bytes, rather than a UDP datagram (actually a UDP datagram), because we run with the tcpdump - e parameters to view hardware address layer. In FIG. 5 - Another point to be noted that in an Ethernet data frame in the second row is shorter than the minimum length (in Section 45, we said that it should be 60 bytes.). The reason is that we are running tcpdump command on sending the Ethernet frame system (bsdi). Application rarpd 42-byte write to the BSD Packet Filter apparatus (which is a 14-byte Ethernet frame header, the remaining 28 bytes RARP reply), which is a copy of the received tcpdump. However, the Ethernet device driver should whitespace padding short frame transmission in order to achieve a minimum length (60). As if we run the tcpdump on another system, the length will be 60 .
As can be seen from this example, when the diskless system receives its IP address from the RARP response, it sends a TFTP request to read a boot image. At this point we will not be discussed in further detail how the system is diskless boot (Chapter 16 will be described diskless X terminal using RARP, BOOTP and TFTP for guiding the process).
When no RARP server on the network, which results are shown 5--2 in FIG. The destination address of each packet are the Ethernet broadcast address. In the latter wh o- Ethernet address is the destination hardware address, Ethernet address behind that tell the sender's hardware address.
Please note that the retransmission frequency. First retransmission was after 6.5 5 seconds, then increased to 4 2.8 0 seconds, and then reduced to 5.3 and 4 seconds 6.5 5 seconds, and then back. 4 2.7 9 seconds . This uncertainty has continued. If the time between the retransmission interval calculate, we found that there is a double relationship: of from 5 3 4 To 655 is 121 seconds, and from 655 to 897... is 2.4 2 seconds from 8.9 7-1 3.8 0 is the 4.8 three seconds, has been so continue. When the time interval reaches a certain threshold (greater than 42. 80 seconds), it is reset to 5.3 to 4 seconds.
With such a time-out interval is incremented each time a method is better than the method of using the same value. In FIG. 6 - 8, we will see a wrong retransmission timeout method, see TCP timeout and retransmission mechanism in a second chapter 1.
5.4 RARP Server Design
While RARP is simple in concept, but a RARP server design and system-related and complex. Rather, an ARP server is very simple, usually part of the TCP / IP implementation in the kernel. Since the kernel know the IP address and hardware address, so when it receives an inquiry IP address of the ARP request, just use the corresponding hardware address to provide an answer on it.
5.4.1 RARP server as a user process
Complexity RARP server is that the server generally provides the hardware address to IP address mapping for a plurality of hosts (all the diskless systems on the network). The map contains in a disk file (the U nix system typically located / etc / ethers directory). In part because of the kernel generally do not read and analyze the disk file, function RARP server would be provided by the user process, rather than as a core TCP / IP implementation.
To further complicate matters, RARP request as a special type of a transmitted Ethernet frame (frame type field value 0 x 8 0 3 5, FIG 2--1 shown). This shows RARP server must be able to send and receive Ethernet data frames of this type. In Appendix A, we describe the BSD Packet Filter, S un, and a network interface pin SVR 4 Data Link Provider Interface can be used to receive these frames. Since the transmission and reception of data frames associated with the system, thus achieving an RARP server is bundled with the system.
5.4.2 Each network has more than RARP server
A complicating factor is achieved RARP server RARP requests are broadcast at the hardware level, as shown in FIG 5--2 in FIG. This means that they are not forwarded through the router. In order for the system can boot diskless RARP server in the shutdown state, typically (e.g. a cable) to provide a plurality RARP server on a network.
As the number of servers (to provide redundancy), network traffic increases, because each server must send RARP reply for every RARP request. Diskless system sends RARP RARP request of the general response was first received (for ARP, we have never encountered such a situation, because only one host sends an ARP reply). In addition, there is a situation that could happen is that each RARP server and your answering machine, this will increase the probability of Ethernet conflict.
5.5 Summary
RARP protocol is many diskless systems to obtain the IP address when booting. RARP packet format substantially identical to an ARP packet. A RARP request broadcast on the network, indicating that the hardware address of the sender in the packet to the corresponding IP address in response to the request. Response is often unicast delivery.
RARP bring the issue to bring include the use of link-layer broadcast, thus preventing most routers forward RARP request, return very little information: only the IP address of the system. In Chapter 16, we will see in the BOOTP diskless boot the system will return more information: name and IP address of the host and other guidance.
While RARP is simple in concept, but realized RARP server has associated with the system. Therefore, not all TCP / IP implementations provide an RARP server.
