Scarica appunti Ipv6 parte 1 e più Appunti in PDF di Reti Di Calcolatori solo su Docsity!
L'evoluzione di IP: Internet Protocol versione 6
Introduzione
Lo scenario
Il successo, assolutamente imprevisto, della rete Internet è ormai sotto gli occhi di tutti. Le teorizzazioni, fatte negli anni 80, di una futura rete a banda larga integrata nei servizi (Broadband Integrated Services Digital Network o B-ISDN) si sono realizzate attraverso l'impiego della tecnologia TCP/IP, anche se all'epoca la tecnologia più promettente sembrava essere Asyncronous Transfer Mode (ATM).
Il grande successo di TCP/IP di questi ultimi anni è visibile attraverso la diffusione della più importante rete che adotta questa tecnologia, Internet. Nell'ambito della tecnologia TCP/IP, il protocollo IP riveste un'importanza particolare: esso è il componente di livello Network (secondo il modello ISO OSI) ed offre la possibilità di trasportare un dato elementare (un pacchetto) tra due qualsiasi nodi (host) che condividono questa tecnologia. Il protocollo IP funge da protocollo unificante rispetto alla moltitudine delle possibili tecnologie di livello inferiore, permettendo, ad un applicazione scritta per una rete TCP/IP, di funzionare indipendentemente dal mezzo fisico e dalla tecnologia di livello Data-Link impiegata. Questo consente di utilizzare tecnologie diverse in parti diverse della rete: per esempio, reti locali (Ethernet, Token Ring, Wireless LAN) all’interno degli edifici e servizi pubblici a commutazione di trama (Frame Relay) o di cella (ATM), canali diretti numerici (CDN) o collegamenti SONET/SDH per la parte geografica della rete stessa, oppure tecnologie mobili (GSM, Bluetooth, etc) per quanto riguarda il mondo delle comunicazioni cellulari.
La crescita vertiginosa del numero di utenti di questi ultimi anni e la conseguente richiesta di servizi nuovi e più efficienti ha reso IP (standardizzato nel 1981 dalla RFC
- un protocollo ormai un po’ datato anche se non ancora obsoleto. Per garantire l'attuale crescita del numero di utenti, applicazioni e servizi, si è reso necessario rimediare ad alcuni problemi attraverso la definizione di una nuova versione dello stesso, l'Internet Protocol versione 6 (IPv6), segnando una decisa evoluzione rispetto alla versione 4 attualmente in uso. Tuttavia, pur condividendo le idee di base, IPv6 si configura più come un nuovo protocollo che non una versione evoluta dell'attuale IPv4.
Per capire le motivazioni che hanno spinto alla definizione dell'IPv6, è opportuno elencare i principali limiti dell'IPv4.
Limiti di IPv
I problemi che hanno messo in luce i limiti del protocollo IPv4 sono tutti legati alla crescita vertiginosa del numero di utenti di Internet in questi ultimi anni; fra questi il più evidente è ovviamente l’esaurimento degli indirizzi disponibili, problema che potrebbe portare in pochi anni all’impossibilità ad accedere alla rete a nuovi utenti; fra i nuovi utenti che con l’attuale organizzazione rischierebbero l’esclusione non ci sarebbero solamente i personal computer classici ma anche terminali GPRS e UMTS, ed elettrodomestici di uso comune, ai quali in futuro potrebbero essere associati degli indirizzi IP; in parole povere è prevedibile che in futuro ad ogni persona siano associati più indirizzi. Inoltre il numero attuale di utenti (quindi senza bisogno di riferirsi ai ben più critici scenari futuri) ha avuto come conseguenza l’aumento del traffico e quindi maggiori problemi per i router nella gestione delle tabelle di instradamento, che sono aumentate in numero e dimensioni. Per finire, come ultima conseguenza della crescita di Internet si è avuta la richiesta di servizi nuovi e l’ottimizzazione di quelli già esistenti, in modo particolare riguardo alla sicurezza, alla qualità di servizio (QoS), alla mobilità e all’autoconfigurazione.
Esaurimento dello spazio di indirizzamento
Fra le tante ragioni che hanno portato alla nascita di IPv6 la principale è stata sicuramente la previsione dell’esaurimento dello spazio di indirizzamento disponibile con IPv4. Come è noto gli indirizzi di IPv4 sono su 32 bit, e tale dimensione si è rivelata per molto tempo un’ottima scelta; infatti con 32 bit sono disponibili circa 4 miliardi di indirizzi, e tale disponibilità sembrava mettere al riparo dal rischio di esaurimento anche per quanto riguarda un futuro abbastanza lontano. In realtà, l'aumento vertiginoso del numero di utenti ha reso questa risorsa un bene prezioso: infatti, nel calcolo del valore massimo di indirizzi disponibili non si è tenuto conto della struttura degli indirizzi IPv4 e delle modalità di assegnazione che erano originariamente piuttosto "sprecone". Infatti, le modalità di assegnazione prevedevano che ogni utente potesse avere 256, 65535, oppure 16777216 indirizzi, senza alcuna gradazione intermedia. Questa modalità assegnazione faceva sì che un utente con 1000 macchine occupasse comunque 65 mila indirizzi, con uno spreco di risorse non indifferente.
Nonostante questa modalità di assegnazione sia stata successivamente variata, è stato dimostrato da Christian Huitema (RFC 1715) come, in una rete moderna, l'efficienza di assegnazione degli indirizzi sia moderatamente bassa. Infatti, definendo l’efficienza di assegnazione degli indirizzi H come il rapporto tra il logaritmo in base 10 del numero di indirizzi utilizzati e il numero di bit dell’indirizzo, da tale formula si può ipotizzare che in uno schema ad efficienza massima vengono utilizzati tutti gli indirizzi e quindi H=0.301. Tuttavia, lo studio di altre reti esistenti (ad esempio quella telefonica, etc) ha rivelato come in condizioni reali tale parametro vari tra 0.22 e 0.26, limitando così il numero di indirizzi assegnabili a circa 200 milioni. Questo numero è dovuto ad principalmente alle seguenti ragioni:
- la rete deve essere essa stessa gestita, quindi alcuni indirizzi devono essere assegnati agli apparati di rete anzichè agli host
- molte reti hanno un certo numero di indirizzi liberi, disponibili in caso di crescita del numero di host sulla rete stessa
- esistono indirizzi riservati a casi speciali (per quanto riguarda IP, esistono gli indirizzi relativi a reti private, quelli riservati, quelli dedicati al multicast)
- per garantire la scalabilità, ogni rete deve gestire i propri indirizzi in maniera gerarchica, e ogni organizzazione gerarchica porta con sè un'utilizzo subottimale degli indirizzi. Prendendo spunto dalla rete telefonica, la numerazione che inizia per "011" è dedicata alla zona di Torino, quella che inizia per "02" a quella di Milano. Eventuali numeri non utilizzati a Torino non possono essere assegnati alla zona di Milano in quanto, per garantire una gestione efficiente della rete, è necessario garantire che tutta la numerazione "011" sia localizzata nell'area torinese. Solo in questo caso un eventuale telefonata originata a Roma e iniziante per "011" potrà essere diretta verso il nodo torinese senza ulteriori controlli.
In riferimento all'ultimo punto, l'attuale modello organizzativo di una rete IP è definito secondo lo schema gerarchico host-network, per cui gli indirizzi non vengono assegnati singolarmente ma a “reti”, l'analogo del "prefisso" telefonico. Questa scelta (gerarchia a due livelli) mitiga il problema della scarsità di indirizzi, in quanto ogni livello gerarchico introduce ulteriori sprechi. Per continuare l'esempio fatto in precedenza, l'inserimento di un ulteriore livello gerarchico (la gerarchia nazionale, dove il codice "39" indica le chiamate dirette in Italia, il codice "44" indica quelle dirette in Gran Bretagna) implica che eventuali numerazioni di "prefisso" non utilizzate n Italia (ad esempio il prefisso "013") non possano essere riassegnate ad altre nazioni in quanto fanno parte della numerazione relativa alla nazione con codice "39".
Nonostante che il timore dell'esaurimento dello spazio di indirizzamento sia stata la principale causa a determinare lo sviluppo di IPv6, attualmente il problema non è così
Richiesta di nuovi servizi
L'evoluzione di Internet non ha comportato solamente l'incremento del numero di utenze, ma anche (e soprattutto) una notevole varietà di nuove esigenze che, inizialmente, non erano state previste.
Tra le nuove tendenze, evidenziatesi già ad inizio degli anni 90 e per cui IPv4 non forniva, all'epoca, adeguate risposte, sicuramente degni di nota sono i seguenti punti:
- supporto alla mobilità: l’utente mobile è normalmente dotato di un computer portatile, un palmare oppure un telefono cellulare con la possibilità di accesso ad una rete fissa, sia essa di tipo pubblico (ad esempio reti cellulari 2.5G/3G) che di tipo privato (ad esempio reti 802.11 o Bluetooth). Il supporto alla mobilità non era originariamente previsto in IPv4.
- supporto alla sicurezza: essendo inizialmente la rete IP molto limitata ad una ristretta cerchia di persone, i problemi di sicurezza (integrità e criptatura della comunicazione, autenticazione del mittente/destinatario) erano completamente al di fuori delle necessità del tempo. Tuttavia, l'aumento della comunità degli utenti (che implica sia nuove persone, sia persone di comunità ed interessi diversi) ha posto il problema di maggiori garanzie di sicurezza sulllo scambio di dati, in particolare dovuto a nuove attività quanli pagamenti elettronici (e-commerce), utilizzo di documenti digitali a valore legate (firma elettronica). etc.
- supporto all'autoconfigurazione (plug-and-play): gli standard TCP/IP non hanno inizialmente previsto meccanismi di autoconfigurazione degli host; era pertanto necessario configurare i parametri principali di ogni stazione (indirizzo IP, default gateway, servizi DNS) in maniera esplicita. Con l'aumento del numero di utenze e con il fatto che alcune di esse non avevano alcuna familiarità con il mondo TCP/IP, la procedura di configurazione manuale poteva essere un problema. Inoltre, rimaneva scoperto anche il problema delle procedure per la ri- numerazione automatica delle reti (router compresi) e non solo degli host.
- supporto alla qualità del servizio: la specifica di IPv4 ha previsto un campo da 8 bit per la gestione della qualità del servizio; tuttavia, la specifica non era matura per i tempi in quanto ben pochi erano gli apparati che potevano fare uso di quel campo. Tuttavia, nuove applicazioni (ad esempio trasmissione audio e video su IP) e nuove esigenze (traffico "privilegiato", ad esempio ordini di borsa in tempo reale) già facevano capolino all'orizzonte.
- supporto multicast: il supporto multicast non ha strettamente a che vedere con il protocollo IPv4, ma è comunque una tendenza degna di nota che, ad inizio anni 90, non trovava una risposta adeguata. Un'esempio di utilizzo di un'infrastruttura multicast può essere cercata nei numerosi tentativi di didattica a distanza (e- learning) ma di tipo "frontale" (ossia condotta in tempo reale).
Il lungo percorso all'adozione di IPv
Ad inizio anni 90, alcuni problemi erano particolarmente gravi, primo fra tutti i problema della scarsità di indirizzi. Per velocizzare il lavoro e per offrire un minimo di margine di sicurezza alla rete Internet, si attivarono alcuni gruppi di lavoro che cercavano di trovare una soluzione ai bisogni più implellenti, mentre altri gruppi di lavoro cercavano di definire, al meglio, il nuovo protocollo successore di IPv4 senza troppi legacci di compatibilità con il passato.
La lunga gestione della definizione del protocollo IPv6 e della migrazione delle reti al nuovo standard ha tuttavia cambiato molte carte in tavola. Infatti, l'idea di definire un nuovo protocollo è da fissare ad inizio anni 90, ma tutt'ora la sua adozione da parte della comunità Internet, ad oltre 10 anni di distanza, è sostanzialmente relegata a poche Università e centri di ricerca. Questo ha fatto sì che le varie "soluzioni tampone" da
applicare ad IPv4 aspettando la nuova versione IPv6 siano state estremamente diffuse. Tuttavia, le soluzioni "tampone" hanno spesso funzionato meglio del previsto mitigando, e di molto, l'esigenza di un nuovo standard, la cui adozione è complicata anche dalle notevoli problematiche legate alla fase di migrazione della rete.
Esaurimento dello spazio di indirizzamento
Questo problema, in assoluto il puù impellente, venne affrontato attraverso la definizione di tre soluzioni.
Introduzione delle reti a dimensione "personalizzata" (tramite la Netmask)
Uno dei grossi problemi della specifica origiaria di IPv4 era lo speco di indirizzi. Attraverso alcuni passi successivi (prima l'introduzione del subnetting, poi del Variable Length Subnet Mask o VLSM, poi della netmask) si è giunti alla definizione di un meccanismo che ammette, come dimensione di una rete, un qualunque valore che sia una potenza di 2 (ossia 4, 8, 16, e così via). In questo modo si è fortemente ridotto lo spreco dovuto a reti con un numero di host che superava, seppur di poco, una delle tre dimensioni ammesse precedentemente (256, 65535, oppure 16777216 indirizzi), le quali erano costrette a richiedere l'assegnazione di una rete sproporzionata alle loro esigenze.
Indirizzamento privato
Originariamente, era normale prassi l'assegnazione di indirizzi pubblici a tutti gli host TCP/IP. Tuttavia, particolarmente in ambito aziendale, molte macchine facevano (e fanno tutt'ora) un utilizzo molto limitato della rete che rende forse superfluo l'utilizzo di un indirizzo IP univoco a livello mondiale (ossia un indirizzo cosiddetto pubblico).
La RFC 1466 del maggio 93 ha introdotto una migliore regolamentazione del processo di assegnazione degli indirizzi, diventando più difficile ottenere un proprio spazio di indirizzamento; quindi si sono definiti (RFC 1918) tre blocchi di indirizzi IP privati, ossia che non saranno mai assegnati a macchine collegate direttamente sulla rete Internet. L'unico vincolo è che questi indirizzi debbano essere utilizzati secondo le regole classiche di gestione dell'indirizzamento IP (ossia questi indirizzi non dovranno essere duplicati all'interno di una Intranet, ossia le rete privata sulla quale sono utilizzati), che gli host siano essere collegati direttamente ad Internet senza l'impiego di un "gateway" apposito, dettagliato in seguito, e che tali reti non siano annunciate a livello di routing sulla rete Internet pubblica. I blocchi di indirizzi riservati dalla IANA (Internet Assigned Numbers Authority) sono i seguenti:
- 10.0.0.0 - 10.255.255.255 (prefisso di rete 1.0.0.0/8)
- 172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
- 192.168.0.0 - 192.168.255.255 (192.168.0.0/16)
Questi indirizzi sono stati massicciamente adottati per la definizione delle Intranet. Tuttavia, questo meccanismo non può funzionare da solo. Infatti, è necessario che venga integrato con un'altra soluzione per poter fornire almeno una parziale connettività ad Internet alle macchine che adottano degli indirizzi privati. la soluzione è statà trovata con la definizione della tecnica del NAT, Network Address Translator.
Network Address Translator (NAT)
Il NAT (Network Address Translator) è un apparato strettamente legato alle reti private ed è in grado di tradurre i pacchetti IPv4 che attraversano i confini tra diversi domini di rete modificando gli indirizzi sorgenti e destinazione dei pacchetti IP, trasformando
di prefissi /8 che non sono ancora stati assegnati a nessuno e che sono pertanto disponibili per il futuro.
Problematiche di scalabilità del routing
Il problema dell’esplosione delle tabelle di instradamento è stato affrontato attraverso la definizione del Classless InterDomain Routing (CIDR). Questa soluzione abolisce la suddivisione degli indirizzi tra le classi A, B e C per quanto riguarda gli annunci di routing e prevede che ogni annuncio contenga sia un prefisso di rete, sia una netmask associata, che definisce l'ampiezza della rete stessa. Questa soluzione generalizza l'impiego della Netmask, definita inizialmente per la gestione dell'indirizzamento, anche per quanto riguarda gli annunci di routing. In questo modo è possibile aggregare reti contigue (ad esempio 130.192.16.0/24 e 130.192.17.0/24) in una rete equivalente (130.192.16.0/23) ma con address range maggiore.
Questa soluzione sarebbe di poca utilità se non fosse accoppiata con una maggiore rigidezza nell'assegnazione degli indirizzi IP. La procedura di assegnazione degli indirizzi viene quindi modificata in modo da evitare, quanto possibile, che piccoli utenti possano richiedere uno spazio di indirizzamento autonomo. Si cerca invece di assegnare gli indirizzi prevalentemente agli Internet Service Provider, ai quali vengono assegnati blocchi di indirizzi più grossi che vengono poi partizionati, all'interno della rete dell'ISP, ai piccoli clienti. Il risultato è che, di fatto, l'ISP può annunciare verso l'esterno un unico blocco di indirizzamento che corrisponde all'insieme dello spazio di indirizzamento di molti suoi clienti.
Un ulteriore problema, quello della scalabilità dei protocolli di routing, non ha trovato invece soluzioni, se si eccettua la proposta MPLS (Multi Protocol Label Switching) che ha, come sottoprodotto, anche una migliore del routing all'interno delle nuvole di rete che adottano questa tecnologia.
La problematica di scalabilità del routing, però, si è rivelata la più difficile da risolvere. Mentre ad inizio anni 90 il problema forse maggiore era la scarsità degli indirizzi, attualmente la scalabilità del routing riveste probabilmente un'importanza addirittura superiore a causa della moderata efficacia delle soluzioni proposte.
Supporto di nuovi servizi
Mobilità
All'interno del concetto di mobilità è necessario distinguere due possibili significati diversi. Il primo livello di mobilità è la mobilità "limitata", ossia la capacità di poter operare (ad esempio leggere la propria casella di posta elettronica) da punti diversi della rete. Questo si risolve con la capacità di assegnare dinamicamente un appropriato indirizzo agli utenti mobili per permettere loro di interagire con la rete (ad esempio per mezzo di standard quali il DHCP oppure PPP). Tuttavia, questa definizione lascia scoperti alcuni problemi. Innanzitutto, gli standard prima citati permettono di gestire l'assegnazione di un indirizzo, ma non di garantirne la portabilità, ossia la capacità, da parte dell'host, di potersi spostare da una rete all'altra mantenendo sempre lo stesso indirizzo. In mancanza di portabilità diventa impossibile poter essere contattati da altri host sempre al proprio indirizzo "ufficiale": di fatto è quindi possibile per un host comportarsi da client (verso un server remoto), ma non il viceversa in quanto il suo indirizzo cambierebbe continuamente. In altre parole, le soluzioni che prevedono solamente l'assegnazione degli indirizzi non sono in grado di gestire le problematiche di roaming (spostamento da un gestore all'altro), di handover (spostamento da una rete all'altra), ossia in generale non gestiscono il problema della portabilità (per alcuni versi detta raggiungibilità) dell'indirizzo di rete assegnato. A questo, si unisce il fatto che la
mobilità implica spesso (ma non necessariamente) anche problematiche di sicurezza per proteggere i dati in transito.
Il problema della portabilità implica infatti che l'utente mobile, pur cambiando punto di accesso alla rete (e quindi indirizzo IP) possa essere comunque raggiunto dai pacchetti IP destinati al vecchio indirizzo. In altre parole, in questa accezione la mobilità "limitata" permette all'host mobile di raggiungere altri host TCP/IP, mentre la raggiungibilità permette anche il percorso opposto.
La soluzione proposta per il primo problema è pertanto in modalità di configurazioni "automatiche", quali il DHCP, Per quanto riguarda il secondo problema, la soluzione è stata proposta dallo standard Mobile IP, definito nello RFC 2002 dell’ottobre 1996; in sintesi, l’host mobile possiede un indirizzo permanente e quando si muove, attraverso opportune procedure, acquisisce un indirizzo di riferimento locale nella nuova rete; l’host mobile comunica tale indirizzo ad un “home agent” e tutti i pacchetti destinati all’host mobile vengono catturati dall’home agent e reinstradati verso l’host mobile; invece i pacchetti uscenti dall’host mobile seguono il normale instradamento su Internet.
Un problema di questa soluzione è che necessita di ulteriori indirizzi IP, risorsa di per sè già preziosa. La soluzione proposta, inoltre, non è mai stata utilizzata su vasta scala anche perchè attualmente non esistono host mobili (nell'accezione della portabilità), nè si prevede possano esistere in un prossimo futuro. Infatti, la necessità di soluzioni di mobilità è prevista prevalentemente per applicazioni quali telefonia su IP (magari con tecnologie cellulari) le quali, per loro natura, hanno bisogno di indirizzi pubblici e pertanto non possono essere utilizzate su reti con indirizzi privati (Intranet). Ne consegue che, essendo gli indirizzi una risorsa scarsa per queste applicazioni, esse tenderanno ad utilizzare prevalentemente IPv6, rendendo vani gli sforzi per la definizione del protocollo Mobile IP.
Sicurezza
La sicurezza è stata affrontata dalle specifiche IPsec (RFC 2401), che in maniera equivalente sia per IPv4 che con IPv6; IPsec può essere usato per proteggere uno o più percorsi fra una coppia di generici host (ad esempio anche due router). IPsec definisce due protocolli principali:
- IP Authentication Header (AH), per l'autenticazione dei messaggi
- Encapsulating Security Payload (ESP), per l'autenticazione e la criptatura dei messaggi.
Dal punto di vista concettuale la differenza tra IPv4 e IPv6 sta nel fatto che per quest'ultimo la specifica IPsec è inclusa nelle caratteristiche del protocollo stesso, mentre la sua implementazione per IPv4 è opzionale.
Autoconfigurazione
Il problema dell'autoconfigurazione è stato affrontato attraverso il protocollo DHCP (Dynamic Host Configuration Protocol), RFC 2131, che permette di configurare automaticamente gli host collegati ad una rete assegnando loro un indirizzo IP e gli altri parametri necessari (netmask, default router, DNS server, etc).
Gli indirizzi IP assegnati tramite DHCP possono essere sia di tipo permanente (l’indirizzo viene assegnato all’host definitivamente; in questo caso si parla di allocazione automatica e il vantaggio principale si ha nel non dover configurare manualmente i singoli host), sia di tipo temporaneo (l’indirizzo viene assegnato all’host per un certo
problemi più grossi (come quelli del routing e dell’indirizzamento) e giunse alle soluzioni che si sono analizzate; il secondo gruppo di lavoro si occupò invece di definire un nuovo protocollo IP.
La discussione nel secondo gruppo si focalizzò su tre proposte che fra il 1992 e il 1994 subirono molte variazioni ed evoluzioni, fino alla scelta della vincitrice. Per la scelta del protocollo IPv6 fu formulata una lista di 17 obiettivi da raggiungere: la proposta vincente avrebbe dovuto soddisfarne il maggior numero.
La prima proposta, conosciuta come TUBA (TCP and UDP over Bigger Addresses) si basava su CLNP (ConnectionLess Network Protocol), il protocollo di livello rete non connesso definito dall’ISO come parte dell’architettura OSI; questa proposta fu scartata poichè i suoi sostenitori volevano che rimanesse rigidamente legata alle specifiche del CNLP originale, considerato però dal resto della comunità Internet un protocollo vecchio ed inefficiente.
La seconda proposta , chiamata CATNIP (Common Architecture for Next Generation Internet Protocol), mirava alla integrazione di diversi protocolli di rete (IP, CLNP, IPX) e di trasporto (TP4, SPX, TCP, UDP); questa proposta presentava degli aspetti interessanti in quanto permetteva, a due qualunque applicativi basati ad esempio sul protocollo di trasporto TCP, di scambiarsi i dati indipendentemente dal protocollo di rete sottostante (ad esempio era ammesso un imbustamento del tipo TCP/IPv4 ad un capo della connessione e TCP/CLNP all'altro).
La terza proposta, chiamata SIPP (Simple IP Plus), è il risultato dell’unione di altre due proposte: la SIP (Simple IP), che proponeva di incrementare gli indirizzi di IP a 64 bit e di eliminare alcuni campi superflui ed obsoleti, ed il PIP (Paul’s Internet Protocol), che introduceva significative novità sul fronte del routing permettendo una efficiente implementazione del policy routing e della mobilità.
Al tempo della decisione (luglio 1994), tutte le proposte vennero riconosciute avere problemi non banali, in particolare la proposta CATNIP che non fu considerata sufficientemente completa. Nella valutazione relativa ai 17 obiettivi prevalse la proposta SIPP. Questa fu pertanto presa come base di partenza per il nuovo IP, operando però prima un cambiamento fondamentale: estendere la dimensione degli indirizzi a 128 bit anche contro il parere dell'autore (Steve Deering) il quale sosteneva, a ragione, si direbbe oggi, che 64 bit erano ampiamente sufficienti e che troppa abbondanza avrebbe solamente potuto creare problemi. Da qui nacque il nuovo protocollo IP: su una base SIPP vennero integrate le proposte di autoconfigurazione e transizione di TUBA, la struttura di indirizzamento che originava dal CIDR, più alcune migliorie per quanto riguarda i routing headers.
La versione corrente era (ed è tuttora) la 4, il numero 5 era già stato assegnato ad un altro protocollo sperimentale, perciò il nuovo protocollo fu chiamato IPv6. Le specifiche di base del nuovo protocollo furono pubblicate nel dicembre 1995 nella RFC 1883.
L'header IPv
Header IPv6 e IPv4 a confronto
Uno dei principali obiettivi della proposta SIPP (e quindi di IPv6) era la semplificazione del protocollo. Questo corrispondeva innanzitutto ad eliminare i campi superflui o con uso estremamente limitato dall'header del protocollo stesso. Questa operazione aveva come obiettivo la semplificazione del cosiddetto critical router loop, ossia quella porzione di codice che un router deve eseguire per tutti i pacchetti che si trova a dover instradare e che influisce quindi direttamente sulle sue prestazioni.
E' evidente (in figura) come il numero di campi si sia ridotto da 12 a 8 (escludendo i campi opzionali), mentre lo spazio occupato da tutti i campi esclusi gli indirizzi di sorgente e di destinazione è passato da 12 a 8 bytes. L'ampiezza totale dell'header è tuttavia aumentata (da 20 a 40 bytes) a causa dei due campi contenente l’indirizzo sorgente e destinazione, grandi ognuno 128 bit, per un totale di 40 bytes, che è la lunghezza fissa dell’header. Questa semplificazione è stata operata eliminando alcuni campi presenti in IPv4 (Header Length, Identification, Flags, Fragment Offset e Checksum), rinominando e ridefinendo le funzioni di altri (Length, Protocol Type e Time To Live) ed aggiungendo un nuovo campo (Flow Label).
Per quanto riguarda la semplificazione del critical router loop, le principali migliorie sono le seguenti:
- Assegnazione di un formato fisso a tutti gli header: nell’header IPv6 non ci sono più campi opzionali, le opzioni per casi speciali sono indicate in extension headers che sono accodati all’header principale; di conseguenza non è più necessario il campo header length.
- Rimozione del checksum: diminuiscono i costi di elaborazione degli header da parte dei router; i rischi di errore sono molto bassi e comunque si presume che vengano rilevati dai protocolli degli altri livelli.
- Rimozione delle procedure di frammentazione: IPv6 presuppone che gli host siano in grado di apprendere la massima dimensione accettabile dalla rete (attraverso una procedura chiamata Path MTU Discovery), di conseguenza è stato possibile eliminare tutti i campi relativi al controllo della frammentazione.
Poichè IPv6 prevede molte funzionalità aggiuntive rispetto ad IPv4, è stato necessario una progettazione oculata di come implementare queste caratteristiche senza appesantire l'header IPv6 standard. Queste funzionalità verranno spesso implementate con Extension Headers, ossia estensioni che vengono inserite dopo l'header IPv standard e prima del protocollo di trasporto.
I risultati di questa semplificazione non sono tuttavia completamente positivi. In particolare, la dimensione dell'indirizzo IPv6, a parte un po' di folclore ("ci sono più indirizzi IPv6 che atomi nell'universo") non trova effettive giustificazioni tecniche tranne la volontà di voler evitare a tutti i costi di incorrere in nuove penurie di indirizzi come è accaduto per il protocollo IPv4. Questa scelta, peraltro, complica notevolmente le operazioni di route lookup ossia la procedura che serve a localizzare, per ogni pacchetto in transito in un router, l'effettiva strada (route) di destinazione. Infatti, questa operazione consiste in un confronto tra l'indirizzo IP di destinazione e ogni route memorizzata nel router per cercare quella che ha in comune un maggior numero di bit (da sinistra verso destra) con l'indirizzo di destinazione. E' evidente che, maggiore è la lunghezza dell'indirizzo, maggiore è la complessità del confronto.
Gli altri due problemi relativi alla dimensione dell'indirizzo sono dovuti al fatto che, nelle reti moderne, i router (in particolare quelli di accesso) non si limitano semplicemente ad inoltrare il traffico verso la destinazione, ma implementano anche politiche di sicurezza (accettazione / rifiuto) e di controllo (classificazione), impedendo il passaggio di traffico con determinate caratteristiche, ad esempio lo scambio di traffico tra due particolari host. Ad ulteriore complicazione, i router effettuano queste operazioni non basandosi soltanto su informazioni di livello 3, ma anche su informazioni di livello 4 (in particolar modo le porte TCP e UDP), violando, in una certa misura, il modello concettuale in cui un router deve occuparsi dell'instradamento a livello 3, mentre deve ignorare qualunque informazione di livello 4.
Il primo problema a questo proposito è rappresentato dal fatto che questi controlli vengono normalmente implementati attraverso l'impiego di memorie di tipo associativo
Il vantaggio nell'introduzione di questo campo sta nel miglioramento delle prestazioni, rispetto ad altre soluzioni introdotte in IPv4; infatti mentre con IPv per poter identificare un flusso bisogna processare il pacchetto fino al livello trasporto (perchè deve conoscere anche i numeri di porta TCP/UDP associati alla connessione), con IPv6 è sufficiente processare l'intestazione di livello rete, poiché un flusso è identificato da un valore non nullo di flow label e dall’indirizzo sorgente. Il valore numerico associato ad un certo flusso viene scelto in modo casuale dal nodo mittente nell’intervallo compreso tra 1 e FFFFFF. Tale valore dovrà essere diverso dalle Flow Label in uso sul nodo mittente o usate nel recente passato. Hop Limit E' lungo 8 bit; tale campo viene decrementato di un’unità ogni volta che un router trasmette il pacchetto. Se il campo Hop Limit assume il valore zero il pacchetto deve essere scartato. Serve per evitare che pacchetti entrati in condizione di loop continuino a circolare nella rete indefinitamente. Data la lunghezza di questo campo, tra due nodi non potranno esserci più di 255 hop, cioè non più di 254 router. Questo campo sostituisce il campo Time To Live (TTL) presente in IPv4, recependo, di fatto, una procedura consolidata in Internet. Infatti il campo TTL di IPv4 dovrebbe essere decrementato con il tempo, secondo una granularità dell’ordine dei millisecondi. In pratica ogni router dovrebbe decrementare tale campo di un valore pari al numero dei secondi di permanenza del pacchetto sul router stesso. Poiché tale operazione risulta difficile o troppo onerosa in termini di risorse computazionali, questo campo viene tipicamente decrementato di un valore fisso, indipendentemente dal tempo effettivo di permanenza sul router. Inoltre la durata temporale di un pacchetto ha un significato diverso a seconda delle capacità trasmissive della rete. Infatti se su connessioni lente un pacchetto potrebbe impiegare qualche secondo per attraversare una decina di hop, su una rete ATM a 155Mbps nello stesso tempo il pacchetto potrebbe attraversarne migliaia di router. IPv6 prende atto della situazione attuale e introduce il campo Hop Limit che indica direttamente il numero di router attraverso i quali è transitato il pacchetto, indipendentemente dalla tecnologia di rete utilizzata. Payload length E' lungo 16 bit; rimpiazza il campo ‘total length’ di IPv4, in cui essendo l’header di lunghezza variabile è necessario indicare la lunghezza totale del pacchetto; in IPv6 invece, essendo l’header di lunghezza fissa è sufficiente indicare la dimensione del campo dati trasportato col pacchetto; essendo questo campo lungo 16 bit la dimensione massima del campo dati di un pacchetto IPv6 può quindi essere 64Kbyte.Per poter utilizzare pacchetti di dimensioni maggiori si deve ricorrere all’Extension Header Jumbo Payload [RFC2675], la cui presenza è segnalata anche dal valore zero nel campo Payload Length. Traffic Class Questo campo è identico al campo presente in IPv4, anche se storicamente le cose erano diverse. Infatti, IPv4 aveva un campo chiamato Typo Of Service, mentre IPv6 venne definito con un campo Priority ed aveva lo scopo di permettere alle sorgenti di specificare un livello di priorità al traffico generato. Successivamente le terminologie (e il significato dei campi) sono state uniformate con il termine Traffic Class. Il vantaggio derivante dall'uso di questo campo consisteva nella possibilità di differenziare i pacchetti da scartare sui router in caso di congestione (in figura sono indicati i valori relativi a particolari categorie di traffico). In questo modo, però, la gestione delle congestioni non era di tipo preventivo, poiché le sorgenti trasmettevano sempre tutto il traffico disponibile anche se non tutto sarebbe poi arrivato a destinazione. Per questa ragione lo IETF ha deciso di ridefinire in parte questo campo, che è diventato ‘Traffic Class. A parte la lunghezza, la principale differenza rispetto a
priority è che ogni nodo che supporti un utilizzo specifico di alcuni o tutti i bit di questo campo ha il permesso di modificarlo in tutti i pacchetti da lui generati, instradati e ricevuti. Un possibile utilizzo del campo traffic class consiste nella differenziazione di parte del traffico immesso nella rete di un ISP da un suo utente. L’ISP si impegna a fornire particolari garanzie di servizio (ad esempio in termini di ritardo massimo o probabilità di errore) per tutti i pacchetti caratterizzati da un certo valore del campo traffic class provenienti da un certo utente. Il campo traffic class può essere settato direttamente dagli host dell’utente o dal border router in uscita verso l’ISP. Ogni ISP può, a sua volta, modificare tale campo per tutti i pacchetti in uscita verso altre reti, al fine di assegnargli una classe di servizio concordata con altri ISP. La prevenzione delle congestioni può essere resa ancora più efficace mediante l’uso di ECN (Explicit Congestion Notification). Tale proposta è in corso di studio per verificarne l’applicabilità sia in IPv4 che in IPv6. Attualmente il controllo delle congestioni realizzato da TCP avviene assumendo la rete come una scatola nera: la stazione a un estremo aumenta la quantità di traffico immesso sulla rete fino a quando non si verifica una perdita di pacchetti (il che è interpretato come congestione dei buffer dei router). Un tale approccio causa uno spreco di risorse in quanto i pacchetti eliminati devono essere ritrasmessi, ma questo implica che anche i pacchetti successivi appartenenti alla stessa sessione, anche se giunti correttamente a destinazione perché passati per altre vie, nella maggior parte dei casi siano scartati in quanto fuori sequenza e debbano perciò essere ritrasmessi. Si sta pensando quindi di introdurre in rete dei meccanismi che consentano di inviare alla sorgente un'indicazione esplicita di congestione prima che si verifichino perdite nei router. ECN propone di usare due bit del campo traffic class nel seguente modo. Il primo bit, ECN-Capable è impostato a uno nel caso in cui il protocollo di trasporto sappia usare ECN. Il bit successivo è posto a uno da un router che è prossimo alla congestione. Quando il pacchetto giunge a destinazione, il ricevitore , per mezzo di TCP, rileva l'indicazione di congestione dei router e invia tale informazione alla sorgente. In questo modo essa è indotta a diminuire la quantità di traffico immesso in rete. Next Header E' lungo 8 bit; identifica il tipo di header che segue immediatamente quello IPv6, localizzato all’inizio del campo dati (payload). Questo campo può essere visto come una generalizzazione del campo Protocol dell'header IPv4; infatti mentre in IPv4 l’header IP era sempre seguito dal protocollo di trasporto (per esempio TCP o UDP), in IPv6 è anche possibile inserire degli extension header fra l’header IP e il carico. Nella tabella sono indicati alcuni dei valori che può assumere il campo Next Header.
La specifica dell'header IPv6 è stata proposta inizialmente nella RFC 1883, aggiornata poi (ad esempio per quanto riguarda il campo Traffic Class) dalla RFC 2460.
La catena degli headers
IPv4 comprende nel suo header alcuni campi opzionali che richiedono un trattamento particolare dei pacchetti. In IPv6 scompaiono i campi opzionali, sostituiti dal meccanismo degli Extension Header, cioè dalla possibilità di inserire degli header aggiuntivi fra l’header IPv6 ed il payload. Questa innovazione è stata introdotta partendo dal presupposto che la maggior parte dei pacchetti necessita di un trattamento molto semplice da parte dei router, ai quali molto spesso sono perciò sufficienti le informazioni contenute nello header IPv6. Nel caso invece che ci sia la necessità di trattamenti particolari (ad esempio si vuole che il pacchetto segua un certo instradamento) è possibile codificare informazioni aggiuntive negli header aggiuntivi introdotti tra l’header IPv6 e l’header del livello superiore. Il collegamento tra gli header avviene mediante il
Infine, vi sono alcuni extension headers che sono in realtà delle opzioni, i cui valori possono essere molteplici e ripetuti più volte. In questo caso si utilizza il classico formato Type - Length - Value, dove il primo campo (Type) indica il tipo di opzione trasportato, il secondo campo (Length) rappresenta la lunghezza del campo stesso, e il terzo campo (Value) rappresenta il valore trasportato dall'opzione stessa. Nel caso delle opzioni definite negli Extension Header di IPv6, la lunghezza dei campi Type e Length è sempre di 8 bit.
Nel caso in cui sia necessario allineare l'extension header ad un multiplo di 8 byte (essendo questa l'unità minima gestita dal campo Header Length, presente nella maggior parte degli extension header), sono stati definite due opzioni di padding:
- Pad1: è contraddistinta dal codice '0' nel campo Type e non prevede alcun campo Length. Pertanto, è utilizzata per inserire un byte di padding.
- PadN: è contraddistinta dal codice '1' nel campo Type, mentre il campo Length riporta la lunghezza del padding che seguirà. Questa opzione è utilizzata per indicare un padding la cui lunghezza è almeno 2 byte.
Tali opzioni sono necessarie solamente nel caso degli extension header che fanno uso di opzioni (ossia Hob-by-Hop Option Header e Destination Option Header) in quanto solo in questi, grazie al loro formato variabile, è possibile che l'extension header non finisca allineato come da specifiche.
Codifica del campo Type
La codifica utilizzata per il campo Type assegna un significato particolare a primi 3 bit partendo dal più significativo.
Per quanto riguarda i primi due bit, essi indicano al'host l'azione da intraprendere qualora l'opzione non venga riconosciuta dall'host destinatario, ad esempio perchè aggiunte successivamente alla specifica originaria di IPv6. In questo caso l'host ha la possibilità di ignorare l'opzione, oppure scartare l'intero pacchetto, oppure scartarlo ma inviando una apposita notifica al mittente. In quest'ultimo caso vi è la possibilità di scegliere tra una modalità nella quale la notifica viene sempre mandata, oppure una nella quale la notifica viene inviata solamente se il pacchetto non è destinato ad un gruppo multicast.
Per quanto riguarda il terzo bit, esso indica se il contenuto dell'opzione corrente può essere modificato in transito oppure no. In altre parole, l'host IPv6 mittente segnala, con questo bit, se i router in transito possono (o meno) modificare il valore dell'opzione.
I principali Extension Header
Hop-by-Hop Option Header
L’Hop-by-Hop Option Header viene utilizzato per trasportare informazioni aggiuntive che devono essere elaborate da tutti i nodi che il pacchetto attraverso nel suo viaggio verso la destinazione. E' composto dai seguenti campi:
- Next Header: identifica il tipo di header (extension header o protocollo) che segue quello presente.
- Header Length: lunghezza totale del presente extension header in multipli di 8 ottetti, esclusi i primi 8.
- Options: contiene una lista di opzioni, strutturate secondo il modello TLV nel formato che è stato descritto in precedenza. Vi sono attualmente 2 opzioni definite (oltre ad Pad1 e PadN già viste in precedenza): o Router Alert [RFC 2711]: indica che il pacchetto contiene alcune informazioni particolari che devono essere esplicitamente processate dal router. Un esempio in cui può essere utile tale opzione è il protocollo RSVP in cui la sorgente ha bisogno di segnare un cammino preferenziale per i suoi pacchetti e che deve essere analizzato da ogni router sul percorso per verificare che le risorse richieste siano disponibili. o Jumbo Payload [RFC 2675]: è utilizzato nel caso in cui si vogliano creare dei pacchetti IPv6 il cui payload è maggiore di 64KB. Infatti, il campo Payload Length (nell'header IPv6) è di 16 bit e non può pertanto essere usato per definire lunghezze superiori a tale soglia. In questo caso, il campo Payload Length dell’header IPv6 è settato a zero. La lunghezza massima di un pacchetto IPv6 contenente questa opzione è 4GB (2^32 bytes).
Nel caso in cui si definisca un Jumbo Payload non è possibilie utilizzare l'opzione di frammentazione. Infatti, non ha molto senso generare un pacchetto grosso per doverlo successivamente frammentare.
Routing Header
Questo extension header implementa la tecnica di instradamento di tipo source routing; la sorgente è pertanto in grado di condizionare il cammino di instradamento di un pacchetto scavalcando il normale instradamento IPv6.
Il formato di questo extension header comprende i seguenti campi:
- Next Header: identifica il tipo di header (extension header o protocollo) che segue quello presente.
- Header Length: lunghezza totale del presente extension header in multipli di 8 ottetti, esclusi i primi 8.
- Routing Type: è possibile specificare più di una variante di routing e, per ogni tipo, vi saranno dati diversi inseriti nel campo type-specific data. Attualmente è stato definito solo il caso in cui il Routing Type è pari a zero, corrispondente al source routing classico.
- Segment Left: indica il numero di nodi di transito ancora da raggiungere prima di arrivare alla destinazione.
- Type-Specific Data: definisce, in generale, i dati da trasportare relativamente al Routing Type in esame.
Nel caso in cui il Routing Type è pari a zero, il pacchetto comprende un campo riservato, quindi un elenco di indirizzi IPv6 che corrispondono alla lista di router che il pacchetto è tenuto ad attraversare. Il percorso specificato da questi indirizzi deve essere rigidamente rispettato, anche se è possibile che, tra un indirizzo e l'altro, siano presenti più router da attraversare e che non vengono specificati. Questo può essere fatto sia volontariamente (ad esempio si vuole che un pacchetto esca da un Autonomous System attraverso un certo router, ma non è vincolante il percorso fatto per giungere a tale router), sia dovuto ad altri motivi (il pacchetto è gestito via tunnel i quali, ai fini dell’instradamento, contano come un singolo hop anche quando i router attraversati sono più di uno).
E’ importante notare che quando si usa questo tipo di routing header l’header IPv iniziale contiene come indirizzo di destinazione il primo indirizzo della lista e non l’indirizzo della destinazione finale. Operativamente, poi, il nodo intermedio sostituisce l'indirizzo di destinazione con quello del successivo scritto nella lista e decrementa il
l’overhead di sistema introdotto dagli header e senza mettere i nodi intermedi nella situazione di dover gestire pacchetti troppo grandi [RFC1981].
Questa procedura è basata sull'invio dei pacchetti dati secondo la MTU della rete corrente: in caso questo pacchetto incontri un link con una MTU inferiore, questo genererà un pacchetto ICMPv6 di ritorno (ICMPv6 Packet Too Big Message) indicante la massima MTU ammessa su quel tratto. La stazione trasmittente sarà pertanto tenuta a generare nuovi pacchetti con quella MTU, ignorando quella definita dalla rete di livello data-link sottostante. Il processo continua fino a quando il pacchetto giungerà a destinazione. In IPv6, pertanto, solamente la stazione trasmittente è abilitata a frammentare un pacchetto: i router intermedi si limitano a notificare l'errore al mittente, scartando contemporaneamente il pacchetto. Questa procedura mira a sgravare i router di un lavoro aggiuntivo che invece era possibile in IPv4.
Il formato di questo extension header comprende i seguenti campi:
- Next Header: identifica il tipo di header (extension header o protocollo) che segue quello presente.
- Reserved: non utilizzato.
- Fragment Offset (13 bit): indica la posizione che occupa il frammento nel pacchetto originale. La posizione è specificata in termini multipli di 8 byte (il pacchetto IPv6 può essere lungo 2^16 bytes, quando questo campo può portare al massimo 2^13 valori).
- Reserved: non utilizzato.
- M (1 bit): ha il significato di More Fragments ed indica se il frammento corrente è seguito da altri oppure è l'ultimo. Viene posto uguale a uno in tutti i frammenti tranne l'ultimo, nel quale viene posto a zero.
- Identification: numero di 32 bit che identifica univocamente i pacchetti frammentati; il suo valore rimane costante (e determinato dalla macchine sorgente) su tutti i pacchetti dello stesso frammento.
Come si vede da come è definito il campo Fragment Offset (13 bit, i cui valori esprimono l'offset in multipli di 8 byte), non è possibile definire un Fragment Header contemporaneamente ad un Jumbo Payload.
Meccanismo di frammentazione
In ogni pacchetto occorre distinguere una parte non frammentabile ed una frammentabile. La prima contiene l'header IPv6 più ogni extension header che deve essere processato dai nodi lungo il percorso verso la destinazione finale, ossia tutti gli header sino al Routing Header incluso. Il resto del pacchetto può considerarsi suddivisibile in frammenti ognuno, tranne eventualmente l’ultimo, di lunghezza pari a multipli di 8 bytes.
Ogni frammento è pertanto costituito da:
- Parte non frammentabile, con il valore originale del campo Payload Length modificata per indicare la lunghezza del frammento e il Next Header dell’ultima intestazione della parte non frammentabile indicante che, a seguire, vi sarà il Fragment Header.
- Fragment Header, che contiene il campo Next Header (che identifica il primo header della parte frammentabile del pacchetto originale), l’offset relativo all’inizio della parte frammentabile del pacchetto originale, il flag M che indica se il frammento corrente è l’ultimo, e il valore Identification del pacchetto originale, tramite il quale il ricevitore è in grado di riunire i frammenti e ricostruire il pacchetto di partenza.
- Frammento, che contiene la porzione di dati del pacchetto originale.
Se il nodo destinazione non riceve tutti i frammenti necessari per ricostruire il pacchetto originale entro un certo tempo dall’arrivo del primo frammento, deve scartare i frammenti ricevuti ed inviare un messaggio ICMPv6 Time Exceeded al nodo mittente.
In figura è riportato un esempio di frammentazione: un pacchetto il cui host mittente risiede su una rete con MTU pari a 1500 bytes (ad esempio una Ethernet) viene trasmesso su un percorso che comprende un tratto in cui la MTU scende a 620 bytes.
Il pacchetto viene pertanto frammentato dall'host mittente inserendo un Fragment Header tra la parte non frammentabile del pacchetto e quella frammentabile. Si notino, tra le altre cose, come il primo e il secondo frammento non siano lunghi 620 bytes, bensì
- Questo è necessario per fare in modo di avere un numero di bytes, nella parte frammentabile, che è un numero multiplo di 8 ottetti, valore richiesto per il campo "Fragment Offset". Un secondo punto degno di nota è il fatto che il Fragment Header riporta, come campo Next Header, sempre il valore del prossimo header incontrato nel pacchetto originale. Pertanto questo valore del campo Next Header viene ripetuto anche nei frammenti successivi anche se l'header a cui si riferisce quella codifica è ormai stato trasmesso.
Authentication Header ed Encrypted Security Payload Header
IPv6 fornisce un servizio nativo di autenticazione e cifratura end-to-end attraverso due distinti extension header.
L’Authentication Header (AH) [RFC2402] ha lo scopo di garantire l’autenticità e l’integrità del pacchetto in cui è posto, ossia garantisce la possibilità di controllare che tale pacchetto non sia modificato in transito o sia stato generato da chi non ha il permesso di accedere a quel'host, evitando le operazioni di spoofing. Per spoofing si intende l'appropriazione indebita dell'identità (in questo caso dell'indirizzo IPv6) altrui, apparendo ad un host remoto come un host diverso da quello cui si è realmente.
L’Encrypted Security Payload header (ESP), invece, consente di realizzare un meccanismo per trattare i dati in modo che possano essere interpretati solo al termine del percorso, rendendo inutili (perchè non si riesce a risalire al dato originale) le operazioni di sniffing. Quando usato, l'ESP header deve essere l’ultimo della catena perché nasconde completamente sia i dati di livello superiore sia gli header successivi.
Nonostante sia l'AH che l'ESP possano essere utilizzati nello stesso pacchetto, il loro impiego contemporaneo è inutile. Infatti, l'ESP aggiunge, alle caratteristiche di protezione dell'AH (autenticazione del mittente, integrità del dato) anche confidenzialità del pacchetto, garanzie di anti-replay, e una limitata confidenzialità dell'intero flusso dati. Per una maggiore sicurezza (ad esempio per evitare che si risalga al mittente del pacchetto) è possibile utilizzare il tunnel mode, che verrà illustrato in seguito.
In entrambi i casi sorgente e destinazione devono accordarsi circa la chiave segreta, l’algoritmo da usare e quali valori assegnare ai propri parametri. L’instaurazione di una transazione IPSec richiede pertanto due passi obbligatori:
- una prima fase richiede la determinazione dell’algoritmo di sicurezza che verrà utilizzato (ad esempio DES o IDEA per la crittografia, oppure MD5 piuttosto che SHA per l'autenticazione AH)
- una seconda fase richiede lo scambio delle chiavi utilizzate per quella sessione
