„Reverse Address Resolution Protocol“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
→Verwendung und Funktionsweise: Wozu dieses Fremdwort hier? Es geht auch allgemeinverständlicher! |
Perrak (Diskussion | Beiträge) gelöschte Kategorie raus |
||
| (26 dazwischenliegende Versionen von 23 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
<div style="float:right;padding-left:15px"> |
<div style="float: right; padding-left: 15px;"> |
||
<center>'''RARP [[TCP/IP-Referenzmodell|Protokollstapel]]'''</ |
<div style="text-align:center;">'''RARP [[TCP/IP-Referenzmodell|Protokollstapel]]'''</div> |
||
{| class="wikitable" |
|||
{| |
|||
| |
|- |
||
! rowspan="1" style="background:#FFCC99;"| Netzwerk |
|||
! colspan="2" style="background:#9999FF;"| RARP |
|||
| |
|- |
||
| rowspan="2" |
| rowspan="2" style="background-color: #FFEEBB; text-align: center;" | ''Netzzugang'' |
||
| |
| style="background-color: #EEEEEE; text-align: center;" | [[Ethernet]] |
||
| |
| style="background-color: #EEEEEE; text-align: center;" | … |
||
|} |
|} |
||
</div> |
</div> |
||
| Zeile 15: | Zeile 15: | ||
== Verwendung und Funktionsweise == |
== Verwendung und Funktionsweise == |
||
Beispiel für [[Ethernet]]-[[Rechnernetz|Netzwerke]]: |
Beispiel für [[Ethernet]]-[[Rechnernetz|Netzwerke]]: |
||
RARP wird verwendet, wenn |
RARP wird verwendet, wenn einem Computer die eigene [[IP-Adresse]] nicht bekannt ist. |
||
RARP sendet dazu ein ''RARP Request''-[[Broadcast]] mit der eigenen [[MAC-Adresse]] als Inhalt an die am Netzwerk angeschlossenen Rechner. Ein RARP-[[Server]], welcher alle Zuordnungen IP- zu MAC-Adressen kennt, sendet daraufhin eine Antwort mit der IP-Adresse an die anfragende MAC-Adresse (''RARP-Reply''). |
RARP sendet dazu ein ''RARP Request''-[[Broadcast]] mit der eigenen [[MAC-Adresse]] als Inhalt an die am Netzwerk angeschlossenen Rechner. Ein RARP-[[Server]], welcher alle Zuordnungen IP- zu MAC-Adressen kennt, sendet daraufhin eine Antwort mit der IP-Adresse an die anfragende MAC-Adresse (''RARP-Reply''). |
||
| Zeile 24: | Zeile 23: | ||
Ausgenutzt wird bei RARP, dass den Herstellern weltweit eindeutige Präfixe für MAC-Adressen vergeben werden. Die Hersteller bemühen sich wiederum, weltweit eindeutige MAC-Adressen zu verteilen. In einem Netz der Schicht 2 dürfen keine zwei Geräte dieselbe MAC-Adresse verwenden. Außerhalb eines Schicht-2-Netzes ist dies zwar nicht wünschenswert, jedoch möglich. Die MAC-Adressen können von Benutzern relativ einfach angepasst werden. Daher ist es nicht garantiert, dass eine MAC-Adresse weltweit eindeutig ist. |
Ausgenutzt wird bei RARP, dass den Herstellern weltweit eindeutige Präfixe für MAC-Adressen vergeben werden. Die Hersteller bemühen sich wiederum, weltweit eindeutige MAC-Adressen zu verteilen. In einem Netz der Schicht 2 dürfen keine zwei Geräte dieselbe MAC-Adresse verwenden. Außerhalb eines Schicht-2-Netzes ist dies zwar nicht wünschenswert, jedoch möglich. Die MAC-Adressen können von Benutzern relativ einfach angepasst werden. Daher ist es nicht garantiert, dass eine MAC-Adresse weltweit eindeutig ist. |
||
Die vermeintliche Eindeutigkeit der MAC-Adresse darf nicht als Sicherheitskriterium angewandt werden. Es ist viel zu einfach, MAC-Adressen |
Die vermeintliche Eindeutigkeit der MAC-Adresse darf nicht als Sicherheitskriterium angewandt werden. Es ist viel zu einfach, MAC-Adressen-[[Spoofing]] zu betreiben. Fast alle Betriebssysteme erlauben es gewöhnlichen Benutzern, die MAC-Adresse komfortabel in Konfigurationsmasken oder mit einfachen Dienstprogrammen wie ''ifconfig (UNIX, Linux)'' oder ''ip link'' (Linux) zu überschreiben. Gültige MAC-Adressen in einem Schicht-2-Netz können durch ''Abhören'' des Netzverkehrs ausfindig gemacht werden. Dazu ist lediglich der physische Zugang zum Netzwerk nötig. Die exklusive Vergabe von IP-Adressen nur an registrierte MAC-Adressen über RARP oder [[Dynamic Host Configuration Protocol|DHCP]] schließt also nicht aus, dass Unberechtigte Zugriff auf das Netzwerk erhalten; dafür ist der Einsatz eines sicheren Authentifizierungsmechanismus wie [[IEEE 802.1X]] notwendig. |
||
Die Zuordnungstabelle auf dem RARP-Server, die zu jeder MAC-Adresse die lokal vergebene IP-Adresse enthält, muss vom Systemverwalter manuell gepflegt werden. |
Die Zuordnungstabelle auf dem RARP-Server, die zu jeder MAC-Adresse die lokal vergebene IP-Adresse enthält, muss vom Systemverwalter manuell gepflegt werden. |
||
== Paketformat == |
== Paketformat == |
||
Im Ethernetframe schließt sich das RARP-Paket an den MAC-Header und damit an das Ethernet-Typfeld an. Der Ethernettyp für RARP ist <code>0x8035</code>. Obwohl das Format für [[Address Resolution Protocol|ARP]] und RARP gleich ist und das Protokoll anhand des Operationsfeldes unterschieden werden könnte, handelt es sich um sehr unterschiedliche Operationen. Der unterschiedliche Ethernettyp unterscheidet die Protokolle bereits auf der unteren Ebene, so dass ARP-Server nicht durch RARP-Pakete und umgekehrt gestört werden können. |
Im Ethernetframe schließt sich das RARP-Paket an den MAC-Header und damit an das Ethernet-Typfeld an. Der Ethernettyp für RARP ist <code>0x8035</code>. Obwohl das Format für [[Address Resolution Protocol|ARP]] und RARP gleich ist und das Protokoll anhand des Operationsfeldes unterschieden werden könnte, handelt es sich um sehr unterschiedliche Operationen. Der unterschiedliche Ethernettyp unterscheidet die Protokolle bereits auf der unteren Ebene, so dass ARP-Server nicht durch RARP-Pakete und umgekehrt gestört werden können. |
||
{| class="wikitable" style="text-align:center;" |
|||
'''Ethernet MAC-Adressen und IPv4 Adressen''' |
|||
|+ ARP- und RARP-Nachrichtenformat am Beispiel Ethernet-MAC-Adressen und IPv4-Adressen |
|||
|- style="background:#FFEEBB" |
|||
<center> |
|||
! style="width:25%"| Bit 0–7 |
|||
{| cellpadding="3" cellspacing="1" |
|||
! style="width:25%"| Bit 8–15 |
|||
|----- |
|||
! style="width:25%"| Bit 16–23 |
|||
| align="left" | 0 || align="left" | 8 |
|||
! style="width:25%"| Bit 24–31 |
|||
| align="left" | 16 |
|||
|- style="background:#EEEEFF" |
|||
| align="center" | 24 || align="right" | 31 |
|||
|colspan="2"| Hardwareadresstyp (1) |
|||
|----- |
|||
|colspan="2"| Protokolladresstyp (0x0800) |
|||
| colspan=2 style="border:1px solid black;" align="center" width="50%" | Hardwareadresstyp (1) |
|||
|- style="background:#EEEEFF" |
|||
| colspan=3 style="border:1px solid black;" align="center" width="50%" | Protokolladresstyp (0x800) |
|||
|colspan="1"| Hardwareadressgröße (6) |
|||
|----- |
|||
|colspan="1"| Protokolladressgröße (4) |
|||
| colspan=1 style="border:1px solid black;" align="center" width="25%" | Hardwareadressgröße (6) |
|||
|colspan="2"| Operation |
|||
| colspan=1 style="border:1px solid black;" align="center" width="25%" | Protokolladressgröße (4) |
|||
|- style="background:#EEEEFF" |
|||
| colspan=3 style="border:1px solid black;" align="center" width="50%" | Operation |
|||
|colspan="4"| Quell-MAC-Adresse |
|||
|----- |
|||
|- style="background:#EEEEFF" |
|||
| colspan=5 style="border:1px solid black;" align="center" | Quell-MAC-Adresse |
|||
|colspan="2"| Quell-MAC-Adresse |
|||
|----- |
|||
| |
|colspan="2"| Quell-IP-Adresse |
||
|- style="background:#EEEEFF" |
|||
| colspan=3 style="border:1px solid black;" align="center" width="50%" | Quell-IP-Adresse |
|||
|colspan="2"| Quell-IP-Adresse |
|||
|----- |
|||
| |
|colspan="2"| Ziel-MAC-Adresse |
||
|- style="background:#EEEEFF" |
|||
| colspan=3 style="border:1px solid black;" align="center" width="50%" | Ziel-MAC-Adresse |
|||
|colspan="4"| Ziel-MAC-Adresse |
|||
|----- |
|||
|- style="background:#EEEEFF" |
|||
| colspan=5 style="border:1px solid black;" align="center" | Ziel-MAC-Adresse |
|||
|colspan="4"| Ziel-IP-Adresse |
|||
|----- |
|||
|- style="background:#EEEEFF" |
|||
| colspan=5 style="border:1px solid black;" align="center" | Ziel-IP-Adresse |
|||
|} |
|} |
||
</center> |
|||
Erläuterung der Felder: |
|||
* Operation (2 Byte): Enthält den Wert, der angibt, welche Operation ausgeführt werden soll (<code>3</code> für ''RARP Request'', <code>4</code> für RARP Reply). |
|||
* Quell-MAC-Adresse (6 Byte): Enthält in einem ''RARP Request''-Paket die MAC-Adresse des Senders. In einem ''RARP Reply'' enthält es die MAC-Adresse des antwortenden Servers. |
|||
* Quell-IP-Adresse (4 Byte): Ist bei einem ''RARP Request'' undefiniert. In einem ''RARP Reply'' enthält es die IP-Adresse des antwortenden Servers. |
|||
* Ziel-MAC-Adresse (6 Byte): Enthält in einem ''RARP Request''-Paket die MAC-Adresse des Senders. In einem ''RARP Reply'' enthält es die MAC-Adresse des anfragenden Hosts. |
|||
* Ziel-IP-Adresse (4 Byte): Ist bei einem ''RARP Request'' undefiniert. In einem ''RARP Reply'' enthält es die IP-Adresse des anfragenden Hosts. |
|||
== Probleme == |
== Probleme == |
||
| Zeile 76: | Zeile 74: | ||
Ethernet-Broadcasts sind auf Subnetze beschränkt, so dass RARP nur in einem Subnetz eingesetzt werden kann. Wird ein lokales Netzwerk ([[Local Area Network|LAN]]) in Subnetze aufgeteilt, muss in jedem dieser Subnetze, in dem RARP-fähige Terminals oder Workstations eingesetzt werden, ein eigener RARP-Server vorhanden sein. |
Ethernet-Broadcasts sind auf Subnetze beschränkt, so dass RARP nur in einem Subnetz eingesetzt werden kann. Wird ein lokales Netzwerk ([[Local Area Network|LAN]]) in Subnetze aufgeteilt, muss in jedem dieser Subnetze, in dem RARP-fähige Terminals oder Workstations eingesetzt werden, ein eigener RARP-Server vorhanden sein. |
||
Durch RARP erfährt ein Rechner nur seine IP-Adresse. Zu einer vollständigen Konfiguration einer Netzwerkschnittstelle für Endgeräte gehört aber mindestens noch die Netzmaske und das Default-Gateway. IP-Adressen |
Durch RARP erfährt ein Rechner nur seine IP-Adresse. Zu einer vollständigen Konfiguration einer Netzwerkschnittstelle für Endgeräte gehört aber mindestens noch die Netzmaske und das Default-Gateway. IP-Adressen wurden früher, vor der Einführung der Netzmasken, in Klassen eingeteilt, deren Netzmaske bekannt ist. Im Falle von Subnetting ist diese Netzmaske jedoch falsch. Auch das Setzen von weiteren Parametern wäre wünschenswert, kann aber nicht über RARP vorgenommen werden. RARP ist kein Ersatz für DHCP. |
||
== RARP und TFTP == |
== RARP und TFTP == |
||
Nach RARP wird häufig [[Trivial File Transfer Protocol|TFTP]] (''Trivial File Transfer Protocol'') eingesetzt, das z. B. bei Diskless-Workstations einen Speicherabzug des Betriebssystems an den Rechner überträgt. Erst nachdem dieser Speicherabzug in den Speicher der Workstation geladen ist, kann sie hochgefahren werden. Wird RARP eingesetzt, so kann weder der Name des Speicherabzugs noch die Adresse des TFTP-Servers übergeben werden. |
Nach RARP wird häufig [[Trivial File Transfer Protocol|TFTP]] (''Trivial File Transfer Protocol'') eingesetzt, das z. B. bei Diskless-Workstations einen Speicherabzug des Betriebssystems an den Rechner überträgt. Erst nachdem dieser Speicherabzug in den Speicher der Workstation geladen ist, kann sie hochgefahren werden. Wird RARP eingesetzt, so kann weder der Name des Speicherabzugs noch die Adresse des TFTP-Servers übergeben werden. |
||
Frühe Diskless-Workstations der Firma [[Sun Microsystems]] verwenden deshalb die hexadezimale Darstellung der IP-Adresse als Dateiname. Zunächst versuchen sie unter der Annahme, dass RARP- und TFTP-Server identisch sind, den TFTP-Transfer mit dem RARP-Server durchzuführen, dessen Adresse sie im Quelladressen-Feld des RARP-Replies finden. Falls dieser eine bestimmte Zeit (3 Sekunden) nicht antwortet, wird der gesamte TFTP-Transfer mit Hilfe von Ethernet-Broadcasts durchgeführt. Der TFTP-Server muss daher nicht mit dem RARP-Server identisch sein. Trotzdem muss auch der TFTP-Server bei diesem Verfahren ein lokaler Rechner auf dem jeweiligen Subnetz sein. Daneben werden unter Umständen viele Broadcast-Frames gesendet, was zu einer Belastung der anderen Geräte im selben Subnetz führt. |
Frühe Diskless-Workstations der Firma [[Sun Microsystems]] verwenden deshalb die hexadezimale Darstellung der IP-Adresse als Dateiname. Zunächst versuchen sie unter der Annahme, dass RARP- und TFTP-Server identisch sind, den TFTP-Transfer mit dem RARP-Server durchzuführen, dessen Adresse sie im Quelladressen-Feld des RARP-Replies finden. Falls dieser eine bestimmte Zeit (3 Sekunden) nicht antwortet, wird der gesamte TFTP-Transfer mit Hilfe von Ethernet-Broadcasts durchgeführt. Der TFTP-Server muss daher nicht mit dem RARP-Server identisch sein. Trotzdem muss auch der TFTP-Server bei diesem Verfahren ein lokaler Rechner auf dem jeweiligen Subnetz sein. Daneben werden unter Umständen viele Broadcast-Frames gesendet, was zu einer Belastung der anderen Geräte im selben Subnetz führt. |
||
| Zeile 89: | Zeile 87: | ||
Bei Verwendung eines [[BOOTP]]-Helpers auf dem [[Router]] kann der BOOTP-Broadcast auch in andere Netzwerke geroutet werden. Die Notwendigkeit eines Servers auf jedem Subnetz entfällt daher. Da die Aufteilung von [[Local Area Network|LANs]] in Subnetze mittlerweile üblich ist, haben BOOTP und DHCP das RARP-Protokoll fast vollständig verdrängt. |
Bei Verwendung eines [[BOOTP]]-Helpers auf dem [[Router]] kann der BOOTP-Broadcast auch in andere Netzwerke geroutet werden. Die Notwendigkeit eines Servers auf jedem Subnetz entfällt daher. Da die Aufteilung von [[Local Area Network|LANs]] in Subnetze mittlerweile üblich ist, haben BOOTP und DHCP das RARP-Protokoll fast vollständig verdrängt. |
||
== Siehe auch == |
|||
* [[Address Resolution Protocol]] |
|||
== Weblinks == |
== Weblinks == |
||
* RFC 903 |
* {{RFC-Internet |Autor=Finlayson, Mann, Mogul, Theimer |RFC=903 |Titel=A Reverse Address Resolution Protocol |Datum=1984-06}} |
||
[[Kategorie:Internetprotokoll]] |
|||
[[ |
[[Kategorie:Internet Protocol]] |
||
[[ca:Protocol invers de resolució d'adreces]] |
|||
[[cs:Reverse Address Resolution Protocol]] |
|||
[[da:Reverse address resolution protocol]] |
|||
[[en:Reverse Address Resolution Protocol]] |
|||
[[eu:RARP]] |
|||
[[fi:RARP]] |
|||
[[fr:Reverse address resolution protocol]] |
|||
[[it:Reverse Address Resolution Protocol]] |
|||
[[ja:Reverse address resolution protocol]] |
|||
[[nl:Reverse Address Resolution Protocol]] |
|||
[[no:RARP]] |
|||
[[pl:Reverse Address Resolution Protocol]] |
|||
[[pt:Reverse Address Resolution Protocol]] |
|||
[[ru:RARP]] |
|||
[[sv:Reverse Address Resolution Protocol]] |
|||
[[tr:RARP]] |
|||
[[zh:反向地址转换协议]] |
|||
Aktuelle Version vom 1. Oktober 2024, 23:43 Uhr
| Netzwerk | RARP | |
|---|---|---|
| Netzzugang | Ethernet | … |
Das Reverse Address Resolution Protocol (RARP) ist ein Netzwerkprotokoll, das die Zuordnung von Hardwareadressen zu Internetadressen ermöglicht. Es gehört zur Vermittlungsschicht der Internetprotokollfamilie.
Verwendung und Funktionsweise
[Bearbeiten | Quelltext bearbeiten]Beispiel für Ethernet-Netzwerke:
RARP wird verwendet, wenn einem Computer die eigene IP-Adresse nicht bekannt ist.
RARP sendet dazu ein RARP Request-Broadcast mit der eigenen MAC-Adresse als Inhalt an die am Netzwerk angeschlossenen Rechner. Ein RARP-Server, welcher alle Zuordnungen IP- zu MAC-Adressen kennt, sendet daraufhin eine Antwort mit der IP-Adresse an die anfragende MAC-Adresse (RARP-Reply).
Ausgenutzt wird bei RARP, dass den Herstellern weltweit eindeutige Präfixe für MAC-Adressen vergeben werden. Die Hersteller bemühen sich wiederum, weltweit eindeutige MAC-Adressen zu verteilen. In einem Netz der Schicht 2 dürfen keine zwei Geräte dieselbe MAC-Adresse verwenden. Außerhalb eines Schicht-2-Netzes ist dies zwar nicht wünschenswert, jedoch möglich. Die MAC-Adressen können von Benutzern relativ einfach angepasst werden. Daher ist es nicht garantiert, dass eine MAC-Adresse weltweit eindeutig ist.
Die vermeintliche Eindeutigkeit der MAC-Adresse darf nicht als Sicherheitskriterium angewandt werden. Es ist viel zu einfach, MAC-Adressen-Spoofing zu betreiben. Fast alle Betriebssysteme erlauben es gewöhnlichen Benutzern, die MAC-Adresse komfortabel in Konfigurationsmasken oder mit einfachen Dienstprogrammen wie ifconfig (UNIX, Linux) oder ip link (Linux) zu überschreiben. Gültige MAC-Adressen in einem Schicht-2-Netz können durch Abhören des Netzverkehrs ausfindig gemacht werden. Dazu ist lediglich der physische Zugang zum Netzwerk nötig. Die exklusive Vergabe von IP-Adressen nur an registrierte MAC-Adressen über RARP oder DHCP schließt also nicht aus, dass Unberechtigte Zugriff auf das Netzwerk erhalten; dafür ist der Einsatz eines sicheren Authentifizierungsmechanismus wie IEEE 802.1X notwendig.
Die Zuordnungstabelle auf dem RARP-Server, die zu jeder MAC-Adresse die lokal vergebene IP-Adresse enthält, muss vom Systemverwalter manuell gepflegt werden.
Paketformat
[Bearbeiten | Quelltext bearbeiten]Im Ethernetframe schließt sich das RARP-Paket an den MAC-Header und damit an das Ethernet-Typfeld an. Der Ethernettyp für RARP ist 0x8035. Obwohl das Format für ARP und RARP gleich ist und das Protokoll anhand des Operationsfeldes unterschieden werden könnte, handelt es sich um sehr unterschiedliche Operationen. Der unterschiedliche Ethernettyp unterscheidet die Protokolle bereits auf der unteren Ebene, so dass ARP-Server nicht durch RARP-Pakete und umgekehrt gestört werden können.
| Bit 0–7 | Bit 8–15 | Bit 16–23 | Bit 24–31 |
|---|---|---|---|
| Hardwareadresstyp (1) | Protokolladresstyp (0x0800) | ||
| Hardwareadressgröße (6) | Protokolladressgröße (4) | Operation | |
| Quell-MAC-Adresse | |||
| Quell-MAC-Adresse | Quell-IP-Adresse | ||
| Quell-IP-Adresse | Ziel-MAC-Adresse | ||
| Ziel-MAC-Adresse | |||
| Ziel-IP-Adresse | |||
Erläuterung der Felder:
- Operation (2 Byte): Enthält den Wert, der angibt, welche Operation ausgeführt werden soll (
3für RARP Request,4für RARP Reply).
- Quell-MAC-Adresse (6 Byte): Enthält in einem RARP Request-Paket die MAC-Adresse des Senders. In einem RARP Reply enthält es die MAC-Adresse des antwortenden Servers.
- Quell-IP-Adresse (4 Byte): Ist bei einem RARP Request undefiniert. In einem RARP Reply enthält es die IP-Adresse des antwortenden Servers.
- Ziel-MAC-Adresse (6 Byte): Enthält in einem RARP Request-Paket die MAC-Adresse des Senders. In einem RARP Reply enthält es die MAC-Adresse des anfragenden Hosts.
- Ziel-IP-Adresse (4 Byte): Ist bei einem RARP Request undefiniert. In einem RARP Reply enthält es die IP-Adresse des anfragenden Hosts.
Probleme
[Bearbeiten | Quelltext bearbeiten]Ethernet-Broadcasts sind auf Subnetze beschränkt, so dass RARP nur in einem Subnetz eingesetzt werden kann. Wird ein lokales Netzwerk (LAN) in Subnetze aufgeteilt, muss in jedem dieser Subnetze, in dem RARP-fähige Terminals oder Workstations eingesetzt werden, ein eigener RARP-Server vorhanden sein.
Durch RARP erfährt ein Rechner nur seine IP-Adresse. Zu einer vollständigen Konfiguration einer Netzwerkschnittstelle für Endgeräte gehört aber mindestens noch die Netzmaske und das Default-Gateway. IP-Adressen wurden früher, vor der Einführung der Netzmasken, in Klassen eingeteilt, deren Netzmaske bekannt ist. Im Falle von Subnetting ist diese Netzmaske jedoch falsch. Auch das Setzen von weiteren Parametern wäre wünschenswert, kann aber nicht über RARP vorgenommen werden. RARP ist kein Ersatz für DHCP.
RARP und TFTP
[Bearbeiten | Quelltext bearbeiten]Nach RARP wird häufig TFTP (Trivial File Transfer Protocol) eingesetzt, das z. B. bei Diskless-Workstations einen Speicherabzug des Betriebssystems an den Rechner überträgt. Erst nachdem dieser Speicherabzug in den Speicher der Workstation geladen ist, kann sie hochgefahren werden. Wird RARP eingesetzt, so kann weder der Name des Speicherabzugs noch die Adresse des TFTP-Servers übergeben werden.
Frühe Diskless-Workstations der Firma Sun Microsystems verwenden deshalb die hexadezimale Darstellung der IP-Adresse als Dateiname. Zunächst versuchen sie unter der Annahme, dass RARP- und TFTP-Server identisch sind, den TFTP-Transfer mit dem RARP-Server durchzuführen, dessen Adresse sie im Quelladressen-Feld des RARP-Replies finden. Falls dieser eine bestimmte Zeit (3 Sekunden) nicht antwortet, wird der gesamte TFTP-Transfer mit Hilfe von Ethernet-Broadcasts durchgeführt. Der TFTP-Server muss daher nicht mit dem RARP-Server identisch sein. Trotzdem muss auch der TFTP-Server bei diesem Verfahren ein lokaler Rechner auf dem jeweiligen Subnetz sein. Daneben werden unter Umständen viele Broadcast-Frames gesendet, was zu einer Belastung der anderen Geräte im selben Subnetz führt.
BOOTP und DHCP
[Bearbeiten | Quelltext bearbeiten]Das BOOTP-Protokoll und das darauf aufsetzende DHCP-Protokoll vermeiden die Probleme des RARP-Protokolls. Sie gestatten das Setzen vieler Parameter und damit unter anderem die vollständige Konfiguration der Netzwerkschnittstelle. Falls zusätzlich TFTP verwendet wird, kann der Dateiname und die Serveradresse mehrerer Server übergeben werden. Wird die Adresse eines Gateways bei der Schnittstellenkonfiguration gesetzt, können die TFTP-Server in einem beliebigen Netzwerk stehen, da die Pakete korrekt geroutet werden.
Bei Verwendung eines BOOTP-Helpers auf dem Router kann der BOOTP-Broadcast auch in andere Netzwerke geroutet werden. Die Notwendigkeit eines Servers auf jedem Subnetz entfällt daher. Da die Aufteilung von LANs in Subnetze mittlerweile üblich ist, haben BOOTP und DHCP das RARP-Protokoll fast vollständig verdrängt.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Finlayson, Mann, Mogul, Theimer: RFC: – A Reverse Address Resolution Protocol. Juni 1984 (englisch).