[...]
IV.4 IPv6
Il
protocollo IPv4 è stato standardizzato nel 1981. Come sinora discusso,
le sue caratteristiche hanno facilitato la ben nota diffusione di
Internet, ma, anche a causa di questa enorme diffusione, IPv4 appare
non essere più adeguato a soddisfare le accresciute esigenze dell'utenza.
In particolare, si è detto che la modalità senza connessione e lo
schema di indirizzamento universale di IP ne hanno determinato la
semplicità implementativa ed hanno significativamente contribuito
allo sviluppo di Internet, ma proprio questi punti di forza costituiscono
oggi i principali limiti di IPv4 e richiedono di introdurre una nuova
versione di questo protocollo. Infatti, la modalità best effort non
consente di fornire servizi con una prefissata qualità di servizio,
mentre lo spazio di indirizzi di IPv4 è in via di esaurimento. La
nuova versione di IP è denominata IP versione 6, IPv6 (la nomenclatura
versione 5 era stata temporaneamente assegnata ad un protocollo per
il supporto di flussi con requisiti di tempo reale ed è poi caduta
in disuso). IPv6 è stato anche denominato per un certo periodo come
"IP new generation", IPng. Nel seguito esporremo le caratteristiche
principali di IPv6, rimandando alle relative RFC o, ad esempio, a
[GAI97], [STA96] per maggiori dettagli. La problematica del supporto
di servizi con una prefissata qualità di servizio è stata discussa
in IV.3. La problematica dell'esaurimento dello spazio di indirizzi
è stata invece accennata in III.4.3. In particolare si è detto che
la scelta di uno schema di indirizzamento gerarchico può risultare
in indirizzi non utilizzati e quindi in sprechi. Gli indirizzi corrispondenti
alla parte Host_Id di una data rete logica, non usati dall'organizzazione
responsabile della corrispondente Net_Id, non possono essere usati
da nessun altro; ciò spiega l'attuale penuria di indirizzi IP, a fronte
dei 3 758 096 384 indirizzi teoricamente disponibili per le prime
tre classi e dei 2^32 (=4 294 967 296) possibili indirizzi totali;
penuria questa che altrimenti non apparirebbe comprensibile, visto
che l'attuale numero di host è sicuramente inferiore a questa cifra
(il numero di utenti di Internet dovrebbe essere di circa 300 milioni
entro la fine del 2000). Va però detto che il numero di utenti appare
destinato a sestuplicarsi entro la fine del 2005. Un altro fenomeno,
destinato per altro a incidere profondamente sulla organizzazione
della nostra vita domestica e lavorativa, è rappresentato dalla diffusione
di "utensili" informatici in aggiunta agli ormai tradizionali PC.
Si prevede una esigenza di elaborazione "ovunque" (ricreativi, elettrodomestici,
autoveicoli, controllori di traffico, ecc.) realizzata con "processori"
e con associati mezzi di comunicazione via Internet. La prospettiva
è trasformare "prodotti" in "servizi", consentendo una larga varietà
di applicazioni personalizzate. Si parla di un numero di "utensili"
informatici che nel 2010 potrebbe raggiungere la quota di un miliardo.
A questi si aggiungono i terminali mobili, che, in prospettiva, richiederanno
anch'essi un indirizzo IP. Gli accessi ad Internet sono inoltre destinati
ad assumere una configurazione unificata per qualunque tipo di applicazione
o di servizio (voce, dati, immagini, ecc.), magari supportati da un
DNS evoluto che distingua il tipo di servizio richiesto, indirizzando
una richiesta di comunicazione non solo verso un dato utente, ma anche
verso uno specifico apparecchio di quell'utente (cosa che in parte
avviene già oggi). Ad esempio, un utente potrebbe essere identificato
globalmente da un opportuno nome. Un DNS evoluto potrebbe provvedere
sia a rintracciare l'attuale posizione dell'utente, (tramite Mobile
IP, cfr. IV.5), sia a indirizzare una chiamata verso uno specifico
tipo di terminale appartenente a quell'utente: una chiamata vocale
verso un telefono cellulare, una posta elettronica verso il calcolatore
posizionato nel luogo di lavoro, una chiamata videotelefonica verso
un opportuno terminale, etc. La conseguenza ovvia di queste tendenze
è un incremento vertiginoso delle esigenze di indirizzamento e quindi
dello spazio di indirizzi di IPv6. La comunità Internet era conscia
di questo problema già da diversi anni; addirittura, nel 1991, si
prevedeva l'esaurimento degli indirizzi di classe B nel 1994. L'introduzione
del classless interdomain addressing (o routing) (cfr. fine del III.4.5.3)
ha alleviato il problema, rinviando tale esaurimento ad una data stimata
(forse ottimisticamente) intorno al 2010, ma, come si è detto, questa
tecnica aumenta la complessità del'instradamento IP. La conclusione
di queste considerazioni è che IP necessita di uno nuovo schema di
indirizzamento.
IV.4.1
Caratteristiche generali
Una volta riconosciuta la necessità di cambiare il protocollo di rete
di Internet, operazione sicuramente non semplice, si è deciso di introdurre
anche altri miglioramenti. Nel seguito elenchiamo gli obiettivi che
IPv6 si prefigge, ed insieme le sue caratteristiche generali [GAI97],
[STA96]. Circa la nomenclatura, IPv6 definisce con il termine "nodo"
un qualunque dispositivo che implementa IPv6, sia esso un host o un
router, mentre la sua unità di dati è denominata "pacchetto", invece
che datagramma.
IV.4.1.1
Nuovo piano di indirizzamento
Il piano di indirizzamento dovrà avere le seguenti caratteristiche:
- introduzione di una gerarchia degli indirizzi che faciliti l'assegnazione
degli stessi e le operazioni di instradamento; se lo spazio di indirizzi
è sufficientemente grande, l'assegnazione degli indirizzi risulta
più semplice ed è anche possibile che ogni sistema sia in grado di
"autoassegnarsi" un indirizzo, evitando agli utenti le operazioni
di configurazioni ed ottenendo così capacità di "plug and play" (molto
vantaggiose soprattutto per gli utenti meno esperti); un generoso
dimensionamento dello spazio degli indirizzi consente anche di introdurre
una gerarchia molto articolata, il che facilita notevolmente il compito
di individuare le strade. - introduzione di diverse tipologie di indirizzi,
ognuna delle quali pensata per una specifica funzione; - lo spazio
di indirizzi dovrà avere una dimensione tale da non rischiare futuri
esaurimenti, tenendo conto che una stima di diverse decine di indirizzi
per ogni abitante del pianeta non è irrealistica e che un indirizzamento
gerarchico conduce ad inevitabili sprechi. In accordo a queste considerazioni,
l'indirizzo di IPv6 è una stringa binaria di 128 bits. Gli indirizzi
possibili diventano quindi 2128, con un incremento di un fattore pari
a 296 rispetto a IPv4. Si tratta di un numero difficilmente apprezzabile:
si pensi che con IPv6 sarebbe possibile avere 665*10^21 indirizzi
IP per ogni metro quadro del pianeta (ed anche quest'ultimo numero
risulta non facile da immaginare). Anche se tali indirizzi saranno
assegnati in modo non efficiente, la loro numerosità sembra sufficiente.
IV.4.1.2
Miglioramenti prestazionali
L'intestazione dell'unità di dati di IPv6 si compone di una parte
"base" sempre presente e di una parte opzionale. L'intestazione base
(denominata IPv6 header) ha un numero di campi inferiore a quella
di IPv4. Diverse funzionalità di IPv6 sono realizzate mediante campi
opzionali che vengono aggiunti all'intestazione nella parte, appunto,
opzionale, solo quando sono realmente necessari (questi campi opzionali
sono denominati Extension Headers). Molti di questi campi opzionali
non sono esaminati necessariamente da tutti i nodi attraversati. Questa
scelta semplifica e velocizza il trattamento dei pacchetti di IPv6,
rispetto a IPv4 e ne aumenta la flessibilità, in quanto sarà più semplice
in futuro aggiungere opzioni attualmente non previste. L'intestazione
base di IPv6 ha una lunghezza fissa, contrariamente a IPv4; la frammentazione
dei pacchetti IP (cfr. III.4.2) è eseguita solo alla sorgente e non
più in tutti i router attraversati. Queste caratteristiche semplificano
notevolmente il cosiddetto "critical router loop", ovvero quell'insieme
di funzioni che riguardano il trattamento base dei pacchetti e quindi
tutti quei pacchetti che non hanno richieste particolari, se non quella
di giungere a destinazione (attualmente la gran parte del traffico).
E' questo insieme di funzioni quello che determina in modo significativo
le prestazioni dei router e quindi è opportuno semplificarlo il più
possibile. A titolo di raffronto, l'intestazione tipica di un datagramma
IPv4 è grande 24 bytes, di cui solo 8 sono usati per gli indirizzi
e il resto da campi che non sempre sono necessari. L'intestazione
base di IPv6 è grande 40 bytes di cui 32 sono usati per gli indirizzi.
IV.4.1.3 Supporto della qualità di servizio
IPv6 dovrà consentire di associare ogni pacchetto ad una determinata
classe di servizio. Ogni pacchetto dovrà essere quindi trattato dai
sistemi attraversati in modo da soddisfare i requisiti prestazionali
della classe a cui appartiene, introducendo opportuni politiche di
disciplina di coda e di priorità relative. Un apposito campo dell'intestazione
base di IPv6 (flow label) consente di associare un pacchetto ad un
dato flusso ovvero di identificare tutti i pacchetti che fanno parte
di uno stesso flusso. Tale campo è usato per fornire servizi con una
prefissata qualità di servizio (cfr. IV.3) (unitamente all'indirizzo
IP di sorgente e di destinazione).
IV.4.1.4
Flessibilità nell'indirizzamento
IPv4
definisce due tipologie di indirizzi "unicast" e "multicast". A queste
tipologie IPv6 aggiunge quella di "anycast". Un indirizzo anycast
è un indirizzo di gruppo a cui però risponde il nodo "più vicino"
ad un nodo dato, dove il concetto di vicinanza è espresso in un'opportuna
metrica. Questa tipologia di indirizzi è molto utile per individuare
e quindi interrogare dei servers, siano essi default router, name
servers, time servers, etc e facilita le operazioni di configurazione
dei nodi. IPv6 fornisce anche un meccanismo di indirizzamento unificato
per Internet e per le Intranet, superando alcune soluzioni transitorie
definite per IPv4. Sono previsti indirizzi di tipo globale, locale
e indirizzi che identificano un singolo "link", ovvero un singolo
collegamento (ad es., un circuito diretto numerico, una porta di un
LAN switch, etc.). Gli indirizzi globali sono quelli con significatività
nell'intera Internet, quelli locali sono usati per nodi interni alle
Intranet, mentre quelli di link sono usati dagli operatori per scopi
di gestione e di generale funzionamento dell'Internet. Sono anche
previste classi di indirizzi compatibili con indirizzi IPv4, OSI SNAP
e Novel IPX; queste ultime classi di indirizzo facilitano l'inter-lavoro
di IPv6 con tali paradigmi (si pensa che tale inter-lavoro sarà necessario
solo in un periodo di transizione, dopo il quale tutto il traffico
dovrebbe convergere verso IPv6).
IV.4.1.5
Facilitazione della conversione tra indirizzi IP e indirizzi locali
(ARP)
Si
è detto che il problema di tradurre indirizzi globali IP in indirizzi
locali è risolto in IPv4 o mediante interrogazioni diffusive o mediante
interrogazioni di opportuni servers (cfr. par. III.4.4). Una comunicazione
diffusiva è ricevuta da tutti i sistemi presenti. Ciò causa inefficienza.
IPv6 semplifica questa funzione ricorrendo in alcuni casi ad interrogazioni
di tipo multicast invece che broadcast.
IV.4.1.6
Facilitazione della configurazione dei nodi (plug and play)
La configurazione di un host connesso ad Internet non è oggi banale,
per un utente non esperto. Occorre fornire l'indirizzo IP dell'host
stesso, la maschera di sotto-rete, l'indirizzo del router di default
e del name server. Nel caso di utente connessi ad Internet tramite
un ISP, queste informazioni vengono generalmente fornite dall'ISP
stesso (cfr. fine del III.4.4). Si è anche detto (cfr. III.4.3) che
nel caso di indirizzi IPv4, invece di usare la notazione binaria si
può usare una notazione decimale. La notazione in questione si ottiene
separando i 32 bits in 4 campi di 8 bits ciascuno; questi campi si
esprimono poi in decimale invece che in binario, separandoli con un
punto. Ad esempio l'indirizzo IP di un particolare sistema, espresso
in una stringa di 32 bits e nella relativa notazione decimale è:
10010111 01100100 00001000 00010010 che equivale
a
151.100.8.18
Nel
caso di IPv6 si usa un accorgimento analogo; i 128 bits dell'indirizzo
vengono considerati come 8 numeri interi senza segno, ognuno di 16
bit; ognuno di questi numeri è scritto in esadecimale e separato dal
precedente con il segno ":". Un indirizzo IPv6 espresso in questa
notazione potrebbe essere ad esempio:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
La
notazione esadecimale è sicuramente più semplice rispetto ad una stringa
binaria di 128 bits, ma ciononostante risulta molto complesso e potenzialmente
fonte di errori configurare manualmente dei nodi, usando indirizzi
così lunghi. IPv4 aveva già introdotto dei meccanismi per la configurazione
automatica degli host (e.g., Dynamic Host Configuration Protocol,
DHCP). IPv6 rende ancora più sentita l'esigenza di tali meccanismi
e ne definisce nuove versioni che consentono la configurazione automatica
degli host (anche per ciò che attiene ai loro nomi, tramite un'interazione
con il DNS).
IV.4.1.7 Funzioni di sicurezza
Nell'attuale
Internet, funzioni di sicurezza possono essere implementate su una
base da estremo a estremo (e.g., Secure Socket Layer, SSL), ma la
rete stessa non le fornisce. IPv6 introduce, in rete, sia funzioni
di autenticazione (che accertano l'identità degli utenti) che di crittografia
(che proteggono da ascolti non desiderati). In altri termini, è la
rete a fornire comunicazioni sicure, anche in assenza di appositi
meccanismi implementati nei sistemi terminal.
IV.4.1.8 Supporto della mobilità
Questo tema è trattato in IV.5. Qui accenniamo solo che in IPv4 il
supporto della mobilità è realizzato mediante l'aggiunta di protocolli
ad hoc (Mobile IP). In IPv6 si vorrebbe invece che fosse lo stesso
protocollo IP a fornire, se non in modo completo tale funzionalità,
almeno degli strumenti che facilitino la mobilità di utente.
IV.4.1.9
Transizione da IPv4 a IPv6
Questa
è una delle problematiche più delicate. Più volte nel corso di questa
trattazione si è sottolineato che la cosiddetta "backward compatibility"
è un elemento chiave nel giudicare la bontà di una nuova soluzione
e che molte soluzioni, seppure valide, non hanno avuto successo perché
troppo complessa risultava la migrazione da un protocollo ad un altro.
A titolo di aneddoto, si tenga conto che la rete ARPANET originaria
usava, al posto di IP, un protocollo denominato Network Control Protocol.
Nel 1983 il Dipartimento della Difesa degli Stati Uniti decretò la
sostituzione del Network Control Protocol con TCP/IP mediante una
transizione di tipo "flag day", ovvero contemporanea in tutti i nodi
di rete. I nodi coinvolti erano abbastanza pochi e sicuramente non
paragonabili e quelli dell'Internet attuale, eppure la transizione
fu molto complessa e pose molti problemi. Si pensi a cosa significherebbe
sostituire i protocolli nell'Internet attuale in un solo giorno! Infatti,
anche se si vuole cambiare "solo" la versione del protocollo e non
l'intera filosofia di funzionamento del protocollo stesso, l'entità
delle modifiche, tra le quali soprattutto il piano di indirizzamento,
richiede di pianificare con attenzione il passaggio dalle versione
4 alla 6. In particolare si è prevista non una transizione di tipo
"flag day", ma una transizione di tipo graduale; tale transizione
può essere attuata, ad esempio, mediante un "dual stack" (pila protocollare
duale); alcuni nodi di rete implementeranno contemporaneamente le
due versioni in modo da consentire un transitorio dalla durata di
diversi mesi, se non di anni. In altre parole, alcuni sistemi di rete
cominceranno ad implementare IPv6, insieme a IPv4. Opportune funzionalità
consentiranno la coesistenza delle due versioni e, quando un significativo
numero di sistemi disporrà di IPv6, il software di IPv4 comincerà
ad essere eliminato, finché rimarrà solo IPv6. E' quindi evidente
che uno dei fattori critici di questa migrazione riguarderà le gestione
contemporanea delle due versioni. Un datagramma IPv4 o un pacchetto
IPv6 saranno riconosciuti dai sistemi che li trattano mediante la
lettura del campo Vers (o mediante un apposito campo dell'unità di
dati di strato inferiore, dalla quale sono trasportati, cfr. III.4.1).
Si noti infatti che il campo Vers e' l'unico a conservare la stessa
posizione nel pacchetto IPv6 rispetto a IPv4: cio' consente la discriminazione
dei due protocolli. Le unità dati di ognuna delle due versioni saranno
consegnate al relativo "stack" o pila protocollare. Il punto più complesso
riguarda la gestione degli indirizzi e gli instradamenti: un nodo
con il dual stack userà IPv4 e indirizzi di 32 bits per comunicare
con nodi IPv4, mentre userà IPv6 ed indirizzi di 128 bits per comunicare
con nodi IPv6. Un insieme contiguo di nodi che implementano IPv6 è
denominato isola IPv6. Affinché tale approccio possa funzionare è
necessario che le isole IPv6 (che saranno, almeno nelle fasi iniziali,
appunto "isole" in un"mare" di sistemi IPv4), siano tra loro interconnesse.
Tale interconnessione sarà realizzata, ad esempio, mediante dei "tunnel"
nell'Internet attuale e quindi in IPv4. Cioè, un pacchetto IPv6 sarà
incapsulato all'interno di un datagramma IPv4 e da questi trasportato,
rendendo quindi possibile l'instradamento di tale pacchetto nella
attuale Internet (cfr. IV.5.4, per maggiori particolare circa il concetto
di tunnel). Il numero di isole IPv6 crescerà fino a consentire l'interconnessione
diretta di alcune di esse, senza il bisogno di usare tunnel. Gli host
IPv6 avranno poi la possibilità di comunicare con host IPv4 tramite
un'opportuna classe di indirizzi IPv6, basata sull'inserimento di
un indirizzo IPv4 all'interno di un indirizzo IPv6, in cui sono posti
a zero i primi 128-32=96 bit dell'indirizzo IPv6 (cfr. IV.4.4). Il
numero di sistemi con IPv6 crescerà sempre più, finché i sistemi con
IPv4 perderanno la possibilità di essere connesse direttamente ad
Internet [GAI97]. Nonostante tali accorgimenti la complessità di questa
migrazione è tale che ad oggi il numero di sistemi con IPv6 è ancora
molto limitato ed è costituito per lo più da soluzioni sperimentali.
Recentemente l'IETF si è espressa raccomandando con forza la transizione
ad IPv6, sottolineando che: - lo spazio di indirizzi di IPv4 si sta
esaurendo ad un velocità superiore a quella sinora prevista - secondo
molte previsioni è probabile che nel 2010 tutto il traffico mondiale
sia "pacchettizzato" e che usi come protocollo di rete IP, incluso
il traffico delle attuali reti telefoniche (previsione forse ottimistica
per IP) - il bisogno di servizi con requisiti di tempo reale è sempre
più sentito. Dopo aver introdotto le caratteristiche generali di IPv6,
ne descriviamo ora le principali modalità operative.
IV.4.2
Terminologia
La
terminologia utilizzata da IPv6 differisce, in parte, da quella relativa
a IPv4. E' opportuno quindi riportare alcune definizioni, anche perché
contengono delle sfumature indicative del diverso approccio seguito
da IPv6 rispetto a IPv4. § un "Nodo" è ogni dispositivo che implementa
IPv6; § un "Router" è ogni Nodo che inoltra pacchetti IPv6 non esplicitamente
indirizzati ad uno dei suoi indirizzi IPv6; § un "Host" è ogni Nodo
che non è un Router; § si definisce "Strato Superiore" (in inglese
"upper layer") uno strato protocollare immediatamente sopra IPv6,
ad esempio i protocolli di trasporto TCP e UDP, i protocolli di controllo
come ICMP, i protocolli di instradamento come OSPF e tutti i protocolli
(sia Internet che di strato inferiore) che vengono inviati attraverso
"Tunnel" protocollari (ovvero incapsulati in IPv6) ad esempio: IPX,
AppleTalk o lo stesso IPv6; § si definisce "Link" un mezzo di comunicazione
usato da un Nodo per trasferire informazione; il relativo strato protocollare
è quello di link, ovvero lo strato immediatamente sottostante IPv6.
Esempi di link sono: reti Ethernet, collegamenti PPP, X.25, Frame
Relay, o reti ATM., ma anche dei collegamenti basati su tunnel attraverso
IPv6 o IPv4; § si definiscono "Vicini" (Neighbor) i nodi connessi
allo stesso link; § si definisce "Interfaccia" il punto di connessione
di un Nodo ad un link; § si definisce "Indirizzo" un identificatore
di strato IPv6 di una interfaccia o di un insieme di interfacce; §
si definisce IPv6 header, la parte base dell'intestazione, sempre
presente in un pacchetto; § si definisce Extension Header una parte
addizionale dell'intestazione, presente solo opzionalmente e dedicata
a specifiche funzioni.
IV.4.3
Formato dell'unità di dati
Il
pacchetto IPv6 è progettato in modo da essere analizzato e processato
il più velocemente possibile dai Router IPv6. A tal fine ed a differenza
dei datagrammi IPv4 che hanno un header di lunghezza variabile, in
IPv6 l'header è stata suddiviso in due parti, una di lunghezza fissa
che contiene lo "stretto necessario" ed una di lunghezza variabile
(eventualmente anche assente) contenente ulteriori informazioni.
[...]
Il
significato e la dimensione dei campi sono i seguenti:
Versione
(4 bits): Contiene il valore 6, per distinguere i pacchetti che usano
il protocollo IPv6 da quelli IPv4. Tale distinzione è pero tipicamente
attuata mediante un opportuno identificatore dell'unità di dati dello
strato inferiore che trasporta il pacchetto.
Priorità
(4 bits): Consente ad una sorgente di associare ai pacchetti emessi
un codice che rappresenta la classe di servizio e la priorità relativa
del pacchetto all'interno della classe. Al momento sono definiti due
gruppi di classi di servizio: con controllo di congestione, come ad
esempio il traffico TCP, e senza controllo di congestione, ad esempio
traffico UDP. All'interno di ciascuna classe di servizio sono poi
definiti diversi livelli relativi di priorità,; tali livelli di priorità
servono a classificare il traffico; questa informazione potrà poi
essere utilizzata dai Router per ottimizzare il trasporto dei pacchetti
(e per prendere opportune decisioni riguardo alle modalità con cui
servire i pacchetti, soprattutto in caso di congestione).
Flow
label (24 bits): Quando questo campo è diverso da zero identifica,
insieme al campo Source Address, un flusso. Il protocollo IPv6 non
da istruzioni specifiche riguardo a come comportarsi in base all'etichetta
di un pacchetto: è compito di altri protocolli gestire questo campo
e coordinarne l'utilizzo tra i vari Router. Anche la scelta delle
etichette da associare ai flussi (operazione eseguita dalla sorgente)
può essere fatta in accordo ad apposite regole. Tutti i pacchetti
associati allo stesso flusso dovranno avere caratteristiche comuni
in modo tale che i Router non abbiano bisogno di processare ogni volta
l'intera intestazione del pacchetto prima di prendere delle decisioni,
ma possano applicare direttamente le decisioni già prese per gli altri
pacchetti appartenenti allo stesso flusso (cfr. IV.3).
Lunghezza del Payload (16 bits): Rappresenta la lunghezza del payload,
in ottetti
Next
Header (8 bits): Indica o il tipo dell'Extension Header successivo,
se ne esiste uno, oppure il protocollo di strato superiore a cui il
pacchetto deve essere consegnato. È stato anche definito un valore
speciale (59) per rappresentare la mancanza di un ulteriore Extension
Header. E' una generalizzazione del campo Protocol di IPv4.
Hop
limit (8 bits): il campo Time To Live (TTL) di IPv4 è stato ribattezzato
Hop Limit; ricordiamo che in IPv4 la specifica iniziale del campo
Time to Live indicava quanto tempo un datagramma può rimanere all'interno
della inter-rete. Quando un host genera un datagramma, inizializza
questo campo con il valore del tempo concesso al datagramma stesso
per attraversare l'inter?rete. Questo valore viene decrementato da
ogni router incontrato nel cammino percorso dal datagramma. Quando
il valore di questo campo sarà nullo, il relativo datagramma verrà
scartato. Questa tecnica impedisce ad un datagramma di viaggiare indefinitamente
nella rete, se, a causa di errori, il suo instradamento risultasse
in un cammino chiuso o, in ogni caso, di evitare tempi di trasferimento
eccessivamente lunghi. Già in IPv4, però, il valore di questo campo
è attualmente definito non in secondi ma in "salti" (hops). Per salto
si intende l'attraversamento di un router e quindi un datagramma può
attraversare al massimo 256 routers prima di essere scartato. In IPv6
si adotta lo stesso approccio.
Source
address (128 bits)
Destinat.
Address (128 bits): Questi due campi, contengono gli indirizzi IPv6
della sorgente e del destinatario. Come già sottolineato, questi indirizzi
non identificano un sistema finale (un host o un Router), ma sono
assegnati a delle interfacce di rete. Ciascuna interfaccia può avere
più di un indirizzo "unicast", ma ogni indirizzo "unicast" è associato
ad un solo Nodo (ovviamente la corrispondenza, anche se non biunivoca,
è necessaria al fine di far arrivare i pacchetti al destinatario)
Veniamo
ora agli Extension Header. Questi campi costituiscono una delle principali
innovazioni nel formato dell'unità di dati di IPv6 e consentono di
gestire le funzionalità di rete più avanzate (dall'instradamento alla
privacy); inoltre aggiungono flessibilità al protocollo, in quanto
risulta semplice definire nuove funzionalità aggiungendo un Extension
Header che lascia immutato il resto del protocollo. Un altro aspetto
importante è che ciascun Extension Header può essere rintracciato
rapidamente (e quindi processato in modo indipendente dagli altri),
grazie al campo Next Header. Si noti che sia l'intestazione base di
IPv6 (IPv6 Header), che ogni Extension Header dispongono di un campo
Next Header, che identifica appunto l'Extension Header successivo.
L'unico Header sempre presente è quello base (IPv6 Header); se a questo
non ne seguono altri, il campo Next Header contiene tipicamente l'identificativo
del protocollo di strato superiore a cui il pacchetto deve essere
consegnato (informazione analoga al campo "Protocol" di IPv4). Viceversa,
se all'Header base seguono degli Extension Header, il campo Next Header
contiene un identificativo del prossimo Extension Header. Il processo
si ripete per ogni Extension Header presente fino all'ultimo, che
riporta l'identificativo del protocollo di strato superiore a cui
il pacchetto deve essere consegnato. Si noti che tutti gli Extension
Header sono inseriti dalla sorgente e possono essere solo modificati
ma non eliminati dai router intermedi.
Gli
Extension Header sinora definiti sono i seguenti:
Hop-by-Hop
options Header: Definisce delle opzioni che, se presenti, vanno processate
da ogni Router attraversato dal pacchetto. Questa estensione è progettata
in modo tale da funzionare come "punto di inserimento" di istruzioni
da processare in ogni Router, quindi deve fornire anche informazioni
su come il Router si deve comportare se non è in grado di gestire
l'istruzione trasportata e deve inoltre poter specificare se durante
il percorso le informazioni contenute nell'estensione possono cambiare.
In questo caso è necessario escludere la verifica di questo campo
dai sistemi di protezione e sicurezza, gestiti da estremo ad estremo.
Routing
Header: svolge una funzione simile a quella della Source Route Option
di IPv4. Contiene una lista di uno o più nodi intermedi attraverso
i quali si vuole che transiti il pacchetto; è caratterizzato anche
da un campo che indica la lunghezza dell'Extension Header stesso,
da un campo che ne specifica il tipo ed infine da un campo che indica
il numero di nodi presenti nella lista, ma che devono ancora essere
visitati. L'informazione relativa al tipo di Routing Header è importante;
finora è stato standardizzato il tipo 0. Usando questo tipo di Routing
Header, l'indirizzo di destinazione non viene posto nel campo Destination
Address dei pacchetti IPv6; al contrario in quest'ultimo campo viene
posto l'indirizzo del prossimo Router elencato nel Routing Header,
mentre l'indirizzo di destinazione viene posto come ultimo indirizzo
della lista nel Routing Header. La lista non viene consultata finché
il pacchetto non raggiunge la sua prima destinazione, a quel punto
si consulta la lista per verificare se si è giunti a destinazione,
in caso negativo si modifica di nuovo il campo Destination Address
e si aggiorna il numero di nodi che devono ancora essere visitati.
Questo modo di procedere consente un aumento di efficienza rispetto
all'esaminare il Routing Header sempre, ad ogni "salto".
Fragment
Header: Contiene informazioni per la frammentazione e la ri-aggregazione
delle unità informative. È importante sottolineare che in IPv6 tutte
le funzioni di segmentazione e di riaggregazione sono effettuate da
estremo a estremo (source e dest) e non coinvolgono i Router intermedi,
che in questo modo non si devono preoccupare di processare il contenuto
dei pacchetti, risparmiando capacità elaborative. Questo metodo di
gestione della segmentazione comporta ovviamente che i nodi agli estremi
conoscano, o almeno abbiano a disposizione dei mezzi per scoprire,
la minima MTU supportata dal collegamento.
Encapsulating Security Payload Header: Questo è uno degli Extension
Header che consentono di gestire le questioni legate alla sicurezza.
In IPv6 tali questioni sono state tenute in considerazione come specifiche
dello strato di rete (IP). In questo modo è possibile fornire un elevato
grado di sicurezza anche alle applicazioni che ignorano tali problematiche.
Le questioni legate alla sicurezza possono essere affrontate da due
punti di vista: quello della autenticazione ("Authentication") e quello
della sicurezza. Nel primo caso, si vuole accertare l'identità di
chi origina i pacchetti e la non manomissione da parte di terzi degli
stessi; nel secondo si vuole proteggere l'informazione trasmessa da
ascolti non desiderati (privacy). L'Header ESP si occupa di quest'ultima
funzionalità.
Authentication
Header: svolge le funzioni di autenticazione accennate nel punto precedente
Destination
Options Header: Contiene informazioni che possono essere esaminate
solo dai nodi di destinazione (che possono essere sia il solo destinatario,
che i Router esplicitamente inclusi nel Routing Header). Il formato
utilizzato per questo Header è lo stesso che si usa per l'hop-by-hop
options Header. Le "destination options" sono di fondamentale importanza
per gestire in modo agile i protocolli end-to-end; infatti, inserendo
i messaggi di controllo di questi protocolli direttamente in una destination
option è possibile evitare l'invio di un pacchetto di controllo ad
hoc e separato, aumentando così l'efficienza del collegamento.
Gli Extension Headers devono essere inseriti nel seguente ordine,
all'interno del pacchetto:
IPv6
Header: È la parte obbligatoria di ciascun pacchetto IPv6, come descritto
qui sopra. Viene ovviamente posta al primo posto in modo da velocizzare
le operazioni di instradamento in tutti quei casi in cui i Router
non devono compiere nessuna modifica, né alcun tipo di processamento
sulla restante parte del pacchetto IPv6.
Hop-by-Hop
options Header: Questa parte opzionale della PCI, trasporta delle
informazioni che, se presenti, devono essere esaminate da ogni Router
che processa il pacchetto. È quindi importante che tali informazioni
siano posizionate all'inizio del pacchetto IP.
Destination
options Header 1: Contiene le sole opzioni che devono essere processate
dal primo Router e da tutti i Routers elencati nel Routing Header.
Viene posto prima dell'elenco dei nodi da attraversare (contenuto
nel Routing Header) in modo da avere tempo per iniziare a processare
le opzioni mentre si riceve il resto del pacchetto.
Routing
Header: Viene inserito appositamente dopo le destination options in
modo da segnalare quali nodi devono esaminare quest'ultime
Fragment
Header: E' gestito da estremo a estremo (vedi sopra); viene quindi
posto nella parte finale dell'intestazione del pacchetto, dovendo
essere analizzato solo alla destinazione finale
Authentication Header: Consente alla rete di autenticare l'intero
pacchetto IP; essendo anche questo elemento gestito da estremo ad
estremo, non può essere usato per autenticare quei campi che possono
essere modificati durante il percorso.
Encapsulating
security payload Header: E' utilizzato al fine di proteggere il pacchetto
IP dal punto di vista della sicurezza (intesa come privacy), può agire
sia su tutto il pacchetto che sul solo payload e fornire sia riservatezza
che una verifica dell'integrità informativa.
Destination
options Header 2: Contiene le opzioni che non devono essere processate
dai Routers intermedi ma solamente dalla destinazione finale.
La
seguente figura (Fig. 45) mostra degli esempi di pacchetti IPv6. Nel
primo esempio è presente solo l'IPv6 header, che punta al protocollo
TCP, ovvero comunica che il contenuto del payload del pacchetto deve
essere consegnato a tale protocollo di strato superiore. Negli altri
due esempi sono presenti degli Extension Header e l'intestazione globale
del pacchetto è sempre conclusa con l'indicazione del protocollo TCP,
come destinatario del payload.
[...]
IV.4.4
Schema di indirizzamento
Gli
indirizzi IPv6 sono lunghi 128 bit; tale dimensionalità lascia una
grande libertà nella gestione della numerazione. Nell'allocazione
degli indirizzi IPv6 sono state tenute in considerazione anche le
necessità relative all'integrazione con diversi tipi di rete già esistenti
ed il supporto per diversi tipi di indirizzi. Sono definite tre principali
tipologie di indirizzi: unicast, anycast e multicast; il loro significato
è stato brevemente accennato in precedenza. E' stato anche detto che
la maggiore dimensionalità dello spazio di indirizzi consente di introdurre
una gerarchia più articolata di quella relativa a IPv4 e quindi di
facilitare le operazioni di instradamento. Un generico indirizzo IPv6
è quindi diviso in campi. Il primo campo è un prefisso di dimensione
variabile, il cui significato è mostrato nella Tab. 13. Tale tabella
mostra anche i possibili valori dei prefissi e la corrispondente frazione
dello spazio totale dedicato ad indirizzi che iniziano con un certo
prefisso.
Prefisso - Frazione dello spazio di indirizzamento - Allocazione
0000
0000 1/256 Riservato
0000 0001
1/256 Non assegnato
0000 001 1/128 Nsap
0000 010
1/128 Ipx
0000 011
1/128 Non assegnato
0000 1 1/32
Non assegnato
0001 1/16 Non assegnato
001 1/8
Non assegnato
010 1/8 Indirizzi Unicast basati sul provider
011 1/8
Non assegnato
100 1/8 Riservato per indirizzi Unicast su base geografica
101 1/8 Non assegnato
110 1/8 Non assegnato
1110 1/16 Non assegnato
1111 0 1/32 Non assegnato
1111 10 1/64 Non assegnato
1111 110 1/128 Non assegnato
1111 1110 0 1/512 Non assegnato
1111 1110 10 1/1024 Indirizzi per uso Locale al link
1111 1110 11 1/1024 Indirizzi per uso Locale al sito
1111 1111 1/256 Indirizzi Multicast
Gli
indirizzi il cui prefisso è costituito dal valore 1111 1111 sono indirizzi
di tipo multicast. Un indirizzo multicast identifica un insieme di
interfacce. Un pacchetto indirizzato ad un indirizzo multicast viene
consegnato a tutti i nodi facenti parte di tale insieme, ovvero a
tutti i membri di un "gruppo multicast". Oltre alla tipica funzione
di comunicazione per servizi di utente punto-multipunto (già definita
in IPv4), in IPv6 gli indirizzi Multicast sostituiscono quelli "broadcast"
in alcuni funzionalità gestionali. Si è detto che in IPv4 si usano
comunicazioni diffusive (ovvero broadcast) per alcune funzionalità
di rete (ad es. risoluzione di indirizzi, ARP) è che tale modalità
genera inefficienze in quanto una comunicazione diffusiva è ricevuta
da tutti i sistemi presenti, anche da quelli che non sono potenzialmente
interessati. IPv6 semplifica questa funzione ricorrendo ad interrogazioni
di tipo multicast invece che broadcast. In tal modo le interrogazioni
sono ricevute solo dall'insieme di nodi che hanno effettivamente necessità
di riceverle e che si sono registrati a tal fine. Inoltre, se esiste
la necessità di comunicare informazioni a tutti i nodi presenti su
un dato link o in una data sotto-rete, IPv6 può definire un indirizzo
multicast che consente di raggiungere tutti i nodi presenti su quel
link o su quella sottorete. Gli indirizzi che iniziano con un prefisso
diverso da 1111 1111 sono invece di tipo unicast o anycast. Un indirizzo
di tipo Unicast identifica una interfaccia di un Nodo. Sono stati
definiti diversi tipi di indirizzi Unicast: § indirizzi "basati" sul
provider: sono assegnati in base al provider a cui un nodo fa riferimento;
sono indirizzi con significatività globale. Dopo il prefisso sono
presenti cinque diversi campi:
-
Registry ID: identifica l'autorità di registrazione che attribuisce
il campo Provider ID dell'indirizzo ad uno specifico Provider - Provider
ID: identifica uno specifico provider che attribuisce poi il campo
Subscriber ID dell'indirizzo
-
Subscriber ID: identifica un utente del provider descritto dal campo
Provider ID
-
Subnet ID: identifica un insieme contiguo di nodi dell'utente descritto
dal campo Subscriber ID
-
Interface ID: identifica una singola interfaccia di nodo appartenente
all'insieme contiguo di nodi descritto dal campo Subnet ID.
§ indirizzi Unicast su base geografica: sono assegnati all'utente
in base alla sua posizione geografica, al momento non sono stati definiti
in dettaglio.
§
indirizzi locali al link: hanno significatività locale e non possono
essere integrati nello schema di indirizzamento globale; vengono quindi
usati per comunicare all'interno di un link o di una sottorete, tipicamente
per fini di auto-configurazione e di ricerca di nodi vicini (neighbor
discovery)
§ indirizzi locali al sito: hanno significatività locale e non possono
essere integrati nello schema di indirizzamento globale; vengono quindi
usati solo per comunicare all'interno di un determinato dominio; rispetto
ai precedenti hanno però il vantaggio che, previa solo la sostituzione
di opportuni prefissi (introducendo ad esempio la gerarchia dei prefissi
"basati" sul provider) possono acquisire significatività globale.
Questi indirizzi sono quindi indicati per dei nodi di un'organizzazione
che, in una prima fase, non sono connessi alla Internet globale ma
che in prospettiva intendono esserlo. Altri indirizzi Unicast hanno
il prefisso 0000 0000 (designato come "riservato" e da non confondere
con la dizione "non assegnato"). Tali indirizzi includono le seguenti
tipologie:
§
indirizzi IPv6 compatibili IPv4: sono indirizzi pensati appositamente
per gestire la lunga transizione tra IPv4 ed IPv6 e sono costituiti
da 96 zeri seguiti dai 32 bit dell'indirizzo IPv4. In questo modo
è molto semplice utilizzare dei tunnel in IPv4: l'indirizzo IPv4 di
uscita del tunnel può essere dedotto dall'indirizzo IPV6.
§
indirizzo loopback: questo indirizzo (0:0:0:0:0:0:0:1) viene utilizzato
dal Nodo IPv6 per inviare pacchetti a se stesso (per scopi gestionali,
i.e., di prova); pacchetti con questo indirizzo non devono mai essere
inviati al di fuori dal singolo Nodo.
§
Indirizzo non specificato (0:0:0:0:0:0:0:0): indica l'assenza di un
indirizzo, non deve mai essere assegnato ad un interfaccia e può essere
usato come indirizzo mittente di un nodo in fase di auto-configurazione.
Sono anche previste classi di indirizzi pensati per facilitare l'inter-lavoro
con indirizzi ISO/OSI NSAP (Network Service Access Point) (con prefisso
0000 001) e Novel IPX (con prefisso 0000 010); tali indirizzi sono
derivati da quelli NSAP o IPX in modo analogo a quanto appena descritto
con riferimento agli indirizzi IPv4. Un indirizzo anycast è un indirizzo
di gruppo a cui però risponde solo il nodo "più vicino" ad un nodo
dato, dove il concetto di vicinanza è espresso in un'opportuna metrica.
Un indirizzo di tipo Anycast identifica quindi un insieme di interfacce
tra loro alternative (i pacchetti sono però inviati solo ad una di
queste interfacce). Gli indirizzi Anycast sono scelti all'interno
dello stesso spazio di indirizzi scelto per gli indirizzi unicast,
è compito dei Router non solo sapere che ad un determinato indirizzo
anycast corrisponde un certo insieme di indirizzi unicast, ma anche
di scegliere, secondo la metrica prescelta, il più "vicino". Gli indirizzi
con la dizione "non assegnato" in Tab. 13, non sono ancora stati definiti.
In conclusione, sottolineiamo solo che la gerarchia appena discussa,
ed in particolare quella relativa agli indirizzi basati sul provider
e quelli assegnati su base geografica, consentono, grazie alla presenza
di diversi livelli gerarchici, di facilitare significativamente le
operazioni di instradamento.
Clicca
qui per ottenere la copia integrale di queste dispense in formato
.pdf
|
