5.3. Tunnel Header Field Descriptions (Descrizioni dei campi dell'header del tunnel)

5.3. Tunnel Header Field Descriptions (Descrizioni dei campi dell'header del tunnel)

Inner Header (IH, Header interno): L'header interno è l'header sul datagramma originato dall'host di origine. Gli indirizzi IP di origine e di destinazione sono EID [RFC0791] [RFC2460].

Outer Header (OH, Header esterno): L'header esterno è un nuovo header anteposto dall'ITR. I campi indirizzo contengono RLOC ottenuti dalla cache EID-to-RLOC del router di ingresso. Il numero di protocollo IP è "UDP (17)" da [RFC0768]. L'impostazione del bit Don't Fragment (DF) nel campo Flags segue le regole elencate nelle Sezioni 5.4.1 e 5.4.2.

UDP Header (Header UDP): L'header UDP contiene una porta di origine scelta dall'ITR durante l'incapsulamento dei pacchetti. Vedere la Sezione 6.5 per i dettagli sull'algoritmo di hashing utilizzato per selezionare una porta di origine basata sulla tupla a 5 elementi dell'header interno. La porta di destinazione DEVE essere impostata sul valore di porta noto assegnato da IANA 4341.

UDP Checksum (campo UDP Checksum): Il campo UDP Checksum DOVREBBE essere trasmesso come zero dall'ITR per l'incapsulamento IPv4 [RFC0768] o IPv6 [UDP-TUNNELS] [UDP-ZERO]. Quando un ETR riceve un pacchetto con un checksum UDP pari a zero, DEVE accettare il pacchetto per il disincapsulamento. Quando un ITR trasmette un valore diverso da zero per il checksum UDP, DEVE inviare un valore calcolato correttamente in questo campo. Quando un ETR riceve un pacchetto con un checksum UDP diverso da zero, PUÒ scegliere di verificare il valore del checksum. Se sceglie di eseguire tale verifica e la verifica fallisce, il pacchetto DEVE essere scartato silenziosamente. Se l'ETR sceglie di non eseguire la verifica o se la verifica ha successo, il pacchetto DEVE essere accettato per il disincapsulamento. Il trattamento del checksum UDP per tutti i protocolli di tunneling, incluso LISP, è ancora oggetto di discussione attiva all'interno dell'IETF. Quando questa discussione si concluderà, verranno apportate le modifiche necessarie per allineare LISP con i risultati della discussione più ampia.

UDP Length (campo UDP Length): Per i pacchetti incapsulati IPv4, il campo UDP Length è impostato sulla somma della lunghezza totale IPv4 interna più la lunghezza degli header UDP e LISP. Per i pacchetti incapsulati IPv6, il campo UDP Length è la somma della lunghezza del payload IPv6 interno, della dimensione dell'header IPv6 (40 ottetti) e della dimensione degli header UDP e LISP.

N: Il bit N è il bit nonce-present. Quando questo bit è impostato a 1, i 24 bit di ordine inferiore dei primi 32 bit dell'header LISP contengono un Nonce. Vedere la Sezione 6.3.1 per i dettagli. Il bit N e il bit V NON DEVONO essere entrambi impostati nello stesso pacchetto. Se sono entrambi impostati, un ETR di disincapsulamento DEVE trattare il campo Nonce/Map-Version come se contenesse un valore Nonce.

L: Il bit L è il bit di abilitazione del campo Locator-Status-Bits. Quando questo bit è impostato a 1, i Locator-Status-Bits nei secondi 32 bit dell'header LISP sono in uso.

x 1 x x 0 x x x

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator-Status-Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E: Il bit E è il bit echo-nonce-request. Questo bit DEVE essere ignorato e non ha significato quando il bit N è impostato a 0. Quando il bit N è impostato a 1 e questo bit è impostato a 1, un ITR sta richiedendo che il valore nonce nel campo Nonce venga ripetuto nel pacchetto incapsulato LISP di ritorno quando l'ITR è anche un ETR. Vedere la Sezione 6.3.1 per i dettagli.

V: Il bit V è il bit Map-Version present. Quando questo bit è impostato a 1, il bit N DEVE essere 0. Vedere la Sezione 6.6.3 per ulteriori dettagli. Questo bit indica che l'header LISP è codificato in questo caso come:

0 x 0 1 x x x x

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator-Status-Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I: Il bit I è il bit Instance ID. Vedere la Sezione 5.5 per ulteriori dettagli. Quando questo bit è impostato a 1, il campo Locator-Status-Bits viene ridotto a 8 bit e i 24 bit di ordine superiore vengono utilizzati come Instance ID. Se il bit L è impostato a 0, gli 8 bit di ordine inferiore vengono trasmessi come zero e ignorati alla ricezione. Il formato dell'header LISP è codificato come:

x x x x 1 x x x

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags: Il campo flags è di 3 bit, riservato per flag futuri. DEVE essere impostato a 0 in trasmissione e DEVE essere ignorato alla ricezione.

LISP Nonce: Il campo LISP Nonce è un valore a 24 bit generato casualmente dall'ITR quando il bit N è impostato a 1. L'algoritmo di generazione del nonce è un dettaglio implementativo, ma richiede la generazione di nonce diversi quando si invia a destinazioni diverse. Tuttavia, lo stesso nonce può essere utilizzato per la stessa destinazione per un periodo di tempo. Quando il bit E è impostato a 1, il nonce viene anche utilizzato per richiedere che il valore del nonce venga ripetuto dal peer quando il pacchetto ritorna. Quando il bit E è cancellato ma il bit N è impostato, l'ITR remoto ripete un echo-nonce precedentemente richiesto o fornisce un nonce casuale. Vedere la Sezione 6.3.1 per ulteriori dettagli.

LISP Locator-Status-Bits (LSB): Quando anche il bit L è impostato, il campo Locator-Status-Bits nell'header LISP viene impostato dall'ITR per indicare all'ETR lo stato up/down dei Locator nel sito di origine. A ciascun RLOC in un Map-Reply viene assegnato un valore ordinale da 0 a n-1 (ci sono n RLOC nella voce di mappatura). I Locator-Status-Bits sono numerati da 0 a n-1 dal bit meno significativo del campo. Il campo è di 32 bit quando il bit I è impostato a 0 e di 8 bit quando il bit I è impostato a 1. Quando un Locator-Status-Bit è impostato a 1, l'ITR sta indicando all'ETR che l'RLOC associato all'ordinale del bit è up. Vedere la Sezione 6.3 per dettagli su come un ITR determina lo stato degli altri ETR nello stesso sito. Quando un sito ha più EID-Prefix che producono più mappature (ciascuna potenzialmente con Locator-Set diversi), l'impostazione dei Locator-Status-Bits in un pacchetto incapsulato DEVE riflettere la mappatura per l'EID-Prefix che corrisponde all'indirizzo EID di origine dell'header interno. Se un LSB per un Locator anycast è impostato a 1, allora esiste almeno un RLOC con quell'indirizzo e l'ETR è considerato up.

Durante l'incapsulamento ITR/PITR:

o Il campo Time to Live dell'header esterno (campo Hop Limit nel caso di IPv6) DOVREBBE essere copiato dal campo Time to Live dell'header interno.

o Il campo Type of Service dell'header esterno (campo Traffic Class nel caso di IPv6) DOVREBBE essere copiato dal campo Type of Service dell'header interno (con un'eccezione, vedere di seguito).

Durante il disincapsulamento ETR/PETR:

o Il campo Time to Live dell'header interno (campo Hop Limit nel caso di IPv6) DOVREBBE essere copiato dal campo Time to Live dell'header esterno quando il valore Time to Live dell'header esterno è inferiore al valore Time to Live dell'header interno. Se questa verifica non viene eseguita, potrebbe verificarsi un incremento del Time to Live dell'header interno attraverso un ciclo di incapsulamento/disincapsulamento. Questa verifica viene eseguita anche all'incapsulamento iniziale quando un pacchetto arriva a un ITR o PITR e la destinazione è un sito LISP.

o Il campo Type of Service dell'header interno (campo Traffic Class nel caso di IPv6) DOVREBBE essere copiato dal campo Type of Service dell'header esterno (con un'eccezione, vedere di seguito).

Si noti che se un ETR/PETR è anche un ITR/PITR e sceglie di reincapsulare dopo il disincapsulamento, l'effetto netto è che il nuovo header esterno trasporterà lo stesso Time to Live dell'header esterno precedente meno 1.

La copia del Time to Live (TTL) ha due scopi: primo, preservare l'intenzione dell'host sulla distanza che il pacchetto deve viaggiare; secondo, e più importante, sopprimere i pacchetti in loop quando esiste un loop di tunnel seriale a causa di una configurazione errata. Vedere la Sezione 9.3 per un trattamento eccezionale del TTL per i pacchetti traceroute.

Il campo Explicit Congestion Notification (ECN) occupa i bit 6 e 7 del campo IPv4 Type of Service e del campo IPv6 Traffic Class [RFC3168]. Per evitare di scartare le indicazioni di congestione, il campo ECN richiede un trattamento speciale [RFC3168]. Un ITR che incapsula DEVE copiare il campo ECN a 2 bit dall'header interno all'header esterno. Un reincapsulamento DEVE copiare il campo ECN a 2 bit dall'header esterno rimosso al nuovo header esterno. Se il campo ECN contiene il codepoint di indicazione della congestione (valore 11, cioè il codepoint Congestion Experienced (CE)), un ETR che disincapsula DEVE copiare il campo ECN a 2 bit dall'header esterno rimosso all'header interno sopravvissuto utilizzato per l'inoltro oltre l'ETR. Questi requisiti preservano l'indicazione CE quando i pacchetti che utilizzano l'ECN attraversano un tunnel LISP e vengono contrassegnati con un'indicazione CE a causa della congestione tra gli endpoint del tunnel.