NAME

rarpd − DARPA Reverse Address Resolution Protocol service

SYNOPSIS

/usr/etc/rarpd if hostname

Sun386i SYNOPSIS

/usr/etc/rarpd if [ hostname ]

AVAILABILITY

This program is available on all Sun386i systems.  On other Sun systems, it is available with the Networking Tools and Programs software installation option. Refer to Installing the SunOS for information on how to install optional software. 

DESCRIPTION

rarpd starts a daemon that responds to Reverse Address Resolution Protocol (Reverse ARP) requests.  The daemon forks a copy of itself, and requires root privileges. 

The Reverse ARP protocol is used by machines at boot time to discover their (32 bit) IP address given their (48 bit) Ethernet address.  In order for the request to be answered, a machine’s name-to-IP-address entry must exist in the /etc/hosts file and its name-to-Ethernet-address entry must exist in the /etc/ethers file.  Furthermore, the server that runs the rarpd daemon must have entries in both files.  Note that if the server machine is using the Yellow Pages service, the server’s files are ignored, and the appropriate Yellow Pages maps queried. 

The first argument, if, is one of the interface parameter strings (listed in boot(8S)), in the form of “name unit”, for example ie0.  The second argument, hostname, is the interface’s corresponding host name.  The if, hostname pair should be the same as the arguments passed to the ifconfig (8) command.  As with ifconfig, rarpd must be invoked for each interface that the server wishes to support.  Therefore a gateway machine may invoke the rarpd multiple times, for example:

/usr/etc/rarpd ie0 host
/usr/etc/rarpd ie1 host-backbone

Sun386i DESCRIPTION

On the Sun386i, rarpd is responsible for dynamic IP address allocation using Dynamic RARP.  If the pnp policy is not set to restricted in the YP policies map, then Dynamic RARP requests may cause rarpd to request allocation of a temporarily unused IP address from the ipalloc daemon.  This happens only when the system is not listed in the hosts and ethers YP maps as being on the particular network segment. 

If the pnp policy is set to restricted then Dynamic RARP requests that can not be satisfied will receive an error response indicating that Automatic System Installation is not enabled on the network segment.  In such a case, systems trying to install themselves on the network will report that manual installation by the network administrator is required. 

Only Yellow Pages servers provide Dynamic RARP service.  If any system incorrectly tries to provide Dynamic RARP service on the network, this will be detected and dynamic IP address allocation will be disabled.  This is required, since otherwise two different authorities could be assigning IP addresses on the network and would probably allocate addresses that should not be allocated.  Only one Address Authority may exist for a network segment; it must have the authoritative list of all Dynamic RARP clients. 

IP address allocation using the RARP protocol, as well as the Dynamic RARP protocol, may be enabled by setting the ip_address_allocation policy (in the YP policies map) to the value rarp_and_drarp .  If this is done, then all RARP clients must be listed in the YP databases used by rarpd.  If this is not done, some clients may be returned incorrect addresses when one is dynamically assigned.  The Dynamic RARP protocol may be completely disabled by setting this policy value to none .  This is strongly discouraged. 

FILES

/etc/ethers

/etc/hosts

SEE ALSO

boot(8S), ifconfig(8C) ipallocd(8C), ethers(5), hosts(5), ipallocd(8C), netconfig(8C), pnpboot(8), policies(5)

Finlayson, Ross, Timothy Mann, Jeffrey Mogul, and Marvin Theimer, A Reverse Address Resolution Protocol, RFC 903, Network Information Center, SRI International, Menlo Park, Calif., June 1984. 

Sun Release 4.0  —  Last change: 6 October 1988