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 [IP: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 [IP: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)
3.3.1.1 Einführung (Introduction)
Wenn ein Host ein IP-Datagramm sendet, muss er entscheiden, welche physische Schnittstelle zu verwenden ist und welches Gateway den ersten Hop darstellt (sofern der Zielhost nicht im verbundenen Netz liegt). Dieser Entscheidungsprozess wird „Routing“ genannt.
Ein Host MUSS (MUST) die Adressmaske verwenden, wenn er zwischen „lokal“ (verbundenes Netz) und „entfernt“ (nicht verbunden) entscheidet.
Ein Host MUSS (MUST) in der Lage sein, in einem verbundenen Netz ohne konfiguriertes Gateway normal zu funktionieren.
DISKUSSION (DISCUSSION):
Das Routing ist einer der komplexesten und sich noch entwickelnden Bereiche der Internet-Architektur. Hosts sollten nicht das vollständige Gateway-Routing-Protokoll implementieren, sondern sich auf einfache Mechanismen verlassen: Standard-Gateway, Redirect-Nachrichten und Routing-Cache.
3.3.1.2 Routing-Cache und statische Routen (Route Cache and Static Routes)
Ein Host MUSS (MUST) einen „Routing-Cache“ (route cache) pflegen, der das Gateway des nächsten Hops für jedes Zielnetz/-host festhält. Ein Host MUSS (MUST) das Standard-Gateway verwenden, wenn kein Eintrag im Cache gefunden wird. Ein Host MUSS (MUST) mehrere Standard-Gateways unterstützen.
Ein Host KANN (MAY) eine Tabelle statischer Routen (static routes) bereitstellen; diese statischen Routen KÖNNEN (MAY) als durch Redirects überschreibbar oder nicht markiert werden.
DISKUSSION (DISCUSSION):
Die Redirect-Nachricht wird von einem Gateway gesendet, um einen Host über ein besseres Gateway für den ersten Hop zu einer bestimmten Zieladresse zu informieren. Wenn ein Host eine Redirect-Nachricht empfängt, MUSS (MUST) er seinen Routing-Cache aktualisieren. Ein Host MUSS (MUST) Host- und Net-Redirects gleichwertig behandeln.
Eine ungültige Redirect-Nachricht (z. B. die auf ein Gateway zeigt, das nicht in einem direkt verbundenen Netz liegt) SOLLTE (SHOULD) ignoriert werden.
3.3.1.3 Schlüsselung des Routing-Caches (Route Cache Keying)
Der Routing-Cache SOLLTE (SHOULD) nach der Ziel-Host-Adresse (statt der Netzadresse) indiziert werden und SOLLTE (SHOULD) den TOS-Wert im Cache enthalten.
DISKUSSION (DISCUSSION):
Die Indizierung nach Host vermeidet Probleme, bei denen verschiedene Hosts im selben Netz unterschiedliche Pfade nehmen, und ermöglicht eine feinere Steuerung pro Zielhost.
3.3.1.4 Erkennung ausgefallener Gateways (Dead Gateway Detection)
Ein Host MUSS (MUST) in der Lage sein, den Ausfall des Gateways des nächsten Hops zu erkennen. Ein Host DARF NICHT (MUST NOT) annehmen, dass eine Route für immer gültig bleibt.
DISKUSSION (DISCUSSION):
Mehrere Techniken können ein ausgefallenes Gateway erkennen. Eine Methode besteht darin, das Gateway kontinuierlich zu pingen, was jedoch zu viel Verkehr erzeugt; man SOLLTE (SHOULD) daher nur pingen, wenn tatsächlich Daten zu senden sind, und SOLLTE (SHOULD) dies nur bei Fehlen einer positiven Anzeige tun. Die obere und untere Schicht können Erfolgs-/Fehlerhinweise (advice) liefern.
Eine weitere verbreitete Technik (passives Abhören der Gateway-Routing-Protokolle) wird nicht empfohlen (siehe unten).
3.3.1.5 Auswahl eines neuen Gateways (New Gateway Selection)
Wenn das ausgefallene Gateway nicht das aktuelle Standard-Gateway ist, kann die IP-Schicht sofort auf ein anderes Standard-Gateway umschalten. Ist das ausgefallene Gateway das aktuelle Standard-Gateway, MUSS (MUST) die IP-Schicht ein anderes auswählen (sofern mehrere bekannt sind), sowohl für die ausgefallene Route als auch zum Aufbau neuer Routen.
DISKUSSION (DISCUSSION):
Wenn ein Gateway ausfällt, werden andere Gateways im verbundenen Netz über ein Gateway-zu-Gateway-Routing-Protokoll informiert, aber dies ist nicht sofort der Fall (die Stabilisierungszeit beträgt typischerweise 30 bis 60 Sekunden). Wenn der Host vor der Einigung der Gateways auf ein Ersatz-Gateway umschaltet, leitet das neue Ziel-Gateway die Datagramme wahrscheinlich an das ausgefallene Gateway weiter und sendet einen Redirect dorthin zurück. Dies führt während der Stabilisierung zu einer schnellen Oszillation des Routing-Cache-Inhalts des Hosts. Es wurde vorgeschlagen, die Logik für ausgefallene Gateways mit einer gewissen Hysterese auszustatten, um diese Oszillation zu vermeiden, doch die Erfahrung zeigt, dass sie harmlos ist.
IMPLEMENTIERUNG (IMPLEMENTATION):
Eine Implementierungstechnik zur Auswahl eines neuen Standard-Gateways besteht darin, schlicht die Liste der Standard-Gateways im Round-Robin durchzugehen; eine andere darin, Gateways nach Priorität zu ordnen und Gateways mit höherer Priorität zu „pingen“, wenn sie nicht das aktuelle Standard-Gateway sind.
3.3.1.6 Initialisierung (Initialization)
Folgende Informationen MÜSSEN (MUST) konfigurierbar sein:
(1) IP-Adresse(n) (eine oder mehrere). (2) Adressmaske(n) (eine oder mehrere). (3) Liste der Standard-Gateways, mit Priorität.
Eine Methode zur manuellen Eingabe dieser Konfigurationsdaten MUSS (MUST) bereitgestellt werden. Darüber hinaus können verschiedene Methoden zur dynamischen Ermittlung dieser Informationen verwendet werden (siehe Kapitel „Host Initialization“ in [INTRO:1]).
DISKUSSION (DISCUSSION):
Einige Host-Implementierungen ermitteln vorhandene Gateways, indem sie die Gateway-Protokolle im Broadcast-Netz abhören. Eine Standardmethode zur Ermittlung des Standard-Gateways wird derzeit erarbeitet.
3.3.2 Reassemblierung (Reassembly)
Die IP-Reassemblierungsfunktion MUSS (MUST) folgende Anforderungen erfüllen:
- Ein Host MUSS (MUST) in der Lage sein, fragmentierte Datagramme von mindestens 576 Bytes zu reassemblieren.
- Das Reassemblierungs-Timeout MUSS (MUST) mindestens 60 Sekunden betragen, darf aber 120 Sekunden nicht überschreiten.
- Wenn ein Datagramm wegen Überschreitung des Reassemblierungs-Timeouts verworfen wird, MUSS (MUST) der Host eine ICMP-„Time Exceeded“-Nachricht (Code 1) an die Quelle des Datagramms senden.
- Der Host MUSS (MUST) der Transportschicht einen Mechanismus bereitstellen, um die maximale Größe der empfangbaren Transportnachricht (MMS_R) zu erfahren; diese Information wird normalerweise von der effektiven maximalen Datagrammgröße (EMTU_R) abgeleitet. Der Wert EMTU_R SOLLTE (SHOULD) vom Betreiber konfigurierbar sein oder SOLLTE (SHOULD) als unbegrenzt betrachtet werden.
DISKUSSION (DISCUSSION):
Der Wert von 576 Bytes für die garantierte Mindest-Datagrammgröße hängt historisch mit den Grenzen der anfänglichen LAN-Technologie zusammen; er sollte für die meisten Protokollköpfe über IP ausreichen. Beachten Sie, dass die Anforderung, mindestens 576 Bytes zu reassemblieren, von der Anforderung zu unterscheiden ist, Datagramme dieser Größe zu übertragen.
3.3.3 Fragmentierung (Fragmentation)
Ein Host MUSS (MUST) lokale IP-Fragmentierung unterstützen. Beim Fragmentieren eines Datagramms MUSS (MUST) ein Host die entsprechenden IP-Header-Felder in jeden Fragment-Header kopieren. Der Host MUSS (MUST) der Transportschicht die maximale Größe der sendbaren Transportnachricht (MMS_S) bereitstellen. Wenn der Host seine ausgehenden Datagramme nicht fragmentiert, DARF (MUST NOT) er keine Datagramme senden, die größer als das der Transportschicht gemeldete MMS_S sind.
DISKUSSION (DISCUSSION):
Die Fragmentierung ist wichtig für die Interoperabilität. Sie bringt jedoch Overhead und geringere Zuverlässigkeit mit sich (geht ein Fragment verloren, muss das gesamte Datagramm erneut übertragen werden). Sobald möglich, SOLLTEN (SHOULD) Hosts die Fragmentierung vermeiden, indem sie das korrekte MMS_S für das Ziel verwenden.
Ein Host SOLLTE (SHOULD) an Ziele außerhalb des Netzes (off-net) Datagramme von höchstens 576 Bytes senden, sofern keine andere MTU-Erkennung vorliegt.
Ein Konfigurationsflag „All-Subnets-MTU“ KANN (MAY) bereitgestellt werden.
3.3.4 Lokales Multihoming (Local Multihoming)
Ein multihomed Host besitzt mehrere IP-Adressen, die im selben oder in verschiedenen Netzen liegen können. Ein Host mit mehreren IP-Adressen MUSS (MUST) in der Lage sein, Datagramme mit jeder seiner IP-Adressen zu senden und zu empfangen.
Ein multihomed Host MUSS (MUST) in der Lage sein, auf ein eingehendes Datagramm mit derselben Adresse zu antworten wie die spezifische Zieladresse (specific-destination) des ursprünglichen Datagramms. Der Host MUSS (MUST) einer Anwendung erlauben, die lokale Quell-IP-Adresse für die von ihr gesendeten Datagramme zu wählen.
DISKUSSION (DISCUSSION):
Multihoming ist komplex. Wenn ein Datagramm auf einer Schnittstelle eingeht, die nicht zur Zieladresse passt, SOLLTE (SHOULD) der Host das Datagramm stillschweigend verwerfen, es sei denn, es handelt sich um eine gültige Broadcast- oder Multicast-Adresse auf dieser Schnittstelle. Umgekehrt SOLLTE (SHOULD) der Host kein Datagramm über eine „falsche“ Schnittstelle senden, die zur gewählten Quelladresse gehört, sofern er nicht dafür konfiguriert ist.
3.3.5 Quellrouten-Weiterleitung (Source Route Forwarding)
Unter den folgenden Einschränkungen KANN (MAY) ein Host als Zwischen-Hop in einer Quellroute auftreten, indem er ein Quellrouten-Datagramm an den angegebenen nächsten Hop weiterleitet.
Beim Ausführen dieser gateway-artigen Funktion MUSS (MUST) ein Host alle entsprechenden Regeln für die Weiterleitung von Quellrouten-Datagrammen durch ein Gateway beachten [INTRO:2]. Dies umfasst Folgendes (diese speziellen Klauseln ersetzen die entsprechenden Host-Klauseln weiter oben in diesem Dokument):
(A) TTL (siehe Abschnitt 3.2.1.7)
Das TTL-Feld **MUSS (MUST)** wie in [INTRO:2] für Gateways vorgegeben dekrementiert werden, wobei das Datagramm dadurch verworfen werden kann.
(B) ICMP Destination Unreachable (siehe Abschnitt 3.2.2.1)
Der Host **MUSS (MUST)** in der Lage sein, „Destination Unreachable“-Nachrichten mit folgenden Codes zu erzeugen:
4 (Fragmentation Needed but DF Set — Fragmentierung nötig, aber DF gesetzt) — wenn ein Quellrouten-Datagramm nicht fragmentiert werden kann, um in das Zielnetz zu passen;
5 (Source Route Failed — Quellroute fehlgeschlagen) — wenn ein Quellrouten-Datagramm nicht weitergeleitet werden kann, z. B. wegen eines Routing-Problems oder weil der nächste Hop einer strengen Quellroute nicht im verbundenen Netz liegt.
(C) IP-Quelladresse (siehe Abschnitt 3.2.1.3)
Das weitergeleitete Quellrouten-Datagramm **KANN (MAY)** (und wird dies in der Regel) eine Quelladresse besitzen, die nicht eine der IP-Adressen des weiterleitenden Hosts ist.
(D) Record-Route-Option (siehe Abschnitt 3.2.1.8d)
Ein Host, der ein Quellrouten-Datagramm mit einer Record-Route-Option weiterleitet, **MUSS (MUST)** diese Option aktualisieren (sofern noch Platz vorhanden ist).
(E) Timestamp-Option (siehe Abschnitt 3.2.1.8e)
Ein Host, der ein Quellrouten-Datagramm mit einer Timestamp-Option weiterleitet, **MUSS (MUST)** den aktuellen Zeitstempel gemäß den Regeln dieser Option hinzufügen.
Um die Einschränkungen zu definieren, unter denen ein Host Quellrouten-Datagramme weiterleitet, verwenden wir die Begriffe „lokales Quellrouting (local source-routing)“ für den Fall, dass der nächste Hop über dieselbe physische Schnittstelle erreicht wird, über die das Datagramm einging; andernfalls handelt es sich um „nicht-lokales Quellrouting (non-local source-routing)“.
- Ein Host darf lokales Quellrouting uneingeschränkt ausführen.
- Ein Host, der nicht-lokales Quellrouting unterstützt, MUSS (MUST) einen konfigurierbaren Schalter zum Deaktivieren der Weiterleitung besitzen, und dieser Schalter MUSS (MUST) standardmäßig deaktiviert sein.
- Ein Host MUSS (MUST) alle Gateway-Anforderungen der konfigurierbaren Richtlinienfilter aus [INTRO:2] erfüllen, die die nicht-lokale Weiterleitung einschränken.
Wenn ein Host ein unvollständiges Quellrouten-Datagramm empfängt, es aber aus irgendeinem Grund nicht weiterleitet, SOLLTE (SHOULD) der Host eine ICMP-„Destination Unreachable (Code 5, Source Route Failed)“-Nachricht zurücksenden, sofern das Datagramm selbst keine ICMP-Fehlernachricht ist.
3.3.6 Broadcasts
Abschnitt 3.2.1.3 definiert vier Standardformen von IP-Broadcast-Adressen:
Eingeschränkter Broadcast (Limited Broadcast): {-1, -1}
Gerichteter Broadcast (Directed Broadcast): {
Subnetz-gerichteter Broadcast (Subnet Directed Broadcast): {
Alle-Subnetze-gerichteter Broadcast (All-Subnets Directed Broadcast): {
Ein Host MUSS (MUST) jede der obigen Formen im Zieladressfeld eines eingehenden Datagramms erkennen.
Es gibt eine Klasse von Hosts*, die nicht standardmäßige Broadcast-Adressformen verwenden, bei denen -1 durch 0 ersetzt wird. Alle Hosts SOLLTEN (SHOULD) jede dieser nicht standardmäßigen Broadcast-Adressen als Zieladresse eines eingehenden Datagramms erkennen und akzeptieren. Ein Host KANN (MAY) für jede physische Schnittstelle optional eine Konfigurationsoption bereitstellen, um die 0- oder -1-Form der Broadcast-Adresse zu wählen, diese Option SOLLTE (SHOULD) jedoch standardmäßig die Standardform (-1) verwenden.
*Unix 4.2BSD und dessen Derivate, mit Ausnahme von 4.3BSD.
Wenn ein Host ein Datagramm an eine Link-Layer-Broadcast-Adresse sendet, MUSS (MUST) die IP-Zieladresse eine gültige IP-Broadcast- oder IP-Multicast-Adresse sein.
Ein Host SOLLTE (SHOULD) Datagramme stillschweigend verwerfen, die über einen Link-Layer-Broadcast (siehe Abschnitt 2.4) empfangen wurden, aber keine IP-Multicast- oder Broadcast-Zieladresse angeben.
Ein Host SOLLTE (SHOULD) die eingeschränkte Broadcast-Adresse für Broadcasts im verbundenen Netz verwenden.
DISKUSSION (DISCUSSION):
Die Verwendung der eingeschränkten Broadcast-Adresse anstelle der gerichteten Broadcast-Adresse kann die Robustheit des Systems erhöhen. Probleme entstehen oft durch Maschinen, die die große Vielfalt der Broadcast-Adressen (siehe Abschnitt 3.2.1.3) nicht verstehen, oder die eine abweichende Meinung darüber haben, welche Broadcast-Adressen verwendet werden. Ein typisches Beispiel für letzteres ist eine Maschine, die Subnetting nicht versteht, aber mit einem subnetzierten Netz verbunden ist. Das Senden eines Subnetz-Broadcasts für das verbundene Netz verwirrt diese Maschinen, die ihn als an einen anderen Host gerichtete Nachricht ansehen.
Die Frage, ob an die eingeschränkte Broadcast-Adresse gerichtete Datagramme von allen Schnittstellen eines multihomed Hosts gesendet werden sollen, wurde diskutiert. Diese Spezifikation nimmt dazu keine Stellung.
3.3.7 IP-Multicasting
Ein Host SOLLTE (SHOULD) das lokale IP-Multicasting auf allen verbundenen Netzen unterstützen, für die eine Abbildung von IP-Adressen der Klasse D auf Link-Layer-Adressen definiert ist (siehe unten). Die Unterstützung des lokalen IP-Multicastings umfasst das Senden von Multicast-Datagrammen, das Beitreten zu Multicast-Gruppen und den Empfang von Multicast-Datagrammen sowie das Verlassen von Multicast-Gruppen. Dies bedeutet die Unterstützung des gesamten [IP:4] (mit Ausnahme des IGMP-Protokolls selbst, das OPTIONAL (OPTIONAL) ist).
DISKUSSION (DISCUSSION):
IGMP liefert die für Multicast-Routing fähigen Gateways benötigten Informationen, um IP-Multicasting über mehrere Netze zu unterstützen. Derzeit befinden sich Multicast-Routing-Gateways noch im experimentellen Stadium und sind nicht weit verbreitet. Für Hosts, die nicht mit einem Netz verbunden sind, das Multicast-Routing-Gateways besitzt, oder die keine aus anderen Netzen stammenden Multicast-Datagramme empfangen müssen, ist IGMP nutzlos und daher vorerst optional. Der übrige Teil von [IP:4] wird jedoch derzeit empfohlen, um auf IP-Ebene Zugriff auf die lokale Netz-Multicast-Adressierung als wünschenswerte Alternative zur lokalen Broadcast-Adressierung bereitzustellen. Es wird erwartet, dass IGMP in Zukunft, wenn Multicast-Routing-Gateways verbreiteter werden, empfohlen wird.
Wenn IGMP nicht implementiert ist, SOLLTE (SHOULD) der Host dennoch bei der Initialisierung der IP-Schicht der „all-hosts“-Gruppe (224.0.0.1) beitreten und diese Mitgliedschaft aufrechterhalten, solange die IP-Schicht aktiv ist.
DISKUSSION (DISCUSSION):
Der Beitritt zur „all-hosts“-Gruppe unterstützt die strikt lokale Verwendung von Multicasting, beispielsweise Gateway-Erkennungsprotokolle, selbst ohne IGMP-Implementierung.
Die Abbildung von IP-Adressen der Klasse D auf lokale Adressen ist derzeit für folgende Netztypen festgelegt:
-
Ethernet/IEEE 802.3, wie in [IP:4] definiert.
-
Alle Netze, die Broadcasts, aber kein Multicast-Adressing unterstützen: Alle IP-Adressen der Klasse D werden auf die lokale Broadcast-Adresse abgebildet.
-
Alle Arten von Punkt-zu-Punkt-Verbindungen (z. B. SLIP- oder HDLC-Leitungen): Keine Abbildung nötig. Alle IP-Multicast-Datagramme werden unverändert im lokalen Frame gesendet.
Abbildungen für andere Netztypen werden künftig festgelegt.
Ein Host SOLLTE (SHOULD) eine Möglichkeit bereitstellen, mit der höhere Protokolle oder Anwendungen feststellen können, welche seiner verbundenen Netze IP-Multicast-Adressierung unterstützen.
3.3.8 Fehlermeldung (Error Reporting)
Soweit möglich, MUSS (MUST) ein Host bei erkannter Fehlersituation ein ICMP-Fehlerdatagramm zurücksenden, außer in den Fällen, in denen das Zurücksenden von ICMP-Fehlernachrichten ausdrücklich untersagt ist.
DISKUSSION (DISCUSSION):
Ein im Datagramm-Netz häufiges Phänomen ist die „Schwarzes-Loch-Krankheit (black hole disease)“: Datagramme werden gesendet, aber es kommt nichts zurück. Ohne Fehlermeldung kann der Benutzer nur schwer erkennen, wo das Problem liegt.
3.4 INTERNET-/TRANSPORTSCHICHT-SCHNITTSTELLE (INTERNET/TRANSPORT LAYER INTERFACE)
Die Schnittstelle zwischen Internet-Schicht und Transportschicht MUSS (MUST) vollen Zugriff auf alle Mechanismen der Internet-Schicht bieten, einschließlich Optionen, Type-of-Service und Time-to-Live. Die Transportschicht MUSS (MUST) einen Mechanismus besitzen, um diese Schnittstellenparameter zu setzen, oder einen Pfad zu ihrer transparenten Weitergabe aus der Anwendungsschicht, oder beides.
DISKUSSION (DISCUSSION):
Anwendungen wird nahegelegt, diese Mechanismen dort zu nutzen, wo sie anwendbar sind, selbst wenn sie im heutigen Internet noch nicht wirksam sind (z. B. TOS). Dies ermöglicht ihnen, sofort verfügbar zu sein, wenn sie wirksam werden, ohne dass Host-Software umfassend umgestaltet werden muss.
Wir beschreiben nun die konzeptionelle Schnittstelle zwischen Transportschicht und IP-Schicht als eine Reihe von Prozeduraufrufen. Dies ist eine Erweiterung der Informationen in Abschnitt 3.3 von RFC-791 [IP:1].
-
Datagramm senden (Send Datagram)
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )
Die Parameter sind in RFC-791 definiert. Die Übergabe des Id-Parameters ist optional; siehe Abschnitt 3.2.1.5.
-
Datagramm empfangen (Receive Datagram)
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
Alle Parameter sind in RFC-791 definiert, mit Ausnahme von:
SpecDest = die spezifische Zieladresse des Datagramms (definiert in Abschnitt 3.2.1.3)
Der Parameter result dst enthält die Zieladresse des Datagramms. Da diese eine Broadcast- oder Multicast-Adresse sein kann, MUSS (MUST) der SpecDest-Parameter übergeben werden (in RFC-791 nicht gezeigt). Der Parameter opt enthält alle im Datagramm empfangenen IP-Optionen; diese MÜSSEN (MUST) ebenfalls an die Transportschicht übergeben werden.
-
Quelladresse wählen (Select Source Address)
GET_SRCADDR(remote, TOS) -> local
remote = entfernte IP-Adresse TOS = Type-of-Service local = lokale IP-Adresse
Siehe Abschnitt 3.3.4.3.
-
Maximale Datagrammgrößen ermitteln (Find Maximum Datagram Sizes)
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = maximale empfangbare Transportnachrichtengröße. MMS_S = maximale sendbare Transportnachrichtengröße. (local, remote, TOS wie oben definiert)
Siehe Abschnitte 3.3.2 und 3.3.3.
-
Hinweis bei Zustellungserfolg (Advice on Delivery Success)
ADVISE_DELIVPROB(sense, local, remote, TOS)
Hier ist der Parameter sense ein 1-Bit-Flag, das angibt, ob ein positiver oder negativer Hinweis gegeben wird; siehe Diskussion in Abschnitt 3.3.1.4. Die übrigen Parameter sind weiter oben definiert.
-
ICMP-Nachricht senden (Send ICMP Message)
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result
(Parameter in RFC-791 definiert).
Die Übergabe des Id-Parameters ist optional; siehe Abschnitt 3.2.1.5. Die Transportschicht MUSS (MUST) in der Lage sein, bestimmte ICMP-Nachrichten zu senden: Port Unreachable oder jede Anfragetyp-Nachricht. Diese Funktion kann selbstverständlich als Sonderfall des SEND()-Aufrufs betrachtet werden; wir beschreiben sie der Klarheit halber getrennt.
-
ICMP-Nachricht empfangen (Receive ICMP Message)
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(Parameter in RFC-791 definiert).
Die IP-Schicht MUSS (MUST) bestimmte ICMP-Nachrichten an die entsprechenden Transportschicht-Routinen weitergeben. Auch diese Funktion kann als Sonderfall des RECV()-Aufrufs betrachtet werden; wir beschreiben sie der Klarheit halber getrennt.
Bei ICMP-Fehlernachrichten MÜSSEN (MUST) die nach oben übergebenen Daten den ursprünglichen Internet-Header plus alle Bytes der ursprünglichen Nachricht enthalten, die in der ICMP-Nachricht enthalten sind. Die Transportschicht wird diese Daten nutzen, um Verbindungsstatusinformationen (falls vorhanden) zu lokalisieren.
Insbesondere SOLLTEN (SHOULD) folgende ICMP-Nachrichten nach oben übergeben werden:
- Destination Unreachable (Ziel nicht erreichbar)
- Source Quench (Quelldrosselung)
- Echo Reply (Echo-Antwort) (an die ICMP-Benutzerschnittstelle, sofern die Echo-Anfrage nicht aus der IP-Schicht stammt)
- Timestamp Reply (Zeitstempel-Antwort) (an die ICMP-Benutzerschnittstelle)
- Time Exceeded (Zeit überschritten)
DISKUSSION (DISCUSSION):
Künftig können dieser Schnittstelle Ergänzungen hinzugefügt werden, um Pfaddaten zwischen IP-Schicht und Transportschicht zu übergeben (siehe Abschnitt 3.3.1.3).
3.5 ZUSAMMENFASSUNG DER INTERNET-SCHICHT-ANFORDERUNGEN (INTERNET LAYER REQUIREMENTS SUMMARY)
| Funktion | Abschnitt | Must | Should | May | Should Not | Must Not |
|---|---|---|---|---|---|---|
| IP und ICMP implementieren (Implement IP and ICMP) | 3.1 | x | ||||
| Remote-Multihoming in der Anwendungsschicht behandeln (Handle remote multihoming in application layer) | 3.1 | x | ||||
| Lokales Multihoming unterstützen (Support local multihoming) | 3.1 | x | ||||
| Gateway-Spezifikationen erfüllen, wenn Datagramme weitergeleitet werden (Meet gateway specs if forward datagrams) | 3.1 | x | ||||
| Konfigurationsschalter für eingebettetes Gateway (Configuration switch for embedded gateway) | 3.1 | x | 1 | |||
| - Konfigurationsschalter standardmäßig Nicht-Gateway (- Config switch default to non-gateway) | 3.1 | x | 1 | |||
| - Auto-Konfiguration nach Anzahl der Schnittstellen (- Auto-config based on number of interfaces) | 3.1 | x | ||||
| Verworfene Datagramme protokollieren können (Able to log discarded datagrams) | 3.1 | x | ||||
| - In Zähler erfassen (- Record in counter) | 3.1 | x | ||||
| Version != 4 stillschweigend verwerfen (Silently discard Version != 4) | 3.2.1.1 | x | ||||
| IP-Prüfsumme prüfen, schlechte Datagramme still verwerfen (Verify IP checksum, silently discard bad dgram) | 3.2.1.2 | x | ||||
| Adressierung (Addressing): | ||||||
| - Subnetz-Adressierung (RFC-950) (- Subnet addressing (RFC-950)) | 3.2.1.3 | x | ||||
| - Quelladresse muss eigene IP-Adresse des Hosts sein (- Src address must be host's own IP address) | 3.2.1.3 | x | ||||
| - Datagramm mit falscher Zieladresse still verwerfen (- Silently discard datagram with bad dest addr) | 3.2.1.3 | x | ||||
| - Datagramm mit falscher Quelladresse still verwerfen (- Silently discard datagram with bad src addr) | 3.2.1.3 | x | ||||
| Reassemblierung unterstützen (Support reassembly) | 3.2.1.4 | x | ||||
| Gleiches Id-Feld in identischem Datagramm beibehalten (Retain same Id field in identical datagram) | 3.2.1.5 | x | ||||
| TOS: | ||||||
| - Transportschicht darf TOS setzen (- Allow transport layer to set TOS) | 3.2.1.6 | x | ||||
| - Empfangenen TOS an Transportschicht weitergeben (- Pass received TOS up to transport layer) | 3.2.1.6 | x | ||||
| - RFC-795 Link-Layer-Abbildungen für TOS nutzen (- Use RFC-795 link-layer mappings for TOS) | 3.2.1.6 | x | ||||
| TTL: | ||||||
| - Paket mit TTL von 0 senden (- Send packet with TTL of 0) | 3.2.1.7 | x | ||||
| - Empfangene Pakete mit TTL < 2 verwerfen (- Discard received packets with TTL < 2) | 3.2.1.7 | x | ||||
| - Transportschicht darf TTL setzen (- Allow transport layer to set TTL) | 3.2.1.7 | x | ||||
| - Fester TTL konfigurierbar (- Fixed TTL is configurable) | 3.2.1.7 | x | ||||
| IP-Optionen (IP Options): | ||||||
| - Transportschicht darf IP-Optionen senden (- Allow transport layer to send IP options) | 3.2.1.8 | x | ||||
| - Alle empfangenen IP-Optionen an höhere Schicht weitergeben (- Pass all IP options rcvd to higher layer) | 3.2.1.8 | x | ||||
| - IP-Schicht ignoriert unbekannte Optionen still (- IP layer silently ignore unknown options) | 3.2.1.8 | x | ||||
| - Security-Option (- Security option) | 3.2.1.8a | x | ||||
| - Stream Identifier Option senden (- Send Stream Identifier option) | 3.2.1.8b | x | ||||
| - Stream Identifer Option still ignorieren (- Silently ignore Stream Identifer option) | 3.2.1.8b | x | ||||
| - Record Route Option (- Record Route option) | 3.2.1.8d | x | ||||
| - Timestamp Option (- Timestamp option) | 3.2.1.8e | x | ||||
| Source-Route-Option (Source Route Option): | ||||||
| - Source-Route-Optionen erzeugen und beenden (- Originate & terminate Source Route options) | 3.2.1.8c | x | ||||
| - Datagramm mit fertiger SR an TL weitergeben (- Datagram with completed SR passed up to TL) | 3.2.1.8c | x | ||||
| - Korrekte (nicht-redundante) Rückroute aufbauen (- Build correct (non-redundant) return route) | 3.2.1.8c | x | ||||
| - Mehrere SR-Optionen in einem Header senden (- Send multiple SR options in one header) | 3.2.1.8c | x | ||||
| ICMP: | ||||||
| - ICMP-Nachricht mit unbekanntem Typ still verwerfen (- Silently discard ICMP msg with unknown type) | 3.2.2 | x | ||||
| - Mehr als 8 Oktette des Original-Datagramms einbeziehen (- Include more than 8 octets of orig datagram) | 3.2.2 | x | ||||
| - Eingeschlossene Oktette wie empfangen (- Included octets same as received) | 3.2.2 | x | ||||
| - ICMP-Fehler an Transportprotokoll demultiplexen (- Demux ICMP Error to transport protocol) | 3.2.2 | x | ||||
| - ICMP-Fehlernachricht mit TOS=0 senden (- Send ICMP error message with TOS=0) | 3.2.2 | x | ||||
| - ICMP-Fehlernachricht senden für: (- Send ICMP error message for: ) | ||||||
| - ICMP-Fehlernachricht (- ICMP error msg) | 3.2.2 | x | ||||
| - IP-Broadcast oder IP-Multicast (- IP b'cast or IP m'cast) | 3.2.2 | x | ||||
| - Link-Layer-Broadcast (- Link-layer b'cast) | 3.2.2 | x | ||||
| - Nicht-initiales Fragment (- Non-initial fragment) | 3.2.2 | x | ||||
| - Datagramm mit nicht eindeutiger Quelladresse (- Datagram with non-unique src address) | 3.2.2 | x | ||||
| - ICMP-Fehlernachrichten zurückgeben (wenn nicht verboten) (- Return ICMP error msgs (when not prohibited)) | 3.3.8 | x | ||||
| - Destination Unreachable: | ||||||
| Destination Unreachable erzeugen (Code 2/3) (Generate Dest Unreachable (code 2/3)) | 3.2.2.1 | x | ||||
| ICMP Dest Unreachable an höhere Schicht weitergeben (Pass ICMP Dest Unreachable to higher layer) | 3.2.2.1 | x | ||||
| Höhere Schicht reagiert auf Dest Unreach (Higher layer act on Dest Unreach) | 3.2.2.1 | x | ||||
| Dest Unreach nur als Hinweis interpretieren (Interpret Dest Unreach as only hint) | 3.2.2.1 | x | ||||
| - Redirect: | ||||||
| Host sendet Redirect (Host send Redirect) | 3.2.2.2 | x | ||||
| Route-Cache bei Redirect-Empfang aktualisieren (Update route cache when recv Redirect) | 3.2.2.2 | x | ||||
| Sowohl Host- als auch Net-Redirects behandeln (Handle both Host and Net Redirects) | 3.2.2.2 | x | ||||
| Ungültigen Redirect verwerfen (Discard illegal Redirect) | 3.2.2.2 | x | ||||
| - Source Quench: | ||||||
| Source Quench senden bei Pufferüberlauf (Send Source Quench if buffering exceeded) | 3.2.2.3 | x | ||||
| Source Quench an höhere Schicht weitergeben (Pass Source Quench to higher layer) | 3.2.2.3 | x | ||||
| Höhere Schicht reagiert auf Source Quench (Higher layer act on Source Quench) | 3.2.2.3 | x | ||||
| - Time Exceeded: an höhere Schicht weitergeben (Time Exceeded: pass to higher layer) | 3.2.2.4 | x | ||||
| - Parameter Problem: | ||||||
| Parameter-Problem-Nachrichten senden (Send Parameter Problem messages) | 3.2.2.5 | x | ||||
| Parameter Problem an höhere Schicht weitergeben (Pass Parameter Problem to higher layer) | 3.2.2.5 | x | ||||
| Parameter Problem an Benutzer melden (Report Parameter Problem to user) | 3.2.2.5 | x | ||||
| - ICMP Echo Request oder Reply: | ||||||
| Echo-Server und Echo-Client (Echo server and Echo client) | 3.2.2.6 | x | ||||
| Echo-Client (Echo client) | 3.2.2.6 | x | ||||
| Echo-Request an Broadcast-Adresse verwerfen (Discard Echo Request to broadcast address) | 3.2.2.6 | x | ||||
| Echo-Request an Multicast-Adresse verwerfen (Discard Echo Request to multicast address) | 3.2.2.6 | x | ||||
| Spezifische Zieladresse als Echo-Reply-Quelle nutzen (Use specific-dest addr as Echo Reply src) | 3.2.2.6 | x | ||||
| Gleiche Daten in Echo-Reply senden (Send same data in Echo Reply) | 3.2.2.6 | x | ||||
| Echo-Reply an höhere Schicht weitergeben (Pass Echo Reply to higher layer) | 3.2.2.6 | x | ||||
| Record-Route-, Timestamp-Optionen reflektieren (Reflect Record Route, Time Stamp options) | 3.2.2.6 | x | ||||
| Source-Route-Option umkehren und reflektieren (Reverse and reflect Source Route option) | 3.2.2.6 | x | ||||
| - ICMP Address Mask Request und Reply: | ||||||
| Addr-Mask-Quelle konfigurierbar (Addr Mask source configurable) | 3.2.2.9 | x | ||||
| Statische Konfiguration der Adressmaske unterstützen (Support static configuration of addr mask) | 3.2.2.9 | x | ||||
| Adressmaske während des Bootens dynamisch beziehen (Get addr mask dynamically during booting) | 3.2.2.9 | x | ||||
| Adresse über ICMP Addr Mask Request/Reply beziehen (Get addr via ICMP Addr Mask Request/Reply) | 3.2.2.9 | x | ||||
| Addr-Mask-Req erneut senden, falls keine Reply (Retransmit Addr Mask Req if no Reply) | 3.2.2.9 | x | 3 | |||
| Standardmaske annehmen, falls keine Reply (Assume default mask if no Reply) | 3.2.2.9 | x | 3 | |||
| Adressmaske nur aus erster Reply aktualisieren (Update address mask from first Reply only) | 3.2.2.9 | x | 3 | |||
| Plausibilitätsprüfung der Addr-Mask (Reasonableness check on Addr Mask) | 3.2.2.9 | x | ||||
| Nicht autorisierte Addr-Mask-Reply senden (Send unauthorized Addr Mask Reply msgs) | 3.2.2.9 | x | ||||
| Explizit als Agent konfiguriert (Explicitly configured to be agent) | 3.2.2.9 | x | ||||
| Statische Config => Addr-Mask-Authoritative-Flag (Static config=> Addr-Mask-Authoritative flag) | 3.2.2.9 | x | ||||
| Addr-Mask-Reply bei Init als Broadcast (Broadcast Addr Mask Reply when init.) | 3.2.2.9 | x | 3 | |||
| Routing ausgehender Datagramme (ROUTING OUTBOUND DATAGRAMS): | ||||||
| - Adressmaske bei lokal/entfernt-Entscheidung nutzen (Use address mask in local/remote decision) | 3.3.1.1 | x | ||||
| - Ohne Gateways im verbundenen Netz betreiben (Operate with no gateways on conn network) | 3.3.1.1 | x | ||||
| - „Route-Cache“ der Next-Hop-Gateways pflegen (Maintain "route cache" of next-hop gateways) | 3.3.1.2 | x | ||||
| - Host- und Net-Redirect gleich behandeln (Treat Host and Net Redirect the same) | 3.3.1.2 | x | ||||
| - Bei fehlendem Cache-Eintrag Standard-Gateway nutzen (If no cache entry, use default gateway) | 3.3.1.2 | x | ||||
| Mehrere Standard-Gateways unterstützen (Support multiple default gateways) | 3.3.1.2 | x | ||||
| - Tabelle statischer Routen bereitstellen (Provide table of static routes) | 3.3.1.2 | x | ||||
| Flag: Route durch Redirects überschreibbar (Flag: route overridable by Redirects) | 3.3.1.2 | x | ||||
| - Route-Cache nach Host, nicht Netz, schlüsseln (Key route cache on host, not net address) | 3.3.1.3 | x | ||||
| - TOS in Route-Cache einbeziehen (Include TOS in route cache) | 3.3.1.3 | x | ||||
| - Ausfall des Next-Hop-Gateways erkennen können (Able to detect failure of next-hop gateway) | 3.3.1.4 | x | ||||
| - Annehmen, Route bleibt für immer gültig (Assume route is good forever) | 3.3.1.4 | x | ||||
| - Gateways kontinuierlich pingen (Ping gateways continuously) | 3.3.1.4 | x | ||||
| - Nur bei zu sendendem Verkehr pingen (Ping only when traffic being sent) | 3.3.1.4 | x | ||||
| - Nur ohne positive Anzeige pingen (Ping only when no positive indication) | 3.3.1.4 | x | ||||
| - Höhere und niedrigere Schichten geben Hinweise (Higher and lower layers give advice) | 3.3.1.4 | x | ||||
| - Auf anderes Standard-Gateway bei Ausfall umschalten (Switch from failed default g'way to another) | 3.3.1.5 | x | ||||
| - Manuelle Methode zur Eingabe von Config-Infos (Manual method of entering config info) | 3.3.1.6 | x | ||||
| Reassemblierung und Fragmentierung (REASSEMBLY and FRAGMENTATION): | ||||||
| - Eingehende Datagramme reassemblieren können (Able to reassemble incoming datagrams) | 3.3.2 | x | ||||
| Mindestens 576-Byte-Datagramme (At least 576 byte datagrams) | 3.3.2 | x | ||||
| EMTU_R konfigurierbar oder unbegrenzt (EMTU_R configurable or indefinite) | 3.3.2 | x | ||||
| - Transportschicht kann MMS_R erfahren (Transport layer able to learn MMS_R) | 3.3.2 | x | ||||
| - ICMP Time Exceeded bei Reassembly-Timeout senden (Send ICMP Time Exceeded on reassembly timeout) | 3.3.2 | x | ||||
| Fester Reassembly-Timeout-Wert (Fixed reassembly timeout value) | 3.3.2 | x | ||||
| - MMS_S an höhere Schichten weitergeben (Pass MMS_S to higher layers) | 3.3.3 | x | ||||
| - Lokale Fragmentierung ausgehender Pakete (Local fragmentation of outgoing packets) | 3.3.3 | x | ||||
| Sonst nicht größer als MMS_S senden (Else don't send bigger than MMS_S) | 3.3.3 | x | ||||
| - Max 576 an off-net Ziel senden (Send max 576 to off-net destination) | 3.3.3 | x | ||||
| - All-Subnets-MTU-Konfigurationsflag (All-Subnets-MTU configuration flag) | 3.3.3 | x | ||||
| Multihoming: | ||||||
| - Mit gleicher Adresse wie spezif. Ziel antworten (Reply with same addr as spec-dest addr) | 3.3.4.2 | x | ||||
| - Anwendung darf lokale IP-Adresse wählen (Allow application to choose local IP addr) | 3.3.4.2 | x | ||||
| - Datagramm auf „falscher“ Schnittstelle still verwerfen (Silently discard d'gram in "wrong" interface) | 3.3.4.2 | x | ||||
| - Datagramm nur über „richtige“ Schnittstelle senden (Only send d'gram through "right" interface) | 3.3.4.2 | x | 4 | |||
| Quellrouten-Weiterleitung (SOURCE-ROUTE FORWARDING): | ||||||
| - Datagramm mit Source-Route-Option weiterleiten (Forward datagram with Source Route option) | 3.3.5 | x | 1 | |||
| Entsprechende Gateway-Regeln beachten (Obey corresponding gateway rules) | 3.3.5 | x | 1 | |||
| TTL nach Gateway-Regeln aktualisieren (Update TTL by gateway rules) | 3.3.5 | x | 1 | |||
| ICMP-Fehlercodes 4, 5 erzeugen können (Able to generate ICMP err code 4, 5) | 3.3.5 | x | 1 | |||
| IP-Quelladresse nicht lokaler Host (IP src addr not local host) | 3.3.5 | x | 1 | |||
| Timestamp-, Record-Route-Optionen aktualisieren (Update Timestamp, Record Route options) | 3.3.5 | x | 1 | |||
| Konfigurierbarer Schalter für nicht-lokales SRing (Configurable switch for non-local SRing) | 3.3.5 | x | 1 | |||
| Standardmäßig AUS (Defaults to OFF) | 3.3.5 | x | 1 | |||
| Gateway-Zugriffsregeln für nicht-lokales SRing erfüllen (Satisfy gwy access rules for non-local SRing) | 3.3.5 | x | 1 | |||
| Falls nicht weitergeleitet, Dest Unreach (cd 5) senden (If not forward, send Dest Unreach (cd 5)) | 3.3.5 | x | 2 | |||
| Broadcast (BROADCAST): | ||||||
| - Broadcast-Adresse als IP-Quelladresse (Broadcast addr as IP source addr) | 3.2.1.3 | x | ||||
| - 0- oder -1-Broadcast-Formate empfangen OK (Receive 0 or -1 broadcast formats OK) | 3.3.6 | x | ||||
| - Konfig-Option zum Senden von 0 oder -1 b'cast (Config'ble option to send 0 or -1 b'cast) | 3.3.6 | x | ||||
| Standardmäßig -1-Broadcast (Default to -1 broadcast) | 3.3.6 | x | ||||
| - Alle Broadcast-Adressformate erkennen (Recognize all broadcast address formats) | 3.3.6 | x | ||||
| - IP-b'cast/m'cast-Adresse in Link-Layer-b'cast nutzen (Use IP b'cast/m'cast addr in link-layer b'cast) | 3.3.6 | x | ||||
| - Nur Link-Layer-Broadcast-Datagramme still verwerfen (Silently discard link-layer-only b'cast dg's) | 3.3.6 | x | ||||
| - Eingeschränkte Broadcast-Adresse für verbundenes Netz nutzen (Use Limited Broadcast addr for connected net) | 3.3.6 | x | ||||
| Multicast (MULTICAST): | ||||||
| - Lokales IP-Multicasting unterstützen (RFC-1112) (Support local IP multicasting (RFC-1112)) | 3.3.7 | x | ||||
| - IGMP unterstützen (RFC-1112) (Support IGMP (RFC-1112)) | 3.3.7 | x | ||||
| - All-hosts-Gruppe beim Start beitreten (Join all-hosts group at startup) | 3.3.7 | x | ||||
| - Höhere Schichten lernen m'cast-Fähigkeit der iface (Higher layers learn i'face m'cast capability) | 3.3.7 | x | ||||
| Schnittstelle (INTERFACE): | ||||||
| - Transportschicht darf alle IP-Mechanismen nutzen (Allow transport layer to use all IP mechanisms) | 3.4 | x | ||||
| - Schnittstellen-ID an Transportschicht weitergeben (Pass interface ident up to transport layer) | 3.4 | x | ||||
| - Alle IP-Optionen an Transportschicht weitergeben (Pass all IP options up to transport layer) | 3.4 | x | ||||
| - Transportschicht kann bestimmte ICMP-Nachrichten senden (Transport layer can send certain ICMP messages) | 3.4 | x | ||||
| - Angegebene ICMP-Nachrichten an Transp.-Schicht weitergeben (Pass spec'd ICMP messages up to transp. layer) | 3.4 | x | ||||
| IP-Hdr + mind. 8 Oktette aus Original einbeziehen (Include IP hdr+8 octets or more from orig.) | 3.4 | x |
Fußnoten (Footnotes):
(1) Nur wenn die Funktion implementiert ist. (2) Diese Anforderung entfällt, wenn das Datagramm eine ICMP-Fehlernachricht ist. (3) Nur wenn die Funktion implementiert und auf „ein“ konfiguriert ist. (4) Außer wenn eingebettete Gateway-Funktion vorhanden oder über Quellroute geleitet.