Scarica appunti Ipv6 (parte2) e più Appunti in PDF di Reti Di Calcolatori solo su Docsity!
Internet Protocol versione 6: aspetti avanzati
Introduzione
Autoconfigurazione
Una grande innovazione introdotta dal nuovo protocollo è la disponibilità di meccanismi avanzati di Plug & Play, vale a dire di autoconfigurazione degli apparati. Per autoconfigurazione degli host si intende un meccanismo che consente di assegnare, senza configurazioni manuali, indirizzi ed altri parametri alle interfacce di rete. In IPv l’unico meccanismo di autoconfigurazione è rappresentato dal protocollo DHCP; i meccanismi messi a disposizione da IPv6 invece sono molto più avanzati e completi, e rendono molto più semplici le operazioni di amministrazione della rete perché non richiedono il mantenimento e la configurazione di un server centralizzato. Le entità di una rete per cui può essere necessario cambiare gli indirizzi sono host, router e DNS. Per quanto riguarda gli hosts, IPv6 definisce due meccanismi di autoconfigurazione: stateful e stateless.
Autoconfigurazione degli host: stateless
IPv6 introduce un nuovo tipo di configurazione automatica che si attiva non appena viene abilitata un’interfaccia ed ha il grande vantaggio di non richiedere l’intervento di server centralizzati semplificando notevolmente le operazioni di configurazione ed amministrazione della rete. Tale meccanismo, chiamato stateless autoconfiguration, consente agli host di auto-configurare le interfacce di rete in base alle informazioni diffuse sulla rete dai router.
Il processo si compone di alcuni passi:
- Viene generato automaticamente un indirizzo di tipo link-local (a partire dall’interface identifier, quale ad esempio il MAC address associato all’interfaccia) all’attivazione di un’interfaccia a partire dall’interface identifier
- Si inizia una procedura di Duplicate Address Detection (DAD), che sarà descritta nei prossimi paragrafi, per assicurarsi che il nuovo indirizzo sia unico all’interno del link. Se l’indirizzo è già utilizzato da un altro host sul link, la procedura di autoconfigurazione riprende con un nuovo token generato random (oppure mediante configurazione manuale); viceversa se la procedura conferma l’unicità dell’indirizzo, questo viene assegnato all’interfaccia interessata.
In questo modo il nodo possiede un indirizzo locale utilizzabile per comunicare con tutti gli altri nodi on-link, ossia tutti gli host a cui è direttamente connesso su quella LAN ed in particolare con i router. A questo punto se non ci sono router direttamente connessi sul link la procedura di stateless autoconfiguration termina, mentre se ne esiste almeno uno la procedura continua per l’assegnazione di un indirizzo “globale”. Questa procedura si compone dei seguenti passi:
- Se l’host riceve, tramite pacchetti ICMPv6, dei messaggi di router advertisement [RFC2461], li interpreta e si autoconfigura (in questi messaggi sono contenuti i parametri fondamentali)
- Poiché l’intervallo di tempo che intercorre tra l’invio di due messaggi consecutivi da parte di un router è generalmente più lungo di quanto un host è disposto ad attendere, il nodo può inviare uno o più messaggi di router solicitation [RFC2461] all’indirizzo “all router multicast address” (FF02::2), forzando la risposta anticipata di un router
I messaggi di router advertisement possono contenere uno o più prefissi associati al link con i quali il nodo può completare la procedura di autoconfigurazione stateless creando gli indirizzi globali (o site local) per le proprie interfacce. Per sicurezza è necessario verificare, mediante DAD, che i nuovi indirizzi globali siano univoci, prima di assegnarli all’interfaccia. Poiché l’unicità di un indirizzo è basata, nell’ambito di un link, sull’unicità dell’interface identifier, un nodo che abbia eseguito con successo la procedura di Duplicate Address Detection per un indirizzo link-local non è tenuto a ricontrollare l’unicità di tutti gli indirizzi creati a partire dallo stesso interface ID [RFC2462]. La procedura di autoconfigurazione stateless presenta due problemi che non sono stati ancora risolti: essendo gli indirizzi unicast costruiti a partire dall'identificativo di interfaccia, il cambio della scheda di rete comporta il cambio dell'indirizzo IP; inoltre la presenza su una rete di due router porta all'assegnazione di due indirizzi diversi alla stessa interfaccia.
Dal momento che i router inviano periodicamente nuovi messaggi di router advertisement, i nodi ricevono continuamente nuove informazioni con le quali aggiungere nuovi indirizzi o aggiornare quelli già configurati. Le procedure di autoconfigurazione degli host possono essere vantaggiosamente utilizzate per cambiare gli indirizzi di un sito (site renumbering), operazione tipicamente poco amata dai gestori delle reti poiché complessa e soggetta a facili errori. Questa caratteristica quindi favorisce operazioni di ristrutturazioni della rete, cambio di ISP, merging di aziende, così come il passaggio da una architettura di rete privata (indirizzi site-local) ad una pubblica (indirizzi globali). Al momento attuale i protocolli di livello alto quali TCP identificano le connessioni utilizzando anche l’indirizzo IP e quindi un cambiamento di indirizzo non può essere effettuato senza distruggere le connessioni in corso. Per tenere conto di questo fatto gli indirizzi IPv6 sono divisi in due categorie, quelli preferiti (preferred) e quelli deprecati (deprecated). I protocolli di alto livello, quando devono aprire una nuova connessione, devono sempre utilizzare un indirizzo di tipo preferito. Per iniziare una procedura di rinumerazione occorre innanzitutto inserire sui router i nuovi prefissi assegnati alla rete (utilizzati per generare i nuovi indirizzi delle stazioni della rete) ed attendere che vengano propagati in tutta la rete. Dal momento che ad ogni prefisso è associata una validità temporale, allo scadere della loro validità, non essendo più confermati dai messaggi dei router, i vecchi prefissi verranno automaticamente etichettati come deprecati, rimanendo in questo stato per un tempo ragionevolmente sufficiente a consentire a tutte le connessioni attivate in precedenza di terminare (per esempio alcuni giorni). Si noti a questo proposito che un indirizzo deprecato è comunque valido e può quindi essere utilizzato con la sola limitazione che non può essere utilizzato per aprire nuove connessioni. Infine gli indirizzi deprecati diventano non validi e possono essere completamente eliminati, terminando così la transizione dai vecchi ai nuovi indirizzi.
Poiché l’identificativo di interfaccia può rimanere invariato per un tempo molto lungo (addirittura per tutta la durata dell’esistenza dell’interfaccia stessa), potrebbero presentarsi dei problemi di sicurezza legati al fatto che tale identificativo potrebbe potenzialmente essere utilizzato per tenere traccia dei movimenti sulla rete di un nodo particolare, mettendo in relazione tra di loro attività apparentemente scorrelate effettuate in contesti differenti. Ad esempio un analizzatore di rete collocato in una posizione strategica della rete potrebbe raccogliere informazioni riguardo al traffico generato da un host distinguendolo in base all’interface ID (anche se si tratta di un utente mobile o di una connessione PPP) e tali informazioni potrebbero, ad esempio, essere utilizzate per verificare se un certo impiegato è al lavoro e a quale ora, oppure se c’è qualcuno in una certa abitazione o ufficio. Siti particolarmente trafficati (ad esempio un portale WEB) potrebbero catalogare, in base all’interface ID, il traffico proveniente da un certo host allo scopo di creare un profilo dell’utente (o degli utenti) che lo utilizzano. Nel caso di utenti mobili che si spostano tra reti differenti (ad esempio utilizzando una connessione PPP su rete GSM) tali meccanismi potrebbero, in alcuni casi, consentire addirittura di tenere traccia dei spostamenti geografici dell’apparecchio.
chiavi crittografiche. Il terzo tipo di messaggio si distingue per il campo ICMP code e per il contenuto del campo Message Body. I pacchetti di Router Renumbering sono trasportati da pacchetti ICMPv6 con Type = 138. Il messaggio comprende un’intestazione RR, contenente l’intestazione ICMPv6, i numeri di sequenza e segmento più altre informazioni, e il RR Message Body di lunghezza variabile. La combinazione delle tecniche di autoconfigurazione degli indirizzi degli host e di Router Renumbering consente di rinumerare completamente una sottorete totalmente in modo automatico, senza intervenire manualmente su nessun nodo o router della rete.
DNS
Le applicazioni manipolano in genere nomi piuttosto che indirizzi numerici. Un indirizzo associato ad un certo nome è ottenuto attraverso una ricerca nel Domain Name System (DNS), il database distribuito che memorizza le associazioni tra identificatori umanamente comprensibili (ed altri parametri) ed indirizzi IP. L’elemento atomico di questo database prende il nome di Resource Record (RR): gli indirizzi IPv4 sono memorizzati in record di tipo A, che associano ad identificativi alfanumerici indirizzi di 32 bit. Per IPv6 è stato definito il nuovo tipo AAAA che consente di memorizzare indirizzi su 128 bit [RFC1886]. Gli indirizzi IPv6 sono codificati nei Resource Record AAAA in ordine network byte (bit più significativi all’inizio). È stato definito un nuovo dominio, chiamato IP6.INT, con lo scopo di fornire un metodo per associare un indirizzo IPv6 con un nome. Un indirizzo IPv6 viene rappresentato nel dominio IP6.INT da una sequenza di numeri esadecimali, separati da un punto a cui viene aggiunto il suffisso “.IP6.Int”. La sequenza è scritta in ordine inverso, nel senso che il primo primo a comparire è il numero meno significativo. Ad esempio l’indirizzo 4321 : 0 : 1 : 2 : 3 : 4 : 567 : 89ab si trasforma in b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
L’aggiornamento del DNS è un’operazione delicata e complessa poiché occorre introdurre manualmente le corrette associazioni tra nomi e indirizzi numerici. In IPv6 tale operazione è resa ancora più onerosa a causa delle dimensioni dell’indirizzo e dal fatto che la rinumerazione di un sito può essere potenzialmente più frequente. Diventa pertanto molto importante disporre di un meccanismo che consenta la configurazione e l’aggiornamento automatico del DNS. A tale scopo è stata definita una ulteriore estensione al DNS che utilizza un tipo innovativo di RR chiamato A6 (RFC 2874). L’idea alla base di questo meccanismo è quella di suddividere l’informazione tipicamente contenuta in un solo record su più RR, associando ad ogni record anche ulteriori informazioni utili per reperire le parti mancanti e ricostruire l’indirizzo completo. Il record A6 contiene infatti tre campi: la lunghezza della porzione di indirizzo conosciuta, la parte di indirizzo conosciuta e il nome di dominio del prefisso considerato.. In questo modo un client DNS per risalire all’indirizzo completo deve ottenere tutta la catena di Resource Record, che inizia con il record corrispondente al nome ricercato e che continua con il record corrispondente al Prefix Name, e così via con il record successivo. Questa tecnica permette di semplificare notevolmente le operazioni di Renumbering di una rete, perché sarà sufficiente cambiare quei record che contengono l’indirizzo di rete senza andare a toccare tutti gli altri record che contengono gli indirizzi delle macchine appartenenti a tale rete e delle sue eventuali sottoreti.
Neighbor discovery
Le procedure necessarie a risolvere i problemi fondamentali legati all’interazione tra nodi IPv6 connessi allo stesso link, in particolare per quanto riguarda l’autoconfigurazione e la risoluzione degli indirizzi, presentati nei lucidi precedenti, sono realizzate tramite i meccanismi messi a disposizione dal protocollo di Neighbor Discovery. Tali procedure sono le seguenti:
- Router Discovery: tutti i nodi utilizzano il protocollo di Neighbor Discovery per individuare eventuali router connessi direttamente alloro stesso link. Tutti i router IPv6 inviano dei messaggi di router advertisement (all’indirizzo “all node multicast address”) periodicamente oppure in risposta a messaggi di router solicitation inviati dagli host; nei messaggi di router advertisement i router annunciano la loro presenza, permettendo così ad ogni nodo sul link di mantenere aggiornata una lista di router disponibili. In questi messaggi sono riportati gli indirizzi link- local e parametri del router, e i prefissi del link
- Prefix Discovery: con questo meccanismo i nodi possono risalire ai prefissi IPv associati al link cui sono connessi. Questo viene realizzato leggendo i messaggi di router advertisement che contengono una lista di prefissi associati al link e particolari flag associati a tali prefissi che ne specificano l’uso cui sono destinati. In questo modo i nodi possono mantenere un database di tutti i prefissi a disposizione e quando una destinazione è direttamente raggiungibile a livello data link oppure attraverso un router intermedio.
- Parameter Discovery: queste procedure consentono ai nodi di risalire a parametri necessari a configurare le proprie interfacce, come, ad esempio, il valore di Hop Limit da utilizzare nei pacchetti in uscita o l’ MTU del link.
- Address Autoconfiguration: è la procedura di autoconfigurazione degli indirizzi delle interfacce. Si noti che i router possono, mediante messaggi di router advertisement, indicare ai nodi quale tipo di autoconfigurazione utilizzare.
- Neighbor Discovery: dato un indirizzo IPv6 di una stazione on link questa procedura consente di determinare il corrispondente indirizzo di livello data link da utilizzare per trasmettere il traffico. A tale scopo un nodo deve inviare un messaggio all’indirizzo “solicited node multicast address”, richiedendo al nodo di cui si dispone dell’indirizzo IPv6 il suo indirizzo link layer. Poiché il nodo richiedente include nel messaggio il proprio indirizzo di livello 2, il nodo destinazione è in grado di rispondere utilizzando un messaggio unicast. Questo meccanismo sostituisce l'ARP di IPv4.
- Neighbor Unreachability Detection: meccanismo mediante il quale i nodi possono determinare se un nodo vicino è diventato irraggiungibile.
- Duplicate Address Detection: permette di verificare se un indirizzo che un nodo intende utilizzare per una sua interfaccia è già in uso su un certo link; il nodo può inviare un messaggio di neighbor solicitation all’indirizzo da verificare, specificando come mittente l’unspecified address. In questo nodo, se esiste una interfaccia associata all’indirizzo da verificare, questa risponderà con un messaggio di neighbor advertisement, segnalando in questo modo che l’indirizzo è già in uso.
- Next-hop determination: è l’algoritmo che permette di associare ad ogni indirizzo IPv6 destinazione l’indirizzo IPv6 del nodo successivo verso il quale deve essere trasmesso il traffico; questo può essere un router o la destinazione stessa.
- Redirect: un router può informare un host riguardo ad un migliore next hop per una certa destinazione remota.
Ricerca dell’indirizzo MAC
E' la procedura corrispondente dell'ARP; in questo caso il pacchetto di ricerca viene inviato ad un indirizzo IPv6 multicast che è derivato da quello dell'host di cui si vuole cercare l'indirizzo MAC.
Address Resolution
Per address resolution si intende il meccanismo mediante il quale un nodo può risalire all’indirizzo link layer di un’interfaccia dato il suo indirizzo di livello IP. Tale procedura
- STALE. Si suppone che il nodo non sia raggiungibile, ma fino a quando non ci saranno pacchetti da inviare a questa destinazione, non se ne verificherà la raggiungibilità.
- DELAY. Si suppone che il nodo non sia raggiungibile, ma si aspetta un certo intervallo di tempo prima di iniziare la procedura di verifica della sua raggiungibilità per dare ai protocolli di livello superiore la possibilità di fornire delle prove di raggiungibilità.
- PROBE. Si stanno inviando pacchetti di neighbor solicitation per risalire al suo indirizzo link layer.
La principale fonte di informazione dello stato di raggiungibilità di un nodo sono i protocolli di livello superiore, ed in particolare, TCP. In alcuni casi, però, tali protocolli non possono fornire queste informazioni, o perché non ne sono a conoscenza (ad esempio UDP dal momento che non è un protocollo connesso) o perché, come accade sui router, tali protocolli non sono supportati. Per verificare la raggiungibilità di un nodo, qualora non esistano conferme dai livelli superiori, un nodo invia dei pacchetti di probe all’indirizzo da verificare ed attende dei messaggi di neighbor advertisement con il flag S settato a 1. Tali pacchetti confermano la raggiungibilità del nodo remoto. Si osservi che eventuali pacchetti di neighbor advertisement con il flag S a 0 indicano soltanto che la comunicazione dal nodo remoto verso l’interfaccia locale funziona correttamente, ma non dice nulla riguardo il viceversa. Quando una entry in stato di reachable non riceve conferme di raggiungibilità da 30 secondi, viene posta in stato di stale. All’atto della trasmissione del primo pacchetto verso il neighbor associato alla entry di cui non è stata confermata la raggiungibilità inizia un periodo di 5 secondi terminato il quale, se un protocollo di livello superiore non ha confermato la raggiungibilità della destinazione, il pacchetto entra in stato di probe. In tale stato vengono inviati 3 pacchetti di probe, uno ogni secondo. Se non si ricevono conferme dal nodo remoto, la entry viene eliminata, mentre, al contrario, viene riportata nello stato di reachable.
Algoritmo di comunicazione
Per inviare un pacchetto ad una destinazione remota, un nodo deve utilizzare una particolare combinazione delle informazioni contenute nella destination cache, nella prefix list e nella default router cache al fine di determinare il next hop, ossia l’indirizzo del nodo direttamente connesso cui inviare il pacchetto. Quando il next hop è stato determinato deve consultare la neighbor cache per verificare se esiste l’identificatore link layer associato a quell’indirizzo. Per risalire al next hop il nodo mittente effettua un confronto di tipo longest prefix match tra l’indirizzo destinazione ed i prefissi contenuti nella prefix list. In caso riscontri che il prefisso del nodo remoto è contenuto in questa tabella, il next hop sarà lo stesso indirizzo destinazione, poiché il nodo destinazione si trova on-link. In caso contrario occorre selezionare un router dalla default router cache da utilizzare come next hop. Nel caso il router selezionato come next hop si trovi nella situazione di dover instradare i pacchetti sulla stessa interfaccia da cui gli sono pervenuti, invierà un messaggio di routing redirect per informare la stazione che, per quella destinazione, esiste un percorso migliore. Per motivi di efficienza, il risultato di tale procedura viene memorizzato nella destination cache. In questo modo ad ogni nuovo pacchetto da inviare il nodo può verificare nella destination cache se esiste già un’informazione per la destinazione remota nel qual caso non è necessario ripetere la procedura di next hop determination. Una volta determinato l’indirizzo del next hop il nodo mittente accede alla neighbor cache. Se non esiste una entry specifica per il next hop, viene creata una nuova entry nello stato incomplete, viene iniziata la procedura di neighbor discovery e i pacchetti per questa destinazione vengono accodati. Gli indirizzi multicast vengono sempre considerati
on-link, pertanto un pacchetto inviato ad un indirizzo multicast avrà come next hop l’indirizzo stesso.
Sicurezza
Il problema della sicurezza è già stato affrontato con successo in IPv4, ed a confermare ciò c’è il fatto che i meccanismi implementati in IPv4 sono in linea di massima i medesimi che sono stati adottati per IPv6; la grande differenza fra le due situazioni consiste che mentre nel primo caso si è dovuto lavorare su di un protocollo già esistente, con i conseguenti problemi di adattabilità, nel caso di IPv6 la sicurezza è uno standard nato con il protocollo stesso. I meccanismi fondamentali su cui si basa la sicurezza sono l’autenticazione e la cifratura, che sono implementate attraverso l’uso di due Extension Header che sono già stati descritti dettagliatamente in precedenza. Attraverso l’autenticazione si vuole garantire l’autenticità e l’integrità dei pacchetti trasmessi; l’algoritmo utilizzato è il keyed MD5, che oltre all’autenticazione compie anche un controllo di integrità. La cifratura è invece il meccanismo tramite cui i dati vengono trattati in modo che possano essere letti solo al termine del percorso; l’algoritmo utilizzato è il DES_CBC. Entrambi questi meccanismi si basano sull’uso di chiavi segrete, che devono essere conosciute dalle due entità impegnate nella comunicazione. Uno dei metodi attualmente utilizzato si basa sull’algoritmo Photuris (che non è un acronimo, bensì il termine greco con cui si indicano le lucciole, non si conosce il motivo di tale scelta),che a sua volta si basa sull’algoritmo di Diffie-Hellman. Il protocollo IPv4 è stato concepito per lavorare in un ambiente di tipo collaborativo e nell’ipotesi che i collegamenti di rete siano fisicamente sicuri. Tale ipotesi però non sempre corrisponde alla realtà; le comunicazioni possono subire diversi tipi di attacchi. Si parla di packet sniffing quando i pacchetti in transito vengono letti da un nodo posto tra mittente e destinatario, acquisendo così informazioni riservate come, ad esempio, le password. Altri tipi di attacchi sono noti come IP spoofing e connection hacking. Nel primo caso si tratta di una falsificazione dell’indirizzo mittente, allo scopo di ingannare i servizi utilizzano tale parametro per autenticare i messaggi o sovvertire l’ordine della rete falsificando i messaggi ICMP. Nell’altro caso il sabotatore si inserisce in una comunicazione in corso, introducendo dati errati. In commercio esistono molte soluzioni efficaci a questi problemi, tutte a livello applicativo. Il loro maggior difetto è l’incompatibilità tra di esse e la duplicazione di funzionalità. Lo sviluppo di IPv6 ha permesso di offrire una risposta più efficiente alle richieste di sicurezza, in modo trasversale a tutti gli applicativi. Un contesto in cui si possono usare AH e ESP è quello delle reti private virtuali (VPN), cioè reti di un’impresa con sedi distribuite sul territorio che sono collegate tra loro non più da canali dedicati, ma mediante rete pubblica. Anche in IPv4 esiste questo tipo di reti e per garantire la sicurezza occorre proteggere crittograficamente i pacchetti IP e incapsularli in altri pacchetti IP creando tunnel sicuri tra i due firewall. Questa soluzione di incapsulamento può creare problemi di compatibilità tra firewall di costruttori diversi e problemi con la frammentazione. Infatti, nel caso in cui i pacchetti da trasmettere abbiano la dimensione massima consentita in IP non sarà possibile incapsularli dentro un solo pacchetto IP, ma dovranno essere frammentati. Un eventuale firewall dovrà estrarre ogni frammento e ricomporre il pacchetto per decodificarlo e verificarne l'autenticità, quindi spedirlo alla corretta destinazione dopo un'eventuale ulteriore frammentazione. Questo causa un decadimento delle prestazioni che può arrivare fino ad una riduzione pari al 50% del throughput medio, soprattutto per pacchetti di grandi dimensioni. In IPv6, il firewall non deve riassemblare il pacchetto, ma semplicemente eliminare l'header più esterno che permette di realizzare il tunnel. La verifica circa l'autenticità del pacchetto è fatta direttamente dalla destinazione grazie ai nuovi meccanismi introdotti da IPv6. L’overhead introdotto dagli extension header AH e ESP ha dimensione fissa ed indipendente da quella del pacchetto originale quindi il degrado delle prestazioni è più contenuto. Questa soluzione può anche essere usata in presenza di un terminale mobile, in cui il firewall svolge la funzione di home agent.
Il principio su cui si basa il protocollo Mobile IPv6 è quello di assegnare ad ogni host un indirizzo IPv6 globale, ossia che sia valido indipendentemente dalla locazione dell'host stesso. Tale indirizzo diventerà una sorta di "indirizzo ufficiale" dell'host in esame. Questo indirizzo è detto Home Address e rappresenta appunto l'indirizzo con il quale l'host verrà raggiunto.
Tuttavia, per poter permettere ai router la gestione dell'instradamento secondo le regole viste in precedenza, un host che si sposta in un'altra rete (anche detto Mobile Node) è tenuto ad acquisire un altro indirizzo che è contraddistinto da un prefisso di rete pari a quello della rete in cui è fisicamente connesso. Questo indirizzo è detto Care-Of Address, e rappresenta un indirizzo temporaneo che è necessario all'host per poter operare fino a quando rimarrà connesso alla rete ospite.
L'idea fondamentale di Mobile IPv6 è quella di definire un meccanismo che permetta di riconoscere che un utente si è spostato dalla locazione "ufficiale" ad una nuova rete, permettendo di redirigere il traffico alla nuova locazione. Per questo, di definisce Home Agent un router che si incarica di redirigere il traffico destinato all'host in esame verso la sua nuova locazione, attraverso il tunnelling del traffico ad esso diretto al nuovo indirizzo di destinazione.
Nelle sezioni seguenti si concretizzerà ques'idea illustrando le principali fasi nelle quali è possibile scomporre il protocollo.
Rilevamento del movimento
Lo standard Mobile IPv6 non prevede nessun meccanismo ad-hoc per il rilevamento del movimento da una rete all'altra (handover). Una soluzione è quella di affidarsi a segnali di livello 2 (ad esempio il cambio di una cella nel caso di telefonia mobile), che però potrebbero non essere sempre disponibili. Inoltre, vi sono casi di cambiamento del livello 2 (ad esempio da una cella WiFi ad un altra), senza il corrispondente cambio della rete di livello 3. I meccanismi di livello 2 devono quindi essere integrati con altre informazioni per poter dichiarare un avvenuto movimento.
D'altro canto, Mobile IPv6 non specifica nessun meccanismo neppure a livello 3, e l'unico modo per intuire un movimento è quello di affidarsi ai meccanismi di router advertisement, verificando che il proprio prefisso di rete corrisponda a quello annunciato dai router. Ad esempio, questo viene spesso fatto all'accensione della macchina attraverso la generazione di un messaggio ICMPv6 Router Solicitation, che obbliga i router della LAN a dichiararsi. In ogni caso, anche a run-time, ogni host è tenuto a verificare sempre i messaggi di ICMPv6 Router Advertisement che vengono inviati periodicamente.
Tuttavia, questi messaggi possono essere fuorvianti. Infatti, la ricezione di un nuovo messaggio di router advertisement per un nuovo prefisso puù semplicemente significare che la rete ha acquisito un nuovo router con un nuovo spazio di indirizzamento, quindi in questo caso l'annuncio di un nuovo prefisso non corrisponde ad un segnale di mobilità. Inoltre, nel caso di network renumbering, i router sono tenuti ad annunciare dei prefissi di rete diversi da quelli annunciati in precedenza, senza tuttavia che si sia in presenza di un movimento da parte dell'host mobile.
Questa problematica è tuttora aperta.
Determinazione del Care-Of Address
L'host mobile è tenuto, attraverso un insieme di modalità, ad accorgersi qualora la sua posizione nei confronti della rete cambi (handover). In questo caso è tenuto ad acquisire un nuovo indirizzo IPv6 che appartiene allo spazio di indirizzamento della rete di destinazione, il Care-Of Address, appunto.
Nel momento in cui si rileva un cambio nella rete, l'host mobile si attiva per acquisire un nuovo indirizzo, sia attraverso la modalità di configurazione stateless che stateful. Acquisito il nuovo indirizzo, provvede a comunicarlo al proprio Home Agent.
Altri care-of address precedentemente acquisiti possono essere conservati per permettere all’host di continuare a ricevere pacchetti indirizzati a precedenti locazioni. Questo può essere utile nelle reti via radio in cui un host può decidere di configurarsi sulla cella da cui riceve il segnale a massima potenza, ma continuare a ricevere i segnali anche da altre celle che precedentemente lo avevano servito.
Registrazione dell'indirizzo temporaneo presso l'Home Agent
La procedura è iniziata dal nodo mobile che invia un messaggio di Binding Update verso uno qualunque degli indirizzi (unicast) degli Home Agent nel quale effettuerà la registrazione del suo nuovo indirizzo temporaneo (Care-Of Address), a cui seguirà, se non ci sono errori, un messaggio di Binding Acknowledgement da parte dell'Home Agent prescelto.
Il messaggio di Binding Update deve essere protetto attraverso qualche meccanismo di sicurezza per evitare che qualche malintenzionato si appropri dell'identità dello host mobile. Inoltre, l'Home Agent che riceve questo messaggio è tenuto ad attivare una fase di Duplicate Address Detection (DAD) per verificare che non esista un altro host, localmente, con lo stesso indirizzo. Questa verifica da parte dell'Home Agent deve essere fatta solamente la prima volta che l'host mobile si registra presso di lui e può essere evitata ai successivi rinnovi, in quanto si suppone che non possa esistere un indirizzo duplicato. Infatti, se esistesse, sarebbe già stato rilevato dalla procedura di DAD relativa alla prima registrazione; se, invece, un secondo host locale cercasse di acquisire lo stesso indirizzo IPv6 successivamente alla prima registrazione, sarebbe costui stesso ad accorgersi della duplicazione dell'indirizzo a causa del fallimento della procedura di DAD da lui iniziata e alla quale l'Home Agent risponde con un pacchetto di ICMPv6 Neighbor Advertisement in sostituzione dell'host mobile.
All'accettazione di un messaggio di Binding Update, l'Home Agent si preoccupa anche di inviare un messaggio ICMPv6 Neighbor Solicitation, che è utilizzato per informare tutti gli host sulla LAN che il loro mapping tra l'indirizzo IPv6 e l'indirizzo MAC non è più valido. Questo messaggio viene quindi utilizzato dalle macchine che avevano una entry relativa all'host mobile nella loro neighbor cache per aggiornarla con l'indirizzo di livello 2 dell'Home Agent.
Compiti dell'Home Agent
L'Home Agent riveste un'importanza fondamentale per il funzionamento del meccanismo di Mobile IPv6. Infatti, l'Home Agent ha i seguenti compiti:
- Sulla LAN in esame agisce "in rappresentanza" dello hos mobile, come se questi fosse fisicamente presente. Esso, pertanto, genera i messaggi ICMPv6 Neighbor Solicitation / ICMPv6 Neighbor Advertisement che vengono richiesti dalle specifiche IPv6 così come se l'host mobile fosse connesso alla rete locale.
Tuttavia, se da un lato l'host mobile dovrebbe generare pacchetti con il proprio indirizzo permanente come sorgente, questo causa problemi nel caso in cui la rete "ospite" abbia attivato meccanismi di Network Ingress Filtering (RFC 2267), che offrono una certa protenzione contro attacchi di tipo Distributed Denial Of Service. Questo meccanismo infatti prevede che solo i pacchetti che abbiano un indirizzo sorgente appartenente allo spazio di indirizzamento relativo alla rete stessa possano essere inoltrati dal router verso il resto del mondo, nel qual caso l'indirizzo sorgente deve essere obbligatoriamente quello temporaneo.
Queste necessità contrapposte complicano pertanto la gestione dell'inoltro dei pacchetti in uscita da parte del nodo mobile.
Route Optimization
Questo meccanismo può essere utilizzato nelle seguenti condizioni:
- il Correspondent Node deve avere il supporto Mobile IPv
- deve esistere un binding attivo tra il Mobile Node e il Correspondent Node, in modo che ques'ultimo conosca l'indirizzo temporaneo dell'host mobile. Questo corrisponde a dire che la Binding Update List dell'host mobile deve contenere una informazione valida riferita al Correspondent Node (ossia deve esistere una registrazione non scaduta che si riferisce all'attuale indirizzo temporaneo presso il Correspondent Node). Questo implica che, in modo duale, il Correspondent Node avrà una informazione valida nella sua Binding Cache relativa all'indirizzo temporaneo del nodo mobile.
In presenza di queste condizioni, l'host mobile invierà i pacchetti dati direttamente al Correspondent Node, con le seguenti caratteristiche:
- l'indirizzo IPv6 sorgente sarà il Care-Of Address del nodo mobile
- l'indirizzo IPv6 destinazione sarà l'indirizzo IPv6 del Correspondent Node
- il pacchetto conterrà un Destination Option Extension Header (Home Address Destination Option) che conterrà l'indirizzo permanente (Home Address) del nodo mobile. Questo Destination Option sarà inserito dopo il Routing Header e prima del Fragment Header.
- tutto il calcolo delle checksum (e altro) relativi ai protocolli di livello superiore verranno fatti considerando come se l'indirizzo IPv6 sorgente fosse l'indirizzo permanente e non quello temporaneo.
In riferimento all'ultimo punto, l'idea è che i protocolli di livello superiore vedranno il pacchetto IPv6 contenente l'indirizzo permanente come indirizzo sorgente, permettendo loro di poter mantenere attive le sessioni anche nel caso di handover. Tuttavia, il pacchetto IPv6 che viene fisicamente generato sulla rete contiene l'indirizzo temporaneo come indirizzo sorgente (garantendo la compatibilità con i meccanismi di Network Ingress Filtering), e questo indirizzo viene sostituito con quello permanente (contenuto nell'Home Address Destination Option) dal nodo destinazione prima della consegna del pacchetto stesso ai protocolli di livello superiore.
Inoltro senza uso di Mobile IPv
Questo meccanismo ammette che, in determinate situazioni, l'host mobile si comporti come un normale host IPv6 senza nessun riferimento al fatto di essere un host mobile. In particolare, esistono situazioni in cui lo scambio di dati tra due applicativi è molto breve: si pensi ad una query DNS, dove la "sessione" consiste tendenzialmente in un pacchetto inviato dal client verso il DNS server e la relativa risposta che segue il percorso inverso.
Per questi tipi di interazione non vi è nessuna particolare controindicazione ad utilizzare il Care-Of Address come indirizzo sorgente dei pacchetti in uscita: è infatti ragionevole che la "sessione" si chiuda prima di un eventuale handover; nel caso poi in cui l'handover si verifica esattamente durante la sessione stessa, è ragionevole che gli applicativi siano in grado di recuperare l'errore.
In generale, quindi, per sessioni molto corte (e normalmente iniziate dal nodo stesso in modalità client-server) è possibile gestire il traffico in uscita dal nodo mobile come se non si fosse in presenza di mobilità, utilizzando pertanto l'indirizzo temporaneo. In queste condizioni, nè l'host mobile, nè il Correspondent Node faranno uso di meccanismi previsti da Mobile IPv6.
Il tallone d'achille di questa soluzione è che, al momento, la scelta di questo meccanismo di inoltro viene demandata all'applicativo, ma non esiste un'interfaccia attualmente definita (API) che permetta di farlo.
Reverse Tunnelling
Il meccanismo di Reverse Tunnelling viene utilizzato qualora i due meccanismi precedenti non possano essere utilizzati, ossia si presume che la sessione sia lunga e non esiste un binding opportuno per il Correspondent Node. Questo secondo punto può significare o che il binding non è ancora stato attivato, oppure che l'host remoto non ha il supporto Mobile IPv6 e pertanto non è in grado di attivare nessun binding.
L'host mobile genererà pertanto un pacchetto IPv6 contentente il suo indirizzo permanente come indirizzo sorgente e l'indirizzo del Correspondent Node come indirizzo destinazione, quindi inoltrerà questo pacchetto all'Home Agent tramite tunnelling. Il pacchetto uscente dal nodo mobile sarà quindi un pacchetto ha avrà due serie di header IPv6, un primo header riferito al tunnel (quindi l'indirizzo temporaneo come sorgente e l'indirizzo dell'Home Agent come destinazione), e un secondo header che si riferisce al pacchetto che l'Home Agent inoltrerà verso la destinazione. E' ovviamente consigliato proteggere il tunnel con un header ESP.
Questa soluzione ha il problema di obbligare il pacchetto a fare un percorso che normalmente non è ottimizzato in quanto viene recapitato prima all'Home Agent e solo successivamente alla destinazione finale.
Invio dei pacchetti dati da parte del Correspondent Node
La procedura di invio dei dati da parte del Correspondent Node è duale rispetto a quella descritta in precedenza. La procedura prevede che, per prima cosa, il Correspondent Node debba controllare la presenza di una registrazione per l'indirizzo IPv6 desiderato all'interno della Binding Cache. Pertanto, questa il Correspondent Node deve controllare il contenuto di questa cache prima di inviare ogni pacchetto.
Nel caso in cui il Correspondent Node non abbia un opportuno binding nella sua Binding Cache per l'host mobile, il pacchetto verrà inviato all'Home Address. L'Home Agent intercetterà questi pacchetti e li inoltrerà verso il Care-Of Address. L'inoltro verrà fatto attraverso tunnelling, meglio se protetto (ESP) in modo da celare il contenuto dei dati da occhi indiscreti. In ogni caso, l'host mobile è tenuto a controllare che l'indirizzo IPv sorgente del tunnel sia quello del suo Home Agent.
Viceversa, nel caso in cui il il Correspondent Node abbia un opportuno binding nella sua Binding Cache per l'host mobile, il pacchetto verrà inviato verso il Care-Of Address, ma verrà aggiunto uno speciale Routing Header (di tipo 2, mentre il Routing Header
verso l'Home Agent (e analogamente ai Correspondent Node che sono elencati nella sua Binding Update List), il quale avrà le seguenti caratteristiche:
- Bit A (Acknowledge): settato
- Bit H (Home Registration): settato
- Lifetime: impostato a zero
- Care-Of Address: impostato al valore dell'indirizzo permanente.
E' importante notare che fino a quando l'Home Agent non è stato aggiornato, l'host mobile non potrà utilizzare il suo indirizzo permanente sulla rete locale, in quanto l'Home Agent continuerà ad agire in sua vece fino a quando il binding non verrà annullato. E' pertanto necessario che l'host mobile conosca l'indirizzo di tipo link-layer del proprio Home Agent (ad esempio attraverso la ricezione di un messaggio di Router Advertisement) per poter inviare il pacchetto, in quanto ogni pacchetto inviato con il proprio indirizzo IPv6 sorgente non è ammesso (l'Home Agent risponde con un ICMPv Destination Unreachable), mentre il proprio indirizzo permanente è "posseduto" dall'Home Agent, il quale non invierà mai una risposta sulla rete in quanto ritiene che quel pacchetto sia stato generato da lui stesso.
Richiesta di aggiornamento del Binding da parte del Correspondent Node
Nel caso in cui il Correspondent Node rileva, nella sua Binding Cache, un valore che è attualmente in uso e la cui validità volge al termine, ha la possibilità di generare un messaggio di Binding Refresh Request verso l'host mobile, richiedendo esplicitamente un rinnovo del Binding Update. Se questo avviene, il valore in scadenza nella Binding Cache viene rinnovato.
Le differenze tra Mobile IP e Mobile IPv
Nonostante sia possibile elencare molte differenze tra Mobile IPe Mobile IPv6, queste sono prevalentemente di dettaglio e sono illustrate nella slide.
Il processo di standardizzazione per IPv6 e per Mobile IPv6 non è ancora terminato, ma è in futuro tutti i nodi IPv6 dovranno offrire il supporto alla mobilità.
Protocolli di Routing
RIP è un protocollo di tipo distance vector utilizzato per il routing intra-domain; le sue prestazioni sono nettamente inferiori a quelle di protocolli di tipo link-state, come ad esempio OSPF; per questo motivo viene utilizzato in autonomous system di piccole dimensioni. Il vantaggio del RIP è che la sua implementazione è molto semplice. Nell’ upgrade alla versione per IPv6, si è cercato di mantenere la semplicità del protocollo originario, anche se ciò non ha permesso un miglioramento significativo delle prestazioni. Le sue caratteristiche, a parte la capacità di lavorare con gli indirizzi IPv6, sono quelle del RIP classico:
- I Timer
- Elaborazione degli Output
- Split Horizon
- Funzioni di Controllo
OSPF è un protocollo di tipo link-state ed è raccomandato per il routing intra-domain. Si basa sul fatto che tutti i router hanno una copia di un database che contiene i link state record che descrivono lo stato della rete, o per lo meno lo stato della rete a cui appartengono; lo scambio di informazioni fra i diversi router avviene tramite LSA (Link
State Advertisement). OSPF viene utilizzato da molti anni con IPv4 e, grazie ai miglioramenti che ha subito nel corso del tempo, il meccanismo per la versione IPv6 è rimasto praticamente invariato, tranne che per alcune variazioni che riguardano principalmente l’adattamento al nuovo formato degli indirizzi. Le innovazioni più significative del nuovo protocollo sono le seguenti:
- rimozione semantica degli indirizzi
- elaborazione del protocollo per link
- miglioramento del flooding
- cambiamenti sull’autenticazione
- cambiamenti sul formato dei pacchetti
- reso network protocol indipendente
- più flessibile manipolazione degli LSA sconosciuti
IDRP (Inter Domain Routing Protocol) e’ un protocollo di tipo Path Vector che lavora con Routing Domain diversi. E’ un protocollo di derivazione ISO e nella sua progettazione si è tenuto conto di un altro protocollo di routing, il BGP-4; quest’ultimo non è stato utilizzato direttamente per IPv6 perchè i suoi algoritmi erano ottimizzati per lavorare con indirizzi di 32 bit ed un aggiornamento ad IPv6 sarebbe stato troppo oneroso; comunque la nuova versione di IDRP modifica e aggiunge alcune funzionalità derivate da BGP-4. BGP4+, ovvero l'ultima versione di BGP, è perfettamente compatibile con IPv6.
Le difficoltà della transizione
Il problema dell’esaurimento degli indirizzi IPv4 è stato la motivazione principale che ha portato alla nascita di IPv6 ed alla necessità di passare entro qualche anno al nuovo protocollo. A questo punto però bisogna analizzare le difficoltà della transizione da un protocollo all’altro; infatti, vista la dimensione e l’eterogeneità di Internet, la transizione sarà molto lunga e quindi i due protocolli dovranno coesistere per molto tempo. La descrizione del protocollo IPv6 fatta finora ha messo in evidenza il fatto che esso non può essere considerato una sempice evoluzione di IPv4, bensì un nuovo protocollo che in linea di massima non è in grado di interoperare con IPv4; infatti le applicazioni progettate per IPv4 non funzionano su IPv6 ed i nodi di rete IPv4 (terminali o router) non possono comunicare con nodi di rete IPv6, in quanto sono diverse molte delle procedure di comunicazione e soprattutto è completamente diverso il formato degli indirizzi. Si sono cercate ( e si cercano tuttora) delle soluzioni a questi problemi, in modo che , in attesa della diffusione totale di IPv6, i nuovi apparati IPv6 possano interlavorare con gli apparati IPv4 esistenti e sia possibile la comunicazione tra reti IPv6 isolate nella Internet IPv4. Le soluzioni trovate e messe in atto possono essere divise in tre categorie:
- Multiprotocol End System: è conosciuto anche come ‘Dual-Stack’ e si basa sulla coesistenza di più protocolli sullo stesso end o intermediate system.
- Conversion: si basa sulla presenza di apparati preposti alla conversione diretta del traffico.
- Tunneling: Source e Destination usano lo stesso protocollo (ad esempio IPv6), ma i pacchetti devono passare su una rete intermedia diversa (che ad esempio si basa su IPv4).
Dual-stack
La tecnica dual-stack permette un supporto completo da parte di host e router di entrambi i protocolli. Essa consiste nel dotare tutti i nuovi nodi Ipv6 anche di Ipv4 in modo da farli diventare multiprotocollo. Fra tutte le tecniche multiprotocol è la più semplice e diretta ma presenta dei grossi limiti, che non ne permettono una diffusione su larga scala. Il difetto principale consiste nel fatto che, essendo gli host dotati anche dello
registrato il nuovo utente configura il DNS ed uno o più tunnel server; i tunnel server sono gli apparati tramite i quali l’utente può raggiungere la rete IPv6 desiderata.
La rete 6bone
La rete 6bone è una rete IPv6 sperimentale a livello mondiale. In buona parte è realizzata su Internet sfruttando la tecnica del tunneling, tramite la quale si collegano le varie isole IPv6 sparse nella Internet IPv4; è costituita da oltre 500 laboratori interconnessi distribuiti in oltre 40 nazioni; per quanto riguarda il backbone, questi comprende oltre 60 laboratori di cui due in Italia: CSELT (Torino) e INFN-CNAF (Bologna). Al momento le indicazioni fornite dall’attività di 6bone sono positive: le dimensioni delle tabelle di routing sono contenute e le condizioni operative per l’80% dei siti sono buone. Per maggiori informazioni è possibile consultare il sito http://www.6bone.net.
