3. INTERNET-SCHICHT-PROTOKOLLE (INTERNET LAYER PROTOCOLS)
3.1 EINFÜHRUNG (INTRODUCTION)
Das Internetprotokoll (Internet Protocol, IP) ist das zentrale Protokoll der Internet-Protokollsuite. Alle Internet-Transportprotokolle verwenden IP, um Daten vom Quell-Host zum Ziel-Host zu transportieren. IP ist ein Datagramm- oder verbindungsloses Internetwork-Dienst und enthält Bestimmungen für Adressierung, Diensttyp-Spezifikation, Fragmentierung und Reassemblierung sowie Sicherheitsinformationen.
Die Internet-Schicht umfasst auch das Internet-Kontrollnachrichtenprotokoll (Internet Control Message Protocol, ICMP), das Kontroll- und Berichtsfunktionen bereitstellt, und das Internet-Gruppenverwaltungsprotokoll (Internet Group Management Protocol, IGMP), das für Multicasting verwendet wird.
Alle Internet-Hosts müssen IP und ICMP implementieren (MUST). Hosts, die IP-Multicasting unterstützen, müssen auch IGMP implementieren (MUST).
3.2 PROTOKOLL-DURCHLAUF (PROTOCOL WALK-THROUGH)
3.2.1 Internetprotokoll -- IP (Internet Protocol)
Das Internetprotokoll ist in RFC 791 [IP:1] definiert. Das IP-Header-Format und die Semantik jedes Feldes sind gut definiert und dokumentiert. Es gibt jedoch mehrere Bereiche, die Klarstellungen oder zusätzliche Spezifikationen für Host-Implementierungen erfordern.
3.2.1.1 Versionsnummer (Version Number)
Ein Host muss jedes IP-Datagramm, dessen Versionsnummer nicht 4 ist (die aktuelle Versionsnummer des Internetprotokolls), stillschweigend verwerfen (MUST).
3.2.1.2 Prüfsumme (Checksum)
Ein Host muss die IP-Header-Prüfsumme für jedes empfangene Datagramm überprüfen und jedes Datagramm mit schlechter Prüfsumme stillschweigend verwerfen (MUST).
3.2.1.3 Adressierung (Addressing)
Jedes IP-Datagramm umfasst eine Quell-IP-Adresse und eine Ziel-IP-Adresse. Eine IP-Adresse hat zwei Komponenten: eine Netzwerknummer und eine Hostnummer.
Die Netzwerknummer identifiziert ein physisches Netzwerk, mit dem der Host verbunden ist. Die Hostnummer identifiziert einen bestimmten Host in diesem Netzwerk.
Ein Host muss die folgenden Spezial-Adressen unterstützen (MUST):
- Begrenzter Broadcast (Limited Broadcast): 255.255.255.255
- Gerichteter Broadcast (Directed Broadcast): alle 1 im Host-Teil
- Dieser Host in diesem Netzwerk (This Host on This Network): 0.0.0.0
- Host in diesem Netzwerk (Host on This Network):
{netzwerk, host} - Loopback: 127.x.x.x
3.2.1.4 Fragmentierung und Reassemblierung (Fragmentation and Reassembly)
Jedes Internet-Modul muss in der Lage sein, ein 68-Byte-Datagramm ohne Fragmentierung weiterzuleiten (MUST). Ein Host muss in der Lage sein, fragmentierte Datagramme von mindestens 576 Bytes zu reassemblieren (MUST).
3.2.1.5 Identifikation (Identification)
Wenn eine identische Kopie eines Datagramms gesendet wird, muss das IP-Identifikationsfeld dasselbe wie beim ursprünglichen Datagramm sein (MUST).
Wenn ein Host ein IP-Datagramm fragmentiert, muss er das Identifikationsfeld vom ursprünglichen IP-Header in alle Fragment-Header kopieren (MUST).
3.2.1.6 Diensttyp (Type-of-Service)
Das Diensttyp-Byte (Type-of-Service, TOS) im IP-Header wird verwendet, um die gewünschte Dienstqualität für ein bestimmtes Datagramm anzuzeigen. Der TOS-Wert spezifiziert die relative Wichtigkeit von Durchsatz, Verzögerung, Zuverlässigkeit und Kosten.
Eine Anwendung muss in der Lage sein, einen TOS-Wert für die von ihr gesendeten Pakete zu spezifizieren (MUST). Die IP-Schicht muss den TOS-Wert unverändert an die Verbindungsschicht übergeben (MUST).
3.2.1.7 Lebensdauer (Time-to-Live)
Das Lebensdauer-Feld (Time-to-Live, TTL) wird vom Sender definiert und von jedem Router, der das Datagramm weiterleitet, dekrementiert. Wenn der TTL Null erreicht, wird das Datagramm verworfen.
Ein Host darf kein Datagramm mit einem Lebensdauer-Wert (TTL) von Null senden (MUST NOT). Ein Host darf ein Datagramm nicht einfach verwerfen, nur weil es mit TTL kleiner als 2 empfangen wurde (MUST NOT).
3.2.1.8 Optionen (Options)
Mehrere IP-Optionen sind definiert:
- Route aufzeichnen (Record Route): Zeichnet die von einem Datagramm genommene Route auf
- Zeitstempel (Timestamp): Zeichnet Zeitstempel an Routern entlang des Pfades auf
- Quellroute (Source Route): Spezifiziert die Route, die ein Datagramm nehmen soll
- Sicherheit (Security): Bietet Sicherheits- und Handhabungsbeschränkungen
Ein Host muss in der Lage sein, auf alle IP-Optionen zu reagieren, die er empfängt (MUST). Einige Optionen erfordern eine Verarbeitung durch jeden Host, der sie empfängt; andere erfordern eine Verarbeitung nur durch den Ziel-Host.
3.2.2 Internet-Kontrollnachrichtenprotokoll -- ICMP (Internet Control Message Protocol)
ICMP [INTERNET:8] wird verwendet, um Fehler und andere Informationen über die Verarbeitung von IP-Paketen an die Quelle zu melden. ICMP-Nachrichten werden in IP-Datagrammen gesendet.
Jeder Host muss ICMP implementieren (MUST). Eine ICMP-Fehlermeldung darf nicht gesendet werden (MUST NOT) als Ergebnis des Empfangs von:
- Einer ICMP-Fehlermeldung
- Einem Datagramm, das für eine IP-Broadcast- oder IP-Multicast-Adresse bestimmt ist
- Einem Datagramm, das als Verbindungsschicht-Broadcast gesendet wurde
- Einem nicht-initialen Fragment
- Einem Datagramm, dessen Quelladresse ungültig ist
3.2.2.1 Ziel unerreichbar (Destination Unreachable)
Die Nachricht Destination Unreachable wird gesendet, wenn ein Datagramm aus anderen Gründen als Stau nicht an sein Ziel zugestellt werden kann.
Ein Host sollte Destination-Unreachable-Nachrichten mit den folgenden Codes generieren (SHOULD):
- 2 (Protocol Unreachable): Gesendet, wenn das in einem Datagramm angegebene Transportprotokoll nicht unterstützt wird
- 3 (Port Unreachable): Gesendet, wenn das Zieltransportprotokoll das Datagramm nicht demultiplexen kann
3.2.2.2 Umleitung (Redirect)
Eine Redirect-Nachricht wird von einem Router an einen Host gesendet, um ihn über eine bessere Route zu einem bestimmten Ziel zu informieren.
Ein Host muss in der Lage sein, auf Redirect-Nachrichten zu reagieren (MUST). Ein Host muss seine Routing-Tabelle aktualisieren, wenn er einen Redirect empfängt (MUST).
3.2.2.3 Source Quench
Source Quench ist ein Staukontrollmechanismus. Wenn ein Host oder Router ein Datagramm aufgrund eines Pufferüberlaufs verwerfen muss, kann er eine Source-Quench-Nachricht an die Quelle senden (MAY).
Ein Host, der eine Source-Quench-Nachricht empfängt, muss die Rate reduzieren, mit der er Datagramme an das angegebene Ziel sendet (MUST).
3.2.2.4 Zeit überschritten (Time Exceeded)
Eine Time-Exceeded-Nachricht wird von einem Router gesendet, wenn ein Datagramm verworfen wird, weil sein Time-to-Live-Feld Null erreicht hat.
Eine Time-Exceeded-Nachricht wird auch von einem Ziel-Host gesendet, wenn die Fragment-Reassemblierung nicht innerhalb eines Timeouts abgeschlossen werden kann.
3.2.2.5 Parameterproblem (Parameter Problem)
Eine Parameter-Problem-Nachricht zeigt an, dass ein Problem beim Verarbeiten eines IP-Header-Parameters erkannt wurde und das Datagramm verworfen wurde.
3.2.2.6 Echo-Anfrage/Antwort (Echo Request/Reply)
Jeder Host muss eine ICMP-Echo-Server-Funktion implementieren, die Echo-Anfragen empfängt und entsprechende Echo-Antworten sendet (MUST).
Eine ICMP-Echo-Anfrage, die an eine IP-Broadcast- oder IP-Multicast-Adresse gerichtet ist, kann stillschweigend verworfen werden (MAY).
3.2.2.7 Informationsanfrage/Antwort (Information Request/Reply)
Die Information-Request- und Reply-Nachrichten sind veraltet und sollten nicht implementiert werden (SHOULD NOT).
3.2.2.8 Zeitstempel und Zeitstempel-Antwort (Timestamp and Timestamp Reply)
Die Timestamp- und Timestamp-Reply-Nachrichten werden verwendet, um Hin- und Rücklaufzeiten zu messen und Uhren zu synchronisieren.
Ein Host kann ICMP Timestamp implementieren (MAY). Wenn er dies tut, muss er dem für Zeitstempel spezifizierten Format folgen (MUST).
3.2.2.9 Adressmasken-Anfrage/Antwort (Address Mask Request/Reply)
Die Address-Mask-Request- und Reply-Nachrichten ermöglichen es einem Host, die Subnetzmaske für ein lokales Netzwerk zu erhalten.
Ein Host muss ICMP-Subnetzmasken-Nachrichten unterstützen, wenn er Subnetting unterstützt (MUST). Wenn er dies tut, muss er auf Address-Mask-Anfragen antworten (MUST) und sollte eine Konfigurationsoption haben, um Address-Mask-Anfragen während des Starts zu senden (SHOULD).
3.2.3 Internet-Gruppenverwaltungsprotokoll -- IGMP (Internet Group Management Protocol)
IGMP [INTERNET:4] wird von Hosts und benachbarten Routern verwendet, um Multicast-Gruppenmitgliedschaften zu etablieren.
Ein Host muss IGMP implementieren, wenn er IP-Multicasting unterstützt (MUST). Level-2-Konformität (vollständige IGMP-Implementierung) ist erforderlich (REQUIRED).
3.3 SPEZIFISCHE PROBLEME (SPECIFIC ISSUES)
3.3.1 Routing ausgehender Datagramme (Routing Outbound Datagrams)
Um zu entscheiden, ob ein Ziel lokal oder entfernt ist, prüft ein IP-Host, ob die Zieladresse dasselbe Netzwerk-Präfix wie eine der eigenen IP-Adressen des Hosts hat.
3.3.2 Reassemblierung (Reassembly)
Die IP-Reassemblierungsfunktion muss den folgenden Anforderungen entsprechen (MUST):
- Ein Host muss in der Lage sein, fragmentierte Datagramme von mindestens 576 Bytes zu reassemblieren (MUST)
- Das Reassemblierungs-Timeout muss mindestens 60 Sekunden betragen, darf aber 120 Sekunden nicht überschreiten (MUST)
3.3.3 Fragmentierung (Fragmentation)
Ein Host muss lokale IP-Fragmentierung unterstützen (MUST). Bei der Fragmentierung eines Datagramms muss ein Host bestimmte IP-Header-Felder in jeden Fragment-Header kopieren (MUST).
3.3.4 Lokales Multihoming (Local Multihoming)
Ein multihomed Host hat mehrere IP-Adressen, die sich auf denselben Netzwerken oder auf verschiedenen Netzwerken befinden können. Ein Host mit mehreren IP-Adressen muss in der Lage sein, Datagramme mit einer seiner IP-Adressen zu senden und zu empfangen (MUST).
3.3.5 Quellrouten-Weiterleitung (Source Route Forwarding)
Ein Host muss das Ursprung und die Verarbeitung von Quellrouten unterstützen (MUST).
3.3.6 Broadcasts
Ein Host muss den Empfang und die Verarbeitung von Broadcast-Datagrammen unterstützen (MUST). Wenn ein Host ein Broadcast-Datagramm empfängt, muss er eine Kopie an jedes Transportprotokoll übergeben (MUST).
3.3.7 IP-Multicasting
Ein Host sollte IP-Multicasting unterstützen (SHOULD). Hosts, die IP-Multicasting unterstützen, müssen den Anforderungen in [INTERNET:4] entsprechen (MUST).
3.3.8 Fehlermeldung (Error Reporting)
IP-Schichtfehler sollten der Transportschicht oder Anwendung entsprechend gemeldet werden (SHOULD).
3.4 INTERNET-/TRANSPORTSCHICHT-SCHNITTSTELLE (INTERNET/TRANSPORT LAYER INTERFACE)
Die Internet-Schicht bietet Dienste für die Transportschicht-Protokolle (TCP und UDP). Die Schnittstelle umfasst die folgenden Operationen:
- Senden (Send): Ein Paket von der Transportschicht akzeptieren und senden
- Empfangen (Receive): Ein eingehendes Paket akzeptieren und es an die Transportschicht liefern
- Fehlerbericht (Report Error): Einen Fehler an die Transportschicht melden
3.5 ZUSAMMENFASSUNG DER INTERNET-SCHICHT-ANFORDERUNGEN (INTERNET LAYER REQUIREMENTS SUMMARY)
| Funktion | Abschnitt | Must | Should | May | Not |
|---|---|---|---|---|---|
| IP-Prüfsumme überprüfen, schlechte Datagramme verwerfen | 3.2.1.2 | x | |||
| Datagramme mit Version != 4 verwerfen | 3.2.1.1 | x | |||
| Datagramme von mindestens 576 Bytes reassemblieren | 3.2.1.4 | x | |||
| Subnetz-Adressierung unterstützen | 3.3.4.2 | x | |||
| ICMP implementieren | 3.2.2 | x | |||
| ICMP Destination Unreachable senden | 3.2.2.1 | x | |||
| ICMP Echo-Server implementieren | 3.2.2.6 | x | |||
| IP-Multicasting unterstützen | 3.3.7 | x | |||
| Dead-Gateway-Erkennung | 3.3.1.4 | x | |||
| Record-Route-Option verarbeiten | 3.2.1.8 | x | |||
| Source-Route-Option verarbeiten | 3.3.5 | x |