Zum Hauptinhalt springen

4. Updates to the IPv4 ID Specification (Aktualisierungen der IPv4-ID-Spezifikation)

Dieses Dokument aktualisiert die Spezifikation des IPv4-ID-Feldes auf drei verschiedene Arten, die in den nachfolgenden Unterabschnitten erörtert werden:

  • Verwendung des IPv4-ID-Feldes nur für die Fragmentierung
  • Förderung eines sicheren Betriebs bei Verwendung des IPv4-ID-Feldes
  • Vermeidung von Auswirkungen auf die Leistung bei Verwendung des IPv4-ID-Feldes

Es gibt zwei Arten von Datagrammen, die im Folgenden definiert und in der nachstehenden Erörterung verwendet werden:

  • Atomare Datagramme sind Datagramme, die noch nicht fragmentiert wurden und bei denen eine weitere Fragmentierung unterbunden wurde.
  • Nicht-atomare Datagramme sind Datagramme, die entweder bereits fragmentiert wurden oder bei denen eine Fragmentierung weiterhin möglich ist.

Dieselbe Definition kann in Pseudocode unter Verwendung gängiger logischer Operatoren ausgedrückt werden (Gleichheit ist ==, logisches 'und' ist &&, logisches 'oder' ist ||, größer als ist >, und die Klammerfunktion wird typischerweise verwendet) wie folgt:

  • Atomare Datagramme: (DF==1)&&(MF==0)&&(frag_offset==0)
  • Nicht-atomare Datagramme: (DF==0)||(MF==1)||(frag_offset>0)

Der Test für nicht-atomare Datagramme ist die logische Negation des Tests für atomare Datagramme; somit werden alle Möglichkeiten berücksichtigt.

4.1. IPv4 ID Used Only for Fragmentation (IPv4-ID nur für Fragmentierung verwendet)​

Obwohl RFC 1122 nahelegt, dass das IPv4-ID-Feld andere Verwendungen hat, einschließlich der Deduplizierung von Datagrammen, sind solche Verwendungen bereits nicht interoperabel mit bekannten Implementierungen von Quellen, die ihre ID nicht verändern. Dieses Dokument definiert den Wert dieses Feldes daher nur für Fragmentierung und Reassemblierung:

Das IPv4-ID-Feld DARF NICHT für andere Zwecke als Fragmentierung und Reassemblierung verwendet werden.

Die Deduplizierung von Datagrammen kann weiterhin mithilfe hashbasierter Duplikaterkennung für Fälle erreicht werden, in denen das ID-Feld fehlt (nicht fragmentierte IPv6-Datagramme), was auch auf atomare IPv4-Datagramme angewendet werden kann, ohne das ID-Feld zu nutzen [RFC6621].

In atomaren Datagrammen hat das IPv4-ID-Feld keine Bedeutung; es kann daher auf einen beliebigen Wert gesetzt werden, d. h., die Anforderung sich nicht wiederholender IDs innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll ist für atomare Datagramme nicht mehr erforderlich:

Ursprüngliche Quellen KÖNNEN das IPv4-ID-Feld atomarer Datagramme auf jeden beliebigen Wert setzen.

Zweitens können sich alle Netzwerkknoten, ob an Zwischenroutern, Zielhosts oder anderen Geräten (z. B. NATs und andere Adressfreigabemechanismen, Firewalls, Tunnelausgänge), nicht auf das Feld atomarer Datagramme verlassen:

Alle Geräte, die IPv4-Header untersuchen, MÜSSEN das IPv4-ID-Feld atomarer Datagramme ignorieren.

Das IPv4-ID-Feld ist somit nur für nicht-atomare Datagramme von Bedeutung -- entweder für diejenigen Datagramme, die bereits fragmentiert wurden, oder für diejenigen, bei denen eine Fragmentierung weiterhin zulässig ist. Atomare Datagramme werden anhand ihrer DF-, MF- und Fragmentierungsoffset-Felder erkannt, wie in Abschnitt 4 erläutert, weil ein solcher Test vollständig abwärtskompatibel ist; daher reserviert dieses Dokument keine IPv4-ID-Werte, einschließlich 0, als ausgezeichnete Werte.

Die Abkehr von der Verwendung des IPv4-ID-Feldes für Zwecke, die nicht der Reassemblierung dienen, dürfte kaum -- wenn überhaupt -- Auswirkungen haben. IPv4-IDs werden bereits häufig wiederholt, z. B. über selbst mäßig schnelle Verbindungen und von einigen Quellen, die die ID überhaupt nicht verändern, und es wurden keine nachteiligen Auswirkungen beobachtet. Die Duplikatunterdrückung wurde vorgeschlagen [RFC1122] und in einigen Protokollbeschleunigern implementiert, aber bisher wurden keine Auswirkungen der Wiederverwendung von IPv4-IDs festgestellt. Router sind nicht verpflichtet, ICMPs in einem bestimmten Zeitrahmen auszugeben, sodass die Wiederholung von IPv4-IDs nicht zu Validierungszwecken verwendet worden sein sollte; dieses Szenario wurde nicht beobachtet. Außerdem tritt die Wiederholung bereits auf und wäre bemerkt worden [RFC1812]. Die ICMP-Weiterleitung an Tunneleingängen ist so spezifiziert, dass sie Soft State anstelle eines Datagramm-Caches verwendet; aus ähnlichen Gründen, wenn letzterer verwendet wird, hätte dies bemerkt werden müssen [RFC2003]. Diese und andere Altlastprobleme werden in Abschnitt 5.1 weiter erörtert.

4.2. Encouraging Safe IPv4 ID Use (Förderung einer sicheren Verwendung der IPv4-ID)​

Dieses Dokument ändert außerdem die Spezifikation des IPv4-ID-Feldes, um dessen sichere Verwendung zu fördern.

Wie in RFC 1122 erörtert, kann es möglich sein, die IPv4-ID wiederzuverwenden, wenn TCP ein Segment erneut überträgt (siehe Abschnitt 6.2). Dies kann es für eine Quelle schwierig machen, die Wiederholung von IPv4-IDs für empfangene Fragmente zu vermeiden. RFC 1122 kommt zu dem Schluss, dass dieses Verhalten "nicht nützlich" ist; dieses Dokument formalisiert diese Schlussfolgerung wie folgt:

Die IPv4-ID nicht-atomarer Datagramme DARF NICHT wiederverwendet werden, wenn eine Kopie eines früheren nicht-atomaren Datagramms gesendet wird.

RFC 1122 legt außerdem nahe, dass Fragmente überlappen können. Eine solche Überlappung kann auftreten, wenn aufeinanderfolgende erneute Übertragungen auf unterschiedliche Weise fragmentiert werden, aber dieselbe Reassemblierungs-IPv4-ID aufweisen. Diese Überlappung wird als Folge der Wiederverwendung von IPv4-IDs beim erneuten Übertragen von Datagrammen genannt, was dieses Dokument verwirft. Sie ist jedoch auch die Folge der Duplizierung von Datagrammen innerhalb des Netzwerks, die weiterhin auftreten kann. Infolgedessen ändert dieses Dokument die Notwendigkeit für Empfänger, überlappende Fragmente zu unterstützen, nicht.

4.3. IPv4 ID Requirements That Persist (Fortbestehende Anforderungen an die IPv4-ID)​

Dieses Dokument lockert die Eindeutigkeitsanforderungen des IPv4-ID-Feldes aus [RFC791] für nicht-atomare Datagramme nicht, das heißt:

Quellen, die nicht-atomare Datagramme aussenden, DÜRFEN IPv4-ID-Werte innerhalb einer MDL für ein gegebenes Tupel aus Quelladresse/Zieladresse/Protokoll NICHT wiederholen.

Zu solchen Quellen gehören ursprüngliche Hosts, Tunneleingänge und NATs (einschließlich anderer Adressfreigabemechanismen) (siehe Abschnitt 5.3).

Dieses Dokument lockert die Anforderung nicht, dass alle Netzwerkgeräte das DF-Bit beachten, das heißt:

IPv4-Datagramme mit DF=1 DÜRFEN NICHT fragmentiert werden.

IPv4-Datagramm-Transitgeräte DÜRFEN das DF-Bit NICHT löschen.

Konkret verhindert DF=1 die Fragmentierung atomarer Datagramme. DF=1 verhindert außerdem die weitere Fragmentierung empfangener Fragmente. Eine Fragmentierung innerhalb des Netzwerks ist nur zulässig, wenn DF=0; dieses Dokument ändert diese Anforderung nicht.