Zum Hauptinhalt springen

3. The IPv4 ID Field (Das IPv4-ID-Feld)

IP unterstützt die Fragmentierung von Datagrammen, bei der große Datagramme in kleinere Komponenten aufgeteilt werden, um Verbindungen mit begrenzten maximalen Übertragungseinheiten (Maximum Transmission Units, MTUs) zu überqueren. Fragmente werden in IPv4 und IPv6 auf unterschiedliche Weise angezeigt:

  • In IPv4 werden Fragmente anhand von vier Feldern des Basis-Headers angezeigt: Identification (ID), Fragment Offset, ein "Don't Fragment"-Flag (DF) und ein "More Fragments"-Flag (MF) [RFC791].
  • In IPv6 werden Fragmente in einem Erweiterungs-Header angezeigt, der eine ID, einen Fragment Offset und ein M-Flag (more fragments) enthält, ähnlich ihren Gegenstücken in IPv4 [RFC2460].

Die IPv6-Fragmentierung unterscheidet sich in einigen wichtigen Punkten von der IPv4-Fragmentierung. Die IPv6-Fragmentierung erfolgt nur an der Quelle, sodass kein DF-Bit benötigt wird, um nachgelagerte Geräte daran zu hindern, eine Fragmentierung einzuleiten (d. h. IPv6 verhält sich immer so, als wäre DF=1). Der IPv6-Fragment-Header ist nur vorhanden, wenn ein Datagramm fragmentiert wurde oder wenn die Quelle eine ICMPv6-Fehlermeldung "packet too big" empfangen hat, die anzeigt, dass der Pfad die erforderliche minimale IPv6-MTU von 1280 Bytes nicht unterstützen kann und daher einer Übersetzung unterliegt [RFC2460] [RFC4443]. Der letztere Fall ist nur für IPv6-Datagramme relevant, die an IPv4-Ziele gesendet werden, um eine nachfolgende Fragmentierung nach der Übersetzung nach IPv4 zu unterstützen.

Mit Ausnahme dieser beiden Fälle ist das ID-Feld bei nicht fragmentierten Datagrammen nicht vorhanden; es ist daher nur für Datagramme von Bedeutung, die bereits fragmentiert sind, oder für Datagramme, die im Rahmen der IPv4-Übersetzung fragmentiert werden sollen. Schließlich ist das IPv6-ID-Feld 32 Bit groß und muss für IPv6 pro Quell-/Zieladresspaar eindeutig sein, während es für IPv4 nur 16 Bit groß ist und pro Tupel aus Quelladresse/Zieladresse/Protokoll eindeutig sein muss.

Dieses Dokument konzentriert sich auf die Probleme des IPv4-ID-Feldes, weil das Feld in IPv6 größer und nur in Fragmenten vorhanden ist.

3.1. Uses of the IPv4 ID Field (Verwendungen des IPv4-ID-Feldes)​

Das IPv4-ID-Feld war ursprünglich für Fragmentierung und Reassemblierung vorgesehen [RFC791]. Innerhalb einer gegebenen Quelladresse, Zieladresse und eines gegebenen Protokolls werden Fragmente eines ursprünglichen Datagramms anhand ihrer IPv4-ID einander zugeordnet. Dies erfordert, dass IDs innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll eindeutig sind, wenn eine Fragmentierung möglich ist (z. B. DF=0) oder wenn sie bereits stattgefunden hat (z. B. frag_offset>0 oder MF=1).

Für das IPv4-ID-Feld wurden weitere Verwendungen ins Auge gefasst. Das Feld wurde als Möglichkeit vorgeschlagen, doppelte Datagramme zu erkennen und zu entfernen, z. B. an überlasteten Routern (erwähnt in Abschnitt 3.2.1.5 von [RFC1122]) oder in Netzwerkbeschleunigern. In ähnlicher Weise wurde seine Verwendung an Endhosts vorgeschlagen, um die Auswirkungen von Duplikaten auf Protokolle höherer Schichten zu verringern (z. B. zusätzliche Verarbeitung in TCP oder die Notwendigkeit einer Duplikatunterdrückung auf Anwendungsschicht in UDP). Dies wird in Abschnitt 5.1 weiter erörtert.

Das IPv4-ID-Feld wird in einigen Diagnosewerkzeugen verwendet, um Datagramme zu korrelieren, die an verschiedenen Stellen entlang eines Netzwerkpfades gemessen werden. In IPv6 ist dies bereits unzureichend, weil nicht fragmentierte Datagramme keine ID besitzen, sodass diese Werkzeuge bereits aktualisiert werden, um eine solche Abhängigkeit vom ID-Feld zu vermeiden. Auch dies wird in Abschnitt 5.1 weiter erörtert.

Die ID muss offensichtlich eindeutig sein (innerhalb der MDL, innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll), um Fragmentierung und Reassemblierung zu unterstützen, aber nicht alle Datagramme sind fragmentiert oder lassen eine Fragmentierung zu. Dieses Dokument verwirft Verwendungen, die nicht der Fragmentierung dienen, und erlaubt in diesen Fällen die Wiederholung der ID (innerhalb der MDL, innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll).

3.2. Background on IPv4 ID Reassembly Issues (Hintergrund zu IPv4-ID-Reassemblierungsproblemen)​

Das Folgende ist eine Zusammenfassung der zuvor angesprochenen Probleme mit der IPv4-Fragmentreassemblierung in Hochgeschwindigkeitsumgebungen [RFC4963]. Den Lesern wird empfohlen, RFC 4963 für eine ausführlichere Erörterung dieser Probleme heranzuziehen.

Bei der maximalen IPv4-Datagrammgröße von 64 KB bedeutet ein 16-Bit-ID-Feld, das sich innerhalb von 120 Sekunden nicht wiederholt, dass die Gesamtheit aller TCP-Verbindungen eines gegebenen Protokolls zwischen zwei IP-Endpunkten auf etwa 286 Mbit/s begrenzt ist; bei einer typischeren MTU von 1500 Bytes sinkt diese Geschwindigkeit auf 6,4 Mbit/s [RFC791] [RFC1122] [RFC4963]. Diese Grenze gilt derzeit für alle IPv4-Datagramme innerhalb eines einzelnen Protokolls (d. h. des IPv4-Protokollfeldes) zwischen zwei IP-Adressen, unabhängig davon, ob die Fragmentierung aktiviert oder unterbunden ist und ob ein Datagramm fragmentiert ist oder nicht.

IPv6 ist selbst bei typischen MTUs mit Fragmentierung zwischen zwei IP-Endpunkten als Aggregat über alle Protokolle zu 18,7 Tbit/s fähig, was auf das größere 32-Bit-ID-Feld zurückzuführen ist (und auf die Tatsache, dass das IPv6-Next-Header-Feld, das Äquivalent des IPv4-Protokollfeldes, bei der Unterscheidung von Fragmenten nicht berücksichtigt wird). Wenn keine Fragmentierung verwendet wird, fehlt das Feld, und in diesem Fall werden die IPv6-Geschwindigkeiten nicht durch die Eindeutigkeit des ID-Feldes begrenzt.

Beachten Sie außerdem, dass 120 Sekunden nur eine Schätzung der MDL sind. Sie steht mit dem Reassemblierungs-Timeout als unterer Grenze und der TCP Maximum Segment Lifetime als oberer Grenze in Beziehung (beide wie in [RFC1122] erwähnt). Netzwerkverzögerungen entstehen auch auf andere Weise, z. B. bei Satellitenverbindungen, die Sekunden an Verzögerung hinzufügen können, obwohl die Time to Live (TTL) nicht um einen entsprechenden Betrag verringert wird. Es gibt somit keinen Durchsetzungsmechanismus, der sicherstellt, dass Datagramme, die älter als 120 Sekunden sind, verworfen werden.

Drahtlose Internet-Geräte sind häufig mit Geschwindigkeiten von über 54 Mbit/s verbunden, und kabelgebundene Verbindungen mit 1 Gbit/s sind seit mehreren Jahren der Standard. Obwohl viele Ende-zu-Ende-Transportpfade durch Überlastung begrenzt sind, erreichen diese Geräte über LANs leicht einen Anwendungsschicht-Durchsatz von über 100 Mbit/s (z. B. Dateiübertragungsraten von Festplatte zu Festplatte), und zahlreiche Durchsatzvorführungen mit Commercial-Off-The-Shelf-Systemen (COTS) über Weitverkehrspfade zeigen diese Geschwindigkeiten seit über einem Jahrzehnt. Dies deutet stark darauf hin, dass die Eindeutigkeit der IPv4-ID seit langem gegenstandslos ist.