Zum Hauptinhalt springen

RFC 6864 - Aktualisierte Spezifikation des IPv4-ID-Feldes

  • Status: Proposed Standard
  • Veröffentlicht: February 2013
  • Stream: IETF
  • Aktualisiert: RFC791, RFC1122, RFC2003
  • Errata: Keine Errata

Status dieses Memos​

Dies ist ein Internet Standards Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung genehmigt. Weitere Informationen zu Internet-Standards finden Sie in Abschnitt 2 von RFC 5741.

Informationen über den aktuellen Status dieses Dokuments, Errata und Feedback können unter http://www.rfc-editor.org/info/rfc6864 abgerufen werden.

Copyright (c) 2013 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (http://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gültig sind. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben.

Zusammenfassung​

Das IPv4-Identifikationsfeld (ID) ermöglicht Fragmentierung und Reassemblierung und muss gemäß aktueller Spezifikation für alle Datagramme mit demselben Quelladresse/Zieladresse/Protokoll-Tupel innerhalb der maximalen Lebensdauer eindeutig sein. Aktuelle Implementierungen folgen dieser Spezifikation jedoch nicht, sondern behandeln das ID-Feld als eindeutigen Wert für jedes Datagramm, was bei Hochgeschwindigkeitsgeräten zur Erschöpfung des ID-Feldes führen kann. Dieses Dokument aktualisiert die Spezifikation des IPv4-ID-Feldes in RFC 791, RFC 1122 und RFC 2003, um sie näher an die aktuelle Praxis anzupassen, und diskutiert die Auswirkungen dieser Änderungen auf Datagramm-Designer.

Inhaltsverzeichnis​

1. Einführung​

2. Das IPv4-ID-Feld​

3. Aktualisierungen der IPv4-ID-Spezifikation​

4. Auswirkungen der vorgeschlagenen Änderungen​

5. Aktualisierungen bestehender Standards​

6. Sicherheitsüberlegungen​

7. Referenzen​

Anhang A. Duplikaterkennung​

Anhang B. Danksagungen​

Offizielle Quelle: IETF RFC 6864

1. Einführung​

In IPv4 ist das Identifikationsfeld (ID) ein 16-Bit-Wert zur Unterstützung der Fragmentierung und Reassemblierung von Datagrammen. Gemäß der aktuellen Spezifikation muss das ID-Feld für Datagramme mit derselben Quelladresse, Zieladresse und demselben Protokoll innerhalb der maximalen Segmentlebensdauer (MSL) eindeutig sein. Aktuelle Implementierungen folgen dieser Spezifikation jedoch nicht streng, sondern behandeln das ID-Feld als eindeutigen Identifikator für jedes Datagramm, unabhängig davon, ob das Datagramm fragmentiert wird oder nicht.

In IPv4 verwenden Transport- und höhere Protokolle in der Regel 16-Bit- oder 32-Bit-Felder zur Erkennung doppelter Datagramme, wie z.B. TCP-Sequenznummern oder UDP-Prüfsummen. Das IPv4-ID-Feld hat jedoch nur 16 Bit, was bedeutet, dass in Hochgeschwindigkeitsnetzwerken das ID-Feld in kurzer Zeit erschöpft sein kann, wodurch keine eindeutigen ID-Werte für neue Datagramme zugewiesen werden können.

In IPv6 wird die Fragmentierung nur vom Quellknoten durchgeführt, und der Fragmentierungsheader enthält ein 32-Bit-Identifikationsfeld. Die IPv6-Spezifikation besagt ausdrücklich, dass dieses Identifikationsfeld nur eindeutig sein muss, wenn das Datagramm fragmentiert wird. Im Gegensatz dazu ist das IPv4-ID-Feld in allen Datagrammen vorhanden, unabhängig von der Fragmentierung.

Dieses Dokument aktualisiert die Spezifikation des IPv4-ID-Feldes in RFC 791, RFC 1122 und RFC 2003, um sie näher an die aktuelle Praxis anzupassen und mit der IPv6-Verarbeitung konsistent zu machen. Insbesondere verdeutlicht dieses Dokument folgende Punkte:

  1. Atomare Datagramme: Für Datagramme mit gesetztem DF-Flag (Don't Fragment) kann das ID-Feld auf einen beliebigen Wert gesetzt werden, und der Empfänger sollte den Wert des Feldes ignorieren.

  2. Nicht-atomare Datagramme: Für Datagramme ohne gesetztes DF-Flag muss das ID-Feld während des Reassemblierungs-Zeitlimits eindeutig sein, um eine korrekte Reassemblierung der Fragmente zu gewährleisten.

  3. Kompatibilität: Dieses Dokument diskutiert die Auswirkungen dieser Änderungen auf bestehende Geräte und Protokolle und bietet Empfehlungen für die Übergangsphase.

1.1 Terminologie​

Dieses Dokument verwendet die folgenden Begriffe:

  • Atomares Datagramm: IPv4-Datagramm mit gesetztem DF-Flag (DF=1)
  • Nicht-atomares Datagramm: IPv4-Datagramm ohne gesetztes DF-Flag (DF=0)
  • Quellknoten: Host oder Gerät, das IPv4-Datagramme erzeugt
  • Zwischenknoten: Router oder Gateway, der IPv4-Datagramme weiterleitet
  • Zielknoten: Host oder Gerät, das IPv4-Datagramme empfängt
  • ID-Wiederverwendungsintervall: Minimales Zeitintervall zwischen Datagrammen mit demselben Quelladresse/Zieladresse/Protokoll-Tupel für die Wiederverwendung desselben ID-Wertes

Navigation:

2. Das IPv4-ID-Feld​

Das IPv4-Identifikationsfeld (ID) wurde ursprünglich zur Unterstützung der Fragmentierung und Reassemblierung von Datagrammen entwickelt. Gemäß RFC 791 muss das ID-Feld für Datagramme mit derselben Quelladresse, Zieladresse und demselben Protokoll innerhalb der maximalen Segmentlebensdauer (MSL) eindeutig sein. Mit zunehmender Netzwerkgeschwindigkeit und sich ändernden Anwendungsanforderungen haben sich die aktuellen Implementierungen jedoch von der ursprünglichen Spezifikation entfernt.

2.1 IPv4-ID für Fragmentierung​

Das IPv4-ID-Feld wird hauptsächlich zur Unterstützung der Fragmentierung und Reassemblierung von Datagrammen verwendet. Wenn ein Datagramm über eine Verbindung mit kleinerer Maximum Transmission Unit (MTU) übertragen werden muss, kann der Zwischenrouter das Datagramm in mehrere kleinere Fragmente aufteilen. Jedes Fragment enthält denselben ID-Wert, damit der Zielknoten diese Fragmente zum ursprünglichen Datagramm reassemblieren kann.

In Hochgeschwindigkeitsumgebungen kann das 16-Bit-ID-Feld schnell erschöpft sein. Beispielsweise können auf einer 10-Gbps-Verbindung bei einer durchschnittlichen Datagrammgröße von 1500 Bytes etwa 833.333 Datagramme pro Sekunde übertragen werden, wodurch der 16-Bit-ID-Raum in etwa 0,079 Sekunden erschöpft wäre.

Um dieses Problem zu lösen, führt dieses Dokument die Konzepte atomare Datagramme und nicht-atomare Datagramme ein:

  • Atomare Datagramme: Datagramme mit gesetztem DF-Flag. Diese werden nicht von Zwischenroutern fragmentiert.
  • Nicht-atomare Datagramme: Datagramme ohne gesetztes DF-Flag. Diese können von Zwischenroutern fragmentiert werden.

2.2 IPv4-ID für Duplikaterkennung​

Neben der Fragmentierung kann das IPv4-ID-Feld auch zur Erkennung doppelter Datagramme verwendet werden. In Hochgeschwindigkeitsumgebungen kann sich das ID-Feld jedoch schnell wiederholen, wodurch es für die Duplikaterkennung unzuverlässig wird.

RFC 1122 weist darauf hin, dass Transportprotokolle ihre eigenen Mechanismen zur Duplikaterkennung verwenden sollten. Dieses Dokument bekräftigt, dass das IPv4-ID-Feld hauptsächlich für Fragmentierung und Reassemblierung verwendet wird, nicht für Duplikaterkennung.

2.3 Hintergrund zu IPv4-ID-Reassemblierungsproblemen​

In Hochgeschwindigkeitsumgebungen kann die 16-Bit-Beschränkung des ID-Feldes zu folgenden Problemen führen:

  1. ID-Feld-Erschöpfung: Auf Hochgeschwindigkeitsverbindungen kann das ID-Feld schnell erschöpft sein.
  2. Reassemblierungsfehler: Wenn zwei verschiedene Datagramme denselben ID-Wert verwenden und ihre Fragmente gleichzeitig im Netzwerk vorhanden sind, kann der Zielknoten Fragmente von verschiedenen Datagrammen falsch kombinieren.
  3. Leistungsabfall: Um ID-Erschöpfung zu vermeiden, könnten einige Implementierungen die Datagramm-Senderate begrenzen.

RFC 4963 diskutiert diese Probleme ausführlich und weist darauf hin, dass die aktuelle IPv4-ID-Feldspezifikation in Hochgeschwindigkeitsumgebungen nicht mehr anwendbar ist.

Navigation:

3. Aktualisierungen der IPv4-ID-Spezifikation​

Dieses Kapitel beschreibt die Aktualisierungen der IPv4-ID-Feldspezifikation zur Lösung des ID-Erschöpfungsproblems in Hochgeschwindigkeitsumgebungen.

3.1 IPv4-ID für atomare Datagramme​

Atomare Datagramme sind IPv4-Datagramme mit gesetztem DF-Flag (Don't Fragment). Da diese nicht fragmentiert werden, wird das ID-Feld nicht für die Reassemblierung benötigt.

3.1.1 Sender-Verhalten​

Für atomare Datagramme KANN (MAY) der Sender das ID-Feld auf einen beliebigen Wert setzen:

  • Fester Wert: Alle atomaren Datagramme können denselben Wert haben (z.B. 0)
  • Einfacher Zähler: Verwenden eines einfachen Zählers ohne Eindeutigkeitsanforderung
  • Zufallswert: Generieren zufälliger ID-Werte für jedes atomare Datagramm

3.1.2 Empfänger-Verhalten​

Für atomare Datagramme MUSS (MUST) der Empfänger das ID-Feld ignorieren:

  • Nicht zur Duplikaterkennung verwenden
  • Keine Annahmen über Bedeutung oder Reihenfolge machen
  • Auf Transportprotokolle (wie TCP-Sequenznummern) verlassen

3.1.3 Zwischenknoten-Verhalten​

Zwischenknoten beim Weiterleiten atomarer Datagramme:

  • DÜRFEN NICHT (MUST NOT) das ID-Feld ändern
  • DÜRFEN NICHT (MUST NOT) atomare Datagramme fragmentieren

3.2 IPv4-ID für nicht-atomare Datagramme​

Nicht-atomare Datagramme sind IPv4-Datagramme ohne gesetztes DF-Flag. Diese können fragmentiert werden, daher muss das ID-Feld für die Reassemblierung verwendet werden.

3.2.1 Sender-Verhalten​

Für nicht-atomare Datagramme MUSS (MUST) der Sender sicherstellen, dass das ID-Feld während des Reassemblierungs-Timeouts eindeutig ist.

3.2.2 Empfänger-Verhalten​

Für Fragmente nicht-atomarer Datagramme MUSS (MUST) der Empfänger das ID-Feld zur Reassemblierung verwenden.

3.2.3 Zwischenknoten-Verhalten​

Zwischenknoten beim Verarbeiten nicht-atomarer Datagramme:

  • KÖNNEN (MAY) Datagramme fragmentieren, wenn die Größe die MTU überschreitet
  • MÜSSEN (MUST) den ursprünglichen ID-Feldwert beibehalten

3.3 Beibehaltung des IPv4-ID-Verhaltens​

In bestimmten Fällen können Geräte das traditionelle IPv4-ID-Verhalten beibehalten, wobei für alle Datagramme eindeutige ID-Werte generiert werden. Dies umfasst:

  1. Kompatibilitätsanforderungen: Interoperabilität mit älteren Geräten
  2. Spezielle Anwendungen: Anwendungen, die von ID-Eindeutigkeit abhängen
  3. Sicherheitsüberlegungen: Sicherheitsmechanismen, die ID-Zufälligkeit erfordern

Navigation:

4. Auswirkungen der vorgeschlagenen Änderungen​

Dieses Kapitel analysiert die Auswirkungen der IPv4-ID-Feldaktualisierungen auf bestehende Geräte, Datagramm-Generierung und Header-Kompressionsschemata.

4.1 Auswirkungen auf Legacy-Internet-Geräte​

4.1.1 Sender-Auswirkungen​

Legacy-Sender: Traditionelle Sender, die für alle Datagramme eindeutige ID-Werte generieren, bleiben unter den Aktualisierungen konform.

Neue Sender: Neue Implementierungen können vereinfachte ID-Generierungsalgorithmen für atomare Datagramme verwenden, wodurch Leistung und Ressourcenverbrauch verbessert werden.

4.1.2 Empfänger-Auswirkungen​

Legacy-Empfänger: Möglicherweise müssen Empfänger aktualisiert werden, um ID-Felder atomarer Datagramme zu ignorieren. Selbst ohne Aktualisierung führt die Verarbeitung des ID-Feldes jedoch nicht zu funktionalen Fehlern.

Neue Empfänger: Sollten ID-Felder atomarer Datagramme explizit ignorieren.

4.1.3 Zwischenknoten-Auswirkungen​

Router und Gateways müssen ihr Verhalten nicht ändern, um den Aktualisierungen zu entsprechen.

4.1.4 Kompatibilitätszusammenfassung​

  • Rückwärtskompatibilität: Legacy-Geräte funktionieren weiterhin ohne Änderungen
  • Vorwärtskompatibilität: Neue Geräte können von den Spezifikationsaktualisierungen profitieren
  • Interoperabilität: Neue und alte Geräte können korrekt zusammenarbeiten

4.2 Auswirkungen auf Datagramm-Generierung​

4.2.1 ID-Generierung für atomare Datagramme​

Für atomare Datagramme können Sender vereinfachte Strategien verwenden:

  1. Fester Wert: Alle atomaren Datagramme verwenden denselben Wert
  2. Einfacher Zähler: Globaler Zähler für alle atomaren Datagramme
  3. Zufallswert: Zufällige ID-Werte für besseren Datenschutz
  4. Per-Flow-Zähler: Separate Zähler für jedes (Quelle, Ziel, Protokoll)-Tupel

4.2.2 ID-Generierung für nicht-atomare Datagramme​

Für nicht-atomare Datagramme müssen Sender Eindeutigkeit gewährleisten:

  1. Globaler Zähler: Einfach, aber könnte in Hochgeschwindigkeitsumgebungen erschöpft sein
  2. Per-Flow-Zähler: Reduziert Erschöpfungsrisiko
  3. Zeitbasierte Algorithmen: Verwendet Zeitstempel zur ID-Generierung
  4. Hybride Algorithmen: Kombiniert Zähler und Zufallswerte

4.2.3 Leistungsüberlegungen​

Die Aktualisierungen können die Datagramm-Generierungsleistung erheblich verbessern durch:

  • Reduzierung des Rechenaufwands für atomare Datagramme
  • Reduzierung der Zustandsverwaltung
  • Erhöhung des Durchsatzes in Hochgeschwindigkeitsumgebungen

4.3 Auswirkungen auf Header-Kompressionsschemata​

Header-Kompressionsschemata (wie ROHC, RFC 5795) müssen möglicherweise angepasst werden:

4.3.1 Kompression atomarer Datagramme​

Für atomare Datagramme sollten Kompressionsschemata verschiedene ID-Generierungsstrategien berücksichtigen.

4.3.2 Kompression nicht-atomarer Datagramme​

Für nicht-atomare Datagramme können bestehende Kompressionsalgorithmen weiterhin verwendet werden.

4.3.3 Empfehlungen für Kompressionsschemata​

  1. Unterscheiden zwischen atomaren und nicht-atomaren Datagrammen
  2. Adaptive Kompression basierend auf ID-Mustern
  3. Verhandlungsmechanismen für ID-Generierungsstrategien

Navigation:

5. Aktualisierungen bestehender Standards​

Dieses Kapitel beschreibt die spezifischen Aktualisierungen von RFC 791, RFC 1122 und RFC 2003.

5.1 Aktualisierungen von RFC 791​

RFC 791 ist die grundlegende IPv4-Spezifikation. Dieses Dokument aktualisiert die ID-Feldspezifikation:

Für atomare Datagramme (DF=1):

  • Sender KANN (MAY) das ID-Feld auf einen beliebigen Wert setzen
  • Empfänger MUSS (MUST) das ID-Feld ignorieren

Für nicht-atomare Datagramme (DF=0):

  • Sender MUSS (MUST) Eindeutigkeit während des Reassemblierungs-Timeouts gewährleisten
  • Empfänger MUSS (MUST) das ID-Feld zur Reassemblierung verwenden

5.2 Aktualisierungen von RFC 1122​

RFC 1122 definiert Anforderungen für Internet-Hosts. Die Aktualisierungen umfassen:

Für atomare Datagramme (DF=1):

  • Hosts KÖNNEN (MAY) das ID-Feld auf einen beliebigen Wert setzen
  • Hosts SOLLTEN NICHT (SHOULD NOT) auf das ID-Feld zur Duplikaterkennung vertrauen
  • Hosts MÜSSEN (MUST) Transportschicht-Mechanismen verwenden

Für nicht-atomare Datagramme (DF=0):

  • Hosts MÜSSEN (MUST) ID-Eindeutigkeit während des Reassemblierungs-Timeouts gewährleisten
  • Hosts SOLLTEN (SHOULD) separate ID-Zähler für jedes Tupel pflegen

5.3 Aktualisierungen von RFC 2003​

RFC 2003 definiert IP-in-IP-Kapselung. Die Aktualisierungen umfassen:

Für äußere IPv4-Header:

  • Wenn äußeres DF=1: Kapselierer KANN (MAY) ID auf beliebigen Wert setzen
  • Wenn äußeres DF=0: Kapselierer MUSS (MUST) Eindeutigkeit gewährleisten

Für innere IPv4-Header:

  • Kapselierer DARF NICHT (MUST NOT) das innere ID-Feld ändern
  • Entkapselierer MUSS (MUST) das innere ID-Feld bewahren

5.4 Zusammenfassung der Aktualisierungen​

RFCAktualisierungsinhaltAuswirkungsbereich
RFC 791Unterscheidung zwischen atomaren und nicht-atomaren DatagrammenIPv4-Protokollspezifikation
RFC 1122Aktualisierte Host-AnforderungenInternet-Host-Implementierungen
RFC 2003Aktualisierte IP-in-IP-KapselungIP-Tunnel und Mobile IP

Navigation:

6. Sicherheitsüberlegungen​

Dieses Kapitel diskutiert Sicherheitsauswirkungen der IPv4-ID-Feldaktualisierungen.

6.1 Datenschutzauswirkungen​

Die ID-Feldgenerierungsstrategie kann Informationen über den Sender preisgeben:

  1. Datagramm-Senderate: Durch Beobachtung der ID-Wachstumsrate
  2. Geräte-Fingerprinting: Identifizierung von Gerätetypen durch ID-Muster
  3. Benutzeraktivitätsverfolgung: Verfolgung durch ID-Änderungen

Gegenmaßnahmen:

  • Verwendung von Zufallswerten für atomare Datagramme
  • Per-Flow-Zähler statt globaler Zähler
  • Regelmäßiges Zurücksetzen der Zähler
  • Zufällige Initialwerte

6.2 Fragmentierungsangriffe​

IPv4-Fragmentierung kann für verschiedene Angriffe ausgenutzt werden:

6.2.1 Fragmentierungs-Reassemblierungsangriffe​

Angreifer können:

  1. Ressourcenerschöpfung: Unvollständige Fragmente senden
  2. Reassemblierungsfehler: Fragmente mit gleicher ID aber unterschiedlichem Inhalt senden
  3. Firewall-Umgehung: Durch Fragmentierung Firewall-Prüfungen umgehen

Gegenmaßnahmen:

  • Verwendung atomarer Datagramme (DF=1)
  • Path MTU Discovery
  • Begrenzung unvollständiger Fragmente
  • Fragmentvalidierung

6.3 ID-Kollisionsangriffe​

Angreifer können versuchen, die begrenzte ID-Kapazität auszunutzen:

  1. ID-Vorhersageangriff: Vorhersage von ID-Generierungsalgorithmen
  2. ID-Erschöpfungsangriff: Schnelle Erschöpfung des ID-Raums
  3. Reassemblierungs-Interferenzangriff: Gefälschte Fragmente mit gleicher ID senden

Gegenmaßnahmen:

  • Randomisierte ID-Generierung
  • Per-Flow-ID-Raum
  • Transportschicht-Validierung
  • IPsec

6.4 Denial-of-Service-Angriffe​

IPv4-ID-Feldverarbeitung kann Ziel von DoS-Angriffen sein:

  1. Fragmentierungs-Flutangriff: Massive fragmentierte Datagramme
  2. ID-Erschöpfungsangriff: Schnelle Erschöpfung des Sender-ID-Raums
  3. Reassemblierungs-Ressourcenerschöpfung: Unvollständige Fragmente

Gegenmaßnahmen:

  • Ratenbegrenzung
  • Ressourcenverwaltung
  • Priorisierte Verarbeitung atomarer Datagramme
  • Firewall und Filterung

6.5 Vergleich mit IPv6​

IPv6-Fragmentierung ist sicherer:

  1. End-to-End-Fragmentierung: Nur Quellknoten fragmentieren
  2. 32-Bit-Identifikationsfeld: Größerer ID-Raum
  3. Expliziter Fragmentierungsheader: Klarere und sicherere Verarbeitung

6.6 Empfehlungen​

  1. Atomare Datagramme (DF=1) bevorzugen
  2. Randomisierte ID-Generierung verwenden
  3. Auf Transportschicht-Schutz vertrauen
  4. Überwachungs- und Erkennungsmechanismen einsetzen
  5. Regelmäßige Updates durchführen

Navigation:

Anhang A. Duplikaterkennung​

Dieser Anhang diskutiert die Rolle des IPv4-ID-Feldes bei der Erkennung doppelter Datagramme und die Auswirkungen der Aktualisierungen auf die Duplikaterkennungsfähigkeit.

A.1 Hintergrund zur Duplikaterkennung​

Doppelte Datagramme können aus verschiedenen Gründen auftreten:

  1. Link-Layer-Retransmission: Verlorene Frames werden erneut übertragen
  2. Routing-Schleifen: Netzwerkkonfigurationsfehler
  3. Load Balancing: Datagramme werden auf mehrere Pfade kopiert
  4. Böswillige Angriffe: Absichtliches Senden doppelter Datagramme

A.2 Einschränkungen der IPv4-ID für Duplikaterkennung​

Das IPv4-ID-Feld hat als Duplikaterkennungsmechanismus folgende Einschränkungen:

A.2.1 Begrenzter ID-Raum​

16 Bit können nur 65.536 verschiedene Werte darstellen. In Hochgeschwindigkeitsumgebungen kann dieser Raum schnell erschöpft sein.

A.2.2 Vielfalt der ID-Generierungsalgorithmen​

Verschiedene Geräte und Betriebssysteme verwenden unterschiedliche ID-Generierungsalgorithmen.

A.2.3 Auswirkungen der Fragmentierung​

Alle Fragmente desselben Datagramms teilen denselben ID-Wert.

A.3 Auswirkungen der RFC 6864-Aktualisierungen​

Für atomare Datagramme (DF=1) bietet das IPv4-ID-Feld keine Duplikaterkennungsfähigkeit mehr. Empfänger müssen auf Transportschicht-Protokolle vertrauen.

A.4 Empfohlene Duplikaterkennungsmechanismen​

A.4.1 Transportschicht-Mechanismen​

  • TCP: Verwendet 32-Bit-Sequenznummern
  • UDP: Anwendungsschicht muss eigene Mechanismen implementieren
  • SCTP: Verwendet Transmission Sequence Numbers (TSN)

A.4.2 Anwendungsschicht-Mechanismen​

  1. Sequenznummern
  2. Zeitstempel
  3. Nachrichten-IDs (z.B. UUID)
  4. Idempotentes Design

A.4.3 Netzwerkschicht-Mechanismen​

IPsec: ESP- und AH-Protokolle enthalten Sequenznummern zur Erkennung von Replay-Angriffen.

A.5 Fazit​

Das IPv4-ID-Feld dient hauptsächlich der Fragmentierung und Reassemblierung, nicht der Duplikaterkennung. Anwendungs- und Protokolldesigner sollten auf Transportschicht- oder Anwendungsschicht-Mechanismen vertrauen.

Navigation:

Anhang B. Danksagungen​

Der Autor dieses Dokuments dankt den folgenden Personen und Organisationen für ihre Beiträge und Unterstützung.

B.1 Mitwirkende​

Die Entwicklung dieses Dokuments profitierte von Beiträgen und Feedback zahlreicher Mitglieder der IETF-Community. Besonderer Dank gilt:

  • Fred Baker - Tiefgehende Analyse von IPv4- und IPv6-Fragmentierungsmechanismen
  • Brian Carpenter - Vorschläge zu Interoperabilität und Übergangsstrategien
  • Wesley Eddy - Analyse der Auswirkungen auf Transportprotokolle
  • Fernando Gont - Detaillierte Diskussion von Sicherheitsüberlegungen
  • Alfred Hoenes - Sorgfältige Überprüfung der Dokumentstruktur
  • John Leslie - Diskussion von ID-Generierungsalgorithmen
  • Carlos Pignataro - Analyse der Implementierungsauswirkungen
  • Dan Wing - Diskussion der Auswirkungen auf Header-Kompression

B.2 Arbeitsgruppenbeiträge​

Dieses Dokument wurde in der IETF INTAREA (Internet Area) Arbeitsgruppe ausführlich diskutiert und überprüft.

B.3 Überprüfung und Feedback​

Dieses Dokument durchlief mehrere Überprüfungsrunden während des Standardisierungsprozesses.

B.4 Implementierungserfahrung​

Die Entwicklung dieses Dokuments berücksichtigte Erfahrungen aus mehreren Implementierungen:

  • Betriebssystem-Implementierungen: Linux, FreeBSD, Windows
  • Netzwerkgeräte: Router, Firewalls, Load Balancer
  • Anwendungen: Verschiedene Netzwerkanwendungen

B.5 Historischer Kontext​

Die Entwicklung wurde von folgenden historischen Dokumenten inspiriert:

  • RFC 791 (1981) - Internet Protocol
  • RFC 1122 (1989) - Requirements for Internet Hosts
  • RFC 4963 (2007) - IPv4 Reassembly Errors at High Data Rates

B.6 Organisatorische Unterstützung​

Der Autor dankt:

  • USC/ISI - Forschungsumgebung und Ressourcen
  • IETF - Standardisierungsplattform
  • IRTF - Forschungsergebnisse und theoretische Grundlagen

B.7 Besonderer Dank​

Besonderer Dank an alle, die auf Mailinglisten, in Meetings und in privaten Diskussionen Feedback gaben.

B.8 Autoradresse​

Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
U.S.A.

Navigation: