分类： 系统运维
2012-05-10 15:58:12
Each system on a network has a unique hardware address, assigned by the manufacturer of the network interface. The principle of RARP is for the diskless system to read its unique hardware address from the interface card and send an RARP request (a broadcast frame on the network) asking for someone to reply with the diskless system's IP address (in an RARP reply).
While the concept is simple, the implementation is often harder than ARP for reasons described later in this chapter. The official specification of RARP is RFC 903 [Finlayson et al. 1984].
RARP Packet Format
The format of an RARP packet is almost identical to an ARP packet (Figure 4.3). The only differences are that the frame type is 0x8035 for an RARP request or reply, and the op field has a value of 3 for an RARP request and 4 for an RARP reply.
As with ARP, the RARP request is broadcast and the RARP reply is normally unicast.
RARP Server Design
While
the concept of RARP is simple, the design of an RARP server is system
dependent and complex. Conversely, providing an ARP server is simple,
and is normally part of the TCP/IP implementation in the kernel. Since
the kernel knows its IP addresses and hardware addresses, when it
receives an ARP request for one of its IP addresses, it just replies
with the corresponding hardware address.
RARP Servers as User Processes
The complication with an RARP server is that the server normally provides the mapping from a hardware address to an IP address for many hosts (all the diskless systems on the network). This mapping is contained in a disk file (normally /etc/ethers on Unix systems). Since kernels normally don't read and parse disk files, the function of an RARP server is provided as a user process, not as part of the kernel's TCP/IP implementation. To further complicate matters, RARP requests are transmitted as Ethernet frames with a specific Ethernet frame type field (0x8035 from Figure 2.1.) This means an RARP server must have some way of sending and receiving Ethernet frames of this type.
Multiple RARP Servers per Network
Another complication is that RARP requests are sent as hardware-level broadcasts. This means they are not forwarded by routers. To allow diskless systems to bootstrap even when the RARP server host is down, multiple RARP servers are normally provided on a single network (e.g., a single cable).
As the number of servers increases (to provide redundancy), the network traffic increases, since every server sends an RARP reply for every RARP request. The diskless system that sent the RARP request normally uses the first RARP reply that it receives. (We never had this problem with ARP, because only a single host sends an ARP reply.) Furthermore, there is a chance that each RARP server can try to respond at about the same time, increasing the probability of collisions on an Ethernet.
