7. Compression des sous-en-têtes (Compression of subheaders)
7. Compression des sous-en-têtes (Compression of subheaders)
Cette section décrit comment les champs des en-têtes de base IPv6, des en-têtes d'extension IPv6, des en-têtes IPv4, UDP et TCP sont traités lors de la compression. Chaque champ est classé dans l'une des catégories suivantes :
- NOCHANGE (inchangé) : le champ est envoyé dans l'en-tête compressé et sa valeur est supposée identique à celle du contexte. En cas d'erreur d'inférence, un en-tête complet ou une mise à jour d'en-tête doit être envoyé pour corriger.
- INFERRED (déduit) : la valeur du champ peut être déduite d'autres informations (par exemple la taille de la trame de la couche liaison) et n'est donc pas envoyée dans l'en-tête.
- DEF (champ de définition) : ce champ est un « champ de définition » (voir section 4.1) et sa valeur sert à identifier le flux de paquets. Les champs de définition sont envoyés dans l'en-tête complet et stockés dans le contexte (modèle).
- SAME (identique) : similaire à NOCHANGE, mais ne s'applique que si tous les bits du champ sont identiques.
- DELTA (différentiel) : l'en-tête compressé contient la différence entre le champ et la valeur du contexte. Le récepteur ajoute cette différence à la valeur du contexte pour reconstruire le champ.
- RANDOM (aléatoire) : le champ est envoyé tel quel dans l'en-tête compressé car il n'est pas prévisible.
Chaque champ de l'en-tête de base IPv6 et des en-têtes d'extension IPv6 est traité selon les tableaux de classification figurant à la fin de ce chapitre (sections 7.1, 7.11, 7.12, 7.13).
7.1 En-tête IPv6 (IPv6 Header)
Chaque champ de l'en-tête de base IPv6 et des en-têtes d'extension IPv6 est traité selon les tableaux de l'Annexe A. Dans ces tableaux, les colonnes sont :
Champ (Field)
Le nom du champ dans l'en-tête IPv6 ou l'en-tête d'extension.
Taille (Size)
La taille du champ en bits.
DEF
Marqué Oui si le champ est un champ de définition (voir section 4.1).
Tmpl (Modèle)
Marqué Oui si le champ est envoyé dans l'en-tête complet et stocké dans le contexte (modèle).
C (Compressé)
Marqué Oui si le champ est envoyé dans l'en-tête compressé.
Tmpl & C
Marqué Oui si le champ est envoyé à la fois dans l'en-tête complet et dans l'en-tête compressé. Ces champs ne font pas partie du contexte.
Inféré (Inferred)
Décrit si le champ peut être déduit d'autres informations, par exemple de la taille de la trame de couche liaison.
Notes
Commentaires sur le champ.
| Champ | Taille | DEF | Tmpl | C | Tmpl & C | Inféré | Notes |
|---|---|---|---|---|---|---|---|
| Version | 4 | No | Yes | No | No | No | constante (6) |
| Traffic Class | 8 | No | Yes | Yes | No | No | peut changer |
| Flow Label | 20 | Yes | Yes | No | No | No | champ de définition |
| Payload Length | 16 | No | No | No | No | Yes | déduit de la longueur de trame |
| Next Header | 8 | No | Yes | Yes | No | No | peut changer |
| Hop Limit | 8 | No | Yes | Yes | No | No | peut changer |
| Source Address | 128 | Yes | Yes | No | No | No | champ de définition |
| Destination Address | 128 | Yes | Yes | No | No | No | champ de définition |
7.2 En-têtes d'extension IPv6 (IPv6 Extension Headers)
La présence et l'ordre relatif des en-têtes d'extension ne sont pas censés changer au sein d'un flux de paquets. En cas de changement, un en-tête de paquet complet doit être envoyé. Tous les champs Next Header des en-têtes de base IPv6 et d'extension IPv6 sont NOCHANGE.
7.3 Options
Le contenu des en-têtes d'options Hop-by-Hop et Destination Options est codé avec des « options » TLV (voir [IPv6]) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Les champs Option Type et Opt Data Len sont supposés fixes pour un flux de paquets donné, ils sont donc classés NOCHANGE. Les données d'option (Option Data) sont RANDOM, sauf indication contraire ci-dessous.
Remplissage (Padding)
- Option Pad1
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
L'option entière est NOCHANGE.
- Option PadN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Tous les champs sont NOCHANGE.
7.4 En-tête Hop-by-Hop Options [IPv6, section 4.3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Hdr Ext Len NOCHANGE
Options Valeurs codées TLV et remplissage.
Classifiées selon 7.3 ci-dessus, sauf
l'option Jumbo Payload (voir ci-dessous).
Option Jumbo Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type = 0xC2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Data Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les deux premiers champs sont NOCHANGE, Jumbo Payload Length est INFERRED.
7.5 En-tête Routing [IPv6, section 4.4]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. données spécifiques au type (type-specific data)
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tous les champs du Routing Header sont NOCHANGE.
Si le Routing Type n'est pas reconnu, il est impossible de déterminer tous les champs, le Routing Header entier est donc classé RANDOM.
Dans le Routing Header de type 0, la dernière adresse est DEF si (Segments Left > 0).
Les Routing Headers sont complètement compressés. C'est un gain important pour Mobile IP.
7.6 En-tête Fragment [IPv6, section 4.5]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Reserved | Fragment Off. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset | Res | M | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le premier fragment d'un paquet a Fragment Offset = 0 et la chaîne de fragments peut avoir été réordonnée avant d'atteindre le point de compression. Comme les paquets peuvent être réordonnés, le Fragment Header du premier fragment ne peut pas être examiné pour déterminer le champ Identification. Les champs du Fragment Header sont donc classés comme suit :
Next Header NOCHANGE
Hdr Ext Len NOCHANGE (doit être 0)
Reserved NOCHANGE
Fragment Offset NOCHANGE (doit être 0)
M (More Fragments) NOCHANGE (doit être 0)
Identification RANDOM
Cette classification signifie qu'un Fragment Header est compressé jusqu'à ne conserver que Next Header et Hdr Ext Len (tous deux NOCHANGE), le reste étant déduit (Fragment Offset et M doivent être 0, Identification est RANDOM).
Les fragments peuvent être regroupés selon les directives optionnelles de la section 4.1.
7.7 En-tête Destination Options [IPv6, section 4.6]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les seules Destination Options définies dans [IPv6] sont les options de remplissage, traitées en 7.3.
L'en-tête Destination Options entier est traité selon les règles des en-têtes d'extension IPv6 (7.2).
7.8 En-tête Authentication (AH) [RFC-1826]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (numéro de séquence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authentication Data (longueur variable) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tous les champs de l'en-tête AH sont NOCHANGE, mais les données d'authentification (Authentication Data) sont RANDOM.
Cela signifie qu'après compression de l'en-tête AH, le SPI et le numéro de séquence (tous deux NOCHANGE et envoyés dans l'en-tête compressé) sont conservés, tandis que les données d'authentification sont envoyées telles quelles en tant que champ RANDOM.
7.9 En-tête Encapsulating Security Payload (ESP) [RFC-1827]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (numéro de séquence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (longueur variable) |
. .
. Integrity Check Value (ICV) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cet en-tête signifie que la partie suivante du paquet est chiffrée. Le SPI et le numéro de séquence sont NOCHANGE (envoyés dans l'en-tête compressé), mais en mode tunnel ESP, l'intégralité du paquet IP est chiffrée, le point de compression doit donc pouvoir distinguer l'en-tête ESP des données chiffrées qui suivent.
Cela signifie qu'un paquet IP et son en-tête ESP peuvent être fournis au compresseur, mais les données chiffrées après ESP ne sont pas compressées.
Tout ce qui suit le SPI est chiffré et n'est donc pas compressé.
7.10 Ordre des en-têtes d'extension (Order of Extension Headers)
Les en-têtes d'extension IPv6 doivent apparaître dans l'ordre spécifié dans [IPv6]. Lorsqu'un compresseur rencontre un en-tête d'extension dans un ordre différent de celui attendu, il doit envoyer un en-tête complet.
7.11 En-tête UDP (UDP Header)
Chaque champ de l'en-tête UDP est traité selon les tableaux de l'Annexe A.
| Champ | Taille | DEF | Tmpl | C | Tmpl & C | Inféré | Notes |
|---|---|---|---|---|---|---|---|
| Source Port | 16 | Yes | Yes | No | No | No | champ de définition |
| Destination Port | 16 | Yes | Yes | No | No | No | champ de définition |
| Length | 16 | No | No | No | No | Yes | déduit de la longueur de trame |
| Checksum | 16 | No | No | Yes | No | No | change aléatoirement |
La somme de contrôle UDP DEVRAIT être calculée avant la compression. Cela permet au compresseur de détecter les erreurs de bits dans la charge utile UDP ou l'en-tête UDP. La somme de contrôle est utilisée pour le diagnostic et la détection d'erreurs. Si la couche liaison ne fournit pas de détection d'erreurs robuste, un paquet UDP livré après décompression peut contenir des erreurs, car la couche liaison peut avoir transmis un paquet corrompu au module de compression d'en-têtes. Dans ce cas, la somme de contrôle UDP capture ces erreurs. Même lorsque la somme de contrôle UDP est nulle (c'est-à-dire non utilisée), elle est incluse dans l'en-tête compressé, mais optimisée à zéro, donc sans surcoût.
7.12 En-tête TCP (TCP Header)
La compression des en-têtes TCP suit [RFC-1144]. Cependant, le format de l'en-tête TCP compressé défini dans ce document diffère du format de [RFC-1144]. Les différences sont :
-
Un CID est envoyé avant l'en-tête TCP compressé. Cela permet de multiplexer plusieurs connexions TCP sur une seule liaison.
-
Le champ de numéro de connexion n'est pas utilisé dans l'en-tête compressé. Le CID est utilisé à la place.
-
Le champ de fenêtre est toujours envoyé tel quel (s'il a changé), et non comme différence par rapport à la valeur précédente. Cela simplifie la récupération après perte.
-
Le cas particulier d'encodage où la somme de contrôle TCP n'est pas envoyée n'est pas effectué. La somme de contrôle est toujours envoyée telle quelle.
-
Le mode non compressé de [RFC-1144] n'est pas pris en charge. Si le compresseur décide de ne pas compresser un paquet TCP, il est envoyé comme paquet IPv4 ou IPv6 régulier.
Chaque champ de l'en-tête TCP est traité selon les tableaux de l'Annexe A.
La somme de contrôle TCP DEVRAIT être calculée avant la compression, pour les mêmes raisons que pour UDP (voir section 8).
La section 10 décrit deux mécanismes pour accélérer la récupération après perte pour les flux TCP.
| Champ | Taille | DEF | Tmpl | C | Tmpl & C | Inféré | Notes |
|---|---|---|---|---|---|---|---|
| Source Port | 16 | Yes | Yes | No | No | No | champ de définition |
| Destination Port | 16 | Yes | Yes | No | No | No | champ de définition |
| Sequence Number | 32 | No | Yes | Yes | No | No | codage différentiel |
| Acknowledgment Number | 32 | No | Yes | Yes | No | No | codage différentiel |
| Data Offset | 4 | No | Yes | Yes | No | No | change si les options changent |
| Reserved | 4 | No | Yes | No | No | No | généralement zéro |
| Flags | 8 | No | Yes | Yes | No | No | peut changer |
| Window | 16 | No | Yes | Yes | No | No | envoyé tel quel |
| Checksum | 16 | No | No | Yes | No | No | envoyé tel quel |
| Urgent Pointer | 16 | No | Yes | Yes | No | No | rarement utilisé |
| Options | var | No | Yes | Yes | No | No | change rarement |
7.13 En-tête IPv4 (IPv4 Header)
Le format de l'en-tête IPv4 est le suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Champ | Taille | DEF | Tmpl | C | Tmpl & C | Inféré | Notes |
|---|---|---|---|---|---|---|---|
| Version | 4 | No | Yes | No | No | No | constante (4) |
| IHL | 4 | No | Yes | No | No | No | constante (généralement 5) |
| Type of Service | 8 | No | Yes | Yes | No | No | peut changer |
| Total Length | 16 | No | No | No | No | Yes | déduit de la longueur de trame |
| Identification | 16 | No | No | Yes | No | No | change aléatoirement |
| Flags | 3 | No | Yes | Yes | No | No | peut changer |
| Fragment Offset | 13 | No | Yes | Yes | No | No | change si fragment |
| Time to Live | 8 | No | Yes | Yes | No | No | peut changer |
| Protocol | 8 | Yes | Yes | No | No | No | champ de définition |
| Header Checksum | 16 | No | No | Yes | No | No | recalculé à chaque saut |
| Source Address | 32 | Yes | Yes | No | No | No | champ de définition |
| Destination Address | 32 | Yes | Yes | No | No | No | champ de définition |
| Options | var | No | Yes | Yes | No | No | rarement utilisé |
Il existe deux manières de compresser l'en-tête IPv4.
a) Si l'en-tête IPv4 ne correspond pas à un fragment (le drapeau MF n'est pas positionné et Fragment Offset vaut zéro) et qu'il n'y a pas d'options (IHL vaut 5), il est classé comme suit :
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)
Note : lorsqu'un en-tête TCP suit immédiatement, l'en-tête IPv4 et l'en-tête TCP DOIVENT être compressés comme une unité ainsi que décrit dans la section 6. (MUST). Les bits 6 et 7 du champ Type of Service (bits 14 et 15 du premier mot) peuvent alors être transmis à l'aide du drapeau R (voir section 6 a).
b) Si l'en-tête IPv4 correspond à un fragment (drapeau MF positionné ou Fragment Offset non nul), ou s'il comporte des options (IHL > 5), tous les champs sont RANDOM (c'est-à-dire que si l'en-tête est compressé, tous les champs sont envoyés tels quels et ne sont pas compressés). Cette classification permet de compresser l'en-tête de tunnel mais pas l'en-tête de fragment lorsque des fragments sont tunnelisés. Si l'en-tête IPv4 correspond à un fragment, il termine la chaîne de sous-en-têtes compressibles, c'est-à-dire qu'il doit être le dernier sous-en-tête compressé. Si l'en-tête IPv4 a des options mais ne correspond pas à un fragment, il ne termine pas la chaîne de sous-en-têtes compressibles, les sous-en-têtes suivants peuvent donc être compressés.
Un compresseur suivant les directives optionnelles de la section 4.1 utilisera, dans le cas a), le Version, la Source Address et la Destination Address pour définir le flux de paquets, ainsi que le fait qu'il n'y a pas d'options IPv4 et que ce n'est pas un fragment.
Le cas b) peut définir deux types de flux de paquets selon que l'en-tête IPv4 correspond à un fragment ou non.
Si l'en-tête IPv4 du cas b) correspond à un fragment, un compresseur suivant les directives optionnelles utilisera ce fait, ainsi que le Version, la Source Address et la Destination Address, pour déterminer le flux de paquets.
Si l'en-tête IPv4 du cas b) ne correspond pas à un fragment, il doit avoir des options. Un compresseur suivant les directives optionnelles utilisera ce fait, mais pas la taille des options, ainsi que le Version, la Source Address et la Destination Address, pour déterminer le flux de paquets.
7.14 En-tête Minimal Encapsulation [RFC-2004, section 3.1]
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 (calculé à partir
d'autres valeurs)
Original Destination Address NOCHANGE
Original Source Address NOCHANGE (présent seulement
si S=1)
Cet en-tête est susceptible d'être utilisé par Mobile IP.