Zusammenfassung

  • IPComp verarbeitet jedes Datagramm verlustfrei und unabhängig. Verlust oder Umordnung dürfen kein Wörterbuch aus einem früheren Paket erforderlich machen; Empfänger unterstützen komprimierte und originale Formen zugleich.
  • Ist komprimierte Nutzlast einschließlich des vier Oktette breiten IPComp-Headers nicht kleiner, muss das Original ohne IPComp-Header gesendet werden.
  • Der CPI ist ein vom Dekompressor gewählter, richtungs- und zielbezogener Index. Er ist weder Berechtigungsnachweis noch globaler Algorithmusname oder Beleg eines Nutzens.

Ein ausgehandeltes Merkmal ohne ständige Spur

Bei vielen Protokollen scheint die Abwesenheit eines Headers das Fehlen der Fähigkeit zu beweisen. IPComp trennt beides. Die Association beschreibt, wie ein komprimiertes Paket verstanden wird. Sie verpflichtet nicht jede Nutzlast zur Transformation.

Wiederholte Daten schrumpfen, kurze Steuerpakete wachsen, bereits komprimierte Inhalte verbrauchen oft nur Rechenzeit. Eine Konfiguration kennt zukünftige Bytes nicht. Darum blieb die Ausführungsentscheidung beim einzelnen Datagramm.

Protocol beziehungsweise Next Header 108 belegt eine IPComp-Form an dieser Stelle. Fehlt 108, ist nur die Originalform sichtbar. Ob Schwelle, adaptive Pause, Inkompressibilität oder fehlende Association dahintersteht, verrät das Paket nicht.

Kompression vor Verschlüsselung und Fragmentierung

RFC 2393 führte IPComp 1998 in der Umgebung von IPsec ein. Verschlüsselung lässt Daten zufällig erscheinen und beseitigt die Struktur, die eine tiefere Schicht komprimieren könnte. Deshalb erfolgt Kompression ausgehend vor Authentisierung und Verschlüsselung sowie vor Fragmentierung.

Eingehend kommt Dekompression nach Reassembly und IP-Sicherheitsverarbeitung. Kompression bietet selbst keine Sicherheit. Sie arbeitet vor der Schutztransformation und wird erst nach deren Prüfung rückgängig gemacht.

Der äußere IPv4-Header bleibt erhalten. Im Tunnelmodus zählt ein innerer IP-Header zur äußeren Nutzlast. IPv6 lässt Header unkomprimiert, die Knoten auf dem Weg untersuchen müssen; ein Fragment Header steht vor IPComp.

Zwischen Datagrammen wird kein Rekonstruktionszustand geteilt. Jedes Paket ist allein dekomprimierbar, weil sein Vorgänger fehlen oder später eintreffen kann. Running Code und IP-Verhalten begrenzen damit den theoretischen Gewinn eines fortlaufenden Wörterbuchs.

Vier Oktette gehörten in die Bilanz

Die Non-Expansion Policy in RFC 3173 zählt den IPComp-Header mit. Nur wenn komprimierte Nutzlast plus vier Oktette kleiner sind, entsteht die komprimierte Form. Andernfalls wird das Original ohne zusätzlichen Header übertragen.

So entfallen nutzlose Dekompressionszyklen. Zugleich wird verhindert, dass eine Optimierung ein ursprünglich MTU-gerechtes Paket vergrößert und Fragmentierung auslöst.

Implementierungen dürfen früher aussteigen. Kleine Pakete können unter einer lokalen Schwelle liegen. Mehrere Fehlschläge können eine adaptive Versuchspause auslösen. Ein algorithmischer Test kann unkomprimierbare Daten erkennen. Zähler und Schwellen sind keine Wire-Konstanten.

RFC 2394 empfiehlt für DEFLATE aufgrund informeller Tests, Puffer unter 90 Byte nicht zu versuchen. Der Wert ist weder globale IPComp-Grenze noch Garantie für größere Eingaben. Andere Hardware, Algorithmen und Links behalten ihre Entscheidung.

Die Originalform kann deshalb mehrere korrekte Ursachen haben. Auch eine kleinere Form beweist nur die Größenbedingung, nicht geringere Latenz oder bessere Gesamtkosten. IPComp garantiert Verlustfreiheit und verhindert Expansion auf dem Wire; es verspricht keinen universellen Performancegewinn.

Der Empfänger wählte seinen Index

Der vier Oktette breite Header enthält ursprünglichen Next Header, reservierte Flags und 16-Bit-CPI. Nach erfolgreicher Dekompression entfernt der Empfänger IPComp, stellt den ursprünglichen Selektor wieder her und setzt die rekonstruierte Nutzlast ein.

CPI-Bereiche decken bekannte, ausgehandelte und private Werte ab. Entscheidend ist die Richtung: Jeder Knoten wählt unabhängig seinen Eingangs-CPI, und der Sender benutzt die Wahl des Dekompressors. CPI plus Zieladresse bestimmt die Kompressionsmerkmale.

Die Zahl ist daher kein globaler Name. Wiederverwendung eines bekannten CPI in mehreren Sessions kann Lebensdauer und adaptive Zähler ununterscheidbar machen. RFC 3173 empfiehlt den ausgehandelten Bereich, wenn Eindeutigkeit nötig ist. Der Index findet Zustand; er legitimiert ihn nicht.

Kein unsichtbarer Default

Eine IPCA umfasst Modus, Algorithmus, Parameter und CPI. Sie kann alle Pakete zwischen Knoten oder ausgewählte Sessions betreffen. Richtungen werden getrennt vereinbart und dürfen unterschiedliche Algorithmen verwenden.

Es gibt keinen Standardalgorithmus und keinen für alle IPComp-Implementierungen verpflichtenden Transform. Aus „IPComp“ folgt nicht „DEFLATE“. Gemeinsamkeit muss ausdrücklich entstehen.

RFC 3173 ersetzte den ersten Text vor allem zur IKE-Klärung. IKEv2 erlaubt mehrere Angebote, aber höchstens eine Annahme. Nicht angebotene und angenommene Algorithmen dürfen nicht eingesetzt werden.

Die virtuelle Association lebt nicht außerhalb ihrer ESP/AH Child SA und verschwindet mit ihr. Dennoch bleibt IPComp-Verhandlung von kryptografischen Parametern getrennt. Gemeinsame Lebensdauer macht CPI nicht zum Schlüssel.

Weniger Bytes, weniger unmittelbare Sicht

Ohne IPsec kann IPComp Grenzfiltern Felder entziehen. Der ursprüngliche Protocol-Wert wandert, Ports liegen komprimiert vor. Ein Gerät ohne Association liest sie nicht an ihrer früheren Position.

Das ist keine Vertraulichkeit. Dem Dritten fehlt Auswertungskontext. Wenn jedes Paket gefiltert oder abgerechnet werden muss, verlangt RFC 3173 eine sichere Übermittlung der Association an den Filter.

Der Betriebsnachweis sollte Konfiguration, Annahme, Versuch, Wire-Form, CPI-Lookup und Wiederherstellung trennen. „Kompression aktiv“ beweist keine vollständige Kette.

IPComp schrieb Optimierung damit eine bescheidene Rolle zu. Die gemeinsame Spezifikation definierte, wie ein Erfolg verständlich wird. Ob er diesmal stattfinden sollte, entschied das laufende Datagramm.

Quellen