Passa al contenuto principale

4. Tunneling IP su HTTP

Per consentire la negoziazione di un tunnel per IP su HTTP, questo documento definisce il token di aggiornamento HTTP "connect-ip". I tunnel IP risultanti utilizzano il Protocollo Capsule (vedere Sezione 3.2 di HTTP-DGRAM) con Datagrammi HTTP nel formato definito nella Sezione 6.

Per avviare un tunnel IP associato a un singolo flusso HTTP, un client emette una richiesta contenente il token di aggiornamento "connect-ip".

Quando invia la sua richiesta di proxy IP, il client DEVE eseguire l'espansione del modello URI per determinare il percorso e la query della sua richiesta; vedere Sezione 3.

In virtù della definizione del Protocollo Capsule (vedere Sezione 3.2 di HTTP-DGRAM), le richieste di proxy IP non trasportano alcun contenuto di messaggio. Allo stesso modo, anche le risposte di proxy IP riuscite non trasportano alcun contenuto di messaggio.

Il proxy IP su HTTP DEVE essere operato su crittografia TLS o QUIC, o un altro protocollo di crittografia equivalente, per fornire riservatezza, integrità e autenticazione.

4.1. Gestione del proxy IP​

Dopo aver ricevuto una richiesta di proxy IP:

  • Se il destinatario è configurato per utilizzare un altro server HTTP, agirà come intermediario inoltrando la richiesta all'altro server HTTP. Si noti che tali intermediari potrebbero dover ricodificare la richiesta se la inoltrano utilizzando una versione di HTTP diversa da quella utilizzata per riceverla, poiché la codifica della richiesta differisce per versione (vedere sotto).

  • Altrimenti, il destinatario agirà come un proxy IP. Il proxy IP può scegliere di rifiutare la richiesta di proxy IP. Altrimenti, estrae le variabili opzionali "target" e "ipproto" dall'URI che ha ricostruito dalle intestazioni della richiesta, decodifica la loro codifica percentuale e stabilisce un tunnel IP.

I proxy IP DEVONO convalidare se le variabili "target" e "ipproto" decodificate soddisfano i requisiti nella Sezione 4.6. In caso contrario, il proxy IP DEVE trattare la richiesta come malformata; vedere Sezione 8.1.1 di HTTP/2 e Sezione 4.1.2 di HTTP/3. Se la variabile "target" è un nome DNS, il proxy IP DEVE eseguire la risoluzione DNS (per ottenere gli indirizzi IPv4 e/o IPv6 corrispondenti tramite record A e/o AAAA) prima di rispondere alla richiesta HTTP. Se si verificano errori durante questo processo, il proxy IP DEVE rifiutare la richiesta e DOVREBBE inviare dettagli utilizzando un campo di intestazione Proxy-Status appropriato [PROXY-STATUS]. Ad esempio, se la risoluzione DNS restituisce un errore, il proxy può utilizzare il tipo di errore proxy dns_error dalla Sezione 2.3.2 di PROXY-STATUS.

La durata del tunnel di inoltro IP è legata al flusso di richiesta del proxy IP. Il proxy IP DEVE mantenere tutte le assegnazioni di indirizzi IP e percorsi associate al tunnel di inoltro IP mentre il flusso di richiesta è aperto. I proxy IP POSSONO scegliere di abbattere il tunnel a causa di un periodo di inattività, ma DEVONO chiudere il flusso di richiesta quando lo fanno.

Una risposta di proxy IP riuscita (come definita nelle Sezioni 4.3 e 4.5) indica che il proxy IP ha stabilito un tunnel IP ed è disposto a fare da proxy per i payload IP. Qualsiasi risposta diversa da una risposta di proxy IP riuscita indica che la richiesta non è riuscita; pertanto, il client DEVE interrompere la richiesta.

Insieme a una risposta di proxy IP riuscita, il proxy IP può inviare capsule per assegnare indirizzi e pubblicizzare percorsi al client (Sezione 4.7). Il client può anche assegnare indirizzi e pubblicizzare percorsi al proxy IP per il routing network-to-network.

4.2. Richiesta HTTP/1.1​

Quando si utilizza HTTP/1.1 [HTTP/1.1], una richiesta di proxy IP soddisferà i seguenti requisiti:

  • Il metodo DEVE essere "GET".

  • La richiesta DEVE includere un singolo campo di intestazione Host contenente l'host e la porta opzionale del proxy IP.

  • La richiesta DEVE includere un campo di intestazione Connection con valore "Upgrade" (si noti che questo requisito non fa distinzione tra maiuscole e minuscole, come da Sezione 7.6.1 di HTTP).

  • La richiesta DEVE includere un campo di intestazione Upgrade con valore "connect-ip".

Una richiesta di proxy IP che non è conforme a queste restrizioni è malformata. Il destinatario di tale richiesta malformata DEVE rispondere con un errore e DOVREBBE utilizzare il codice di stato 400 (Bad Request).

Ad esempio, se il client è configurato con il modello URI "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" e desidera aprire un tunnel di inoltro IP senza limitazioni di destinazione o protocollo, potrebbe inviare la seguente richiesta:

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Figura 2: Esempio di richiesta HTTP/1.1

4.3. Risposta HTTP/1.1​

Il server indica una risposta di proxy IP riuscita rispondendo con i seguenti requisiti:

  • Il codice di stato HTTP sulla risposta DEVE essere 101 (Switching Protocols).

  • La risposta DEVE includere un campo di intestazione Connection con valore "Upgrade" (si noti che questo requisito non fa distinzione tra maiuscole e minuscole, come da Sezione 7.6.1 di HTTP).

  • La risposta DEVE includere un singolo campo di intestazione Upgrade con valore "connect-ip".

  • La risposta DEVE soddisfare i requisiti delle risposte HTTP che avviano il Protocollo Capsule; vedere Sezione 3.2 di HTTP-DGRAM.

Se uno qualsiasi di questi requisiti non è soddisfatto, il client DEVE trattare questo tentativo di proxy come fallito e chiudere la connessione.

Ad esempio, il server potrebbe rispondere con:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Figura 3: Esempio di risposta HTTP/1.1

4.4. Richieste HTTP/2 e HTTP/3​

Quando si utilizza HTTP/2 [HTTP/2] o HTTP/3 [HTTP/3], le richieste di proxy IP utilizzano HTTP Extended CONNECT. Ciò richiede che i server inviino un'impostazione HTTP, come specificato in [EXT-CONNECT2] e [EXT-CONNECT3], e che le richieste utilizzino campi pseudo-intestazione HTTP con i seguenti requisiti:

  • Il campo pseudo-intestazione :method DEVE essere "CONNECT".

  • Il campo pseudo-intestazione :protocol DEVE essere "connect-ip".

  • Il campo pseudo-intestazione :authority DEVE contenere l'autorità del proxy IP.

  • I campi pseudo-intestazione :path e :scheme NON DEVONO essere vuoti. I loro valori DEVONO contenere lo schema e il percorso dal modello URI dopo che il processo di espansione del modello URI è stato completato; vedere Sezione 3. Le variabili nel modello URI possono determinare l'ambito della richiesta, come la richiesta di inoltro di pacchetti IP a tunnel completo o un flusso proxy specifico; vedere Sezione 4.6.

Una richiesta di proxy IP che non è conforme a queste restrizioni è malformata; vedere Sezione 8.1.1 di HTTP/2 e Sezione 4.1.2 di HTTP/3.

Ad esempio, se il client è configurato con il modello URI "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" e desidera aprire un tunnel di inoltro IP senza limitazioni di destinazione o protocollo, potrebbe inviare la seguente richiesta:

HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

Figura 4: Esempio di richiesta HTTP/2 o HTTP/3

4.5. Risposte HTTP/2 e HTTP/3​

Il server indica una risposta di proxy IP riuscita rispondendo con i seguenti requisiti:

  • Il codice di stato HTTP sulla risposta DEVE essere nell'intervallo 2xx (Successful).

  • La risposta DEVE soddisfare i requisiti delle risposte HTTP che avviano il Protocollo Capsule; vedere Sezione 3.2 di HTTP-DGRAM.

Se uno qualsiasi di questi requisiti non è soddisfatto, il client DEVE trattare questo tentativo di proxy come fallito e interrompere la richiesta. Ad esempio, qualsiasi codice di stato nell'intervallo 3xx sarà trattato come un fallimento e farà sì che il client interrompa la richiesta.

Ad esempio, il server potrebbe rispondere con:

HEADERS
:status = 200
capsule-protocol = ?1

Figura 5: Esempio di risposta HTTP/2 o HTTP/3

4.6. Limitazione dell'ambito della richiesta​

A differenza delle richieste di proxy UDP, che richiedono di specificare un host di destinazione, le richieste di proxy IP possono consentire agli endpoint di inviare pacchetti IP arbitrari a qualsiasi host. Il client può scegliere di limitare una determinata richiesta a uno specifico prefisso IP o protocollo IP aggiungendo parametri alla sua richiesta. Quando il proxy IP sa che una richiesta è limitata a un prefisso o protocollo di destinazione, può sfruttare queste informazioni per ottimizzare la sua allocazione delle risorse; ad esempio, il proxy IP può assegnare lo stesso indirizzo IP pubblico a due richieste di proxy IP limitate a prefissi diversi e/o protocolli diversi.

L'ambito della richiesta è indicato dal client al proxy IP tramite le variabili "target" e "ipproto" del modello URI; vedere Sezione 3. Entrambe le variabili "target" e "ipproto" sono opzionali; se non sono incluse, si considera che portino il valore jolly "*".

target: La variabile "target" contiene un nome host o un prefisso IP di un host specifico a cui il client desidera inviare pacchetti tramite proxy. Se la variabile "target" non è specificata o il suo valore è "*", il client richiede di comunicare con qualsiasi host consentito. "target" supporta l'uso di nomi DNS, prefissi IPv6 e prefissi IPv4. Si noti che gli identificatori di zona di indirizzamento con ambito IPv6 [IPv6-ZONE-ID] non sono supportati. Se la destinazione è un prefisso IP (indirizzo IP seguito facoltativamente da una barra codificata in percentuale seguita dalla lunghezza del prefisso in bit), la richiesta supporterà solo una singola versione IP. Se la destinazione è un nome host, ci si aspetta che il proxy IP esegua la risoluzione DNS per determinare quale/i percorso/i pubblicizzare al client. Il proxy IP DOVREBBE inviare una capsula ROUTE_ADVERTISEMENT che include percorsi per tutti gli indirizzi che sono stati risolti per il nome host richiesto, che sono accessibili al proxy IP e appartengono a una famiglia di indirizzi per la quale il proxy IP invia anche un indirizzo assegnato.

ipproto: La variabile "ipproto" contiene un numero di protocollo Internet; vedere l'elenco definito nel registro IANA "Assigned Internet Protocol Numbers" [IANA-PN]. Se presente, specifica che un client desidera solo fare da proxy per uno specifico protocollo IP per questa richiesta. Se il valore è "*", o la variabile non è inclusa, il client richiede di utilizzare qualsiasi protocollo IP. Il protocollo IP indicato nella variabile "ipproto" rappresenta un valore di intestazione successiva consentito trasportato nelle intestazioni IP che vengono inviate direttamente nei Datagrammi HTTP (le intestazioni IP più esterne). Il traffico ICMP è sempre consentito, indipendentemente dal valore di questo campo.

Utilizzando i termini IPv6address, IPv4address e reg-name da [URI], le variabili "target" e "ipproto" DEVONO aderire al formato nella Figura 6, utilizzando la notazione da [ABNF]. Inoltre:

  • Se "target" contiene un letterale o un prefisso IPv6, i due punti (":") DEVONO essere codificati in percentuale. Ad esempio, se l'host di destinazione è "2001:db8::42", sarà codificato nell'URI come "2001%3Adb8%3A%3A42".

  • Se presente, la lunghezza del prefisso IP in "target" DEVE essere preceduta da una barra codificata in percentuale ("/"): "%2F". La lunghezza del prefisso IP DEVE rappresentare un intero decimale compreso tra 0 e la lunghezza dell'indirizzo IP in bit, inclusi.

  • Se "target" contiene un prefisso IP e la lunghezza del prefisso è strettamente inferiore alla lunghezza dell'indirizzo IP in bit, i bit inferiori dell'indirizzo IP che non sono coperti dalla lunghezza del prefisso DEVONO essere tutti impostati a 0.

  • "ipproto" DEVE rappresentare un intero decimale compreso tra 0 e 255 inclusi o il valore jolly "*".

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

Figura 6: Formato variabile modello URI

I proxy IP POSSONO eseguire il controllo degli accessi utilizzando le informazioni di ambito fornite dal client, ovvero, se il client non è autorizzato ad accedere a nessuna delle destinazioni incluse nell'ambito, allora il proxy IP può rifiutare immediatamente la richiesta.

4.7. Capsule​

Questo documento definisce più nuovi tipi di capsule che consentono agli endpoint di scambiare informazioni di configurazione IP. Entrambi gli endpoint POSSONO inviare un numero qualsiasi di queste nuove capsule.

4.7.1. Capsula ADDRESS_ASSIGN​

La capsula ADDRESS_ASSIGN (tipo di capsula 0x01) consente a un endpoint di assegnare al suo peer un elenco di indirizzi IP o prefissi. Ogni capsula contiene l'elenco completo dei prefissi IP attualmente assegnati al ricevitore. Qualsiasi di questi indirizzi può essere utilizzato come indirizzo di origine sui pacchetti IP originati dal ricevitore di questa capsula.

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

Figura 7: Formato capsula ADDRESS_ASSIGN

La capsula ADDRESS_ASSIGN contiene una sequenza di zero o più indirizzi assegnati.

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Figura 8: Formato indirizzo assegnato

Ogni indirizzo assegnato contiene i seguenti campi:

Request ID (ID richiesta): Identificatore di richiesta, codificato come intero a lunghezza variabile. Se questa assegnazione di indirizzo è in risposta a una richiesta di indirizzo (vedere Sezione 4.7.2), allora questo campo DEVE contenere il valore del campo corrispondente nella richiesta. Altrimenti, questo campo DEVE essere zero.

IP Version (Versione IP): Versione IP di questa assegnazione di indirizzo, codificata come intero senza segno a 8 bit. DEVE essere 4 o 6.

IP Address (Indirizzo IP): Indirizzo IP assegnato. Se il campo Versione IP ha valore 4, il campo Indirizzo IP DEVE avere una lunghezza di 32 bit. Se il campo Versione IP ha valore 6, il campo Indirizzo IP DEVE avere una lunghezza di 128 bit.

IP Prefix Length (Lunghezza prefisso IP): Il numero di bit nell'indirizzo IP utilizzati per definire il prefisso che viene assegnato, codificato come intero senza segno a 8 bit. Questo DEVE essere inferiore o uguale alla lunghezza del campo Indirizzo IP in bit. Se la lunghezza del prefisso è uguale alla lunghezza dell'indirizzo IP, al ricevitore di questa capsula è consentito inviare pacchetti da un singolo indirizzo di origine. Se la lunghezza del prefisso è inferiore alla lunghezza dell'indirizzo IP, al ricevitore di questa capsula è consentito inviare pacchetti da qualsiasi indirizzo di origine che rientra nel prefisso. Se la lunghezza del prefisso è strettamente inferiore alla lunghezza dell'indirizzo IP in bit, i bit inferiori del campo Indirizzo IP che non sono coperti dalla lunghezza del prefisso DEVONO essere tutti impostati a 0.

Se uno qualsiasi dei campi della capsula è malformato alla ricezione, il ricevitore della capsula DEVE seguire la procedura di gestione degli errori definita nella Sezione 3.3 di HTTP-DGRAM.

Se una capsula ADDRESS_ASSIGN non contiene un indirizzo precedentemente trasmesso in un'altra capsula ADDRESS_ASSIGN, indica che l'indirizzo è stato rimosso. Una capsula ADDRESS_ASSIGN può anche essere vuota, indicando che tutti gli indirizzi sono stati rimossi.

In alcune distribuzioni di proxy IP in HTTP, un endpoint deve vedersi assegnare un indirizzo dal suo peer prima di sapere quale indirizzo di origine impostare sui propri pacchetti. Ad esempio, nel caso VPN di accesso remoto (Sezione 8.1), il client non può inviare pacchetti IP finché non sa quale indirizzo utilizzare. In queste distribuzioni, l'endpoint che si aspetta un'assegnazione di indirizzo DEVE inviare una capsula ADDRESS_REQUEST. Questo non è richiesto se l'endpoint non ha bisogno di alcuna assegnazione di indirizzo, ad esempio, quando è configurato fuori banda con indirizzi statici.

Mentre le capsule ADDRESS_ASSIGN sono comunemente inviate in risposta alle capsule ADDRESS_REQUEST, gli endpoint POSSONO inviare capsule ADDRESS_ASSIGN non richieste.

4.7.2. Capsula ADDRESS_REQUEST​

La capsula ADDRESS_REQUEST (tipo di capsula 0x02) consente a un endpoint di richiedere l'assegnazione di indirizzi IP dal suo peer. La capsula consente all'endpoint di indicare facoltativamente una preferenza per quale indirizzo gli verrebbe assegnato.

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

Figura 9: Formato capsula ADDRESS_REQUEST

La capsula ADDRESS_REQUEST contiene una sequenza di uno o più indirizzi richiesti.

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Figura 10: Formato indirizzo richiesto

Ogni indirizzo richiesto contiene i seguenti campi:

Request ID (ID richiesta): Identificatore di richiesta, codificato come intero a lunghezza variabile. Questo è l'identificatore di questa specifica richiesta di indirizzo. Ogni richiesta da un determinato endpoint porta un identificatore diverso. Gli ID richiesta NON DEVONO essere riutilizzati da un endpoint e NON DEVONO essere zero.

IP Version (Versione IP): Versione IP di questa richiesta di indirizzo, codificata come intero senza segno a 8 bit. DEVE essere 4 o 6.

IP Address (Indirizzo IP): Indirizzo IP richiesto. Se il campo Versione IP ha valore 4, il campo Indirizzo IP DEVE avere una lunghezza di 32 bit. Se il campo Versione IP ha valore 6, il campo Indirizzo IP DEVE avere una lunghezza di 128 bit.

IP Prefix Length (Lunghezza prefisso IP): Lunghezza del prefisso IP richiesto in bit, codificata come intero senza segno a 8 bit. DEVE essere inferiore o uguale alla lunghezza del campo Indirizzo IP in bit. Se la lunghezza del prefisso è strettamente inferiore alla lunghezza dell'indirizzo IP in bit, i bit inferiori del campo Indirizzo IP che non sono coperti dalla lunghezza del prefisso DEVONO essere tutti impostati a 0.

Se l'indirizzo IP è tutto zero (0.0.0.0 o ::), questo indica che il mittente sta richiedendo un indirizzo di quella famiglia di indirizzi ma non ha una preferenza per un indirizzo specifico. In quello scenario, la lunghezza del prefisso indica ancora la preferenza del mittente per la lunghezza del prefisso che sta richiedendo.

Se uno qualsiasi dei campi della capsula è malformato alla ricezione, il ricevitore della capsula DEVE seguire la procedura di gestione degli errori definita nella Sezione 3.3 di HTTP-DGRAM.

Dopo aver ricevuto la capsula ADDRESS_REQUEST, un endpoint DOVREBBE assegnare uno o più indirizzi IP al suo peer e quindi rispondere con una capsula ADDRESS_ASSIGN per informare il peer dell'assegnazione. Per ogni indirizzo richiesto, il ricevitore della capsula ADDRESS_REQUEST DEVE rispondere con un indirizzo assegnato con un ID richiesta corrispondente. Se l'indirizzo richiesto è stato assegnato, i campi Indirizzo IP e Lunghezza prefisso IP nella risposta dell'indirizzo assegnato DEVONO essere impostati sui valori assegnati. Se l'indirizzo richiesto non è stato assegnato, l'indirizzo IP DEVE essere tutto zero e la lunghezza del prefisso IP DEVE essere la lunghezza massima (0.0.0.0/32 o ::/128) per indicare che nessun indirizzo è stato assegnato. Questi rifiuti di indirizzo NON DOVREBBERO essere inclusi nelle successive capsule ADDRESS_ASSIGN. Si noti che altre voci di indirizzo assegnato che non corrispondono ad alcun ID richiesta possono anche essere contenute nella stessa risposta ADDRESS_ASSIGN.

Se un endpoint riceve una capsula ADDRESS_REQUEST che contiene zero indirizzi richiesti, DEVE interrompere il flusso di richiesta del proxy IP.

Si noti che l'ordinamento degli indirizzi richiesti non porta alcuna semantica. Allo stesso modo, l'ID richiesta è inteso solo come identificatore unico; non trasmette alcuna priorità o importanza.

4.7.3. Capsula ROUTE_ADVERTISEMENT​

La capsula ROUTE_ADVERTISEMENT (tipo di capsula 0x03) consente a un endpoint di comunicare al suo peer che è disposto a instradare il traffico verso un insieme di intervalli di indirizzi IP. Questo indica che il mittente ha un percorso esistente verso ciascun intervallo di indirizzi e notifica al suo peer che, se il ricevitore della capsula ROUTE_ADVERTISEMENT invia pacchetti IP per uno di questi intervalli in Datagrammi HTTP, il mittente della capsula li inoltrerà lungo il suo percorso preesistente. Qualsiasi indirizzo che si trova in uno degli intervalli di indirizzi può essere utilizzato come indirizzo di destinazione sui pacchetti IP originati dal ricevitore di questa capsula.

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

Figura 11: Formato capsula ROUTE_ADVERTISEMENT

La capsula ROUTE_ADVERTISEMENT contiene una sequenza di zero o più intervalli di indirizzi IP.

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

Figura 12: Formato intervallo indirizzi IP

Ogni intervallo di indirizzi IP contiene i seguenti campi:

IP Version (Versione IP): Versione IP di questo intervallo, codificata come intero senza segno a 8 bit. DEVE essere 4 o 6.

Start IP Address e End IP Address (Indirizzo IP iniziale e Indirizzo IP finale): Indirizzo IP iniziale e finale inclusivo dell'intervallo pubblicizzato. Se il campo Versione IP ha valore 4, questi campi DEVONO avere una lunghezza di 32 bit. Se il campo Versione IP ha valore 6, questi campi DEVONO avere una lunghezza di 128 bit. L'indirizzo IP iniziale DEVE essere inferiore o uguale all'indirizzo IP finale.

IP Protocol (Protocollo IP): Il numero di protocollo Internet per il traffico che può essere inviato a questo intervallo, codificato come intero senza segno a 8 bit. Se il valore è 0, tutti i protocolli sono consentiti. Se il valore non è 0, rappresenta un valore di intestazione successiva consentito trasportato nelle intestazioni IP che vengono inviate direttamente nei Datagrammi HTTP (le intestazioni IP più esterne). Il traffico ICMP è sempre consentito, indipendentemente dal valore di questo campo.

Se uno qualsiasi dei campi della capsula è malformato alla ricezione, il ricevitore della capsula DEVE seguire la procedura di gestione degli errori definita nella Sezione 3.3 di HTTP-DGRAM.

Dopo aver ricevuto la capsula ROUTE_ADVERTISEMENT, un endpoint PUÒ aggiornare il suo stato locale riguardo a ciò che il suo peer è disposto a instradare (soggetto alla politica locale), ad esempio installando voci in una tabella di routing.

Ogni ROUTE_ADVERTISEMENT contiene l'elenco completo degli intervalli di indirizzi. Se più capsule ROUTE_ADVERTISEMENT vengono inviate in una direzione, ogni capsula ROUTE_ADVERTISEMENT sostituisce le precedenti. In altre parole, se un determinato intervallo di indirizzi era presente in una capsula precedente ma la capsula ROUTE_ADVERTISEMENT ricevuta più di recente non lo contiene, il ricevitore considererà quell'intervallo ritirato.

Se più intervalli che utilizzano lo stesso protocollo IP dovessero sovrapporsi, alcune implementazioni della tabella di routing potrebbero rifiutarli. Per evitare sovrapposizioni, gli intervalli sono ordinati; questo pone l'onere sul mittente e rende la verifica da parte del ricevitore molto più semplice. Se un intervallo di indirizzi IP A precede un intervallo di indirizzi IP B nella stessa capsula ROUTE_ADVERTISEMENT, DEVONO seguire questi requisiti:

  • La versione IP di A DEVE essere inferiore o uguale alla versione IP di B.

  • Se la versione IP di A e B sono uguali, il protocollo IP di A DEVE essere inferiore o uguale al protocollo IP di B.

  • Se la versione IP e il protocollo IP di A e B sono entrambi uguali, l'indirizzo IP finale di A DEVE essere strettamente inferiore all'indirizzo IP iniziale di B.

Se un endpoint riceve una capsula ROUTE_ADVERTISEMENT che non soddisfa questi requisiti, DEVE interrompere il flusso di richiesta del proxy IP.

Poiché l'impostazione del protocollo IP su zero indica che tutti i protocolli sono consentiti, i requisiti di cui sopra rendono possibile che due percorsi si sovrappongano quando uno ha il suo protocollo IP impostato su zero e l'altro lo ha impostato su non zero. Gli endpoint NON DEVONO inviare una capsula ROUTE_ADVERTISEMENT con percorsi che si sovrappongono in questo modo. La convalida di questo requisito è OPZIONALE, ma se un endpoint rileva la violazione, DEVE interrompere il flusso di richiesta del proxy IP.

4.8. Intestazioni di estensione IPv6​

Sia l'ambito della richiesta (vedere Sezione 4.6) che la capsula ROUTE_ADVERTISEMENT (vedere Sezione 4.7.3) utilizzano numeri di protocollo Internet. Questi numeri rappresentano sia i livelli superiori (come definiti nella Sezione 2 di IPv6, con esempi che includono TCP e UDP) sia le intestazioni di estensione IPv6 (come definite nella Sezione 4 di IPv6, con esempi che includono intestazioni Fragment e Options). I proxy IP POSSONO rifiutare le richieste di limitare l'ambito ai numeri di protocollo utilizzati per le intestazioni di estensione. Alla ricezione dei pacchetti, le implementazioni che supportano l'ambito o il routing tramite numero di protocollo Internet DEVONO percorrere la catena di estensioni per trovare il numero di protocollo Internet non di estensione più esterno da confrontare con la regola di ambito. Si noti che la capsula ROUTE_ADVERTISEMENT utilizza il numero di protocollo Internet 0 per indicare che tutti i protocolli sono consentiti; non limita il percorso all'intestazione delle opzioni Hop-by-Hop IPv6 (Sezione 4.3 di IPv6).

Ultimo aggiornamento il