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:
- Link-Layer-Retransmission: Verlorene Frames werden erneut übertragen
- Routing-Schleifen: Netzwerkkonfigurationsfehler
- Load Balancing: Datagramme werden auf mehrere Pfade kopiert
- 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
- Sequenznummern
- Zeitstempel
- Nachrichten-IDs (z.B. UUID)
- 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: