5. Impact of Proposed Changes (Auswirkungen der vorgeschlagenen Änderungen)

Dieser Abschnitt erörtert die Auswirkungen der vorgeschlagenen Änderungen auf ältere Geräte, die Datagrammerzeugung in aktualisierten Geräten, Middleboxes und die Header-Komprimierung.

5.1. Impact on Legacy Internet Devices (Auswirkungen auf ältere Internet-Geräte)

Ältere Verwendungen des IPv4-ID-Feldes bestehen aus Fragmenterzeugung, Fragmentreassemblierung, Erkennung doppelter Datagramme und "sonstigen" Verwendungen.

Aktuelle Geräte erzeugen bereits ID-Werte, die innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll in weniger als der derzeit geschätzten Internet-MDL von zwei Minuten wiederverwendet werden. Sie nehmen an, dass die MDL über ihren Ende-zu-Ende-Pfad viel geringer ist.

Es ist bekannt, dass bestehende Geräte seit fast einem Jahrzehnt unveränderliche IDs für atomare Datagramme erzeugen, insbesondere einige Mobiltelefone. Solche konstanten ID-Werte sind der Grund für deren Unterstützung als Optimierung von ROHC [RFC5225]. Dies wird in Abschnitt 5.4 weiter erörtert. Die Erzeugung von IPv4-Datagrammen mit konstanten (Null-)IDs wird auch als Teil des IP/ICMP-Übersetzungsstandards beschrieben [RFC6145].

Viele aktuelle Geräte unterstützen eine Fragmentierung, die das IPv4-Don't-Fragment-Bit (DF) ignoriert. Solche Geräte leiten bereits Verkehr von Quellen weiter, die die ID wiederverwenden. Wenn Fragmente verschiedener Datagramme, die dieselbe ID wiederverwenden (innerhalb des Tupels aus Quelladresse/Zieladresse/Protokoll), verschachtelt am Ziel eintreffen, würde die Fragmentierung fehlschlagen und der Verkehr würde verworfen. Entweder ist eine solche Verschachtelung ungewöhnlich, oder der Verkehr von solchen Geräten durchquert diese DF-ignorierenden Geräte nicht weit verbreitet, weil ein signifikantes Auftreten von Reassemblierungsfehlern nicht gemeldet wurde. DF-ignorierende Geräte entsprechen nicht den bestehenden Standards, und es ist nicht machbar, die Standards zu aktualisieren, um sie als konform zuzulassen.

Das ID-Feld wurde für die Verwendung bei der Duplikaterkennung ins Auge gefasst, wie in Abschnitt 4.1 erörtert. Obwohl dieses Dokument nun die Wiederverwendung der IPv4-ID für atomare Datagramme erlaubt, ist eine solche Wiederverwendung bereits üblich (wie oben angemerkt). Es ist bekannt, dass Protokollbeschleuniger die IPv4-Duplikaterkennung implementieren, aber es ist auch bekannt, dass solche Geräte andere Internet-Standards verletzen, um eine höhere Ende-zu-Ende-Leistung zu erzielen. Diese Geräte würden für diesen aktuellen Verkehr bereits fehlerhafte Verwerfungen aufweisen, und dies wurde nicht gemeldet.

Es gibt andere potenzielle Verwendungen des ID-Feldes, etwa für Diagnosezwecke. Solche Verwendungen müssen bereits atomare Datagramme mit wiederverwendeten ID-Feldern berücksichtigen. Es gibt keine Berichte darüber, dass solche Verwendungen Probleme mit aktuellen Datagrammen haben, die IDs wiederverwenden.

Daher empfiehlt dieses Dokument als Ergebnis früherer Anforderungen, dass Mechanismen zur IPv4-Duplikaterkennung und -diagnose IPv6-kompatible Methoden anwenden, d. h. Methoden, die nicht auf dem ID-Feld beruhen (z. B. wie in [RFC6621] vorgeschlagen). Dies ist eine Konsequenz daraus, dass das ID-Feld nur für die Reassemblierung verwendet wird, sowie aus der bekannten Gefahr, dass bestehende Geräte das ID-Feld bereits wiederverwenden.

5.2. Impact on Datagram Generation (Auswirkungen auf die Datagrammerzeugung)

Das Folgende ist eine Zusammenfassung der Empfehlungen, die sich aus den vorherigen Änderungen an der Spezifikation des IPv4-ID-Feldes ergeben.

Da atomare Datagramme beliebige IPv4-ID-Werte verwenden können, wirkt sich das ID-Feld in diesen Fällen nicht mehr auf die Leistung aus. Bei nicht-atomaren Datagrammen bleibt die Auswirkung auf die Leistung jedoch bestehen. Infolgedessen:

Quellen nicht-atomarer IPv4-Datagramme MÜSSEN ihre Ausgabe begrenzen, um die Eindeutigkeitsanforderungen an die ID einzuhalten. Zu solchen Quellen gehört insbesondere DNS über UDP [RFC2671].

Da es keine strikte Definition der MDL gibt, bestehen Reassemblierungsgefahren unabhängig vom Wiederverwendungsintervall der IPv4-ID oder vom Reassemblierungs-Timeout. Infolgedessen:

Protokolle höherer Schichten SOLLTEN die Integrität von IPv4-Datagrammen überprüfen, z. B. mithilfe einer Prüfsumme oder eines Hashes, der Reassemblierungsfehler erkennen kann (die UDP- und TCP-Prüfsummen sind diesbezüglich schwach, aber besser als nichts).

Zusätzliche Integritätsprüfungen können mithilfe von Tunneln eingesetzt werden, wie sie von der Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], IPsec [RFC4301] oder dem Stream Control Transmission Protocol (SCTP) [RFC4960] unterstützt werden. Solche Prüfungen können die Reassemblierungsgefahren vermeiden, die bei der Verwendung von UDP- und TCP-Prüfsummen [RFC4963] oder bei der Verwendung partieller Prüfsummen wie in UDP-Lite [RFC3828] auftreten können. Da solche Integritätsprüfungen die Auswirkungen von Reassemblierungsfehlern vermeiden können:

Quellen nicht-atomarer IPv4-Datagramme, die starke Integritätsprüfungen verwenden, KÖNNEN die ID innerhalb von Intervallen wiederverwenden, die kleiner als typische MDL-Werte sind.

Beachten Sie jedoch, dass eine solche häufige Wiederverwendung dennoch zu fehlerhafter Reassemblierung und schlechtem Durchsatz führen kann, obwohl sie Reassemblierungsfehler nicht an Protokolle höherer Schichten weitergeben würde.

5.3. Impact on Middleboxes (Auswirkungen auf Middleboxes)

Middleboxes umfassen umschreibende Geräte wie Network Address Translators (NATs), Network Address/Port Translators (NAPTs) und andere Adressfreigabemechanismen (Address-Sharing Mechanisms, ASMs). Sie umfassen auch Geräte, die Datagramme untersuchen und filtern, aber keine Router sind, wie Beschleuniger und Firewalls.

Die in diesem Dokument vorgeschlagenen Änderungen werden möglicherweise nicht von Middleboxes implementiert; diese Änderungen machen das aktuelle Verhalten von Middleboxes jedoch eher konform, als dass sie den von diesen Geräten bereitgestellten Dienst beeinträchtigen.

5.3.1. Rewriting Middleboxes (Umschreibende Middleboxes)

NATs und NAPTs schreiben IP-Felder um, und Tunneleingänge (unter Verwendung von IPv4-Kapselung) kopieren und ändern einige IPv4-Felder; alle werden daher als Datagrammquellen betrachtet, ebenso wie alle Geräte, die einen beliebigen Teil des Tupels aus Quelladresse/Zieladresse/Protokoll/ID für beliebige Datagramme umschreiben [RFC3022]. Dies gilt auch für andere ASMs, einschließlich IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219] und andere aus der "A+P"-Familie (Address plus Port) [Bo11]. Gleiches gilt für jeden anderen Datagramm-umschreibenden Mechanismus. Infolgedessen unterliegen sie allen Anforderungen, die für jede Datagrammquelle gelten, wie angemerkt wurde.

NATs/ASMs/Rewriter stellen eine besonders schwierige Situation für die Fragmentierung dar. Da sie Teile des Reassemblierungstupels in beide Richtungen überschreiben, können sie die Eindeutigkeit des Tupels zerstören und eine Reassemblierungsgefahr verursachen. Wann immer IPv4-Quelladress-, Zieladress- oder Protokollfelder geändert werden, muss ein NAT/ASM/Rewriter sicherstellen, dass das ID-Feld angemessen erzeugt wird, anstatt einfach aus dem eingehenden Datagramm kopiert zu werden.

Konkret:

Adressfreigabe- oder umschreibende Geräte MÜSSEN sicherstellen, dass das IPv4-ID-Feld von Datagrammen, deren Adressen oder Protokolle übersetzt werden, diese Anforderungen erfüllt, als ob das Datagramm von diesem Gerät stammen würde.

Diese Konformität bedeutet, dass das IPv4-ID-Feld nicht-atomarer Datagramme, die an einem NAT/ASM/Rewriter übersetzt werden, die Eindeutigkeitsanforderungen jeder IPv4-Datagrammquelle befolgen muss. Leider verletzen übersetzte Fragmente diese Anforderung bereits, da sie eine IPv4-ID innerhalb der MDL für ein gegebenes Tupel aus Quelladresse/Zieladresse/Protokoll wiederholen.

Solche Probleme bei der Übertragung von Fragmenten durch NATs/ASMs/Rewriter sind bereits bekannt; die Übersetzung basiert typischerweise auf der Transportportnummer, die ohnehin nur im ersten Fragment vorhanden ist [RFC3022]. Dieses Dokument unterstreicht den Punkt, dass die Reassemblierung (und möglicherweise eine nachfolgende Fragmentierung) nicht nur für die Übersetzung erforderlich ist, sondern auch genutzt werden kann, um Probleme mit der Eindeutigkeit der IPv4-ID zu vermeiden.

Beachten Sie, dass NATs/ASMs bereits besondere Sorgfalt walten lassen müssen, wenn sie Datagramme auf ihrer öffentlichen Seite aussenden, weil das Zusammenführen von Datagrammen aus vielen Quellen auf eine einzelne ausgehende Quelladresse zu IPv4-ID-Kollisionen führen kann. Diese Situation existierte bereits vor diesem Dokument und wird von ihm nicht beeinflusst. Sie wird bei großen, sogenannten "Carrier-Grade"-NATs verschärft [Pe11].

Tunneleingänge fungieren als Quellen für den äußersten Header, Tunnel fungieren jedoch als Router für die inneren Header (d. h. das Datagramm, wie es am Tunneleingang ankommt). Eingänge können stets als ursprüngliche Quellen des äußeren Headers fragmentieren, weil sie die Eindeutigkeit dieses IPv4-ID-Feldes und den Wert von DF im äußeren Header unabhängig von diesen Werten im inneren (ankommenden Datagramm-)Header kontrollieren.

5.3.2. Filtering Middleboxes (Filternde Middleboxes)

Middleboxes umfassen auch Geräte, die Datagramme filtern, wie Netzwerkbeschleuniger und Firewalls. Einige solcher Geräte sollen über eine Datagramm-Deduplizierung verfügen, die auf der Eindeutigkeit der IP-ID beruht, um Duplikate zu identifizieren, was in Abschnitt 5.1 erörtert wurde.

5.4. Impact on Header Compression (Auswirkungen auf die Header-Komprimierung)

Header-Komprimierungsalgorithmen berücksichtigen bereits verschiedene Arten, in denen sich die IPv4-ID zwischen aufeinanderfolgenden Datagrammen ändert [RFC1144] [RFC2508] [RFC3545] [RFC5225]. Solche Algorithmen gehen derzeit davon aus, dass die IPv4-ID Ende-zu-Ende erhalten bleibt. Einige Algorithmen erlauben bereits die Annahme, dass sich die ID nicht ändert (z. B. ROHC [RFC5225]), während andere unveränderliche IDs über Null-Deltas einbeziehen (z. B. Enhanced Compressed RTP (ECRTP) [RFC3545]).

Wenn die Komprimierung standardmäßig von einer sich ändernden ID ausgeht, kann eine unveränderliche ID die Komprimierung weniger effizient machen. Solche unveränderlichen IDs wurden in verschiedenen RFCs beschrieben (z. B. Fußnote 21 von [RFC1144] und cRTP [RFC2508]). Wenn die Komprimierung von einer unveränderlichen IPv4-ID ausgehen kann -- wie bei ROHC und ECRTP -- kann die Effizienz gesteigert werden.

5.5. Impact of Network Reordering and Loss (Auswirkungen von Netzwerkumordnung und -verlust)

Die Toleranz gegenüber Netzwerkumordnung und -verlust ist ein wesentliches Merkmal der Internet-Architektur. Obwohl die meisten aktuellen IP-Netze solche Ereignisse ohne triftigen Grund vermeiden, können sowohl Umordnung als auch Verlust auftreten, und sie treten auch auf. Datagramme sind bereits dafür vorgesehen, umgeordnet oder verloren zu werden, und die Wiederherstellung nach diesen Fehlern (sofern unterstützt) erfolgt bereits auf der Transport- oder einer höheren Protokollschicht.

Umordnung ist typischerweise mit Routing-Übergangserscheinungen verbunden oder damit, dass Flüsse über mehrere Pfade aufgeteilt werden. Verlust ist typischerweise mit Pfadüberlastung oder Verbindungsausfall (teilweise oder vollständig) verbunden. Die Auswirkungen solcher Ereignisse unterscheiden sich für atomare und nicht-atomare Datagramme und werden unten erörtert. Zusammenfassend machen die Empfehlungen dieses Dokuments das Internet robuster gegenüber Umordnung und Verlust, indem sie die Anforderungen an die Eindeutigkeit der ID für nicht-atomare Datagramme betonen und die Auswirkungen dieser Anforderungen sowohl auf Endpunkte als auch auf Datagramm-Transitgeräte deutlicher aufzeigen.

5.5.1. Atomic Datagrams Experiencing Reordering or Loss (Atomare Datagramme, die Umordnung oder Verlust erfahren)

Die Wiederverwendung von ID-Werten wirkt sich nicht auf atomare Datagramme aus, wenn das DF-Bit korrekt beachtet wird, weil die Wiederherstellung der Reihenfolge nicht vom Datagramm-Header abhängt. TCP verwendet eine Sequenznummer im Transport-Header; in einigen anderen Protokollen wird die Reihenfolge auf der Anwendungsschicht angegeben und wiederhergestellt.

Wenn DF=1 ignoriert wird, können Umordnung oder Verlust dazu führen, dass Fragmente verschiedener Datagramme verschachtelt und dadurch falsch reassembliert und verworfen werden. Die Wiederverwendung von ID-Werten in atomaren Datagrammen, wie sie dieses Dokument erlaubt, kann in solchen Fällen zu einem höheren Datagrammverlust führen. Solche Situationen können bereits existieren, weil es bekannte Geräte gibt, die eine konstante ID für atomare Datagramme verwenden (einige Mobiltelefone), und es bekannte Geräte gibt, die DF=1 ignorieren, aber hohe Werte entsprechenden Verlusts wurden nicht gemeldet. Das Fehlen solcher Berichte deutet entweder auf einen Mangel an Umordnung oder Verlust in solchen Fällen hin oder auf eine Toleranz gegenüber den daraus resultierenden Verlusten. Wenn solche Probleme gemeldet werden, wäre es produktiver, nicht konforme Geräte (die DF=1 ignorieren) anzugehen, weil es unpraktisch ist, Internet-Spezifikationen zu definieren, die Geräte tolerieren, die diese Spezifikationen ignorieren. Aus diesem Grund betont dieses Dokument die Notwendigkeit, DF=1 zu beachten, sowie dass Datagramm-Transitgeräte das DF-Bit so beibehalten müssen, wie es empfangen wurde (d. h. anstatt es zu löschen).

5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss (Nicht-atomare Datagramme, die Umordnung oder Verlust erfahren)

Nicht-atomare Datagramme verlassen sich auf die Eindeutigkeit des ID-Wertes, um die Umordnung von Fragmenten zu tolerieren, insbesondere wenn Fragmente verschiedener Datagramme infolge einer solchen Umordnung verschachtelt werden. Fragmentverlust kann zur Reassemblierung von Fragmenten aus verschiedenen Ursprungsdatagrammen führen, weshalb die ID-Wiederverwendung in nicht-atomaren Datagrammen auf der maximalen Lebensdauer des Datagramms (Fragments) und nicht nur auf der erwarteten Umordnungsverschachtelung basiert.

Dieses Dokument ändert die Anforderungen an die Eindeutigkeit von IDs in nicht-atomaren Datagrammen nicht und beeinflusst daher deren Toleranz gegenüber solcher Umordnung oder solchem Verlust nicht. Dieses Dokument betont die Notwendigkeit der ID-Eindeutigkeit für alle Datagrammquellen, einschließlich umschreibender Middleboxes; die Notwendigkeit, Quellen zu begrenzen, um die ID-Eindeutigkeit sicherzustellen; die Notwendigkeit, die ID für erneut übertragene Datagramme nicht wiederzuverwenden; und die Notwendigkeit, Integritätsprüfungen höherer Schichten zu verwenden, um Reassemblierungsfehler zu verhindern -- all dies führt zu einer höheren Toleranz gegenüber Umordnungs- oder Verlustereignissen.