5 RARP: Inverse Address Analysis Agreement
5.1 Introduction When a system boot with a local disk, it is generally read from the IP address from the configuration file on the disk. However, diskless, such as X terminals or diskless workstations, you need to use other methods to get IP addresses. Each system on the network has a unique hardware address, which is configured by a network interface manufacturer. The RARP implementation process of diskless system is to read unique hardware addresses from the interface card, and then send a RARP request (a frame broadcast on the network), requested a host to respond to the IP address of the diskless system (in RARP answer). This process is very simple, but it is often difficult than ARP, which is described later in this chapter. The formal specification of RARP is RFC 903 [FinLayson et al. 1984].
5.2 Rarp Packet Format The format of the RARP packet is basically consistent with the ARP packet (Figure 4.3). The main difference between the RARP requests or answers is 0x8035, and the operation code of the RARP request is 3, and the answer operation code is 4. Corresponding to the ARP, the RARP request is transmitted in broadcast mode, and the RARP answer is generally transmitted by Unicast.
5.3 RARP Example In our interconnect, we can force the Sun host from the network instead of booting from the local disk. If we run the RARP service program and tcpdump command on the host BSDI, you can get the output as shown in Figure 5.1. We use the -e parameter to make the TCPDUMP command print the hardware address:
Figure 5.1 RARP request and answer
RARP request is a broadcast mode (line 1), and the RARP answer of the second line is a unicast method. In the output of the second line AT SUN indicates the RARP answer contains the IP address of the host Sun (140.252.13.33). In line 3, we can see that once Sun receives the RARP answer, it sends a TFTP read request (RRQ) to file 8cfc0d21.sun4c. (TFTP represents a simple file transfer protocol. We will introduce it in Chapter 15.) 8 hexadecimal numbers in the file name on the file name. The IP address of the host Sun is 140.252.13.33. This IP address is returned in the RARP answer. The suffix sun4c of the file name represents the type of the boot system. TCPDUMP pointed out that the length of IP datagram is 65 bytes in line 3, not a UDP datagram (actually a UDP datagram), because we run the tcpdump command to view the hardware layer the address of. Another point you need to point out in Figure 5.1 is that the Ethernet data frame length in the second line is smaller than the minimum length (in Section 4.5), it should be 60 bytes.) The reason is that we are sending this The TCPDUMP command is run on the system (BISDI) of the network data frame. The application RARPD writes 42 bytes to the BSD packet filtering device (where 14 bytes is the header of the Ethernet data frame, the remaining 28-byte is the RARP answer), which is the copy received by TCPDump. However, the Ethernet device driver is to fill this short frame to achieve a minimum transmission length (60). If we run the TCPDUMP command on another system, its length will be 60. We can see from this example that when the diskless system receives its IP address from the RARP answer, it will send a TFTP request to read the lead image. At this point we will no longer discuss how the diskless system is guided. (Chapter 16 will describe the process of booting the disk using RARP, BOOTP, and TFTP.) When there is no RARP server on the network, the results are shown in Figure 5.2. The destination address of each packet is an Ethernet broadcast address. The Ethernet address behind who is a destination hardware address, and the Ethernet address following the TELL is the hardware address of the sender. Please pay attention to the frequency of retransmission. The first retransmission was after 6.55 seconds and then increased to 42.80 seconds, then minus to 5.34 seconds and 6.55 seconds, and then returned to 42.79 seconds. This uncertain condition has continued. If calculating the time interval between two retransmissions, we found a double relationship: from 5.34 to 6.55, it is 1.21 seconds, from 6.55 to 8.97 to 2.42 seconds, from 8.97 to 13.80 to 4.83 seconds, which is always so continued Go down. When the interval at the time reached a certain threshold (greater than 42.80 seconds), it was reset to 5.34 seconds. Figure 5.2 RARP request without RARP server in the network
Overcompaluentation method is better than the method of using the same value each time. In Figure 6.8, we will see a wrong timeout resend method, as well as the timeout resend mechanism of TCP in Chapter 21.
5.4 Rarp Server Design Although RARP is conceptually simple, designing a RARP server is related to the system and is more complicated. Instead, it is very simple to provide an ARP server, usually part of the TCP / IP in the kernel. Since the kernel knows the IP address and hardware address, it is only necessary to provide an answer with the corresponding hardware address when it receives an ARP request for an inquiry IP address.
The complexity of the RARP server RARP server as a user process is that the server typically provides a multi-host (all diskless systems on the network) to map the hardware address to the IP address. This mapping is included in a disk file (which is typically located in the / etc / ethers directory in the UNIX system). Since the kernel generally does not read and analyzing disk files, the functionality of the RARP server is provided by the user process, not part of the TCP / IP implementation of the kernel. More complicated is that the RARP request is transmitted as a special type of Ethernet data frame (the frame type field value is 0x8035, as shown in Figure 2.1). This shows that the RARP server must be able to send and receive this type of Ethernet data frame. In Appendix A, we describe the BSD packet filter, the Sun's network interface plug, and the SVR4 data link provider interface can be used to receive these data frames. Since sending and receiving these data frames are related to the system, the implementation and system of the RARP server are bundled together. One complex factor implemented by multiple RARP server RARP servers each network is that the RARP request is broadcast on the hardware layer, as shown in Figure 5.2. This means that they do not forward the router. In order to let the diskless system can boot in the RARP server shutdown, multiple RARP servers are usually provided on a network (eg, a cable). When the number of servers increases (to provide redundant backup), the network traffic also increases because each server is sent to each RARP request to answer the RARP answer. A diskless system that sends RARP requests generally adopts the first RARP answer. (We have never encountered this situation because only one host sends ARP answers.) In addition, there is a possibility that each RARP server answers at the same time, which increases the probability of conflicts in Ethernet.
5.5 Small ROM RARP protocol is used by many diskless systems to get IP addresses when booting. The RARP packet format is basically consistent with the ARP group. A RARP request broadcasts on the network, which is labeled in the packet to the hardware address of the sender to request a response to the corresponding IP address. Answer is usually unicast delivery. The issues brought by RARP include link layer broadcasting, which prevents most routers from forwarding RARP requests, only returns very little information: just the IP address of the system. In Chapter 16, we will see that BootP will return more information when boot disk-free system: IP address, boot the name of the host, and so on. Although RARP is conceptually simple, the implementation of the RARP server is related to the system. Therefore, not all TCP / IP implementations provide RARP servers.
Exercise 5.1 RARP requires different frame type fields? Both ARP and RARP use the same value 0x0806? 5.2 On a network with multiple RARP servers, how to prevent their response from conflicts? 5-3
