Passa al contenuto principale

7. Compressione dei sotto-header (Compression of subheaders)

7. Compressione dei sotto-header (Compression of subheaders)

Questa sezione descrive come i campi dell'intestazione base IPv6, delle intestazioni di estensione IPv6, dell'intestazione IPv4, dell'intestazione UDP e dell'intestazione TCP vengono trattati durante la compressione. Ogni campo viene classificato in una delle seguenti categorie:

  • NOCHANGE (invariato): Il campo viene inviato nell'intestazione compressa e si suppone che il suo valore sia identico a quello nel contesto. In caso di errore nella derivazione, deve essere inviato un'intestazione completa o un aggiornamento dell'intestazione per correggerlo.
  • INFERRED (dedotto): Il valore del campo può essere dedotto da altre informazioni (ad es. la dimensione del frame del livello di collegamento) e pertanto non viene inviato nell'intestazione.
  • DEF (campo di definizione): Questo campo è un "campo di definizione" (vedere la sezione 4.1) e il suo valore serve a identificare il flusso di pacchetti. I campi di definizione vengono inviati nell'intestazione completa e memorizzati nel contesto (template).
  • SAME (uguale): Simile a NOCHANGE, ma si applica solo se tutti i bit del campo sono identici.
  • DELTA (differenza): Nell'intestazione compressa viene trasmessa la differenza tra il campo e il valore di contesto. Il ricevitore somma questa differenza al valore di contesto per ripristinare il campo.
  • RANDOM (casuale): Il campo viene inviato così com'è nell'intestazione compressa in quanto non prevedibile.

Ogni campo dell'intestazione base IPv6 e delle intestazioni di estensione IPv6 viene trattato secondo le categorie sopra, vedi le tabelle di classificazione alla fine di questo capitolo (sezioni 7.1, 7.11, 7.12, 7.13).

7.1 Intestazione IPv6 (IPv6 Header)

Ogni campo dell'intestazione base IPv6 e delle intestazioni di estensione IPv6 viene trattato secondo le tabelle. In tali tabelle, le colonne sono:

Field (campo): Nome del campo nell'intestazione IPv6 o nell'intestazione di estensione.

Size (dimensione): Dimensione del campo, in bit.

DEF: Marcato Yes se il campo è un campo di definizione (vedere la sezione 4.1).

Tmpl (template): Marcato Yes se il campo viene inviato nell'intestazione completa e memorizzato nel contesto (template).

C (compressed, compresso): Marcato Yes se il campo viene inviato nell'intestazione compressa.

Tmpl & C: Marcato Yes se il campo viene inviato sia nell'intestazione completa sia nell'intestazione compressa. Questi campi non diventano parte del contesto.

Inferred (dedotto): Descrive se il campo può essere dedotto da altre informazioni (ad es. la dimensione del frame del livello di collegamento).

Notes (note): Note sul campo.

FieldSizeDEFTmplCTmpl & CInferredNotes
Version4NoYesNoNoNoCostante (6)
Traffic Class8NoYesYesNoNoPuò cambiare
Flow Label20YesYesNoNoNoCampo di definizione
Payload Length16NoNoNoNoYesDedotto dalla lunghezza del frame
Next Header8NoYesYesNoNoPuò cambiare
Hop Limit8NoYesYesNoNoPuò cambiare
Source Address128YesYesNoNoNoCampo di definizione
Destination Address128YesYesNoNoNoCampo di definizione

7.2 Intestazioni di estensione IPv6 (IPv6 Extension Headers)

Quali intestazioni di estensione siano presenti e il loro ordine relativo non dovrebbero cambiare all'interno di un flusso di pacchetti. Quando ciò accade, deve essere inviata un'intestazione di pacchetto completa. Il campo Next Header nell'intestazione base IPv6 e in tutte le intestazioni di estensione IPv6 è NOCHANGE.

7.3 Opzioni (Options)

Il contenuto dell'intestazione delle opzioni Hop-by-Hop e dell'intestazione delle opzioni di destinazione utilizza la codifica delle opzioni TLV (Type-Length-Value, tipo-lunghezza-valore) (vedere [IPv6]):

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

Il campo Option Type e il campo Opt Data Len si suppongono invariati per un dato flusso di pacchetti e sono pertanto NOCHANGE. Option Data è RANDOM, salvo diversa indicazione.

Padding (riempimento)

  • Opzione Pad1
            +-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+

L'intera opzione è NOCHANGE.

  • Opzione PadN
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Tutti i campi sono NOCHANGE.

7.4 Intestazione delle opzioni Hop-by-Hop (Hop-by-Hop Options Header)

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

Options Valori codificati TLV e padding.
Classificati come in 7.3 sopra, eccetto
per la seguente opzione Jumbo Payload (vedi sotto).

Opzione Jumbo Payload (Jumbo Payload Option)

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type = 0xC2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Data Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I primi due campi sono NOCHANGE, la Jumbo Payload Length è INFERRED.

7.5 Intestazione di routing (Routing Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tutti i campi dell'intestazione di routing sono NOCHANGE.

Se il tipo di routing non è riconosciuto, non tutti i campi possono essere determinati, pertanto l'intera intestazione di routing è classificata come RANDOM.

Nell'intestazione di routing di tipo 0, l'ultimo indirizzo è DEF (se Segments Left > 0).

L'intestazione di routing viene compressa completamente. Questo è un grande vantaggio per Mobile IP.

7.6 Intestazione di frammentazione (Fragment Header)

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

Il primo frammento di un pacchetto ha Fragment Offset = 0, e la catena di frammenti può essere stata riordinata prima di raggiungere il punto di compressione. Poiché i pacchetti possono essere riordinati, l'intestazione di frammentazione del primo frammento non può essere esaminata per determinare il campo Identification. Pertanto i campi dell'intestazione di frammentazione sono classificati come segue:

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

Questa classificazione significa che un'intestazione di frammentazione viene compressa in solo Next Header e Hdr Ext Len (entrambi NOCHANGE), il resto è dedotto (Fragment Offset e M devono essere 0, Identification è RANDOM).

Secondo le linee guida facoltative della sezione 4.1, i frammenti possono essere raggruppati.

7.7 Intestazione delle opzioni di destinazione (Destination Options Header)

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

Le uniche opzioni di destinazione definite in [IPv6] sono opzioni di padding, trattate come in 7.3.

L'intera intestazione delle opzioni di destinazione è trattata secondo le "regole per le intestazioni di estensione IPv6" (7.2).

7.8 Intestazione di autenticazione (AH, Authentication Header)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authentication Data (variable) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tutti i campi dell'intestazione AH sono NOCHANGE, ma i dati di autenticazione sono RANDOM.

Ciò significa che nell'intestazione AH compressa sono ancora presenti SPI e Sequence Number (entrambi NOCHANGE e inviati nell'intestazione compressa), mentre i dati di autenticazione sono inviati così come sono come campo RANDOM.

7.9 Payload di sicurezza incapsulato (ESP, Encapsulating Security Payload)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (variable) |
. .
. Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Questo intestazione indica che la parte restante del pacchetto è cifrata. SPI e Sequence Number sono NOCHANGE (inviati nell'intestazione compressa), ma in modalità tunnel ESP l'intero pacchetto IP è cifrato, pertanto il punto di compressione deve essere in grado di distinguere tra l'intestazione ESP e i dati cifrati successivi.

Ciò significa che il pacchetto IP, insieme alla sua intestazione ESP, deve poter essere passato al compressore, mentre i dati cifrati dopo l'ESP non vengono compressi.

Tutto ciò che segue l'SPI è cifrato e pertanto non compresso.

7.10 Ordine delle intestazioni di estensione (Order of Extension Headers)

Le intestazioni di estensione IPv6 devono apparire nell'ordine stabilito in [IPv6]. Se il compressore incontra un'intestazione di estensione fuori dall'ordine previsto, deve inviare un'intestazione completa.

7.11 Intestazione UDP (UDP Header)

L'intestazione UDP è descritta in [RFC-768]. Il campo Next Header in IPv6 o il campo Protocol in IPv4 indica se il protocollo seguente è UDP.

Ogni campo dell'intestazione UDP viene trattato secondo la seguente tabella:

FieldSizeDEFTmplCTmpl & CInferredNotes
Source Port16YesYesNoNoNoCampo di definizione
Destination Port16YesYesNoNoNoCampo di definizione
Length16NoNoNoNoYesDedotto dalla lunghezza del frame
Checksum16NoNoYesNoNoCambia in modo casuale

Il campo Length dell'intestazione UDP deve coincidere con il campo Length dell'intestazione IP e con l'intestazione UDP stessa, e può pertanto essere dedotto (INFERRED).

L'intestazione UDP viene tipicamente compressa a 2 byte, ovvero il checksum UDP (RANDOM) viene trasmesso così com'è e i rimanenti campi vengono compressi.

7.12 Intestazione TCP (TCP Header)

L'intestazione TCP è descritta in [RFC-793]. Il campo Next Header in IPv6 o il campo Protocol in IPv4 indica se il protocollo seguente è TCP.

Ogni campo dell'intestazione TCP viene trattato secondo la seguente tabella:

FieldSizeDEFTmplCTmpl & CInferredNotes
Source Port16YesYesNoNoNoCampo di definizione
Destination Port16YesYesNoNoNoCampo di definizione
Sequence Number32NoYesYesNoNoCodifica differenziale
Acknowledgment Number32NoYesYesNoNoCodifica differenziale
Data Offset4NoYesYesNoNoCambia quando cambiano le opzioni
Reserved4NoYesNoNoNoDi solito zero
Flags8NoYesYesNoNoPuò cambiare
Window16NoYesYesNoNoInviato così com'è
Checksum16NoNoYesNoNoInviato così com'è
Urgent Pointer16NoYesYesNoNoUsato raramente
OptionsvarNoYesYesNoNoCambia raramente

Vi sono due modi per formare l'intestazione TCP compressa. La classificazione dei campi è la seguente:

       Source Port           NOCHANGE  (DEF)
Destination Port NOCHANGE (DEF)
Sequence Number DELTA
Acknowledgment Number DELTA
Offset NOCHANGE
Reserved DELTA (se diverso dal contesto,
altrimenti NOCHANGE)
Urg, Psh RANDOM (posto nell'ottetto dei flag)
Ack INFERRED a 1
Rst, Syn, Fin INFERRED a 0
Window DELTA (se Window cambia,
altrimenti NOCHANGE)
Checksum RANDOM
Urgent Pointer DELTA (se Urg è impostato, inviato,
altrimenti NOCHANGE)
Options, Padding DELTA (se Options cambia,
altrimenti NOCHANGE)

Questo metodo è essenzialmente la codifica differenziale descritta da Jacobson in [RFC-1144], con la differenza di dove viene posto l'ottetto dei flag e di come vengono trattate le variazioni di campi come Window.

7.13 Intestazione IPv4 (IPv4 Header)

L'intestazione IPv4 è descritta in [RFC-791]. La tabella seguente mostra la classificazione dei campi dell'intestazione IPv4:

FieldSizeDEFTmplCTmpl & CInferredNotes
Version4NoYesNoNoNoCostante (4)
IHL4NoYesNoNoNoCostante, di solito 5
Type of Service8NoYesYesNoNoPuò cambiare
Total Length16NoNoNoNoYesDedotto dalla lunghezza del frame
Identification16NoNoYesNoNoCambia in modo casuale
Flags3NoYesYesNoNoPuò cambiare
Fragment Offset13NoYesYesNoNoCambia durante la frammentazione
Time to Live8NoYesYesNoNoPuò cambiare
Protocol8YesYesNoNoNoCampo di definizione
Header Checksum16NoNoYesNoNoRicalcolato a ogni hop
Source Address32YesYesNoNoNoCampo di definizione
Destination Address32YesYesNoNoNoCampo di definizione
OptionsvarNoYesYesNoNoUsato raramente

Il campo Identification nell'intestazione IPv4 precedente è RANDOM.

Quando un'intestazione TCP segue immediatamente, l'intestazione IPv4 e quella TCP devono essere compresse come un'unica unità (vedere la sezione 6). In tal caso i bit 6 e 7 del campo Type of Service (bit 14 e 15 della prima parola) possono essere trasmessi tramite il flag R (vedere la sezione 6 a).

Vi sono due modi per comprimere l'intestazione IPv4.

a) Se l'intestazione IPv4 non appartiene a un frammento (il flag MF non è impostato e Fragment Offset è zero) e non sono presenti opzioni (IHL è 5), essa viene classificata come segue:

       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)

Nota: quando un'intestazione TCP segue immediatamente, l'intestazione IPv4 e quella TCP DEVONO essere compresse come un'unica unità, come descritto nella sezione 6. I bit 6 e 7 del campo Type of Service (bit 14 e 15 della prima parola) possono in tal caso essere trasmessi mediante il flag R (vedere la sezione 6 a).

b) Se l'intestazione IPv4 appartiene a un frammento (bit MF impostato o Fragment Offset diverso da zero), oppure se sono presenti opzioni (IHL > 5), tutti i campi sono RANDOM (ossia, se l'intestazione viene compressa, tutti i campi sono inviati così come sono e non compressi). Questa classificazione consente la compressione dell'intestazione del tunnel, ma non dell'intestazione del frammento, quando i frammenti sono incapsulati in un tunnel. Se l'intestazione IPv4 appartiene a un frammento, essa termina la catena comprimibile di sotto-header, cioè deve essere l'ultimo sotto-header a essere compresso. Se l'intestazione IPv4 contiene opzioni ma non appartiene a un frammento, essa non termina la catena comprimibile di sotto-header, per cui i sotto-header successivi possono essere compressi.

Un compressore che segue le linee guida facoltative della sezione 4.1 utilizzerà, nel caso a), i campi Version, Source Address e Destination Address insieme al fatto che non vi sono opzioni IPv4 e che non si tratta di un frammento, per definire il flusso di pacchetti.

Il caso b) può definire due tipi di flussi di pacchetti a seconda che l'intestazione IPv4 appartenga o meno a un frammento.

Se l'intestazione IPv4 nel caso b) appartiene a un frammento, un compressore che segue le linee guida facoltative utilizzerà tale fatto insieme a Version, Source Address e Destination Address per determinare il flusso di pacchetti.

Se l'intestazione IPv4 nel caso b) non appartiene a un frammento, essa deve contenere opzioni. Un compressore che segue le linee guida facoltative utilizzerà tale fatto, ma non la dimensione delle opzioni, insieme a Version, Source Address e Destination Address per determinare il flusso di pacchetti.

7.14 Intestazione di incapsulamento minimale (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 (calcolato dagli altri valori)
Original Destination Address NOCHANGE
Original Source Address NOCHANGE (presente solo se S=1)

Questa intestazione sarà probabilmente utilizzata da Mobile IP.