3.7 ARP - Anfrage und Reply

Warum IPv4 im lokalen Netz ARP benötigt

Anwendungen und Transportprotokolle kommunizieren über IP-Adressen. Ein Ethernet-Frame benötigt auf dem lokalen Link dagegen eine Quell- und Ziel-MAC-Adresse. Bevor ein Host ein IPv4-Paket über Ethernet versenden kann, muss er deshalb die IPv4-Adresse des nächsten direkten Kommunikationspartners einer MAC-Adresse zuordnen.

ARP arbeitet nur innerhalb des lokalen Layer-2-Broadcastbereichs. Router leiten gewöhnliche ARP-Anfragen nicht weiter. Für ein Ziel in einem entfernten IPv4-Netz wird daher nicht die MAC-Adresse des entfernten Endgeräts gesucht, sondern die MAC-Adresse des lokalen Next Hops - normalerweise des Default Gateways.

ARP Request und ARP Reply

Kennt Host A die MAC-Adresse zu einer lokalen IPv4-Adresse noch nicht, sendet er einen ARP Request in einem Ethernet-Frame mit der Zieladresse ff:ff:ff:ff:ff:ff. Dadurch prüfen alle Geräte im Broadcastbereich die Anfrage. Der Request lässt sich sinngemäß lesen als: „Wer besitzt 192.0.2.20? Antworte 192.0.2.10.“

Host B erkennt seine eigene IPv4-Adresse im Target Protocol Address-Feld und antwortet mit einem ARP Reply. Dieser wird im Normalfall als Ethernet-Unicast an Host A gesendet. Die Antwort teilt die Zuordnung 192.0.2.20 zu 02:00:00:00:00:20 mit. Host A kann sie in seiner Nachbartabelle speichern und danach den eigentlichen IPv4-Datenverkehr senden.

Die vier Adressfelder richtig lesen

ARP bezeichnet IPv4-Adressen als Protocol Addresses und MAC-Adressen als Hardware Addresses. Sowohl Request als auch Reply enthalten Sender Hardware Address, Sender Protocol Address, Target Hardware Address und Target Protocol Address. Entscheidend ist, aus wessen Sicht die Felder gelesen werden: Sender bezeichnet immer den Erzeuger der jeweiligen ARP-Nachricht.

Im Request kennt Host A seine eigene IPv4- und MAC-Adresse sowie die gesuchte IPv4-Adresse von Host B. Die Target Hardware Address ist noch unbekannt und wird bei Ethernet mit 00:00:00:00:00:00 belegt. Im Reply ist Host B der Sender und trägt deshalb seine Daten in die Senderfelder ein; die Daten von Host A stehen nun in den Targetfeldern.

Aufbau einer ARP-Nachricht

Eine ARP-Nachricht für Ethernet und IPv4 ist 28 Byte groß. Sie wird direkt in einem Ethernet-Frame mit dem EtherType 0x0806 transportiert und besitzt keinen IPv4-Header. Genau deshalb ist ARP nicht einfach ein gewöhnliches Layer-3-Protokoll, obwohl es IPv4-Adressen als Protocol Addresses verarbeitet.

ARP- beziehungsweise Nachbartabelle

Gelernte Zuordnungen werden für eine begrenzte Zeit in einer ARP- oder Nachbartabelle gespeichert. Dadurch muss nicht vor jedem IPv4-Paket erneut ein Broadcast gesendet werden. Dynamische Einträge besitzen Zustände und Zeitgeber; das konkrete Verhalten unterscheidet sich zwischen Betriebssystemen.

Ein gespeicherter Eintrag ist kein dauerhafter Beweis für die Identität eines Geräts. Er beschreibt die momentan angenommene Zuordnung auf einem bestimmten Interface. Nach Ablauf, Änderung oder fehlender Erreichbarkeit kann das System die Zuordnung erneut prüfen.

• Ein Ping kann eine ARP-Auflösung auslösen, sofern das Ziel beziehungsweise der Next Hop lokal erreichbar sein soll.
• Fehlt der Nachbareintrag dauerhaft im Zustand INCOMPLETE oder FAILED, sind VLAN, Link, IPv4-Konfiguration, Zielerreichbarkeit und Filterregeln zu prüfen.
• Statische Einträge sind für Sonderfälle möglich, erhöhen aber den Verwaltungsaufwand und beheben keine falsche Netzplanung.

ARP Probe, Announcement und Adresskonflikte

Vor der Verwendung einer IPv4-Adresse kann ein Host mit ARP Probes prüfen, ob die Adresse bereits auf dem Link verwendet wird. Dabei enthält die Sender Protocol Address 0.0.0.0, damit fremde ARP-Caches nicht mit einer noch ungeprüften Zuordnung befüllt werden. Die Target Protocol Address enthält die zu prüfende IPv4-Adresse.

Nach erfolgreicher Prüfung kann ein ARP Announcement die eigene Zuordnung bekannt geben und veraltete Einträge anderer Teilnehmer aktualisieren. Sender und Target Protocol Address enthalten dabei die eigene IPv4-Adresse. Ein Announcement allein ersetzt keine vollständige Konflikterkennung; RFC 5227 beschreibt Probe, Announcement und laufende Konfliktprüfung zusammenhängend.

Proxy ARP und ARP-Sicherheit

Bei Proxy ARP beantwortet ein Router oder anderes System eine ARP-Anfrage stellvertretend für ein Ziel hinter einem anderen Layer-3-Weg. Der anfragende Host behandelt das Ziel dadurch scheinbar als lokal. Das kann in bestimmten Alt- oder Übergangsszenarien helfen, verschleiert aber Netzgrenzen und sollte nicht mit gewöhnlichem Routing verwechselt werden.

ARP besitzt keine eingebaute Authentisierung. Ein Angreifer oder falsch konfiguriertes Gerät kann gefälschte Zuordnungen verbreiten und Verkehr umleiten oder stören. Dieses Verhalten wird als ARP Spoofing beziehungsweise ARP Poisoning bezeichnet. Switch-Funktionen wie DHCP Snooping und Dynamic ARP Inspection können in verwalteten Netzen helfen, benötigen aber eine korrekte Vertrauens- und Portkonfiguration.

• Unerwartete oder häufig wechselnde MAC-Zuordnungen untersuchen, statt nur den Cache wiederholt zu löschen.
• Statische ARP-Einträge skalieren schlecht und sind kein allgemeiner Ersatz für Netzsegmentierung und Switch-Schutzfunktionen.
• Verschlüsselte Anwendungsprotokolle begrenzen die Folgen einer Umleitung, verhindern jedoch nicht die Störung der lokalen Zustellung.

IPv6 verwendet Neighbor Discovery statt ARP

ARP wird für IPv4 verwendet. IPv6 löst lokale Nachbaradressen über das Neighbor Discovery Protocol mit ICMPv6 Neighbor Solicitation und Neighbor Advertisement auf. Dabei kommen gezielte Solicited-Node-Multicastgruppen statt eines Ethernet-Broadcasts an alle Teilnehmer zum Einsatz.

Neighbor Discovery übernimmt zusätzlich Router Discovery, Erreichbarkeitsprüfung, Duplicate Address Detection und weitere Aufgaben. ARP und NDP erfüllen daher bei der Adressauflösung einen ähnlichen Zweck, sind aber weder paketgleich noch vollständig funktionsgleich.

ARP-Fehler systematisch eingrenzen