RARP: Das Reverse Address Re­so­lu­ti­on Protocol

Was passiert, wenn der eigene Rechner seine IP-Adresse nicht kennt, weil dieser zum Beispiel keinerlei Spei­cher­mög­lich­keit hat? In so einem Fall kann das Reverse Address Re­so­lu­ti­on Protocol (RARP) helfen – ein Protokoll zur um­ge­kehr­ten Adress­auf­lö­sung. Damit bildet RARP das Ge­gen­stück zu ARP – dem Address Re­so­lu­ti­on Protocol.

In­zwi­schen ist Reverse ARP veraltet, neuere Pro­to­kol­le wie das Bootstrap-Protokoll (BOOTP) oder das Dynamic-Host-Con­fi­gu­ra­ti­on-Protokoll (DHCP) haben RARP abgelöst. Dennoch ist es nützlich, auch die ältere Technik zu kennen. Zum einen findet man auch heute noch An­wen­dun­gen, die mit RARP arbeiten. Zum anderen hilft es, die alten Techniken zu kennen, um dadurch die darauf auf­bau­en­den Tech­no­lo­gien besser verstehen zu können.

Zunächst einmal handelt es sich bei RARP um ein Protokoll, das man 1984 ver­öf­fent­licht und in den TCP/IP-Pro­to­koll­sta­pel auf­ge­nom­men hat. RARP liegt dabei auf der Schicht des Netz­zu­gangs (der ele­men­tars­ten und nied­rigs­ten Ebene des Stapels) und stellt somit eine Technik dar, die der Über­tra­gung zwischen zwei Punkten in einem Netzwerk dient. Jeder Teil­neh­mer eines Netzwerks verfügt über zwei (mehr oder weniger) ein­deu­ti­ge Adressen: einer logischen, der IP-Adresse, und einer phy­si­ka­li­schen, der MAC-Adresse. Während die IP-Adresse auf Seiten der Software fest­ge­legt wird, ist die MAC-Adresse mit der Hardware verbunden. Der Her­stel­ler Ihrer Netz­werk­kar­te hat Ihnen somit die Media-Access-Control-Adresse bereits vor­ge­ge­ben.

Nun kann es vorkommen, dass die eigene IP-Adresse nicht bekannt ist, zum Beispiel weil das ent­spre­chen­de Gerät keinen eigenen Speicher hat, der die Adresse sichern könnte. In diesem Fall kommt das Reverse-ARP-Protokoll zum Einsatz. Anhand der bekannten MAC-Adresse kann das Protokoll die eigene IP-Adresse ermitteln. Somit erfüllt es einen komplett anderen Zweck als ARP. Bei letzt­ge­nann­tem Protokoll ist die IP-Adresse bekannt und mithilfe von ARP ermittelt man dann die Adresse der Hardware.

Folgende In­for­ma­tio­nen befinden sich in den einzelnen Feldern:

• Hardware Address Space: In diesen beiden Bytes wird der Typ der Hard­ware­adres­se angegeben.
• Protocol Address Space: Dieses zwei Byte große Feld gibt die Art des Netz­werk­pro­to­kolls an.
• Hardware Address Length: Diese 8 Bit legen die Länge n der Hard­ware­adres­se fest.
• Protocol Address Length: Mit diesem Feld bestimmt man die Länge m der Netz­werk­adres­se.
• Opcode: Das zwei Byte große Feld gibt an, um was für eine Operation es sich handelt. Eine RARP-Anfrage hat den Wert 3 und die ent­spre­chen­de Antwort den Wert 4.
• Source Hardware Address: Dort wird die MAC-Adresse des Absenders hin­ter­legt. Die ei­gent­li­che Länge dieses Feldes ist n und wird durch die Angabe unter Hardware Address Length fest­ge­legt. Bei einem typischen Ethernet-Netzwerk handelt es sich um 6 Bytes.
• Source Protocol Address: In diesem Feld würde theo­re­tisch die IP-Adresse des Absenders stehen, da diese aber ja bei einem Request nicht bekannt ist, bleibt das Feld un­de­fi­niert. Bei der Antwort hingegen findet sich an dieser Stelle die IP-Adresse des Servers. Die Länge dieses Feldes ist m und abhängig von Protocol Address Length. Ty­pi­scher­wei­se hat das Feld al­ler­dings die Länge einer IPv4-Adresse, also 4 Bytes.
• Target Hardware Address: Dieses Feld enthält die MAC-Adresse des Ziels. Da es kein spe­zi­fi­sches Ziel beim RARP-Request gibt, steht auch hier die Adresse des Absenders. Bei der Antwort trägt der Server hier ebenfalls die Adresse des an­fra­gen­den Clients ein. Auch dieses Feld hat die Länge n und ist im Fall eines Ethernet-Netzwerks 6 Byte groß.
• Target Protocol Address: Das letzte Feld schließ­lich bleibt bei einer Anfrage un­de­fi­niert und enthält in der Antwort des Servers die ei­gent­lich gesuchte In­for­ma­ti­on: die IP-Adresse des Netz­teil­neh­mers. Dieses Feld hat ebenfalls die Länge m, also üb­li­cher­wei­se 4 Bytes.

Wichtige Un­ter­schie­de zwischen den beiden Pro­to­kol­len ARP und RARP gibt es dennoch: In erster Linie un­ter­schei­den sich beide natürlich hin­sicht­lich der Angaben. Während man bei einem RARP-Request die eigene MAC-Adresse kennt, aber die ent­spre­chen­de IP-Adresse nachfragt, ist es beim ARP genau andersrum: Die IP-Adresse ist bekannt und die MAC-Adresse soll her­aus­ge­fun­den werden. Die beiden Pro­to­kol­le un­ter­schei­den sich aber auch hin­sicht­lich der Inhalte ihrer Operation-Felder: ARP kennt hier die beiden Werte 1 (für eine Anfrage) und 2 (für eine Antwort). RARP hingegen verwendet 3 und 4. Somit kann ein Server schon am Operation-Code erkennen, ob es sich um ARP oder RARP handelt.

Das Reverse Address Re­so­lu­ti­on Protocol hat einige Nachteile, die schließ­lich dazu geführt haben, dass man das Protokoll durch neuere ersetzt hat. Damit man das Protokoll er­folg­reich einsetzen kann, muss der RARP-Server bei­spiels­wei­se im gleichen phy­si­ka­li­schen Netzwerk liegen. Der Computer sendet den RARP-Request auf der nied­rigs­ten Ebene der Netz­schicht. Somit ist es nicht möglich, dass ein Router das Paket wei­ter­ver­mit­telt. Hinzu kommt noch, dass RARP nicht mit Sub­net­ting umgehen kann, da keinerlei Sub­netz­mas­ken über­tra­gen werden. Sollte das Netzwerk in mehrere Subnetze auf­ge­teilt worden sein, muss in jedem einzelnen ein RARP-Server verfügbar sein.

Durch die Anfrage erfährt der Netz­teil­neh­mer zudem aus­schließ­lich seine IP-Adresse. Wie bereits erwähnt ist eine Sub­netz­mas­ke nicht enthalten und auch In­for­ma­tio­nen zum Gateway erhält man über Reverse ARP nicht. Somit ist es auch nicht möglich, den Computer in einem modernen Netzwerk zu kon­fi­gu­rie­ren. Diese Miss­stän­de haben schließ­lich zur Ent­wick­lung von BOOTP und DHCP geführt.