7. Komprimierung von Subheadern (Compression of subheaders)

Dieser Abschnitt beschreibt, wie die Felder des IPv6-Basis-Headers, der IPv6-Erweiterungs-Header, des IPv4-Headers, des UDP-Headers und des TCP-Headers bei der Komprimierung behandelt werden. Jedes Feld wird in eine der folgenden Kategorien eingeteilt:

NOCHANGE (unverändert): Das Feld wird im komprimierten Header gesendet, und sein Wert wird als identisch mit dem im Kontext angenommen. Bei einem Fehler in der Ableitung muss ein vollständiger Header oder ein Header-Update gesendet werden, um dies zu korrigieren.
INFERRED (abgeleitet): Der Wert des Felds kann aus anderen Informationen abgeleitet werden (z. B. der Größe des Sicherungsschicht-Rahmens) und wird daher nicht im Header gesendet.
DEF (Definitionsfeld): Dieses Feld ist ein „Definitionsfeld“ (siehe Abschnitt 4.1), und sein Wert dient der Identifizierung des Paketstroms. Definitionsfelder werden im vollständigen Header gesendet und im Kontext (Vorlage) gespeichert.
SAME (gleich): Ähnlich wie NOCHANGE, gilt aber nur, wenn alle Bits des Felds identisch sind.
DELTA (Differenz): Im komprimierten Header wird die Differenz zwischen dem Feld und dem Kontextwert übertragen. Der Empfänger addiert diese Differenz zum Kontextwert, um das Feld wiederherzustellen.
RANDOM (zufällig): Das Feld wird im komprimierten Header unverändert gesendet, da es nicht vorhersehbar ist.

Jedes Feld des IPv6-Basis-Headers und der IPv6-Erweiterungs-Header wird gemäß den Kategorien oben behandelt, siehe die Klassifizierungstabellen am Ende dieses Kapitels (Abschnitte 7.1, 7.11, 7.12, 7.13).

7.1 IPv6-Header (IPv6 Header)

Jedes Feld des IPv6-Basis-Headers und der IPv6-Erweiterungs-Header wird gemäß den Tabellen behandelt. In diesen Tabellen sind die Spalten:

Field (Feld): Der Feldname des IPv6-Headers oder Erweiterungs-Headers.

Size (Größe): Die Größe des Felds in Bits.

DEF: Mit „Yes“ markiert, wenn das Feld ein Definitionsfeld ist (siehe Abschnitt 4.1).

Tmpl (Vorlage): Mit „Yes“ markiert, wenn das Feld im vollständigen Header gesendet und im Kontext gespeichert wird (Vorlage).

C (Komprimiert): Mit „Yes“ markiert, wenn das Feld im komprimierten Header gesendet wird.

Tmpl & C: Mit „Yes“ markiert, wenn das Feld sowohl im vollständigen als auch im komprimierten Header gesendet wird. Solche Felder werden nicht Teil des Kontexts.

Inferred (Abgeleitet): Beschreibt, ob das Feld aus anderen Informationen (z. B. der Größe des Sicherungsschicht-Rahmens) abgeleitet werden kann.

Notes (Anmerkungen): Anmerkungen zum Feld.

Field	Size	DEF	Tmpl	C	Tmpl & C	Inferred	Notes
Version	4	No	Yes	No	No	No	Konstant (6)
Traffic Class	8	No	Yes	Yes	No	No	Kann sich ändern
Flow Label	20	Yes	Yes	No	No	No	Definitionsfeld
Payload Length	16	No	No	No	No	Yes	Aus Rahmenlänge abgeleitet
Next Header	8	No	Yes	Yes	No	No	Kann sich ändern
Hop Limit	8	No	Yes	Yes	No	No	Kann sich ändern
Source Address	128	Yes	Yes	No	No	No	Definitionsfeld
Destination Address	128	Yes	Yes	No	No	No	Definitionsfeld

7.2 IPv6-Erweiterungs-Header (IPv6 Extension Headers)

Welche Erweiterungs-Header vorhanden sind und ihre relative Reihenfolge wird innerhalb eines Paketstroms voraussichtlich nicht wechseln. Sobald sich dies ändert, muss ein vollständiger Paket-Header gesendet werden. Das Next-Header-Feld im IPv6-Basis-Header und in allen IPv6-Erweiterungs-Headern ist NOCHANGE.

7.3 Optionen (Options)

Der Inhalt des Hop-by-Hop-Options-Headers und des Destination-Options-Headers verwendet die TLV- (Type-Length-Value-) „Options“-Kodierung (siehe [IPv6]):

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
            |  Option Type  |  Opt Data Len |  Option Data
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Das Feld Option Type und das Feld Opt Data Len werden für einen gegebenen Paketstrom als unveränderlich angenommen und sind daher NOCHANGE. Option Data ist RANDOM, sofern nicht anders angegeben.

Padding (Auffüllung)

Pad1-Option

            +-+-+-+-+-+-+-+-+
            |       0       |
            +-+-+-+-+-+-+-+-+

Die gesamte Option ist NOCHANGE.

PadN-Option

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
            |       1       |  Opt Data Len |  Option Data
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Alle Felder sind NOCHANGE.

7.4 Hop-by-Hop-Options-Header (Hop-by-Hop Options Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header          NOCHANGE
   Hdr Ext Len          NOCHANGE

   Options              TLV-kodierte Werte und Padding.
                        Klassifiziert wie in 7.3 oben, außer bei
                        der folgenden Jumbo-Payload-Option (siehe unten).

Jumbo-Payload-Option

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |       Option Type = 0xC2      |
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |          Opt Data Len = 4     |
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |       Jumbo Payload Length    |
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die ersten beiden Felder sind NOCHANGE, die Jumbo-Payload-Länge ist INFERRED.

7.5 Routing-Header (Routing Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                  Type-spezifische Daten                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alle Felder des Routing-Headers sind NOCHANGE.

Wenn der Routing-Typ nicht erkannt wird, können nicht alle Felder bestimmt werden, daher wird der gesamte Routing-Header als RANDOM klassifiziert.

Im Routing-Header vom Typ 0 ist die letzte Adresse DEF (wenn Segments Left > 0).

Der Routing-Header wird vollständig komprimiert. Dies ist ein großer Gewinn für Mobile IP.

7.6 Fragment-Header (Fragment Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |   Reserved   |  Fragment Off. |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Fragment Offset    | Res |   M   |        Identification      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Das erste Fragment eines Pakets hat Fragment Offset = 0, und die Fragmentkette kann vor Erreichen des Kompressionspunkts neu geordnet worden sein. Da Pakete neu geordnet werden können, kann der Fragment-Header des ersten Fragments nicht daraufhin untersucht werden, das Identification-Feld zu bestimmen. Daher werden die Felder des Fragment-Headers wie folgt klassifiziert:

   Next Header          NOCHANGE
   Hdr Ext Len          NOCHANGE (muss 0 sein)
   Reserved             NOCHANGE
   Fragment Offset      NOCHANGE (muss 0 sein)
   M (More Fragments)   NOCHANGE (muss 0 sein)
   Identification       RANDOM

Diese Klassifizierung bedeutet, dass ein Fragment-Header auf nur Next Header und Hdr Ext Len (beide NOCHANGE) komprimiert wird, der Rest ist abgeleitet (Fragment Offset und M müssen 0 sein, Identification ist RANDOM).

Gemäß den optionalen Richtlinien in Abschnitt 4.1 können Fragmente gruppiert werden.

7.7 Destination-Options-Header (Destination Options Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die einzigen in [IPv6] definierten Destination-Optionen sind Padding-Optionen, die wie in 7.3 behandelt werden.

Der gesamte Destination-Options-Header wird nach den „Regeln für IPv6-Erweiterungs-Header“ (7.2) behandelt.

7.8 Authentication-Header (AH, Authentication Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Header  |  Payload Len  |           Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Security Parameters Index (SPI)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Sequenznummer                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                                 |
    +                                                                 +
    |                  Authentifizierungsdaten (variabel)            |
    .                                                                 .
    .                                                                 .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alle Felder des AH-Headers sind NOCHANGE, aber die Authentifizierungsdaten sind RANDOM.

Das bedeutet, dass im komprimierten AH-Header weiterhin SPI und Sequenznummer (beide NOCHANGE und im komprimierten Header gesendet) vorhanden sind, während die Authentifizierungsdaten als RANDOM-Feld unverändert gesendet werden.

7.9 Encapsulating Security Payload (ESP, Kapselnde Sicherheitsnutzlast)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Security Parameters Index (SPI)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Sequenznummer                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Nutzdaten (variabel)                       |
    .                                                               .
    .                   Integrity Check Value (ICV)                 .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dieser Header bedeutet, dass der nachfolgende Paketteil verschlüsselt ist. SPI und Sequenznummer sind NOCHANGE (im komprimierten Header gesendet), aber im ESP-Tunnelmodus ist das gesamte IP-Paket verschlüsselt, daher muss der Kompressionspunkt zwischen dem ESP-Header und den nachfolgenden verschlüsselten Daten unterscheiden können.

Das bedeutet, dass das IP-Paket zusammen mit seinem ESP-Header dem Kompressor übergeben werden können muss, während die nach dem ESP verschlüsselten Daten nicht komprimiert werden.

Alles nach dem SPI ist verschlüsselt und wird daher nicht komprimiert.

7.10 Reihenfolge der Erweiterungs-Header (Order of Extension Headers)

IPv6-Erweiterungs-Header müssen in der in [IPv6] festgelegten Reihenfolge erscheinen. Wenn der Kompressor auf einen Erweiterungs-Header außerhalb der erwarteten Reihenfolge trifft, muss er einen vollständigen Header senden.

7.11 UDP-Header (UDP Header)

Der UDP-Header ist in [RFC-768] beschrieben. Das Next-Header-Feld in IPv6 oder das Protocol-Feld in IPv4 gibt an, ob das folgende Protokoll UDP ist.

Jedes Feld des UDP-Headers wird gemäß der folgenden Tabelle behandelt:

Field	Size	DEF	Tmpl	C	Tmpl & C	Inferred	Notes
Source Port	16	Yes	Yes	No	No	No	Definitionsfeld
Destination Port	16	Yes	Yes	No	No	No	Definitionsfeld
Length	16	No	No	No	No	Yes	Aus Rahmenlänge abgeleitet
Checksum	16	No	No	Yes	No	No	Ändert sich zufällig

Das Length-Feld des UDP-Headers muss mit dem Length-Feld des IP-Headers und des UDP-Headers selbst übereinstimmen und kann daher abgeleitet werden (INFERRED).

Der UDP-Header wird typischerweise auf 2 Byte komprimiert, d. h. die UDP-Prüfsumme (RANDOM) wird unverändert übertragen und die übrigen Felder werden komprimiert.

7.12 TCP-Header (TCP Header)

Der TCP-Header ist in [RFC-793] beschrieben. Das Next-Header-Feld in IPv6 oder das Protocol-Feld in IPv4 gibt an, ob das folgende Protokoll TCP ist.

Jedes Feld des TCP-Headers wird gemäß der folgenden Tabelle behandelt:

Field	Size	DEF	Tmpl	C	Tmpl & C	Inferred	Notes
Source Port	16	Yes	Yes	No	No	No	Definitionsfeld
Destination Port	16	Yes	Yes	No	No	No	Definitionsfeld
Sequence Number	32	No	Yes	Yes	No	No	Differenzkodiert
Acknowledgment Number	32	No	Yes	Yes	No	No	Differenzkodiert
Data Offset	4	No	Yes	Yes	No	No	Ändert sich, wenn Optionen sich ändern
Reserved	4	No	Yes	No	No	No	Typischerweise null
Flags	8	No	Yes	Yes	No	No	Kann sich ändern
Window	16	No	Yes	Yes	No	No	Unverändert gesendet
Checksum	16	No	No	Yes	No	No	Unverändert gesendet
Urgent Pointer	16	No	Yes	Yes	No	No	Selten verwendet
Options	var	No	Yes	Yes	No	No	Ändert sich selten

Es gibt zwei Möglichkeiten, den komprimierten TCP-Header zu bilden. Die Feldklassifizierung lautet:

       Source Port           NOCHANGE  (DEF)
       Destination Port      NOCHANGE  (DEF)
       Sequence Number       DELTA
       Acknowledgment Number DELTA
       Offset                NOCHANGE
       Reserved              DELTA               (wenn abweichend vom Kontext,
                                                   sonst NOCHANGE)
       Urg, Psh              RANDOM              (im Flag-Oktett platziert)
       Ack                   INFERRED als 1
       Rst, Syn, Fin         INFERRED als 0
       Window                DELTA               (bei Änderung von Window,
                                                   sonst NOCHANGE)
       Checksum              RANDOM
       Urgent Pointer        DELTA               (wenn Urg gesetzt, gesendet,
                                                   sonst NOCHANGE)
       Options, Padding      DELTA               (bei Änderung von Options,
                                                   sonst NOCHANGE)

Diese Methode ist im Wesentlichen die von Jacobson in [RFC-1144] beschriebene Differenzkodierung, mit dem Unterschied, wo das Flag-Oktett platziert wird und wie Änderungen von Feldern wie Window behandelt werden.

7.13 IPv4-Header (IPv4 Header)

Der IPv4-Header ist in [RFC-791] beschrieben. Die folgende Tabelle zeigt die Klassifizierung der IPv4-Header-Felder:

Field	Size	DEF	Tmpl	C	Tmpl & C	Inferred	Notes
Version	4	No	Yes	No	No	No	Konstant (4)
IHL	4	No	Yes	No	No	No	Konstant (typischerweise 5)
Type of Service	8	No	Yes	Yes	No	No	Kann sich ändern
Total Length	16	No	No	No	No	Yes	Aus Rahmenlänge abgeleitet
Identification	16	No	No	Yes	No	No	Ändert sich zufällig
Flags	3	No	Yes	Yes	No	No	Kann sich ändern
Fragment Offset	13	No	Yes	Yes	No	No	Ändert sich bei Fragmentierung
Time to Live	8	No	Yes	Yes	No	No	Kann sich ändern
Protocol	8	Yes	Yes	No	No	No	Definitionsfeld
Header Checksum	16	No	No	Yes	No	No	An jedem Hop neu berechnet
Source Address	32	Yes	Yes	No	No	No	Definitionsfeld
Destination Address	32	Yes	Yes	No	No	No	Definitionsfeld
Options	var	No	Yes	Yes	No	No	Selten verwendet

Das Identification-Feld im vorangehenden IPv4-Header ist RANDOM.

Wenn auf den IPv4-Header unmittelbar ein TCP-Header folgt, müssen IPv4- und TCP-Header als eine Einheit zusammen komprimiert werden (siehe Abschnitt 6). Dabei können die Bits 6 und 7 des Type-of-Service-Felds (Bits 14 und 15 des ersten Worts) über das R-Flag übergeben werden (siehe Abschnitt 6 a).

Es gibt zwei Möglichkeiten, den IPv4-Header zu komprimieren.

a) Wenn der IPv4-Header nicht zu einem Fragment gehört (das MF-Flag ist nicht gesetzt und Fragment Offset ist null) und keine Optionen vorhanden sind (IHL ist 5), wird er wie folgt klassifiziert:

       Version              NOCHANGE   (DEF)
       IHL                  NOCHANGE   (DEF, must be 5)
       Type of Service      NOCHANGE   (might be DEF, see sect 4.1)
                                       (see also 6 a)
       Total Length         INFERRED   (from link-layer implementation
                                        or encapsulating IP header)

       Identification       DELTA/     (If the Protocol field has the
                                       (value corresponding to TCP)
                            RANDOM     (otherwise)

       Flags                NOCHANGE   (MF flag must not be set)
       Fragment Offset      NOCHANGE   (must be zero)
       Time to Live         NOCHANGE   (might be DEF, see sect 4.1)
       Protocol             NOCHANGE
       Header Checksum      INFERRED   (calculated from other fields)
       Source Address       NOCHANGE   (DEF)
       Destination Address  NOCHANGE   (DEF)
       Options, Padding                (not present)

Hinweis: Wenn unmittelbar ein TCP-Header folgt, MUSS der IPv4-Header zusammen mit dem TCP-Header als eine Einheit komprimiert werden, wie in Abschnitt 6 beschrieben. Die Bits 6 und 7 des Type-of-Service-Feldes (Bits 14 und 15 des ersten Wortes) können dann über das R-flag übergeben werden (siehe Abschnitt 6 a).

b) Wenn der IPv4-Header zu einem Fragment gehört (MF-Bit gesetzt oder Fragment Offset ungleich null) oder Optionen vorhanden sind (IHL > 5), sind alle Felder RANDOM (d. h. wenn der Header komprimiert wird, werden alle Felder unverändert gesendet und nicht komprimiert). Diese Klassifizierung erlaubt die Komprimierung des Tunnel-Headers, nicht aber des Fragment-Headers, wenn Fragmente getunnelt werden. Gehört der IPv4-Header zu einem Fragment, so beendet er die komprimierbare Kette von Subheadern, d. h. er muss der letzte zu komprimierende Subheader sein. Besitzt der IPv4-Header Optionen, gehört aber nicht zu einem Fragment, so beendet er die komprimierbare Kette von Subheadern nicht, sodass nachfolgende Subheader komprimiert werden können.

Ein Kompressor, der den optionalen Richtlinien aus Abschnitt 4.1 folgt, verwendet im Fall a) die Felder Version, Source Address und Destination Address zusammen mit der Tatsache, dass keine IPv4-Optionen vorhanden sind und dass es sich nicht um ein Fragment handelt, um den Paketstrom zu definieren.

Fall b) kann zwei Arten von Paketströmen definieren, je nachdem, ob der IPv4-Header zu einem Fragment gehört oder nicht.

Gehört der IPv4-Header in Fall b) zu einem Fragment, so verwendet ein Kompressor, der den optionalen Richtlinien folgt, diese Tatsache zusammen mit Version, Source Address und Destination Address, um den Paketstrom zu bestimmen.

Gehört der IPv4-Header in Fall b) nicht zu einem Fragment, so muss er Optionen besitzen. Ein Kompressor, der den optionalen Richtlinien folgt, verwendet diese Tatsache, jedoch nicht die Größe der Optionen, zusammen mit Version, Source Address und Destination Address, um den Paketstrom zu bestimmen.

7.14 Minimal-Encapsulation-Header (Minimal Encapsulation Header)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol    |S|  reserved   |        Header Checksum        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Original Destination Address                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :            (if present) Original Source Address               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Protocol                             NOCHANGE
Original Source Address Present (S)  NOCHANGE
reserved                             NOCHANGE
Header Checksum                      INFERRED (aus anderen Werten berechnet)
Original Destination Address         NOCHANGE
Original Source Address              NOCHANGE (nur vorhanden, wenn S=1)

Dieser Header wird voraussichtlich von Mobile IP verwendet.