• Multicasting
  • Multicast Listener Discovery ( MLD )
• Sicurezza
• Mobilitá dei terminali
• Servizi a qualità differenziata

Nella definizione di IPv6 si è tenuto conto anche delle nuove esigenze degli utenti di Internet emerse in questi ultimi anni e del fatto che IPv4 le può supportare solo con l'ausilio di applicativi specifici. Integrando in IPv6 i protocolli per la gestione del multicasting, della mobilità dei terminali e dei servizi a qualità differenziata, aumenta l'efficienza ed è più semplice l'implementazione di quelle che vengono chiamate funzionalità evolute.

La possibilità di realizzare trasmissioni multicast su Internet è stata sviluppata a partire dal 1988 con gli indirizzi di classe D. Essa è utilizzata soprattutto dai nuovi applicativi multimediali, che molto spesso devono effettuare trasmissioni da uno a molti.
La principale novità di IPv6 per quel che riguarda il multicast è che tutte le implementazioni IPv6 dovranno includere da subito il supporto nativo a tale servizio IP. L'introduzione del campo scope negli indirizzi multicast IPv6, che permette di specificare la visibilitá di tale indirizzo, insieme al fatto che la gestione del multicast non è più delegata a un protocollo a parte come in IPv4, rappresenta un miglioramento rispetto. Il protocollo MLD, infatti, fa parte di ICMPv6. In IPv4 inoltre sono stati definiti diversi protocolli per realizzare il routing multicast, mentre in IPv6 si è scelto di adottare unicamente una nuova versione del protocollo PIM (Protocol Indipendent Multicast), a cui si sta ancora lavorando.

Multicast Listener Discovery ( MLD )

MLD è un sottoprotocollo di ICMPv6, usato dai router per gestire i gruppi multicast. Deriva dal protocollo IGMPv2 [RFC2236] per IPv4, anche se si differenzia da esso in quanto MLD usa messaggi ICMPv6.
L'intestazione IPv6 che precede un pacchetto MLD ha come indirizzo sorgente quello link-local del mittente, hop limit pari a uno e usa l'opzione di Router Alert.
Ci sono tre tipi di messaggi MLD distinti dal valore del campo type (si veda la figura 40): Multicast Listener Query (type = 130), Multicast Listener Report (type = 131) e Multicast Listener Done (type = 132 ). A sua volta ci sono due sottotipi di Query che si differenziano dal contenuto di Multicast Address: General Query, usato per scoprire quali indirizzi multicast corrispondono a gruppi attivi sul link, ha tale campo nullo, mentre Multicast Address Specific Query, che serve per verificare se un particolare gruppo ha ancora membri attivi, pone in multicast address l'indirizzo del gruppo da interrogare. I messaggi di Report e Done, hanno in multicast address l'indirizzo multicast del gruppo cui appartiene il nodo che lo invia. Maximum response delay ha senso solo per messaggi di Query e specifica il massimo ritardo ammesso, prima che il ricevitore invii un Report.

I nodi usano questo protocollo per conoscere quali gruppi multicast sono attivi e ognuno riporta tali informazioni in apposite tabelle, una per ogni link cui è connesso. Su ogni link vi è un solo router con la funzione di Querier e periodicamente invia messaggi General Query a tutti i nodi del link con lo scopo di tenere aggiornati i propri dati che altrimenti sono soggetti a scadenza. Coloro che li ricevono utilizzano il valore di Maximum Response Delay per inizializzare i loro timer in modo che le risposte non siano sincronizzate tra loro e provochino così collisioni. Lo scadere di un timer di un nodo fa si che esso invii al Querier un Report qualora sia membro attivo di un gruppo.
Per velocizzare l'aggiornamento delle tabelle è stato introdotto il messaggio Done. Quando un nodo abbandona un gruppo manda un avviso di Done al Querier. Questi risponde con un Multicast Address Specific Query per verificare se quel gruppo ha ancora membri attivi, in caso negativo elimina il gruppo dalle proprie tabelle.

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 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 la password. Altri tipi di attacchi sono noti come IP spoofing e connection hijacking. Nel primo caso si tratta di una falsificazione dell'indirizzo mittente, allo scopo di ingannare i servizi che autenticano in base a quel parametro 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 prposte di soluzioni 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 esistono queste 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 (si veda la figura 41). Questa soluzione di incapsulamento può creare problemi di compatibilità tra firewall di costruttori diversi e problemi con la frammentazione. Infatti, nel caso che i pacchetti da trasmettere abbiano la dimensione massima consentita in IP non sarà possibile incapsularli dentro un altro pacchetto IP, ma dovranno essere frammentati. Il firewall FW2 dovrà estrarre ogni frammento e ricomporre il pacchetto per renderlo in chiaro e verificarne l'autenticità, quindi spedirlo alla corretta destinazione dopo un'eventuale frammentazione. Questo causa un decadimento delle prestazioni che può arrivare fino al 50% del throughput normale, soprattutto per pacchetti di grandi dimensioni. In IPv6, FW2 non deve riassemblare il pacchetto, ma semplicemente eliminare l'header più esterno che permette d realizzare il tunnel. La verifica circa l'autenticità del pacchetto è fatta direttamente dalla destinazione grazie ai nuovi meccanismi che IPv6 introduce. 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 fa da home agent.

Mobilitá dei terminali

La mobilità dei terminali è un tipo di servizio innovativo, ma si prevede che nel prossimo futuro assumerà le stesse proporzioni della telefonia mobile. In genere si distingue tra il concetto di portabilità e quello di mobilità. Nel primo caso l'utente si sposta, per esempio in seguito a una trasferta di lavoro, e da un nuovo punto di accesso instaura un collegamento con la propria sede. Anche se può cambiare più volte il punto di accesso non instaura mai dei collegamenti mentre è in movimento. La portabilità è già attiva in IPv4, ma in IPv6 è semplificata grazie ai meccanismi di autoconfigurazione previsti dal nuovo protocollo. Con mobilità invece, si intende il caso in cui il terminale sia in grado di comunicare durante gli spostamenti. Ciò non è facile da realizzare poiché sia in IPv4 che in IPv6, l'instradamento dei pacchetti è basato sul prefisso di sottorete dell'indirizzo di destinazione in essi contenuto. Per poter continuare a comunicare, un nodo mobile dovrebbe cambiare il suo indirizzo IP ogni volta che raggiunge un nuovo link, ma in questo modo non sarebbe in grado di mantenere le connessioni di livello trasporto. Questo perché TCP identifica univocamente le sessioni usando gli indirizzi IP sorgente e destinazione e il numero di porta; se un indirizzo è modificato prima della chiusura della sessione questa viene persa. Per tale ragione è stato necessario definire un protocollo apposito per il supporto della mobilità sia in IPv4 che in IPv6.

Il protocollo, fa sì che il nodo mobile sia sempre raggiungibile mediante il suo "home address", cioè quell'indirizzo IP il cui prefisso identifica la sottorete e il link di appartenenza di quel nodo. L'home address è permanente. I pacchetti possono essere inviati al terminale mobile usando l'home address indipendentemente dall'attuale punto di accesso a Internet che questi sta usando: il nodo mobile può così continuare a comunicare con gli altri nodi (mobili e non) dopo essersi mosso su un nuovo link. Il suo movimento è reso in questo modo trasparente al livello di trasporto e alle applicazioni. Mobile IPv6 deriva direttamente da Mobile IP [RFC2002] e pertanto il funzionamento di base è identico. Le novità introdotte da IPv6, quali l'autoconfigurazione stateless, il protocollo di Neighbor Discovery e i meccanismi per l'autenticazione e crittografia, hanno permesso alcune semplificazioni rispetto al protocollo per IPv4.

Uno scenario possibile di applicazione del protocollo per la mobilità è mostrato in figura 42 dove sono state riportate anche alcune definizioni. In particolare, si parla di home network e home link per indicare la rete e la sottorete di appartenenza di un nodo, mentre con foreign si etichetta tutto ciò che è relativo alla rete visitata da un nodo mobile durante un suo spostamento.

Si consideri il caso in cui la stazione W desideri comunicare con Z, per cui interroga il DNS che gli fornisce A::1 quale indirizzo di destinazione. W genera così un pacchetto in cui l'indirizzo di destinazione è A::1 e quello sorgente è C::1 . Tale pacchetto è instradato come uno qualsiasi e raggiunge la rete A. A questo punto possono porsi due casi.
Il nodo Z è collegato alla sua home network, quindi le modalità di consegna del messaggio seguono le procedure classiche.
Il nodo Z è collegato alla rete B, che quindi è la sua foreign network. In questo caso, è anche indirizzabile mediante uno o più care-of address, cioè quell'indirizzo IP che viene associato al nodo mobile mentre sta visitando una particolare sottorete diversa da quella di appartenenza. Il prefisso del care-of address è quello della sottorete di cui fa parte il foreign link. Nella rete di casa deve esserci un'entità (Home Agent), che si occupa di inoltrare a Z i pacchetti a lui destinati ma che usano come destinazione l'home address. L'Home Agent devia questi pacchetti verso Z mediante l'uso di tunnel. I pacchetti che usano il care-of address come indirizzo di destinazione invece raggiungono direttamente il nodo mobile quando esso è connesso al foreign link, senza passare per l'home link.

L'associazione tra home address e care-of address primario è detta binding. Il primario è quell'indirizzo acquisito mediante l'autoconfigurazione stateless ogni volta che la stazione cambia il suo punto di connessione a livello link da una sottorete IPv6 a un'altra. Quando ciò avviene, registra la nuova associazione con un router della sua home link, il quale svolgerà così il ruolo di home agent per quel nodo. 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.

Figura 41 - Mobilità di una stazione.

La registrazione del care-of address presso l'Home Agent avviene utilizzando i seguenti messaggi:

• Binding Update, inviato dal nodo all'home agent
  
• Binding Acknowledgement, inviato dall'home agent al nodo come conferma dell'Update.

Tali messaggi vengono veicolati utilizzando due nuovi tipi di Destination options definite per Mobile IPv6 e chiamate binding update option e binding acknoledgement option.
Il compito dell'home agent è di intercettare sull'home link, i pacchetti destinati al nodo mobile e inviarglieli mediante un tunnel.
Le opzioni di Binding Update, Acknowledgement e Request sono anche usate per permettere a un nodo IPv6 ( detto in questo caso nodo corrispondente) comunicante con uno mobile, di imparare dinamicamente e memorizzare in una cache il binding del nodo mobile. Quando deve mandare un pacchetto, tale nodo controlla nella cache se vi è una riga per quella destinazione. In caso affermativo usa un IPv6 Routing Header per instradare il pacchetto per mezzo del care-of address. In caso negativo il pacchetto è inviato normalmente e sarà rediretto al nodo mobile dall'home agent. Tali opzioni devono essere presenti in ogni pacchetto IPv6 della comunicazione mobile.

Mobile IPv6 definisce un'ulteriore destination option address detta Home Address. In questo modo il nodo mobile usa come indirizzo sorgente per i suoi pacchetti il care-of address e aggiungendo tale opzione può far conoscere il proprio home address. E´ stato necessario introdurre questa opzione, non presente nella versione per IPv4, perché molti router adottano dei filtri di ingresso che scartano i pacchetti con un indirizzo sorgente non topologicamente corretto, di conseguenza sarebbero eliminati tutti quei pacchetti di un nodo mobile che usa l'home address come indirizzo sorgente quando è fuori casa. D'altro canto usare solo il care-of address non renderebbe gli spostamenti trasparenti al livello trasporto e questo è il fine principale del protocollo. Un altro beneficio derivante dall'aggiunta dell'opzione suddetta è la semplificazione del routing di pacchetti multicast inviati dal nodo mobile. L'uso degli header Destination Option permette a Mobile IPv6 di ottenere un controllo del traffico sfruttando la possibilità di aggiungere i propri pacchetti di controllo a qualsiasi pacchetto IPv6 esistente (piggybacking), in Mobile IP invece tale funzionalità è svolta da pacchetti UDP separati, la cui presenza aumenta il traffico in rete.

Servizi a qualità differenziata

Rispetto IPv4, la nuova versione del protocollo prevede una modalità nuova di individuazione dei flussi di pacchetti IP attraverso il campo flow label dell'intestazione IPv6.
Un "flusso" è una sequenza correlata di pacchetti generati da una sorgente e relativi ad una specifica attività applicativa. Per individuare univocamente un flusso, in IPv4 era necessario riferirsi al valore di cinque parametri: l'indirizzo sorgente, l'indirizzo destinazione e il protocollo di livello superiore trasportato (estratti dall'intestazione IPv4) e i numeri di porta TCP o UDP sorgente e destinazione (estratti dall'intestazione del protocollo di livello superiore). Il campo flow-label di IPv6 permette di individuare univocamente i flussi di pacchetti dati in modo più efficiente per i nodi di rete che devono classificarli.
Questa è l'unica reale differenza tra IPv4 e IPv6 per quanto riguarda le modalità di supporto ai servizi a qualità differenziata e controllata. Infatti, sono applicabili tanto ad IPv4 quanto ad IPv6 i modelli Integrated Services (che offre qualità di servizio on-demand sulla base dell'uso del protocollo RSVP - ReSerVation Protocol) a Differentiated Services (che offre la possibilità di supportare classi di servizio diversificate per aggregati di traffico) in corso di definizione presso l'IETF.

---