Introduction (Einführung)
Das Internet-Protokoll (Internet Protocol, IP) [1] wird für den Host-zu-Host-Datagrammdienst in einem System vernetzter Netzwerke verwendet, das als Catenet [2] bezeichnet wird. Die Netzwerkverbindungsgeräte werden als Gateways bezeichnet. Diese Gateways kommunizieren zu Kontrollzwecken untereinander über ein Gateway-zu-Gateway-Protokoll (Gateway to Gateway Protocol, GGP) [3,4]. Gelegentlich muss ein Gateway oder ein Ziel-Host mit einem Quell-Host kommunizieren, beispielsweise um einen Fehler bei der Datagrammverarbeitung zu melden. Für solche Zwecke wird das Internet Control Message Protocol (ICMP, Internet-Kontrollnachrichtenprotokoll) verwendet. ICMP verwendet die grundlegende Unterstützung von IP, als ob es ein höheres Protokoll wäre, jedoch ist ICMP tatsächlich ein integraler Bestandteil von IP und muss von jedem IP-Modul implementiert werden.
ICMP-Nachrichten werden in mehreren Situationen gesendet: zum Beispiel, wenn ein Datagramm sein Ziel nicht erreichen kann, wenn das Gateway nicht über die Pufferkapazität verfügt, um ein Datagramm weiterzuleiten, und wenn das Gateway den Host anweisen kann, Datenverkehr über eine kürzere Route zu senden.
Das Internet-Protokoll ist nicht darauf ausgelegt, absolut zuverlässig zu sein. Der Zweck dieser Kontrollnachrichten besteht darin, Feedback über Probleme in der Kommunikationsumgebung zu geben, nicht IP zuverlässig zu machen. Es gibt immer noch keine Garantie, dass ein Datagramm zugestellt wird oder dass eine Kontrollnachricht zurückgegeben wird. Einige Datagramme können noch ohne Verlustmeldung nicht zugestellt werden. Die höheren Protokolle, die IP verwenden, müssen ihre eigenen Zuverlässigkeitsverfahren implementieren, wenn zuverlässige Kommunikation erforderlich ist.
ICMP-Nachrichten melden typischerweise Fehler bei der Verarbeitung von Datagrammen. Um eine unendliche Rekursion von Nachrichten über Nachrichten usw. zu vermeiden, werden keine ICMP-Nachrichten über ICMP-Nachrichten gesendet. Außerdem werden ICMP-Nachrichten nur über Fehler bei der Verarbeitung von Fragment Null fragmentierter Datagramme gesendet. (Fragment Null hat einen Fragment-Offset gleich Null).
Wichtige Designprinzipien
1. Teil der IP-Schicht
Anwendungsschicht
↓
Transportschicht (TCP/UDP)
↓
Netzwerkschicht (IP + ICMP) ← ICMP ist integraler Bestandteil von IP
↓
Sicherungsschicht
ICMP ist kein höheres Protokoll, das IP verwendet; vielmehr ist es ein integraler Bestandteil der IP-Schicht selbst.
2. Fehlermeldung, keine Zuverlässigkeit
Was ICMP tut:
- ✅ Meldet Probleme bei der Datagrammverarbeitung
- ✅ Bietet Feedback über Netzwerkbedingungen
- ✅ Unterstützt bei der Netzwerkdiagnose
Was ICMP nicht tut:
- ❌ Garantiert Nachrichtenzustellung
- ❌ Macht IP zuverlässig
- ❌ Bietet Ende-zu-Ende-Zuverlässigkeit
- ❌ Implementiert Flusskontrolle
3. Keine unendliche Rekursion
Regel: ICMP-Nachrichten werden niemals über ICMP-Nachrichten gesendet.
Datagramm mit Fehler
↓
ICMP-Fehlernachricht gesendet ✅
↓
ICMP-Nachricht mit Fehler
↓
KEINE ICMP-Fehlernachricht gesendet ❌ (Verhindert Endlosschleife)
Beispiel:
1. TCP-Paket → IP-Datagramm → Fehler tritt auf
→ ICMP Destination Unreachable gesendet ✅
2. ICMP Destination Unreachable → Fehler tritt auf
→ KEINE ICMP-Nachricht gesendet ❌
Dies verhindert Fehlernachrichten-Kaskaden
4. Fragment-Null-Regel
ICMP-Fehlernachrichten werden nur für das erste Fragment (Fragment-Offset = 0) eines fragmentierten Datagramms gesendet.
Ursprüngliches Datagramm (fragmentiert):
┌─────────────┬─────────────┬─────────────┐
│ Fragment 0 │ Fragment 1 │ Fragment 2 │
│ offset=0 │ offset=500 │ offset=1000 │
└─────────────┴─────────────┴─────────────┘
↓ ↓ ↓
Fehler Fehler Fehler
↓ ↓ ↓
ICMP gesendet ✅ Kein ICMP ❌ Kein ICMP ❌
Begründung:
- Vermeidet die Generierung mehrerer Fehlernachrichten für dasselbe ursprüngliche Datagramm
- Stellt sicher, dass die Fehlermeldung verwaltbar ist
- Nur das erste Fragment enthält vollständige Informationen des höheren Protokolls
Häufige Szenarien für ICMP-Nachrichten
Szenario 1: Ziel nicht erreichbar
Host A → Router → [Netzwerk B ist ausgefallen]
↓
ICMP Type 3: Destination Unreachable
↓
Host A erhält Fehlerbenachrichtigung
Szenario 2: Umleitung
Host A → Gateway 1 → Gateway 2 → Ziel
↓
ICMP Type 5: Redirect
„Verwenden Sie Gateway 2 direkt für dieses Ziel"
↓
Host A aktualisiert Routing-Tabelle
Szenario 3: Zeit überschritten
Paket mit TTL=1
↓
Router dekrementiert TTL auf 0
↓
ICMP Type 11: Time Exceeded
↓
Quell-Host erhält Benachrichtigung
Szenario 4: Quelldrosselung (Überlastungskontrolle)
Gateway-Puffer voll
↓
ICMP Type 4: Source Quench
↓
Quell-Host verringert Übertragungsrate
Hinweis: Source Quench ist jetzt veraltet (RFC 6633) aufgrund von Ineffektivität und Missbrauchspotenzial.
Beziehung zu anderen Protokollen
ICMP und IP
IP-Datagramm:
┌─────────────┬──────────────────┐
│ IP-Header │ IP-Nutzdaten │
│ Protocol=1 │ ICMP-Nachricht │
└─────────────┴──────────────────┘
IP-Header:
- Protocol-Feld = 1 (zeigt ICMP an)
- Source Address = ICMP-Absender
- Destination Address = ICMP-Empfänger
ICMP und GGP
Gateway-zu-Gateway-Protokoll (Gateway to Gateway Protocol, GGP):
- Gateways verwenden GGP für die Kontrollkommunikation untereinander
- ICMP wird für die Gateway-zu-Host-Kommunikation verwendet
- Unterschiedliche Zwecke, komplementäre Protokolle
ICMP und höhere Protokolle
Anwendung (z.B. Ping-Dienstprogramm)
↓ Konstruiert ICMP-Nachricht
IP-Schicht mit ICMP-Modul
↓ Sendet ICMP in IP-Datagramm
Netzwerkschnittstelle
Beispiele für Fehlermeldung
Beispiel 1: Host nicht erreichbar
Schritt 1: Host A sendet Paket an Host B (10.0.2.100)
┌─────────────────────────────┐
│ Src: 10.0.1.10 │
│ Dst: 10.0.2.100 │
│ Data: "Hello" │
└─────────────────────────────┘
Schritt 2: Router R1 bestimmt, dass Host B nicht erreichbar ist
Routing-Tabelle von Router R1: Keine Route zu 10.0.2.0/24
Schritt 3: Router R1 sendet ICMP Destination Unreachable
┌─────────────────────────────┐
│ ICMP Type: 3 │
│ Code: 1 (Host Unreachable) │
│ Enthält: IP-Header + 64 │
│ Bits des │
│ ursprünglichen │
│ Datagramms │
└─────────────────────────────┘
Schritt 4: Host A erhält ICMP und meldet Fehler an Anwendung
Beispiel 2: Fragmentierung erforderlich, aber DF gesetzt
Schritt 1: Host A sendet großes Paket mit Don't Fragment (DF) Flag
┌─────────────────────────────┐
│ Src: 192.168.1.10 │
│ Dst: 203.0.113.50 │
│ Flags: DF=1 (Don't Fragment)│
│ Length: 1500 bytes │
└─────────────────────────────┘
Schritt 2: Router R1 empfängt Paket
- Ausgangsschnittstellen-MTU = 1000 Bytes
- Paketgröße = 1500 Bytes
- DF-Flag ist gesetzt → Kann nicht fragmentieren
Schritt 3: Router R1 sendet ICMP Destination Unreachable
┌─────────────────────────────┐
│ ICMP Type: 3 │
│ Code: 4 (Fragmentation │
│ needed but DF set) │
│ Next-Hop MTU: 1000 │
└─────────────────────────────┘
Schritt 4: Host A erhält ICMP
- Implementiert Path MTU Discovery
- Reduziert Paketgröße auf 1000 Bytes
- Sendet Daten erneut
Dies ist ein kritischer Mechanismus für Path MTU Discovery (PMTUD) [RFC 1191].
Verarbeitungsregeln
Für ICMP-Sender
-
Bestimmen, ob ICMP gesendet werden sollte:
- Ist dies eine Fehlerbedingung?
- Betrifft dies eine ICMP-Nachricht? (Wenn ja, nicht senden)
- Betrifft dies Fragment Null? (Wenn nicht Fragment Null, nicht senden)
-
ICMP-Nachricht konstruieren:
- Geeigneten Type und Code setzen
- Checksum berechnen
- Ursprünglichen IP-Header + 64 Bits der ursprünglichen Daten einschließen
-
Über IP senden:
- IP-Protokoll 1 (ICMP) verwenden
- Geeignete IP-Header-Felder setzen
Für ICMP-Empfänger
-
Nachricht validieren:
- Checksum überprüfen
- Type- und Code-Werte prüfen
-
Nach Type verarbeiten:
- Fehlernachrichten: An höheres Protokoll melden
- Anfragenachrichten: Antwort generieren
- Informationsnachrichten: Entsprechend verarbeiten
-
An geeigneten Handler übergeben:
- Basierend auf ursprünglichen Datagramminformationen demultiplexen
- Betroffenes Protokoll oder Anwendung benachrichtigen
Historischer Kontext: ICMP wurde in RFC 792 (September 1981) als Teil der ursprünglichen Internet-Protokollsuite definiert. Es bleibt eine grundlegende Komponente des IP-Netzwerks, obwohl einige Nachrichtentypen veraltet sind und im Laufe der Jahre neue hinzugefügt wurden.