Zum Hauptinhalt springen

6. Updates to Existing Standards (Aktualisierungen bestehender Standards)

Die folgenden Abschnitte behandeln die spezifischen Änderungen an bestehenden Protokollen, die durch dieses Dokument angegeben werden.

6.1. Updates to RFC 791 (Aktualisierungen von RFC 791)​

RFC 791 besagt:

Das ursprüngliche Protokollmodul eines Internet-Datagramms setzt das Identifikationsfeld auf einen Wert, der für dieses Quell-Ziel-Paar und dieses Protokoll für die Zeit, in der das Datagramm im Internet-System aktiv sein wird, eindeutig sein muss.

Weiter heißt es:

Der Sender muss den Identifier daher so wählen, dass er für dieses Quell-, Ziel-Paar und Protokoll für die Zeit, in der das Datagramm (oder ein beliebiges Fragment davon) im Internet existieren könnte, eindeutig ist.

Es scheint daher, dass ein sendendes Protokollmodul eine Tabelle von Identifiern führen muss, mit einem Eintrag für jedes Ziel, mit dem es während der letzten maximalen Datagrammlebensdauer für das Internet kommuniziert hat.

Da das Identifier-Feld jedoch 65.536 verschiedene Werte zulässt, kann es für einen Host möglich sein, einfach eindeutige Identifier unabhängig vom Ziel zu verwenden.

Es ist für einige Protokolle höherer Ebene angemessen, den Identifier zu wählen. Beispielsweise können TCP-Protokollmodule ein identisches TCP-Segment erneut übertragen, und die Wahrscheinlichkeit eines korrekten Empfangs würde erhöht, wenn die erneute Übertragung denselben Identifier wie die ursprüngliche Übertragung tragen würde, da Fragmente beider Datagramme verwendet werden könnten, um ein korrektes TCP-Segment zu konstruieren.

Dieses Dokument ändert RFC 791 wie folgt:

  • Die Eindeutigkeit der IPv4-ID gilt nur für nicht-atomare Datagramme.
  • Erneut übertragene nicht-atomare IPv4-Datagramme dürfen den ID-Wert nicht mehr wiederverwenden.

6.2. Updates to RFC 1122 (Aktualisierungen von RFC 1122)​

RFC 1122 besagt in Abschnitt 3.2.1.5 ("Identification: RFC 791 Section 3.2"):

Beim Senden einer identischen Kopie eines früheren Datagramms KANN ein Host optional dasselbe Identification-Feld in der Kopie beibehalten.

DISCUSSION:

Einige Internet-Protokollexperten haben die Auffassung vertreten, dass die neue Kopie denselben Identification-Wert wie das Original enthalten sollte, wenn ein Host eine identische Kopie eines früheren Datagramms sendet. Es gibt zwei vorgeschlagene Vorteile: (1) Wenn die Datagramme fragmentiert sind und einige der Fragmente verloren gehen, kann der Empfänger möglicherweise aus Fragmenten des Originals und der Kopien ein vollständiges Datagramm rekonstruieren; (2) ein überlastetes Gateway könnte das IP-Identification-Feld (und den Fragment Offset) verwenden, um doppelte Datagramme aus der Warteschlange zu verwerfen.

Dieses Dokument ändert RFC 1122 wie folgt:

  • Das IPv4-ID-Feld darf nicht mehr für die Duplikaterkennung verwendet werden. Dies gilt sowohl für atomare als auch für nicht-atomare Datagramme.
  • Erneut übertragene nicht-atomare IPv4-Datagramme dürfen den ID-Wert nicht mehr wiederverwenden.

6.3. Updates to RFC 2003 (Aktualisierungen von RFC 2003)​

Dieses Dokument aktualisiert, wie IPv4-in-IPv4-Tunnel IPv4-ID-Werte für den äußeren IPv4-Header erzeugen [RFC2003], jedoch nur auf dieselbe Weise wie für jede andere IPv4-Datagrammquelle. Konkret gibt RFC 2003 Folgendes an, wobei sich [10] auf RFC 791 bezieht:

Identification, Flags, Fragment Offset

Diese drei Felder werden wie in [10] angegeben gesetzt...

Dieses Dokument ändert RFC 2003 wie folgt:

  • Das IPv4-ID-Feld wird wie von RFC 6864 erlaubt gesetzt.