Tecnologie e servizi di rete/IPv6
Internet Protocol version 6 (IPv6) è un nuovo protocollo con lo scopo di superare i limiti di IPv4: il principale motivo dell'introduzione di un nuovo protocollo è avere uno spazio degli indirizzi più grande rispetto a quello di IPv4.
Confronto con IPv4
[modifica | modifica sorgente]IPv6 espande il protocollo ICMP integrando i seguenti protocolli:
- ARP: chiamato "neighbor discovery" per il processo di configurazione degli indirizzi;
- IGMP: chiamato "Multicast Listener Discovery" per gestire le appartenenze ai gruppi multicast.
Con IPv6 alcuni protocolli devono solo essere aggiornati, principalmente per il fatto che tutti hanno a che fare con indirizzi (questi protocolli non sono indipendenti dal livello 3):
- protocolli DNS;
- protocolli di instradamento: RIP, OSPF, BGP, IDRP;
- protocolli di trasporto: TCP, UDP;
- interfacce socket.
Funzionalità aggiuntive di IPv6
[modifica | modifica sorgente]Le funzionalità aggiuntive elencate qui sotto furono originariamente progettate come componenti aggiuntivi per IPv4, poi è stato effettuato il porting per incorporarle in IPv6.
- Distribuzione su LAN
È più efficiente, grazie a un utilizzo efficiente degli indirizzi multicast e anycast:
- multicast: ogni indirizzo multicast identifica un gruppo di stazioni, e il pacchetto viene inoltrato a tutti i nodi nel gruppo;
- anycast: ogni indirizzo anycast identifica un gruppo di stazioni, ma il pacchetto viene inoltrato solo al nodo più vicino nel gruppo.
- Sicurezza e privacy dei dati
Nel protocollo IPv6 sono inclusi meccanismi di sicurezza come IPsec.
- Policy routing
È la possibilità di inoltrare i pacchetti utilizzando politiche diverse dall'indirizzo di destinazione (per es. inoltro in base all'indirizzo sorgente).
- Plug and play
Sono definiti dei protocolli per l'autoconfigurazione:
- stateless: solo l'accesso link-local è garantito senza contattare alcun server;
- stateful: è possibile avere accesso a Internet usando un server DHCP.
- Differenziazione del traffico
Non tutti i flussi di dati sono uguali (per es. le chiamate telefoniche richiedono meno ritardi).
- Mobilità
È la capacità di spostare il dispositivo per reti diverse mantenendo disponibili tutti i servizi (per es. dispositivi mobili che usano GSM/LTE spostandosi intorno a celle diverse).
- Nomadicità
È la capacità di spostare il dispositivo per reti diverse senza la necessità di garantire i servizi attivi → meno stretta della mobilità.
- Scalabilità migliore con l'instradamento
Di norma è necessaria l'aggregazione per semplificare l'instradamento ma richiede uno spreco di indirizzi. L'instradamento IPv6 utilizza quasi le stesse tecniche di IPv4 ma può ridurre le tabelle di instradamento, se gli indirizzi sono dati in un modo efficiente.
Indirizzamento
[modifica | modifica sorgente]Formato degli indirizzi
[modifica | modifica sorgente]Ogni indirizzo IPv6 è lungo 128 bit, e il prefisso sostituisce la netmask:
prefisso | interface identifier |
Link
[modifica | modifica sorgente]Il concetto di link in IPv6 è uguale al concetto di sottorete in IPv4:
- in IPv4 una sottorete è un insieme di host con lo stesso prefisso;
- in IPv6 un link è l'effettiva rete fisica.
Tutti gli host nella stessa sottorete appartengono allo stesso link e viceversa:
- gli host on-link hanno lo stesso prefisso, così possono comunicare direttamente;
- gli host off-link hanno prefissi diversi, così possono comunicare attraverso un router.
Organizzazione dello spazio di indirizzamento
[modifica | modifica sorgente]Indirizzi global unicast
[modifica | modifica sorgente]Indirizzi global unicast aggregatable
[modifica | modifica sorgente]Sono equivalenti agli indirizzi pubblici IPv4, e iniziano con i 3 bit "001":
3 | 16 | 48 | 64 | 88 | 96 | 104 | 128 |
001 | ID TLA | ID NLA | ID SLA | OUI (bit "universale" = 1) | FF | FE | porzione del MAC scelta dal produttore |
prefisso | interface identifier (EUI 64) |
- Prefisso: deve essere uguale a quello assegnato al link a cui è connesso l'host.
- Il criterio per l'assegnazione dei prefissi è basato sulla topologia: essi sono assegnati in base alla gerarchia dei service provider:
- Top Level Authority (TLA): un service provider grande;
- Next Level Authority (NLA): un service provider intermedio;
- Subnet Level Authority (SLA): una azienda.
- Interface identifier: identifica l'interfaccia dell'host.
- Opzionalmente può essere in formato EUI-64: l'interface identifier IPv6 a 64 bit deriva dall'indirizzo MAC a 48 bit dell'host:
24 | 48 |
OUI (bit "universale" = 0) | porzione del MAC scelta dal produttore |
- dove il bit "universale" è il settimo bit nell'OUI e viene cambiato da 0 a 1.
Indirizzi per l'interoperabilità con IPv4
[modifica | modifica sorgente]Sono da usare durante la fase di transizione, e iniziano con 80 bit impostati a zero:
- indirizzi mappati IPv4: i primi 80 bit sono zeri e i successivi 16 bit sono impostati a uno:
0000 | 0000 | 0000 | 0000 | 0000 | FFFF | ... |
- indirizzi compatibili con IPv4: i primi 80 bit sono zeri e i successivi 16 bit sono impostati a zero (per es. l'indirizzo IPv6 "::10.0.0.1" mappa l'indirizzo IPv4 "10.0.0.1"):
0000 | 0000 | 0000 | 0000 | 0000 | 0000 | ... |
Indirizzi local unicast
[modifica | modifica sorgente]Indirizzi link local
[modifica | modifica sorgente]Si riferiscono agli indirizzi privati "automatici", generati dall'autoconfigurazione, che è il processo in cui una stazione genera automaticamente un indirizzo per connettersi a un link IPv6:
FExx | ... |
Indirizzi site local
[modifica | modifica sorgente]Sono equivalenti agli indirizzi privati IPv4:
FDxx | ... |
Indirizzi multicast
[modifica | modifica sorgente]Un indirizzo multicast identifica un gruppo di stazioni, e ha il formato seguente:
8 | 12 | 16 | 128 |
FF | Flag (000T) | Scope | Group ID |
dove i campi sono:
- campo Flag (4 bit): è usato per contrassegnare un gruppo multicast:
- T = 1: il gruppo multicast è temporaneo (per es. chiamata di conferenza definita dall'utente);
- T = 0: il gruppo multicast è permanente (per es. indirizzo di tutti gli host della rete, non può essere sovrascritto);
- campo Scope (4 bit): è usato per limitare la diffusione del multicast (meglio del TTL di IPv4):
- 1 = node local: il pacchetto non può andare fuori dall'host;
- 2 = link local: il pacchetto non può andare fuori dalla rete di livello 2;
- 5 = site local: il pacchetto non può andare fuori per es. dalla rete dell'università;
- 8 = organization local: il pacchetto non può andare fuori dalla rete dell'organizzazione;
- E = global: il pacchetto può andare ovunque;
- campo Group ID (112 bit): identifica il gruppo multicast, e il pacchetto viene inoltrato a tutti i nodi nel gruppo.
Se un host vuole appartenere a un gruppo multicast, deve chiederlo usando il protocollo ICMP; una volta che viene aggiunto al gruppo multicast, riceverà tutti i pacchetti inviati a quel particolare indirizzo multicast. È molto importante notare che gli host che riceveranno un pacchetto multicast non sono definiti dalla sorgente, ma sono "decisi" dalle destinazioni.
Indirizzi multicast solicited node
[modifica | modifica sorgente]Ogni nodo operativo appartiene per impostazione predefinita a un gruppo multicast solicited node il cui indirizzo deriva dal suo indirizzo IPv6:
96 | 104 | 128 |
FF02::1 | FF | 24 bit meno significativi dall'indirizzo IPv6 |
Ci può essere più di un host nello stesso gruppo multicast, ma generalmente no perché l'indirizzo multicast è generato dall'indirizzo IPv6.
Mappare IPv6 su Ethernet
[modifica | modifica sorgente]Ogni pacchetto multicast viene consegnato tramite una trama Ethernet con uno specifico indirizzo MAC derivato da un indirizzo multicast IPv6, in modo che il pacchetto venga elaborato solamente dagli host interessati:
16 | 48 |
3333 | 32 bit meno significativi dall'indirizzo IPv6 di destinazione |
Argomenti avanzati legati agli indirizzi IPv6
[modifica | modifica sorgente]Renumbering
[modifica | modifica sorgente]Poiché i prefissi degli indirizzi global sono assegnati in base alla gerarchia dei service provider, se una società vuole passare da un service provider a un altro, tutti i link nella rete aziendale dovranno cambiare prefisso. IPv6 è pensato per supportare un renumbering facile sia per gli host sia per i router:
- host: i router gradualmente smettono di annunciare il vecchio prefisso (deprecato) e iniziano ad annunciare quello nuovo (preferito) → ogni host avrà durante la fase di migrazione due indirizzi con prefissi diversi per la stessa interfaccia;
- router: Router Renumbering è uno standard che consente al router di frontiera di notificare il nuovo prefisso agli altri router interni.
Tuttavia il renumbering ha ancora alcuni problemi irrisolti, relativi a come aggiornare automaticamente ad es. le entry dei DNS, i filtri dei firewall, le politiche aziendali basate sugli indirizzi, ecc.
Multi-homing
[modifica | modifica sorgente]Una grande società può decidere di acquistare la connettività a Internet da due diversi service provider perché vuole continuare ad essere connessa a Internet anche se uno dei service provider ha qualche problema.
Poiché i prefissi degli indirizzi globali sono assegnati in base alla gerarchia dei service provider, ogni host all'interno della rete aziendale avrà due indirizzi globali con prefissi diversi per la stessa interfaccia → l'host dovrà selezionare l'indirizzo da utilizzare per ogni pacchetto in uscita. Questo può provocare alcuni problemi di configurazione non banali:
- instradamento basato sull'indirizzo di destinazione: l'host dovrebbe essere capace di selezionare il prefisso giusto per i pacchetti in uscita, altrimenti supponiamo che l'host selezioni il prefisso del provider A ma la destinazione si trovi nella rete del provider B → il router di frontiera grazie ai meccanismi di instradamento inoltrerà il pacchetto direttamente nella rete del provider B → il provider B bloccherà quel pacchetto perché l'indirizzo sorgente ha un prefisso diverso;
- registrazione doppia nei DNS: l'host dovrebbe essere registrato nei DNS con due indirizzi diversi per lo stesso alias;
- renumbering automatico: i meccanismi per il renumbering dovrebbero supportare dinamicamente il passaggio da un provider B a un provider C.
Indirizzi scoped
[modifica | modifica sorgente]Un host può avere due interfacce (ad es. un'interfaccia Ethernet e una wi-fi) che possono essere connesse a due link diversi allo stesso tempo. Quando l'host vuole mandare il pacchetto a un indirizzo di destinazione link local, non sa se far uscire il pacchetto dall'interfaccia A o dall'interfaccia B, perché entrambi i link hanno lo stesso prefisso; inoltre, poiché ogni indirizzo link local è univoco entro il proprio link, un host nel link A potrebbe avere lo stesso indirizzo link local di un altro host nel link B.
In IPv6 l'host deve specificare nell'indirizzo IPv6 di destinazione un identificativo chiamato scope che è usato per identificare l'interfaccia fisica (per es. FE80::0237:00FF:FE02:A7FD%19). I valori degli scope vengono selezionati dal sistema operativo secondo i suoi criteri interni.
Intestazione IPv6 standard
[modifica | modifica sorgente]L'intestazione IPv6 standard ha il seguente formato di dimensione fissa (40 byte):
4 | 12 | 16 | 24 | 32 |
Version (6) | Priority | Flow label | ||
Payload length | Next header | Hop limit | ||
Indirizzo | ||||
sorgente | ||||
Indirizzo | ||||
di destinazione | ||||
dove i campi più significativi sono:
- campo Version (4 bit): non è molto usato, perché la discriminazione dei pacchetti è svolta dal livello 2 → ciò permette l'approccio dual-stack ( Tecnologie e servizi di rete/Migrazione a IPv6#Migrazione dei sistemi operativi);
- campo Priority (8 bit): equivalente al campo "Type of Service" di IPv4, permette di distinguere diversi tipi di servizi per la qualità del servizio ( Tecnologie e servizi di rete/Qualità del servizio#Architettura);
- campo Flow label (20 bit): permette di distinguere diversi flussi per la qualità del servizio;
- campo Next header (8 bit): fa riferimento al payload del pacchetto, cioè un'intestazione di livello superiore (per es. TCP/UDP) oppure il primo extension header nella catena ( #Extension header);
- campo Hop limit (8 bit): è equivalente al campo "Time To Live" di IPv4;
- campo Source address (128 bit): contiene l'indirizzo IPv6 sorgente del mittente del pacchetto;
- campo Destination address (128 bit): contiene l'indirizzo IPv6 di destinazione del destinatario del pacchetto.
Alcuni campi IPv4 sono stati rimossi:
- campo Checksum: la protezione dagli errori è demandata a livello 2 (frame check sequence);
- campo Fragmentation: la frammentazione è delegata all'extension header "Fragment";
- campo Header length: l'intestazione IPv6 è di dimensione fissa, poiché le funzionalità aggiuntive sono opzionalmente offerte dagli extension header.
Extension header
[modifica | modifica sorgente]Ci sono sei extension header, aggiunti solo quando necessario ed elaborati nell'ordine seguente:
- Hop by hop option: include informazioni facoltative che ogni hop deve elaborare;
- Routing: consente il source routing, cioè la sorgente decide quale rotta deve prendere il pacchetto;
- Fragment: gestisce la frammentazione;
- Authentication Header (AH): consente di autenticare il mittente;
- Encapsulating Security Payload (ESP): consente di criptare il contenuto del pacchetto;
- Destination option: include informazioni facoltative che solo la destinazione deve elaborare.
I router elaborano sempre solo fino all'extension header "Routing".
Tutti gli extension header hanno lo stesso formato generico (la lunghezza dev'essere un multiplo di 64 bit):
8 | 16 | 32 |
Next Header | Header Length | |
Extension data ::: |
dove i campi sono:
- campo Next Header: specifica l'extension header seguente nella catena, o l'intestazione di livello superiore (ad es. TCP/UDP) se questo è l'ultimo extension header;
- campo Header Length: specifica la lunghezza dell'extension header corrente.
- Poiché nel corso del tempo possono venire standardizzati nuovi extension header, i vecchi apparati potrebbero non essere in grado di elaborare gli extension header recenti → essi possono guardare il campo "Length" per saltare l'extension header sconosciuto.
- Il campo "Header Length" potrebbe non essere presente in alcuni extension header (come l'extension header "Fragment") che lo standard IPv6 definisce come aventi lunghezza fissa.
Hop by hop option e Destination option
[modifica | modifica sorgente]Gli extension header Hop by hop option e Destination option possono includere più opzioni aggiuntive:
- Hop by hop option: include opzioni che deve elaborare ogni router attraverso cui passa il pacchetto;
- Destination option: include opzioni che deve elaborare solo la destinazione.
Per esempio, se ci sono due opzioni con valori lunghi 8 bit, l'extension header avrà il seguente formato:
8 | 16 | 24 | 32 |
Next Header | Header Length | Type1 | Length |
Value1 | Type2 | Length2 | Value2 |
in cui ogni opzione ha sempre i seguenti tre campi:
- campo Length (8 bit): specifica la lunghezza dell'opzione corrente, in modo che i router non in grado di riconoscere l'opzione possano limitarsi a saltarla;
- campo Type (8 bit): identifica l'opzione corrente.
- I primi due bit specificano sempre l'azione da eseguire nel caso in cui l'opzione non venga riconosciuta, mentre il terzo bit specifica se l'opzione può essere modificata al volo:
- 00 = l'opzione corrente può essere ignorata ed è possibile procedere alla prossima;
- 01 = il pacchetto deve essere scartato;
- 10 = il pacchetto deve essere scartato e deve essere generato un ICMPv6 Parameter Problem;
- 11 = il pacchetto deve essere scartato e deve essere generato un ICMPv6 Parameter Problem, a meno che l'indirizzo di destinazione non sia uno multicast;
- xx0 = l'opzione non può essere modificata;
- xx1 = l'opzione può essere modificata al volo;
- campo Value (lunghezza variabile): contiene il valore dell'opzione.
Routing
[modifica | modifica sorgente]L'extension header Routing consente alla sorgente di decidere quale rotta deve prendere il pacchetto (source routing), e ha il formato seguente:
8 | 16 | 24 | 32 | |
Next Header | Header Length | Routing Type | Segment Left | |
(riservato) | ||||
Router | ||||
Address 1 | ||||
... | ||||
Router | ||||
Address N | ||||
dove i campi sono:
- campo Routing Type (8 bit): specifica il tipo di instradamento (attualmente "0" per il classico source routing);
- campo Segment Left (8 bit): specifica il numero di hop rimanenti alla destinazione;
- campi Router Address (128 bit ciascuno): sono la lista degli indirizzi IPv6 dei router attraverso cui deve passare il pacchetto.
Per esempio:
La sorgente S invia il pacchetto verso la destinazione D, aggiungendo un extension header "Routing" che forza il pacchetto a passare per i router intermedi R1 e R2. Quindi all'inizio il pacchetto ha apparentemente il router R1 come destinazione, mentre la vera destinazione D è specificata come ultimo passo nella lista dei router specificata dall'extension header "Routing". Quando il pacchetto arriva al router R1, questo lo riconosce come apparentemente indirizzato ad esso; infatti, il suo indirizzo compare nel campo "Destination Address" nell'intestazione IPv6. Il router R1 controlla le intestazioni successive e scopre che il pacchetto contiene un extension header "Routing", rendendosi conto che la destinazione finale del pacchetto è un altro host (in particolare il campo "Segment Left" dice che è necessario attraversare due hop prima di arrivare alla destinazione finale). Il router R1 trova l'indirizzo IPv6 del prossimo hop a cui mandare il pacchetto e lo sostituisce con il proprio indirizzo IPv6, quindi manda il pacchetto con la destinazione impostata a R2. Il processo continuerà di hop in hop, finché la destinazione D non riceverà un pacchetto IPv6 il cui extension header "Routing" contiene il campo "Segment Left" impostato a 0, che significa che il pacchetto ha raggiunto la destinazione finale. La destinazione D è in grado di sapere tutti gli hop per i quali è passato il pacchetto perché essi si trovano tutti scritti nell'extension header "Routing", quindi esso può inoltrare la risposta alla sorgente S specificando la stessa lista (inversa) di hop.
Fragment
[modifica | modifica sorgente]L'extension header Fragment consente di inviare un pacchetto in parti più piccole chiamate "frammenti", e ha il formato seguente:
8 | 16 | 29 | 31 | 32 |
Next Header | (riservato) | Fragment Offset | (riservato) | M |
Identification |
dove i campi sono:
- campo Fragment Offset (13 bit): specifica il numero del byte in cui inizia il frammento nella sezione frammentata del pacchetto originale;
- flag More Fragments (M) (1 bit): se è impostato a 0 il pacchetto corrente è l'ultimo frammento;
- campo Identification (32 bit): tutti i frammenti di uno specifico pacchetto hanno lo stesso identificativo.
Ogni pacchetto include due sezioni:
- una sezione che non può essere frammentata, così viene ripetuta in tutti i frammenti: include l'intestazione IPv6 e tutti gli extension header che precedono l'extension header "Fragment";
- una sezione che può essere frammentata: include tutti gli extension header che seguono l'extension header "Fragment" e il payload del pacchetto.
Al contrario di IPv4, solo al nodo mittente è consentito frammentare i datagram, mentre i router IPv6 non supportano la frammentazione. Inoltre, lo standard IPv6 suggerisce fortemente di utilizzare il Path MTU Discovery al posto della frammentazione per motivi prestazionali: #Packet Too Big.
IPsec
[modifica | modifica sorgente]Le soluzioni sviluppate per IPv6 derivano dal porting della suite di protocolli IPsec di IPv4. In IPv6 IPsec è una suite di protocolli integrata che definisce due intestazioni:
- Authentication Header (AH): autentica l'intero pacchetto, tranne i campi che cambiano al passaggio da un hop all'altro (per es. limite di hop), garantendo che nessuno abbia modificato il contenuto del pacchetto;
- Encapsulating Security Payload (ESP): autentica e cripta il payload del pacchetto per la privacy dei dati.
SA
[modifica | modifica sorgente]IPsec non definisce quali algoritmi devono essere usati per la crittografia e l'autenticazione, ma le due parti devono concordare su quali usare per scambiare informazioni protette con IPsec → flessibilità: gli algoritmi vengono scelti sulla base delle necessità del momento.
Una Security Association (SA) si può definire come l'insieme degli accordi tra le due parti A e B riguardo alle chiavi e agli algoritmi privati da usare per l'autenticazione e la crittografia ESP e per l'autenticazione AH. Ogni SA è identificata da un tag di identificazione chiamato Security Parameter Index (SPI), incluso nelle intestazioni AH e ESP, ed è un canale logico unidirezionale: A e B devono aprire una SA per concordare sulle chiavi e sugli algoritmi per i messaggi che vanno da A a B, e devono aprire un'altra SA per concordare su di essi per i messaggi che vanno da B a A. Spesso per ogni porta TCP viene aperta una SA.
IKE
[modifica | modifica sorgente]A e B come fanno a mettersi d'accordo su chiavi segrete evitando che degli estranei le sappiano? Ci sono tre principali strategie:
- configurazione statica: le chiavi sono configurate manualmente in A e B → la negoziazione delle chiavi non è richiesta affatto;
- metodo di Diffie-Hellman: permette di concordare su una chiave senza scambiarla → nessuno può scoprire le chiavi segrete sniffando il traffico tra A e B;
- protocollo Internet Key Exchange (IKE): utilizza i certificati digitali e la crittografia asimmetrica per inviare le chiavi segrete in un modo sicuro.
Il protocollo IKE specifica che si deve stabilire una SA IKE da A a B per concordare sulle chiavi segrete per la SA figlia da A a B, e viceversa un'altra per la SA figlia da B ad A. La SA IKE da A a B consiste delle seguenti operazioni basate sulla crittografia asimmetrica:[1]
- B chiede ad A una chiave segreta da usare per la SA figlia da A a B;
- A chiede ad una autorità di certificazione fidata il certificato digitale di B, per sapere se B è veramente chi dice di essere;
- l'autorità di certificazione fornisce ad A il certificato digitale di B, criptato usando la chiave privata dell'autorità di certificazione, contenente la firma di B, cioè l'associazione tra B e una chiave pubblica;
- A decripta il certificato digitale usando la chiave pubblica dell'autorità di certificazione ed apprende la chiave pubblica associata a B;
- A manda a B la chiave segreta per la SA figlia, criptando il messaggio usando la chiave pubblica associata a B in modo che possa essere decriptato solo conoscendo la chiave privata di B;
- B riceve il messaggio da A, lo decripta usando la sua chiave privata ed apprende la chiave segreta decisa da A per la SA figlia;
- si può aprire la SA figlia da A a B che usa la chiave segreta concordata.
Degli estranei potrebbero guardare il traffico scambiato tra A e B e indovinare le chiavi segrete dopo un po' di tempo, effettuando degli attacchi brute-force o analizzando alcune informazioni statistiche dedotte. Internet Security Association Key Management Protocol (ISAKMP) è un sotto-protocollo di IKE per rinegoziare periodicamente le chiavi segrete in un modo sicuro, in modo che gli estranei non abbiano tempo per indovinarle.
AH
[modifica | modifica sorgente]L'Authentication Header (AH) garantisce integrità connectionless e autenticazione dell'origine dei dati per i pacchetti IP: autentica l'intero pacchetto, tranne i campi che cambiano al passaggio da un hop all'altro (per es. campo "Hop limit"), garantendo che nessuno abbia modificato il contenuto del pacchetto.
AH ha dei problemi con i NAT, perché autentica anche gli indirizzi e le porte.
L'Authentication Header ha il seguente formato:
8 | 16 | 32 |
Next Header | Payload Length | (riservato) |
SPI | ||
Sequence Number | ||
Authentication Data ::: |
dove i campi sono:
- campo Next Header (8 bit): specifica il prossimo protocollo incapsulato;
- campo Payload Length (8 bit): specifica la dimensione dell'Authentication Header in parole da 32 bit − 2 (può essere azzerato);
- campo Security Parameters Index (SPI) (32 bit): identifica la Security Association per questo datagram (se azzerato, non esiste una Security Association; i valori nell'intervallo da 1 a 255 sono riservati);
- campo Sequence Number (32 bit): contiene un valore contatore monotonicamente crescente;
- campo Message Digest (lunghezza variabile): riassume il contenuto del pacchetto utilizzando una chiave segreta: tutti coloro che vogliono modificare il contenuto del pacchetto devono sapere la chiave per ricalcolare il message digest (simile al campo per il rilevamento degli errori).
ESP
[modifica | modifica sorgente]L'intestazione Encapsulating Security Payload (ESP) fornisce autenticità dell'origine, integrità e tutela della riservatezza per i pacchetti IP: autentica e cripta il payload del pacchetto per la privacy dei dati.
Sebbene ESP sia in grado di autenticare, non effettua la stessa funzionalità di AH: ESP non autentica l'intero pacchetto IPv6.
L'intestazione ESP è sempre l'ultima nella catena delle intestazioni e ha il seguente formato:
16 | 24 | 32 | ||
SPI | autenticati | |||
Sequence Number | ||||
Payload Data ::: | criptati | |||
Padding ::: | ||||
Payload Length | Next Header | |||
Authentication Data ::: |
dove i campi sono:
- campo Security Parameters Index (SPI) (32 bit): identifica la Security Association per questo datagram;
- campo Sequence Number (32 bit senza segno): contiene un valore contatore monotonicamente crescente.
- Il campo "Sequence number" è obbligatorio per il trasmettitore ed è sempre presente anche se il ricevitore non sceglie di attivare il servizio anti-replay per una specifica SA, ma l'elaborazione di questo campo è a discrezione del ricevitore;
- campo Payload Data (lunghezza variabile): contiene i dati descritti dal campo "Next Header";
- campo Padding (lunghezza variabile da 0 a 255 bit): può essere richiesto del padding, a prescindere dai requisiti degli algoritmi di crittografia, per assicurare che il testo cifrato risultante termini su un boundary di 4 byte;
- campo Padding Length (8 bit): specifica la dimensione del campo "Padding" (in byte);
- campo Next Header (8 bit): un numero di protocollo IPv4/IPv6 che descrive il formato del campo "Payload Data";
- campo Authentication Data (lunghezza variabile): contiene un Integrity Check Value (ICV) calcolato sul pacchetto ESP meno il campo "Authentication Data".
- La lunghezza del campo "Authentication Data" è specificata dalla funzione di autenticazione selezionata. Il campo "Authentication Data" è facoltativo: viene incluso solo se il servizio di autenticazione è stato selezionato per la SA in questione. La specifica dell'algoritmo di autenticazione deve specificare la lunghezza dell'ICV e le regole di confronto e le fasi di elaborazione per la convalida. Si noti che il campo "Authentication Data" non è criptato.
Sono possibili due modi d'uso per ESP (opzionalmente in combinazione con AH):
- transport mode: ESP non cripta l'intestazione IPv6 → chiunque nel mezzo è in grado di vedere gli indirizzi IP sorgente e di destinazione nell'intestazione IPv6:
intestazione IPv6 | altri extension header | intestazione ESP (per la crittografia) |
intestazione TCP/UDP | payload | autenticazione ESP |
dati criptati | |||||
dati autenticati |
- tunnel mode: è possibile incapsulare un pacchetto IPv6 in un altro pacchetto IPv6 avente ESP (e opzionalmente AH) per proteggere anche l'intestazione IPv6 (contenente gli indirizzi IP sorgente e di destinazione):
intestazione IPv6 | intestazione ESP (per la crittografia) |
intestazione IPv6 | altri extension header | intestazione TCP/UDP | payload | autenticazione ESP |
dati criptati | ||||||
dati autenticati |
ICMPv6
[modifica | modifica sorgente]Internet Control Message Protocol version 6 (ICMPv6) è parte integrante dello standard IPv6, e a sua volta integra espandendole le funzionalità dei protocolli ARP e IGMP.
Tutti i messaggi ICMPv6 vengono posti subito dopo gli extension header nel pacchetto, e hanno lo stesso formato generico:
8 | 16 | 32 |
Type | Code | Checksum |
Message Body ::: |
dove il campo "Type" identifica il tipo di messaggio ICMPv6:
- messaggi per la diagnostica: come in ICMPv4, consentono di segnalare errori o problemi nella rete:
- 1 = Destination Unreachable
- 2 = Packet Too Big
- 3 = Time Exceeded
- 4 = Parameter Problem
- messaggi utilizzati dal comando
ping
:- 128 = Echo Request
- 129 = Echo Reply
- messaggi Multicast Listener Discovery: espandono le funzionalità di IGMP:
- 130 = Multicast Listener Query
- 131 = Multicast Listener Report
- 132 = Multicast Listener Done
- messaggi Neighbor Discovery: espandono le funzionalità di ARP:
- 133 = Router Solicitation
- 134 = Router Advertisement
- 135 = Neighbor Solicitation
- 136 = Neighbor Advertisement
- 137 = Redirect
Packet Too Big
[modifica | modifica sorgente]Quando un router riceve un pacchetto che ha una dimensione troppo grande, effettua una tecnica chiamata Path MTU Discovery: scarta il pacchetto e invia in risposta un messaggio ICMPv6 di tipo Packet Too Big al fine di notificare al mittente la dimensione della Maximum Transmission Unit (MTU) consentita e di forzarlo a rimandare il pacchetto stesso (e i pacchetti successivi) con una dimensione che non superi la MTU specificata dal router. Questa tecnica ha l'obiettivo di evitare il più possibile la frammentazione.
Multicast Listener Discovery
[modifica | modifica sorgente]Multicast Listener Discovery è la componente in ICMPv6 che espande le funzionalità del protocollo IGMP di IPv4 per gestire le appartenenze ai gruppi multicast:
- Multicast Listener Query:
- General Query: il router chiede agli host se sono interessati ad appartenere a un qualche gruppo multicast;
- Multicast Address Specific Query: il router chiede agli host se sono interessati ad appartenere a un particolare gruppo multicast;
- Multicast Listener Report: l'host notifica al router che vuole appartenere a un particolare gruppo multicast per ricevere tutti i pacchetti multicast indirizzati all'indirizzo multicast corrispondente al gruppo multicast specificato;
- Multicast Listener Done: l'host notifica al router che vuole smettere di ricevere i pacchetti multicast di un particolare gruppo multicast.
Neighbor Discovery
[modifica | modifica sorgente]Neighbor Discovery è la componente in ICMPv6 che espande le funzionalità del protocollo ARP di IPv4:
- Neighbor Solicitation: l'host invia un pacchetto multicast avente, come indirizzo IPv6 di destinazione, l'indirizzo multicast solicited node corrispondente all'indirizzo IPv6 di cui vuole apprendere l'indirizzo MAC;
- Neighbor Advertisement: l'host avente l'indirizzo IPv6 specificato invia in risposta il suo indirizzo MAC;
- Router Solicitation: l'host invia un pacchetto multicast per sollecitare il router a inviare in risposta un messaggio "Router Advertisement" contenente l'interface identifier associato al link;
- Router Advertisement: il router annuncia la propria presenza nel link segnalando l'interface identifier associato al link.
I messaggi ICMPv6 "Neighbor Discovery" si usano per autoconfigurare gli indirizzi IPv6 di un host che si connette a un link: prima l'host deve ottenere un indirizzo link local per poter contattare gli altri host nel link, quindi deve ottenere un indirizzo global per poter uscire dal link e accedere a Internet con un indirizzo globalmente univoco.
Processo di autoconfigurazione dell'indirizzo link local
[modifica | modifica sorgente]L'indirizzo link local viene autoconfigurato utilizzando i messaggi ICMPv6 "Neighbor Solicitation" e "Neighbor Advertisement":
- l'host genera da sé un indirizzo IPv6 candidato ad essere il suo indirizzo link local:
- prefisso: è sempre "FE80::";
- interface identifier: può essere generato basato sull'indirizzo MAC (formato EUI-64) oppure in modo casuale per motivi di privacy (tracciabilità);
- l'host invia in multicast un messaggio "Neighbor Solicitation" a tutti gli host nel link, specificando come indirizzo IPv6 di destinazione il suo indirizzo auto-generato e chiedendo se esiste nel link un host il cui indirizzo link local è uguale all'indirizzo IPv6 specificato (Duplicated Address Detection);
- se esiste già nel link un host avente l'indirizzo link local del mittente, esso invia in risposta un messaggio "Neighbor Advertisement" al mittente, che dovrà generare in modo casuale un altro indirizzo candidato e inviare in multicast un altro messaggio "Neighbor Solicitation";
- se nessuno risponde, l'indirizzo è univoco nel link e l'host è in grado di contattare ogni altro host entro lo stesso link utilizzando il suo indirizzo link local, ma non è ancora in grado di accedere a Internet perché ha bisogno di un indirizzo global.
Processo di autoconfigurazione dell'indirizzo global
[modifica | modifica sorgente]L'indirizzo global viene autoconfigurato utilizzando i messaggi ICMPv6 "Router Solicitation", "Router Advertisement", "Neighbor Solicitation" e "Neighbor Advertisement":
- l'host invia in multicast un messaggio "Router Solicitation" per sollecitare il router a inviare in risposta un messaggio "Router Advertisement" contenente l'interface identifier associato al link;[2]
- il router invia in risposta un messaggio "Router Advertisement" contenente i due flag "Managed Address Configuration" (M) e "Other configuration" (O):
- M = 1: l'host deve contattare il server DHCP per il prefisso del link e gli altri parametri di configurazione della rete (come l'indirizzo del DNS), senza curarsi dei messaggi "Router Advertisement" dal router (configurazione stateful);
- M = 0: l'host deve guardare il flag "O":
- O = 1: l'host può prendere il prefisso del link dal messaggio "Router Advertisement", ma deve comunque contattare il server DHCP per gli altri parametri di configurazione della rete (come l'indirizzo del DNS);
- O = 0: l'host può prendere il prefisso del link dal messaggio "Router Advertisement", e nessun'altra informazione di configurazione è disponibile dal server DHCP (configurazione stateless) → gli altri parametri di configurazione della rete (come l'indirizzo del DNS) dovranno essere configurati a mano sull'host, oppure l'host può ottenere l'indirizzo del server DNS tramite IPv4 ( Tecnologie e servizi di rete/Migrazione a IPv6#Migrazione dei DNS);
- l'host genera da sé un indirizzo IPv6 candidato ad essere il suo indirizzo global:
- prefisso: è uguale al prefisso del link, preso dal messaggio "Router Advertisement" oppure contattando il server DHCP;
- interface identifier: può essere generato basato sull'indirizzo MAC (formato EUI-64) oppure in modo casuale per motivi di privacy (tracciabilità);
- l'host invia in multicast un messaggio "Neighbor Solicitation" a tutti gli host nel link, specificando come indirizzo IPv6 di destinazione il suo indirizzo auto-generato e chiedendo se esiste nel link un host il cui indirizzo global è uguale all'indirizzo IPv6 specificato (Duplicated Address Detection);
- se esiste già nel link un host avente l'indirizzo global del mittente, esso invia in risposta un messaggio "Neighbor Advertisement" al mittente, che dovrà generare in modo casuale un altro indirizzo candidato e inviare in multicast un altro messaggio "Neighbor Solicitation";
- se nessuno risponde, l'indirizzo è globalmente univoco e l'host è in grado di accedere a Internet utilizzando il suo indirizzo global.
Un'altra implementazione proposta da Microsoft consiste nella possibilità per l'host di contattare il server DNS senza conoscerne l'indirizzo: l'host manda i pacchetti a un indirizzo anycast fisso, e la rete si prende cura di consegnare il pacchetto al server DNS. Tuttavia questa implementazione non è in realtà usata:
- le implementazioni per la gestione degli indirizzi anycast sono rare;
- questa soluzione non è supportata dal sistema operativo GNU/Linux.
L'autoconfigurazione è basata sull'indirizzo MAC, così se la scheda di rete si rompe e richiede di essere sostituita l'host dovrà cambiare il proprio indirizzo, ma le cache (ad es. la cache DNS) non sono in grado di aggiornarsi immediatamente → è sempre possibile la configurazione statica, specialmente per le macchine fisse (ad es. i server di siti Web pubblici) che devono evitare di cambiare i loro indirizzi al fine di continuare ad essere raggiungibili in un modo il più continuo possibile.