1 \chapter{Il protocollo IP}
2 \label{cha:ip_protocol}
5 L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981
6 dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura
7 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
8 dei dati indipendente dal sottostante substrato di rete, che pu\`o essere
9 realizzato con le tecnologie pi\`u disparate (Ethernet, Token Ring, FDDI,
13 \section{Introduzione}
14 \label{sec:appA_intro}
16 Il compito di IP \`e pertanto quello di trasmettere i pacchetti da un computer
17 all'altro della rete; le caratteristiche essenziali con cui questo viene
18 realizzato in IPv4 sono due:
21 \item \textit{Universal addressing} la comunicazione avviene fra due host
22 identificati univocamente con un indirizzo a 32 bit che pu\`o appartenere ad
23 una sola interfaccia di rete.
24 \item \textit{Best effort} viene assicurato il massimo impegno nella
25 trasmissione, ma non c'\`e nessuna garanzia per i livelli superiori n\'e
26 sulla percentuale di successo n\'e sul tempo di consegna dei pacchetti di
30 Per effettuare la comunicazione e l'instradamento dei pacchetti fra le varie
31 reti di cui \`e composta Internet IPv4 organizza gli indirizzi in una
32 gerarchia a due livelli, in cui una parte dei 32 bit dell'indirizzo indica il
33 numero di rete, e un'altra l'host al suo interno. Il numero di rete serve
34 ai router per stabilire a quale rete il pacchetto deve essere inviato, il
35 numero di host indica la macchina di destinazione finale all'interno di detta
38 Per garantire l'unicit\`a dell'indirizzo Internet esiste un'autorit\`a
39 centrale (la IANA, \textit{Internet Assigned Number Authority}) che assegna i
40 numeri di rete alle organizzazioni che ne fanno richiesta; \`e poi compito di
41 quest'ultime assegnare i numeri dei singoli host.
43 Per venire incontro alle diverse esigenze gli indirizzi di rete sono stati
44 originariamente organizzati in \textit{classi}, (rappresentate in
45 Tab.~\ref{tab:ipv4class}), per consentire dispiegamenti di reti di dimensioni
52 \begin{tabular} {c@{\hspace{1mm}\vrule}
53 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
54 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
55 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
56 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
57 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
58 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
59 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
60 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}}
61 \omit&\omit& \multicolumn{7}{c}{7 bit}&\multicolumn{24}{c}{24 bit} \\
63 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
64 classe A &\centering 0&
65 \multicolumn{7}{@{}c@{\vrule}}{\parbox[c]{21mm}{\centering net Id}} &
66 \multicolumn{24}{@{}c@{\vrule}}{\parbox[c]{72mm}{\centering host Id}} \\
67 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
69 \multicolumn{33}{c}{ } \\
71 \multicolumn{14}{c}{14 bit}&\multicolumn{16}{c}{16 bit} \\
73 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
74 classe B&\centering 1&\centering 0&
75 \multicolumn{14}{@{}c@{\vrule}}{\parbox{42mm}{\centering net Id}} &
76 \multicolumn{16}{@{}c@{\vrule}}{\parbox{48mm}{\centering host Id}} \\
77 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
80 \multicolumn{33}{c}{ } \\
82 \multicolumn{21}{c}{21 bit}&\multicolumn{8}{c}{8 bit} \\
84 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
85 classe C&\centering 1&\centering 1&\centering 0&
86 \multicolumn{21}{@{}c@{\vrule}}{\parbox{63mm}{\centering net Id}} &
87 \multicolumn{8}{@{}c@{\vrule}}{\parbox{24mm}{\centering host Id}} \\
88 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
92 \multicolumn{33}{c}{ } \\
93 \omit&\omit&\omit&\omit&
94 \multicolumn{28}{c}{28 bit} \\
96 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
97 classe D&\centering 1&\centering 1&\centering 1&\centering 0&
98 \multicolumn{28}{@{}c@{\vrule}}{\parbox{63mm}{\centering
99 multicast group Id}} \\
100 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
103 \multicolumn{33}{c}{ } \\
104 \omit&\omit&\omit&\omit&\omit&
105 \multicolumn{27}{c}{27 bit} \\
107 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
108 classe E&\centering 1&\centering 1&\centering 1&\centering 1&\centering 0&
109 \multicolumn{27}{@{}c@{\vrule}}{\parbox{59mm}{\centering
110 reserved for future use}} \\
111 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
115 \caption{Le classi di indirizzi secondo IPv4.}
116 \label{tab:ipv4class}
119 Le classi usate per il dispiegamento delle reti sono le prime tre; la classe D
120 \`e destinata al (non molto usato) \textit{multicast} mentre la classe E \`e
121 riservata per usi sperimentali e non viene impiegata.
123 Come si pu\`o notare per\`o la suddivisione riportata in
124 Tab.~\ref{tab:ipv4class} \`e largamente inefficiente in quanto se ad un utente
125 necessita anche solo un indirizzo in pi\`u dei 256 disponibili con una classe
126 A occorre passare a una classe B, con un conseguente spreco di numeri.
128 Inoltre, in particolare per le reti di classe C, la presenza di tanti
129 indirizzi di rete diversi comporta una crescita enorme delle tabelle di
130 instradamento che ciascun router dovrebbe tenere in memoria per sapere dove
131 inviare il pacchetto, con conseguente crescita dei tempi di processo da parte
132 di questi ultimi ed inefficienza nel trasporto.
137 \begin{tabular} {c@{\hspace{1mm}\vrule}
138 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
139 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
140 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
141 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
142 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
143 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
144 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
145 p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}}
147 \multicolumn{12}{c}{$n$ bit}&\multicolumn{20}{c}{$32-n$ bit} \\
149 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
151 \multicolumn{12}{@{}c@{\vrule}}{\parbox[c]{36mm}{\centering net Id}} &
152 \multicolumn{20}{@{}c@{\vrule}}{\parbox[c]{60mm}{\centering host Id}} \\
153 \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
156 \caption{Uno esempio di indirizzamento CIDR.}
160 Per questo nel 1992 \`e stato introdotto un indirizzamento senza classi (il
161 CIDR) in cui il limite fra i bit destinati a indicare il numero di rete e
162 quello destinati a indicare l'host finale pu\`o essere piazzato in qualunque
163 punto (vedi Tab.~\ref{tab:ipv4cidr}), permettendo di accorpare pi\`u classi A
164 su un'unica rete o suddividere una classe B e diminuendo al contempo il
165 numero di indirizzi di rete da inserire nelle tabelle di instradamento dei
169 \section{I motivi della transizione}
172 Negli ultimi anni la crescita vertiginosa del numero di macchine connesse a
173 internet ha iniziato a far emergere i vari limiti di IPv4; in particolare si
174 \`e iniziata a delineare la possibilit\`a di arrivare a una carenza di
175 indirizzi disponibili.
177 In realt\`a il problema non \`e propriamente legato al numero di indirizzi
178 disponibili; infatti con 32 bit si hanno $2^{32}$, cio\`e circa 4 miliardi,
179 numeri diversi possibili, che sono molti di pi\`u dei computer attualemente
182 Il punto \`e che la suddivisione di questi numeri nei due livelli rete/host e
183 l'utilizzo delle classi di indirizzamento mostrate in precedenza, ha
184 comportato che, nella sua evoluzione storica, il dispiegamento delle reti e
185 l'allocazione degli indirizzi siano stati inefficienti; neanche l'uso del CIDR
186 ha permesso di eliminare le inefficienze che si erano formate, dato che il
187 ridispiegamento degli indirizzi comporta cambiamenti complessi a tutti i
188 livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni
191 Diventava perci\`o necessario progettare un nuovo protocollo che permettesse
192 di risolvere questi problemi, e garantisse flessibilit\`a sufficiente per
193 poter continuare a funzionare a lungo termine; in particolare necessitava un
194 nuovo schema di indirizzamento che potesse rispondere alle seguenti
198 \item un maggior numero di numeri disponibili che consentisse di non restare
199 pi\`u a corto di indirizzi
200 \item un'organizzazione gerarchica pi\`u flessibile dell'attuale
201 \item uno schema di assegnazione degli indirizzi in grado di minimizzare le
202 dimensioni delle tabelle di instradamento
203 \item uno spazio di indirizzi che consentisse un passaggio automatico dalle
204 reti locali a internet
208 \section{Principali caratteristiche di IPv6}
211 Per rispondere alle esigenze descritte in Sez.~\ref{sec:whyipv6} IPv6 nasce
212 come evoluzione di IPv4, mantendone inalterate le funzioni che si sono
213 dimostrate valide, eliminando quelle inutili e aggiungendone poche altre
214 ponendo al contempo una grande attenzione a mantenere il protocollo il pi\`u
215 snello e veloce possibile.
217 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
218 grandi linee nei seguenti punti:
220 \item l'espansione delle capacit\`a di indirizzamento e instradamento, per
221 supportare una gerarchia con pi\`u livelli di indirizzamento, un numero di
222 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
223 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
224 si aggiungono agli usuali \textit{unycast} e \textit{multicast}
225 \item la semplificazione del formato della testata, eliminando o rendendo
226 opzionali alcuni dei campi di IPv4, per eliminare la necessit\`a di
227 riprocessamento della stessa da parte dei router e contenere l'aumento di
228 dimensione dovuto ai nuovi indirizzi
229 \item un supporto per le opzioni migliorato, per garantire una trasmissione
230 pi\`u efficiente del traffico normale, limiti meno stringenti sulle
231 dimensioni delle opzioni, e la flessibilit\`a necessaria per introdurne di
233 \item il supporto per delle capacit\`a di qualit\`a di servizio (QoS) che
234 permetta di identificare gruppi di dati per i quali si pu\`o provvedere un
235 trattamento speciale (in vista dell'uso di internet per applicazioni
236 multimediali e/o ``real-time'')
240 \section{La testata di IPv6}
243 Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
244 protocollo per gestire la trasmissione dei pacchetti; in
245 Tab.~\ref{tab:ipv6head} \`e riportato il formato della testata di IPv6 da
246 confrontare con quella di IPv4 in Tab.~\ref{tab:ipv4head}. la spiegazione del
247 significato dei vari campi delle due testate \`e riportato rispettivamente in
248 Tab.~\ref{tab:ipv6field} e Tab.~\ref{tab:ipv4field})
253 \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
254 @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
255 @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
256 \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
258 \centering version&\centering priority&
259 \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
261 \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload lenght} &
262 \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} &
263 \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
265 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
266 \multicolumn{8}{@{\vrule}c@{\vrule}}{
268 \multicolumn{8}{@{\vrule}c@{\vrule}}{
270 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
272 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
273 \multicolumn{8}{@{\vrule}c@{\vrule}}{
275 \multicolumn{8}{@{\vrule}c@{\vrule}}{
277 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
280 \caption{La testata o \textit{header} di IPv6}
285 Come si pu\`o notare la testata di IPv6 diventa di dimensione fissa, pari a 40
286 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
287 IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia
288 quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il
289 numero dei campi da 12 a 8.
294 \begin{tabular}{ l c p{8cm}}
295 \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
297 \textit{version} & 4 bit &
298 \textsl{versione}, nel caso specifico vale sempre 6\\
299 \textit{priority} & 4 bit &
300 \textsl{priorit\`a}, vedi Sez.~\ref{sec:prio} \\
301 \textit{flow label} & 24 bit &
302 \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:flow}\\
303 \textit{payload leght} & 16 bit &
304 \textsl{lunghezza del carico}, cio\`e del corpo dei dati che segue
305 l'intestazione, in bytes. \\
306 \textit{next header} & 8 bit & \textsl{testata successiva},
307 identifica il tipo di pacchetto che segue la testata di IPv6, usa gli
308 stessi valori del campo protocollo nella testata di IPv4\\
309 \textit{hop limit} & 8 bit & \textsl{limite di salti},
310 stesso significato del \textit{time to live} nella testata di IPv4,
311 \`e decrementato di uno ogni volta che un nodo ritrasmette il
312 pacchetto, se arriva a zero il pacchetto viene scartato \\
313 \textit{source IP} & 128 bit & \textsl{indirizzo di origine} \\
314 \textit{destination IP}& 128 bit & \textsl{indirizzo di destinazione}\\
317 \caption{Legenda per il significato dei campi dell'intestazione di IPv6}
318 \label{tab:ipv6field}
322 Abbiamo gi\`a anticipato in Sez.~\ref{sec:ipv6over} uno dei criteri principali
323 nella progettazione di IPv6 \`e stato quello di ridurre al massimo il tempo di
324 processamento dei pacchetti da parte dei router, un confronto con la testata
325 di IPv4 (vedi Tab.~\ref{tab:ipv4head}) mostra le seguenti differenze:
328 \item \`e stato eliminato il campo \textit{header lenght} in quanto le opzioni
329 sono state tolte dalla testata che ha cos\`\i\ dimensione fissa; ci possono
330 essere pi\`u testate opzionali (\textsl{testate di estensione}, vedi
331 Sez.~\ref{sec:extens}), ciascuna dell quali avr\`a un suo campo di lunghezza
333 \item la testata e gli indirizzi sono allineati a 64 bit, questo rende pi\`u
334 veloce il processo da parte di computer con processori a 64 bit.
335 \item i campi per gestire la frammentazione (\textit{identification},
336 \textit{flag} e \textit{fragment offset}) sono stati eliminati; questo
337 perch\'e la frammentazione \'e un'eccezione che non deve rallentare il
338 processo dei pacchetti nel caso normale.
339 \item \`e stato eliminato il campo \textit{checksum} in quanto tutti i
340 protocolli di livello superiore (TCP, UDP e ICMPv6) hanno un campo di
341 checksum che include, oltre alla loro testata e ai dati, pure i campi
342 \textit{payload lenght}, \textit{next header}, e gli indirizzi di origine e
343 di destinazione; una checksum esiste anche per la gran parte protocolli di
344 livello inferiore (anche se quelli che non lo hanno, come SLIP, non possono
345 essere usati con grande affidabilit\`a); con questa scelta si \`e ridotto di
346 molti tempo di riprocessamento dato che i router non hanno pi\'u la
347 necessit\`a di ricalcolare la checksum ad ogni passaggio di un pacchetto per
348 il cambiamento del campo \textit{hop limit}.
349 \item \`e stato eliminato il campo \textit{type of service}, che praticamente
350 non \`e mai stato utilizzato; una parte delle funzionali\`a ad esso delegate
351 sono state reimplementate (vedi il campo \textit{priority} al prossimo
352 punto) con altri metodi.
353 \item \`e stato introdotto un nuovo campo \textit{flow label}, che viene
354 usato, insieme al campo \textit{priority} (che recupera i bit di
355 precedenza del campo \textit{type of service}) per implementare la gestione
356 di una ``qualit\`a di servizio'' (vedi Sez.~\ref{sec:qos}) che permette di
357 identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si
358 pu\`o provvedere un trattamento speciale.
364 \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
365 @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
366 @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
367 \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
370 \centering head lenght&
371 \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &
372 \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total lenght} \\
374 \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} &
375 \multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule
376 \parbox{52mm}{\centering fragment offset}}\\
378 \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}&
379 \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}&
380 \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\
382 \multicolumn{8}{@{\vrule}c@{\vrule}}{
383 source IP address} \\
385 \multicolumn{8}{@{\vrule}c@{\vrule}}{
386 destination IP address} \\
388 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
389 \multicolumn{8}{@{}p{128mm}@{}}{
390 \centering options (if any)} \\
391 \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
394 \caption{L'intestazione o \textit{header} di IPv4}
401 \begin{tabular}{l c p{9cm}}
402 \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
404 \textit{version} & 4 bit & \textsl{versione}, nel caso
405 specifico vale sempre 4\\
406 \textit{head lenght} & 4 bit & \textsl{lunghezza della testata},
407 in multipli di 32 bit\\
408 \textit{type of service} & 8 bit & \textsl{tipo di servizio},
409 consiste in: 3 bit di precedenza,
410 correntemente ignorati; un bit non usato a 0; 4 bit che identificano
411 il tipo di servizio richiesto, uno solo dei quali pu\`o essere 1\\
412 \textit{total lenght} & 16 bit & \textsl{lunghezza totale}, indica
413 la dimensione del pacchetto IP in byte\\
414 \textit{identification} & 16 bit & \textsl{identificazione},
415 assegnato alla creazione, \`e aumentato di uno all'origine alla
416 trasmissione di ciascun pacchetto, ma resta lo stesso per i
417 pacchetti frammentati\\
418 \textit{flag} & 3 bit &
419 \textsl{flag} bit di frammentazione, uno indica se un
420 pacchetto \`e frammentato, un'altro se ci sono ulteriori frammenti, e
421 un'altro se il pacchetto non pu\`o essere frammentato. \\
422 \textit{fragmentation offset} & 13 bit& \textsl{offset di frammento},
423 indica la posizione del frammento rispetto al pacchetto originale\\
424 \textit{time to live} & 16 bit & \textsl{tempo di vita},
425 ha lo stesso significato di
426 \textit{hop limit}, vedi Tab.~\ref{tab:ipv6field}\\
427 \textit{protocol} & 8 bit & \textsl{protocollo}
428 identifica il tipo di pacchetto che segue
430 \textit{header checksum} & 16 bit & \textsl{checksum di testata}, somma
431 di controllo per la testata\\
432 \textit{source IP} & 32 bit & \textsl{indirizzo di origine}\\
433 \textit{destination IP} & 32 bit & \textsl{indirizzo di destinazione}\\
436 \caption{Legenda per il significato dei campi dell'intestazione di IPv4}
437 \label{tab:ipv4field}
441 Oltre alle differenze precedenti, relative ai singoli campi nella testata,
442 ulteriori caratteristiche che diversificano il comportamento di IPv4 da
443 quello di IPv6 sono le seguenti:
446 \item il broadcasting non \`e previsto in IPv6, le applicazioni che lo usano
447 dovono essere reimplementate usando il multicasting (vedi
448 Sez.~\ref{sec:multicast}), che da opzionale diventa obbligatorio.
449 \item \`e stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
450 \item i router non possono pi\`u frammentare i pacchetti lungo il cammino, la
451 frammentazione di pacchetti troppo grandi potr\`a essere gestita solo ai
452 capi della comunicazione (usando un'apposita estensione vedi
453 Sez.~\ref{sec:extens}).
454 \item IPv6 richiede il supporto per il \textit{path MTU discovery} (cio\`e il
455 protocollo per la selezione della massima lunghezza del pacchetto); seppure
456 questo sia in teoria opzionale, senza di esso non sar\`a possibile inviare
457 pacchetti pi\`u larghi della dimensione minima (576 bytes).
460 \section{Gli indirizzi di IPv6}
463 Come gi\`a abbondantemente anticipato la principale novit\`a di IPv6 \`e
464 costituita dall'ampliamento dello spazio degli indirizzi, che consente di avere
465 indirizzi disponibili in un numero dell'ordine di quello degli atomi che
466 costituiscono la terra.
468 In realt\`a l'allocazione di questi indirizzi deve tenere conto della
469 necessit\`a di costruire delle gerarchie che consentano un instradamento
470 rapido ed efficiente dei pacchetti, e flessibilit\`a nel dispiegamento delle
471 reti, il che comporta una riduzione drastica dei numeri utilizzabili; uno
472 studio sull'efficienza dei vari sistemi di allocazione usati in altre
473 architetture (come i sistemi telefonici) \`e comunque giunto alla conclusione
474 che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di
475 fornire pi\`u di un migliaio di indirizzi per ogni metro quadro della
476 superficie terrestre.
479 \subsection{La notazione}
480 \label{sec:notazione}
481 Con un numero di bit quadruplicato non \`e pi\`u possibile usare la notazione
482 coi numeri decimali di IPv4 per rappresentare un numero IP. Per questo gli
483 indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri
484 esadecimali di 4 cifre (cio\`e a gruppi di 16 bit) usando i due punti come
485 separatore; cio\`e qualcosa del tipo
486 \texttt{5f1b:df00:ce3e:e200:0020:0800:2078:e3e3}.
489 Visto che la notazione resta comunque piuttosto pesante esistono alcune
490 abbreviazioni; si pu\`o evitare di scrivere gli zeri iniziali per cui si
491 pu\`o scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero \`e
492 zero si pu\`o omettere del tutto, cos\`\i\ come un insieme di zeri (ma questo
493 solo una volta per non generare ambiguit\`a) per cui il precedente indirizzo
494 si pu\`o scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
496 Infine per scrivere un indirizzo IPv4 all'interno di un indirizzo IPv6 si
497 pu\`o usare la vecchia notazione con i punti, per esempio
498 \texttt{::192.84.145.138}.
503 \begin{tabular}{|l|l|l|}
505 \centering \textbf{Tipo di indirizzo}
506 & \centering \textbf{Prefisso} & {\centering \textbf{Frazione}} \\
509 riservato & \texttt{0000 0000} & 1/256 \\
510 non assegnato & \texttt{0000 0001} & 1/256 \\
512 riservato per NSAP & \texttt{0000 001} & 1/128\\
513 riservato per IPX & \texttt{0000 010} & 1/128\\
515 non assegnato & \texttt{0000 011} & 1/128 \\
516 non assegnato & \texttt{0000 1} & 1/32 \\
517 non assegnato & \texttt{0001} & 1/16 \\
519 provider-based & \texttt{001} & 1/8\\
521 non assegnato & \texttt{010} & 1/8 \\
522 non assegnato & \texttt{011} & 1/8 \\
523 geografic-based& \texttt{100} & 1/8 \\
524 non assegnato & \texttt{101} & 1/8 \\
525 non assegnato & \texttt{110} & 1/8 \\
526 non assegnato & \texttt{1110} & 1/16 \\
527 non assegnato & \texttt{1111 0} & 1/32 \\
528 non assegnato & \texttt{1111 10} & 1/64 \\
529 non assegnato & \texttt{1111 110} & 1/128 \\
530 non assegnato & \texttt{1111 1100 0} & 1/512 \\
532 unicast link-local & \texttt{1111 1100 10} & 1/1024 \\
533 unicast site-local & \texttt{1111 1100 11} & 1/1024 \\
536 multicast & \texttt{1111 1111} & 1/256 \\
539 \caption{Classificazione degli indirizzi IPv6 a seconda dei bit pi\`u
545 \subsection{La architettura degli indirizzi di IPv6}
548 Come per IPv4 gli indirizzi sono identificatori per una singola (indirizzi
549 \textit{unicast}) o per un insieme (indirizzi \textit{multicast} e
550 \textit{anycast}) di interfacce di rete.
552 Gli indirizzi sono sempre assegnati all'interfaccia, non al nodo che la
553 ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo pu\`o
554 essere identificato attraverso uno qualunque degli indirizzi unicast delle sue
555 interfacce. A una interfaccia possono essere associati anche pi\`u indirizzi.
557 IPv6 presenta tre tipi diversi di indirizzi: due di questi, gli indirizzi
558 \textit{unicast} e \textit{multicast} hanno le stesse caratteristiche che in
559 IPv4, un terzo tipo, gli indirizzi \textit{anycast} \`e completamente nuovo.
560 In IPv6 non esistono pi\`u gli indirizzi \textit{broadcast}, la funzione di
561 questi ultimi deve essere reimplementata con gli indirizzi \textit{multicast}.
563 Gli indirizzi \textit{unicast} identificano una singola interfaccia i
564 pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia,
565 gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che
566 un pacchetto mandato a uno di questi indirizzi viene inviato alla pi\`u vicina
567 (nel senso di distanza di routing) delle interfacce del gruppo, gli indirizzi
568 \textit{multicast} identificano un gruppo di interfacce tale che un pacchetto
569 mandato a uno di questi indirizzi viene inviato a tutte le interfacce del
572 In IPv6 non ci sono pi\`u le classi ma i bit pi\`u significativi indicano il
573 tipo di indirizzo; in Tab.~\ref{tab:ipv6addr} sono riportati i valori di detti
574 bit e il tipo di indirizzo che loro corrispondente. I bit pi\`u significativi
575 costituiscono quello che viene chiamato il \textit{format prefix} ed \`e sulla
576 base di questo che i vari tipi di indirizzi vengono identificati.
577 Come si vede questa architettura di allocazione supporta l'allocazione di
578 indirizzi per i provider, per uso locale e per il multicast; inoltre \`e stato
579 riservato lo spazio per indirizzi NSAP, IPX e per le connessioni; gran parte
580 dello spazio (pi\`u del 70\%) \`e riservato per usi futuri.
582 Si noti infine che gli indirizzi \textit{anycast} non sono riportati in
583 Tab.~\ref{tab:ipv6addr} in quanto allocati al di fuori dello spazio di
584 allocazione degli indirizzi unicast.
586 \subsection{Indirizzi unicast \textit{provider-based}}
589 Gli indirizzi \textit{provider-based} sono gli indirizzi usati per le
590 comunicazioni globali, questi sono definiti nell'RFC 2073 e sono gli
591 equivalenti degli attuali indirizzi delle classi da A a C.
593 L'autorit\`a che presiede all'allocazione di questi indirizzi \`e la IANA; per
594 evitare i problemi di crescita delle tabelle di instradamento e una procedura
595 efficiente di allocazione la struttura di questi indirizzi \`e organizzata fin
596 dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi \`e
597 stato suddiviso in una serie di campi secondo lo schema riportato in
598 Tab.~\ref{tab:unicast}.
603 \begin{tabular} {@{\vrule}p{6mm}
604 @{\vrule}p{16mm}@{\vrule}p{24mm}
605 @{\vrule}p{30mm}@{\vrule}c@{\vrule}}
606 \multicolumn{1}{@{}c@{}}{3}&\multicolumn{1}{c}{5 bit}&
607 \multicolumn{1}{c}{$n$ bit}&\multicolumn{1}{c}{$56-n$ bit}&
608 \multicolumn{1}{c}{64 bit} \\
610 \omit\vrule\hfill\vrule&\hspace{16mm} & & &\omit\hspace{76mm}\hfill\vrule\\
612 \centering \textsl{Registry Id}&
613 \centering \textsl{Provider Id}&
614 \centering \textsl{Subscriber Id}&
615 \textsl{Intra-Subscriber} \\
616 \omit\vrule\hfill\vrule& & & &\omit\hspace{6mm}\hfill\vrule\\
619 \caption{Formato di un indirizzo unicast \textit{provider-based}.}
623 Al livello pi\`u alto la IANA pu\`o delegare l'allocazione a delle autorit\`a
624 regionali (i Regional Register) assegnando ad esse dei blocchi di indirizzi; a
625 queste autorit\`a regionali \`e assegnato un Registry Id che deve seguire
626 immediatamente il prefisso di formato. Al momento sono definite tre registri
627 regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si \`e riservata la
628 possibilit\`a di allocare indirizzi su base regionale; pertanto sono previsti
629 i seguenti possibili valori per il \textsl{Registry Id};
630 gli altri valori restano riservati per la IANA.
633 \begin{tabular}{l l l}
634 \textbf{Regione} & \textbf{Registro} & \textbf{Id} \\
636 Nord America &INTERNIC & \texttt{11000} \\
637 Europa & RIPE NCC & \texttt{01000} \\
638 Asia & APNIC & \texttt{00100} \\
639 Multi-regionale & IANA &\texttt{10000} \\
642 \caption{Valori dell'identificativo dei
643 Regional Register allocati ad oggi.}
648 L'organizzazione degli indirizzi prevede poi che i due livelli successivi, di
649 suddivisione fra \textit{Provider Id}, che identifica i grandi fornitori di
650 servizi, e \textit{Subscriber Id}, che identifica i fruitori, sia gestita dai
651 singoli registri regionali. Questi ultimi dovranno definire come dividere lo
652 spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di
653 58~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
654 al \textit{Subscriber Id}, ad essi spetter\`a inoltre anche l'allocazione dei
655 numeri di \textit{Provider Id} ai singoli fornitori, ai quali sar\`a delegata
656 l'autorit\`a di allocare i \textit{Subscriber Id} al loro interno.
658 L'ultimo livello \`e quello \textit{Intra-subscriber} che \`e lasciato alla
659 gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based}
660 lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la
661 modalit\`a pi\`u immediata \`e quella di usare uno schema del tipo mostrato in
662 Tab.~\ref{tab:uninterf} dove l'\textit{Interface Id} \`e dato dal MAC-address
663 a 48~bit dello standard ethernet, scritto in genere nell'hardware delle scheda
664 di rete, e si usano i restanti 16~bit per indicare la sottorete.
669 \begin{tabular} {@{\vrule}p{64mm}@{\vrule}p{16mm}@{\vrule}c@{\vrule}}
670 \multicolumn{1}{c}{64 bit}&\multicolumn{1}{c}{16 bit}&
671 \multicolumn{1}{c}{48 bit}\\
673 \omit\vrule\hfill\vrule&\hspace{16mm}&\omit\hspace{48mm}\hfill\vrule\\
674 \centering \textsl{Subscriber Prefix}&
675 \centering \textsl{Subnet Id}&
676 \textsl{Interface Id}\\
677 \omit\vrule\hfill\vrule& &\omit\hspace{6mm}\hfill\vrule\\
680 \caption{Formato del campo \textit{Intra-subscriber} per un indirizzo unicast
681 \textit{provider-based}.}
685 Qualora si dovesse avere a che fare con una necessit\`a di un numero pi\`u
686 elevato di sottoreti, il precedente schema andrebbe modificato, per evitare
687 l'enorme spreco dovuto all'uso dei MAC-address, a questo scopo si possono
688 usare le capacit\`a di autoconfigurazione di IPv6 per assegnare indirizzi
689 generici con ulteriori gerarchie per sfruttare efficacemente tutto lo spazio
692 Un registro regionale pu\`o introdurre un ulteriore livello nella gerarchia
693 degli indirizzi, allocando dei blocchi per i quali delegare l'autorit\`a a dei
694 registri nazionali, quest'ultimi poi avranno il compito di gestire la
695 attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
696 paese coperto dal registro nazionale con le modalit\`a viste in precedenza.
697 Una tale ripartizione andr\`a effettuata all'interno dei soliti 58~bit come
698 mostrato in Tab.~\ref{tab:uninaz}.
703 \begin{tabular} {@{\vrule}p{3mm}
704 @{\vrule}p{10mm}@{\vrule}p{12mm}@{\vrule}p{18mm}
705 @{\vrule}p{18mm}@{\vrule}c@{\vrule}}
706 \multicolumn{1}{@{}c@{}}{3}&\multicolumn{1}{c}{5 bit}&
707 \multicolumn{1}{c}{n bit}&\multicolumn{1}{c}{m bit}&
708 \multicolumn{1}{c}{56-n-m bit}&\multicolumn{1}{c}{64 bit} \\
710 \omit\vrule\hfill\vrule& & & & &\omit\hspace{64mm}\hfill\vrule\\
711 \centering \texttt{3}&
712 \centering \textsl{Reg.}&
713 \centering \textsl{Naz.}&
714 \centering \textsl{Prov.}&
715 \centering \textsl{Subscr.}&
716 \textsl{Intra-Subscriber} \\
717 \omit\vrule\hfill\vrule &&&&&\\
720 \caption{Formato di un indirizzo unicast \textit{provider-based} che prevede
721 un registro nazionale.}
725 \subsection{Indirizzi ad uso locale}
728 Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo
729 localmente (all'interno di un sito o di una sottorete), e possono avere una
730 unicit\`a locale o globale.
732 Questi indirizzi sono pensati per l'uso all'interno di un sito per mettere su
733 una comunicazione locale immediata, o durante le fasi di autoconfigurazione
734 prima di avere un indirizzo globale.
739 \begin{tabular} {@{\vrule}p{10mm}@{\vrule}p{54mm}@{\vrule}c@{\vrule}}
740 \multicolumn{1}{c}{10} &\multicolumn{1}{c}{54 bit} &
741 \multicolumn{1}{c}{64 bit} \\
743 \omit\vrule\hfill\vrule & & \omit\hspace{64mm}\hfill\vrule\\
744 \centering \texttt{FE80}&
745 \centering\texttt{0000 . . . . . 0000} &
747 \omit\vrule\hfill\vrule & &\\
750 \caption{Formato di un indirizzo \textit{link-local}.}
751 \label{tab:linklocal}
754 Ci sono due tipi di indirizzi, \textit{link-local} e \textit{site-local}. Il
755 primo \`e usato per un singolo link; la struttura \`e mostrata in
756 Tab.~\ref{tab:linklocal}, questi indirizzi iniziano sempre per \texttt{FE80} e
757 vengono in genere usati per la configurazione automatica dell'indirizzo al
758 bootstrap e per la ricerca dei vicini (vedi Sez.~\ref{sec:autoconf}); un
759 pacchetto che abbia tale indirizzo come sorgente o destinazione non deve
760 venire ritrasmesso dai router.
762 Un indirizzo \textit{site-local} invece \`e usato per l'indirizzamento
763 all'interno di un sito che non necessita di un prefisso globale; la struttura
764 \`e mostrata in Tab.~\ref{tab:sitelocal}, questi indirizzi iniziano sempre per
765 \texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del sito
766 stesso; sono in sostanza gli equivalenti degli indirizzi riservati per reti
767 private definiti su IPv4.
768 Per entrambi gli indirizzi il campo \textit{Interface Id} \`e un
769 identificatore che deve essere unico nel dominio in cui viene usato, un modo
770 immediato per costruirlo \`e quello di usare il MAC-address delle schede di
776 \begin{tabular} {@{\vrule}p{10mm}@{\vrule}p{38mm}@{\vrule}p{16mm}
778 \multicolumn{1}{c}{10} &\multicolumn{1}{c}{38 bit} &
779 \multicolumn{1}{c}{16 bit} &\multicolumn{1}{c}{64 bit} \\
781 \omit\vrule\hfill\vrule& & & \omit\hspace{64mm}\hfill\vrule\\
782 \centering \texttt{FEC0}&
783 \centering \texttt{0000 . . . 0000}&
784 \centering Subnet Id &
786 \omit\vrule\hfill\vrule& & &\\
789 \caption{Formato di un indirizzo \textit{site-local}.}
790 \label{tab:sitelocal}
793 Gli indirizzi di uso locale consentono ad una organizzazione che non \`e
794 (ancora) connessa ad Internet di operare senza richiedere un prefisso globale,
795 una volta che in seguito l'organizzazione venisse connessa a Internet
796 potrebbe continuare a usare la stessa suddivisione effettuata con gli
797 indirizzi \textit{site-local} utilizzando un prefisso globale e la
798 rinumerazione degli indirizzi delle singole macchine sarebbe automatica.
800 \subsection{Indirizzi riservati}
803 Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
806 Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
807 Tab.~\ref{tab:ipv6map}), questo sono indirizzi unicast che vengono usati per
808 consentire ad applicazioni IPv6 di comunicare con host capaci solo di IPv4;
809 questi sono ad esempio gli indirizzi generati da un DNS quando l'host
810 richiesto supporta solo IPv4; l'uso di un tale indirizzo in un socket IPv6
811 comporta la generazione di un pacchetto IPv4 (ovviamente occorre che sia IPv4
812 che IPv6 siano supportate sull'host di origine).
817 \begin{tabular} {@{\vrule}p{80mm}@{\vrule}p{16mm}@{\vrule}c@{\vrule}}
818 \multicolumn{1}{c}{80 bit} &\multicolumn{1}{c}{16 bit} &
819 \multicolumn{1}{c}{32 bit} \\
821 \omit\vrule\hfill\vrule& &\omit\hspace{32mm}\hfill\vrule\\
823 \texttt{0000 . . . . . . . . . . . . 0000} &
824 \centering\texttt{FFFF} &
826 \omit\vrule\hfill\vrule& &\\
829 \caption{Formato di un indirizzo IPV4 mappato su IPv6.}
833 Un secondo tipo di indirizzi di compatibilit\`a sono gli \textit{IPv4
834 compatibili IPv6} (vedi Tab.~\ref{tab:ipv6comp} usati nella transizione da
835 IPv4 a IPv6, quando un host che supporta sia IPv6 che IPv4 non ha un router
836 IPv6 deve usare nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6
837 inviato a un tale indirizzo verr\`a automaticamente incapsulato in IPv4.
842 \begin{tabular} {@{\vrule}p{80mm}@{\vrule}p{16mm}@{\vrule}p{32mm}@{\vrule}}
843 \multicolumn{1}{c}{80 bit} &\multicolumn{1}{c}{16 bit} &
844 \multicolumn{1}{c}{32 bit} \\
846 \omit\vrule\hfill\vrule& &\omit\hspace{32mm}\hfill\vrule\\
848 \texttt{0000 . . . . . . . . . . . . 0000} &
849 \centering\texttt{0000} &
850 \parbox{32mm}{\centering IPv4 address} \\
851 \omit\vrule\hfill\vrule& &\\
854 \caption{Formato di un indirizzo IPV4 mappato su IPv6.}
858 Altri indirizzi speciali sono il \textit{loopback address}, costituito da 127
859 zeri ed un uno (cio\`e \texttt{::1}) e l'\textsl{indirizzo generico}
860 costituito da tutti zeri (scritto come \texttt{0::0} o ancora pi\`u
861 semplicemente come \texttt{:}) usato in genere quando si vuole indicare
862 l'accettazione di una connessione da qualunque host.
864 \subsection{Multicasting}
865 \label{sec:multicast}
867 Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
868 gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
869 multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo.
870 Un'interfaccia pu\`o appartenere ad un numero qualunque numero di gruppi di
871 multicast. Il formato degli indirizzi \textit{multicast} \`e riportato in
872 Tab.~\ref{tab:multicast}
877 \begin{tabular} {@{\vrule}p{12mm}
878 @{\vrule}p{6mm}@{\vrule}p{6mm}@{\vrule}c@{\vrule}}
879 \multicolumn{1}{c}{8}&\multicolumn{1}{c}{4}&
880 \multicolumn{1}{c}{4}&\multicolumn{1}{c}{112 bit} \\
882 \omit\vrule\hfill\vrule& & & \omit\hspace{104mm}\hfill\vrule\\
883 \centering\texttt{FF}&
887 \omit\vrule\hfill\vrule &&&\\
890 \caption{Formato di un indirizzo \textit{multicast}.}
891 \label{tab:multicast}
894 Il prefisso di formato per tutti gli indirizzi \textit{multicast} \`e
895 \texttt{FF}, ad esso seguono i due campi il cui significato \`e il seguente:
898 \item \textsl{flag}: un insieme di 4 bit, di cui i primi tre sono riservati e
899 posti a zero, l'ultimo \`e zero se l'indirizzo \`e permanente (cio\`e un
900 indirizzo noto, assegnato dalla IANA), ed \`e uno se invece l'indirizzo \`e
902 \item \textsl{scop} \`e un numero di quattro bit che indica il raggio di
903 validit\`a dell'indirizzo, i valori assegnati per ora sono riportati in
904 Tab.~\ref{tab:multiscope}.
907 Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che
908 transitorio, all'interno del raggio di validit\`a del medesimo.
913 \begin{tabular}[c]{c l c l}
914 \multicolumn{4}{c}{\bf Gruppi di multicast} \\
916 0 & riservato & 8 & organizzazione locale \\
917 1 & nodo locale & 9 & non assegnato \\
918 2 & collegamento locale & A & non assegnato \\
919 3 & non assegnato & B & non assegnato \\
920 4 & non assegnato & C & non assegnato \\
921 5 & sito locale & D & non assegnato \\
922 6 & non assegnato & E & globale \\
923 7 & non assegnato & F & riservato \\
926 \caption{Possibili valori del campo \textsl{scop} di un indirizzo multicast.}
927 \label{tab:multiscope}
930 \subsection{Indirizzi \textit{anycast}}
933 Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
934 gruppo di interfacce per quali un pacchetto indirizzato a questo tipo di
935 indirizzo viene inviato al componente del gruppo pi\`u ``vicino'' secondo la
936 distanza di instradamento calcolata dai router.
938 Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast,
939 usando uno dei formati disponibili, e per questo, sono da essi assolutamente
940 indistinguibili. Quando un indirizzo unicast viene assegnato a pi\`u
941 interfacce (trasformandolo in un anycast) il computer su cui \`e l'interfaccia
942 deve essere configurato per tener conto del fatto.
944 Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una
945 destinazione su un gruppo di possibili interfacce selezionate. La sorgente non
946 deve curarsi di come scegliere l'interfaccia pi\`u vicina, compito che tocca
947 al sistema di instradamento, (in sostanza la sorgente non ha nessun controllo
950 Gli indirizzi anycast, quando vengono usati come parte di una sequenza di
951 instradamento, consentono ad esempio ad un nodo di scegliere quale fornitore
952 vuole usare (configurando gli indirizzi anycast per identificare i router di
953 uno stesso provider).
955 Questi indirizzi pertanto possono essere usati come indirizzi intermedi in una
956 testata di instradamento o per identificare insiemi di router connessi a una
957 particolare sottorete, o che forniscono l'accesso a un certo sotto dominio.
959 L'idea alla base degli indirizzi anycast \`e perci\`o quella di utilizzarli
960 per poter raggiungere il fornitore di servizio pi\`u vicino; ma restano aperte
961 tutta una serie di problematiche, visto che una connessione con uno di questi
962 indirizzi non \`e possibile, dato che per una variazione delle distanze di
963 routing non \`e detto che due pacchetti successivi finiscano alla stessa
966 La materia \`e pertanto ancora controversa e in via di definizione.
969 \section{Le estensioni}
972 Come gi\`a detto in precedenza IPv6 ha completamente cambiato il trattamento
973 delle opzioni; queste ultime infatti sono state tolte dalla testata del
974 pacchetto, e poste in apposite \textsl{testate di estensione} (o
975 \textit{extension header}) poste fra la testata di IPv6 e la testata del
976 protocollo di trasporto.
978 Per aumentare la velocit\`a di processo, sia dei dati del livello seguente che
979 di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di
980 8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti.
982 Dato che la maggior parte di queste estensioni non sono esaminate dai router
983 durante l'instradamento e la trasmissione dei pacchetti, ma solo all'arrivo
984 alla destinazione finale, questa scelta ha consentito un miglioramento delle
985 prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame
988 Un secondo miglioramento \`e che rispetto a IPv4 le opzioni possono essere di
989 lunghezza arbitraria e non limitate a 40 bytes; questo, insieme al modo in cui
990 vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
991 sicurezza, improponibili con IPv4.
993 Le estensioni definite al momento sono le seguenti:
995 \item \textbf{Hop by hop} devono seguire immediatamente la testata principale;
996 indicano le opzioni che devono venire processate ad ogni passaggio da un
997 router, fra di esse \`e da menzionare la \textit{jumbo payload} che segnala
998 la presenza di un pacchetto di dati di dimensione superiore a 64Kb.
999 \item \textbf{Destination options} opzioni che devono venire esaminate al nodo
1000 di ricevimento, nessuna di esse \`e tuttora definita.
1001 \item \textbf{Routing} definisce una \textit{source route} (come la analoga
1002 opzione di IPv4) cio\`e una lista di indirizzi IP di nodi per i quali il
1003 pacchetto deve passare.
1004 \item \textbf{Fragmentation} viene generato automaticamente quando un host
1005 vuole frammentare un pacchetto, ed \`e riprocessato automaticamente alla
1006 destinazione che riassembla i frammenti.
1007 \item \textbf{Authentication} gestisce l'autenticazione e il controllo di
1008 integrit\`a dei pacchetti; \`e documentato dall'RFC 162.
1009 \item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
1010 trasmesso; \`e documentato dall'RFC 1827.
1013 La presenza di opzioni \`e rilevata dal valore del campo \textit{next header}
1014 che indica qual'\`e la testata successiva a quella di IPv6; in assenza di
1015 opzioni questa sar\`a la testata di un protocollo di trasporto del livello
1016 superiore, per cui il campo assumer\`a lo stesso valore del campo
1017 \textit{protocol} di IPv4, altrimenti assumer\`a il valore dell'opzione
1018 presente; i valori possibili sono riportati in Tab.~\ref{tab:nexthead}.
1023 \begin{tabular}{c l l}
1024 \textbf{Valore} & \textbf{Keyword} & \textbf{Tipo di protocollo} \\
1028 & HBH & Hop by Hop \\
1029 1 & ICMP & Internet Control Message (IPv4 o IPv6) \\
1030 2 & ICMP & Internet Group Management (IPv4) \\
1031 3 & GGP & Gateway-to-Gateway \\
1032 4 & IP & IP in IP (IPv4 encapsulation) \\
1034 6 & TCP & Trasmission Control \\
1035 17 & UDP & User Datagram \\
1036 43 & RH & Routing Header (IPv6) \\
1037 44 & FH & Fragment Header (IPv6) \\
1038 45 & IDRP & Inter Domain Routing \\
1039 51 & AH & Autentication Header (IPv6) \\
1040 52 & ESP & Encrypted Security Payload (IPv6) \\
1041 59 & Null & No next header (IPv6) \\
1042 88 & IGRP & Internet Group Routing \\
1043 89 & OSPF & Open Short Path First \\
1046 \caption{Tipi di protocolli e testate di estensione}
1047 \label{tab:nexthead}
1051 Questo meccanismo permette la presenza di pi\`u opzioni in successione prima
1052 del pacchetto del protocollo di trasporto; l'ordine raccomandato per le
1053 estensioni \`e quello riportato nell'elenco precedente con la sola differenza
1054 che le opzioni di destinazione sono inserite nella posizione ivi indicata solo
1055 se, come per il tunnelling, devono essere esaminate dai router, quelle che
1056 devono essere esaminate solo alla destinazione finale vanno in coda.
1059 \section{Qualit\`a di servizio}
1062 Una delle caratteristiche innovative di IPv6 \`e quella di avere introdotto un
1063 supporto per la qualit\`a di servizio che \`e importante per applicazioni come
1064 quelle multimediali o ``real-time'' che richiedono un qualche grado di
1065 controllo sulla stabilit\`a della banda di trasmissione, sui ritardi o la
1066 dispersione dei temporale del flusso dei pacchetti.
1069 \subsection{Etichette di flusso}
1071 L'introduzione del campo \textit{flow label} pu\`o essere usata dall'origine
1072 della comunicazione per etichettare quei pacchetti per i quali si vuole un
1073 trattamento speciale da parte dei router come un una garanzia di banda minima
1074 assicurata o un tempo minimo di instradamento/trasmissione garantito.
1076 Questo aspetto di IPv6 \`e ancora sperimentale per cui i router che non
1077 supportino queste funzioni devono porre a zero il \textit{flow label} per i
1078 pacchetti da loro originanti e lasciare invariato il campo per quelli in
1081 Un flusso \`e una sequenza di pacchetti da una particolare origine a una
1082 particolare destinazione per il quale l'origine desidera un trattamento
1083 speciale da parte dei router che lo manipolano; la natura di questo
1084 trattamento pu\`o essere comunicata ai router in vari modi (come un protocollo
1085 di controllo o con opzioni del tipo \textit{hop-by-hop}).
1087 Ci possono essere pi\`u flussi attivi fra un'origine e una destinazione, come
1088 del traffico non assegnato a nessun flusso, un flusso viene identificato
1089 univocamente dagli indirizzi di origine e destinazione e da una etichetta di
1090 flusso diversa da zero, il traffico normale deve avere l'etichetta di flusso
1093 L'etichetta di flusso \`e assegnata dal nodo di origine, i valori devono
1094 essere scelti in maniera (pseudo)casuale nel range fra 1 e FFFFFF in modo da
1095 rendere utilizzabile un qualunque sottoinsieme dei bit come chiavi di hash per
1098 \subsection{Priorit\`a}
1101 Il campo di priorit\`a consente di indicare il livello di priorit\`a dei
1102 pacchetti relativamente agli altri pacchetti provenienti dalla stessa
1103 sorgente. I valori sono divisi in due intervalli, i valori da 0 a 7 sono usati
1104 per specificare la priorit\`a del traffico per il quale la sorgente provvede
1105 un controllo di congestione cio\`e per il traffico che pu\`o essere ``tirato
1106 indietro'' in caso di congestione come quello di TCP, i valori da 8 a 15 sono
1107 usati per i pacchetti che non hanno questa caratteristica, come i pacchetti
1108 ``real-time'' inviati a ritmo costante.
1110 Per il traffico con controllo di congestione sono raccomandati i seguenti
1111 valori di priorit\`a a seconda del tipo di applicazione:
1116 \begin{tabular} {c l}
1117 Valore & tipo di traffico \\
1119 0 & traffico generico \\
1120 1 & traffico di riempimento (es. news) \\
1121 2 & trasferimento dati non interattivo (es. e-mail)\\
1123 4 & trasferimento dati interattivo (es. FTP, HTTP, NFS) \\
1125 6 & traffico interattivo (telnet, X)\\
1126 7 & traffico di controllo (routing, SNMP) \\
1129 \caption{Formato di un indirizzo \textit{site-local}.}
1130 \label{tab:priority}
1133 Per il traffico senza controllo di congestione la priorit\`a pi\`u bassa
1134 dovrebbe essere usata per quei pacchetti che si preferisce siano scartati
1135 pi\`u facilmente in caso di congestione.
1138 \section{Sicurezza a livello IP}
1139 \label{sec:security}
1141 La attuale implementazione di Internet presenta numerosi problemi di
1142 sicurezza, in particolare i dati presenti nelle testate dei vari protocolli
1143 sono assunti essere corretti, il che da adito alla possibilit\`a di varie
1144 tipologie di attacco forgiando pacchetti false, inoltre tutti questi dati
1145 passano in chiaro sulla rete e sono esposti all'osservazione di chiunque si
1148 Con IPv4 non \`e possibile realizzare un meccanismo di autenticazione e
1149 riservatezza a un livello inferiore al primo (quello di applicazione), con
1150 IPv6 \`e stato progettata la possibilit\`a di intervenire al livello del
1151 collegamento (il terzo) prevendo due apposite estensioni che possono essere
1152 usate per fornire livelli di sicurezza a seconda degli utenti. La codifica
1153 generale di questa architettura \`e riportata nell'RFC 2401.
1155 Il meccanismo in sostanza si basa su due estensioni:
1157 \item una testata di sicurezza (\textit{autentication header}) che garantisce
1158 al destinatario l'autenticit\`a del pacchetto
1159 \item un carico di sicurezza (\textit{Encrypted Security Payload}) che
1160 assicura che solo il legittimo ricevente pu\`o leggere il pacchetto.
1163 Perch\'e tutto questo funzioni le stazioni sorgente e destinazione devono
1164 usare una stessa chiave crittografica e gli stessi algoritmi, l'insieme degli
1165 accordi fra le due stazioni per concordare chiavi e algoritmi usati va sotto
1166 il nome di associazione di sicurezza.
1168 I pacchetti autenticati e crittografati portano un indice dei parametri di
1169 sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima
1170 di ogni comunicazione ed \`e definito dalla stazione sorgente. Nel caso di
1171 multicast dov\`a essere lo stesso per tutte le stazioni del gruppo.
1173 \subsection{Autenticazione}
1174 Il primo meccanismo di sicurezza \`e quello della testata di autenticazione
1175 (\textit{autentication header}) che fornisce l'autenticazione e il controllo
1176 di integrit\`a (ma senza riservatezza) dei pacchetti IP.
1178 La testata di autenticazione ha il formato descritto in Tab.~\ref{tab:authead}
1179 il campo \textit{Next Header} indica la testata successiva, con gli stessi
1180 valori del campo omonimo nella testata principale di IPv6, il campo
1181 \textit{Lengh} indica la lunghezza della testata di autenticazione in numero
1182 di parole a 32 bit, il campo riservato deve essere posto a zero, seguono poi
1183 l'indice di sicurezza, stabilito nella associazione di sicurezza, e un numero
1184 di sequenza che la stazione sorgente deve incrementare di pacchetto in
1187 Completano la testata i dati di autenticazione che contengono un valore di
1188 controllo di intgrit\`a (ICV, \textit{Integrity Check Value}), che deve essere
1189 di dimensione pari a un multiplo intero di 32 bit e pu\`o contenere un padding
1190 per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione
1191 devono provvedere questa capacit\`a.
1193 \renewcommand\arraystretch{1.2}
1197 \begin{tabular}{@{\vrule}p{24mm}@{\vrule}p{24mm}
1198 @{\vrule}p{48mm}@{\vrule} }
1199 \multicolumn{3}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
1201 \centering Next Header&\centering Lenght&
1202 \centering Reserved \tabularnewline
1204 \multicolumn{3}{@{\vrule}c@{\vrule}}
1205 {\centering Security Parameter Index (SPI)}\\
1207 \multicolumn{3}{@{\vrule}c@{\vrule}}
1208 {\centering Sequence Number}\\
1210 \multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
1211 \multicolumn{3}{@{\vrule}c@{\vrule}}{Autentication Data} \\
1212 \multicolumn{3}{@{\vrule}c@{\vrule}}
1213 {\centering ... } \\
1214 \multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
1217 \caption{Formato della testata dell'estensione di autenticazione}
1221 \renewcommand\arraystretch{1} %default
1225 La testata di autenticazione pu\`o essere impiegata in due modi diverse
1226 modalit\`a: modalit\`a trasporto e modalit\`a tunnel.
1228 La modalit\`a trasporto \`e utilizzabile solo per comunicazioni fra stazioni
1229 singole che supportino l'autenticazione. In questo caso la testata di
1230 autenticazione \`e inserita dopo tutte le altre testate di estensione
1231 eccezion fatta per la \textit{Destination Option} che pu\`o comparire sia
1237 \begin{tabular*}{90mm}{|c|c|c|c|c|c|}
1241 \parbox[c]{28mm}{hop by hop, dest., \\
1242 routing, fragment}& AH &
1243 dest.opt & TCP & data \\
1247 \caption{Formato della testata dell'estensione di autenticazione}
1252 \begin{pspicture}(0,0)(9,0.8)
1255 \ncline{<->}{A}{B}\ncput{copertura dell'autenticazione}
1259 La modalit`\a tunnel pu\`o essere utilizzata sia per comunicazioni fra stazioni
1260 singole che con un gateway di sicurezza; in questa modalit\`a
1263 La testata di autenticazione \`e una testata di estensione inserita dopo la
1264 testata principale e prima del carico dei dati. La sua presenza non ha
1265 perci\`o alcuna influenza sui livelli superiori dei protocolli di trasmissione
1272 La procedura di autenticazione cerca di garantire l'autenticit\`a del
1273 pacchetto nella massima estensione possibile, ma dato che alcuni campi della
1274 testata di IP possono variare in maniera impredicibile alla sorgente, il loro
1275 valore non pu\`o essere protetto dall'autenticazione.
1277 Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
1278 versione speciale del pacchetto in cui il numero di salti nella testata
1279 principale \`e settato a zero, cos\`\i\ come le opzioni che possono essere
1280 modificate nella trasmissione, e la testata di routing (se usata) \`e posta ai
1281 valori che deve avere all'arrivo.
1283 L'estensione \`e indipendente dall'algoritmo particolare, e il protocollo \`e
1284 ancora in fase di definizione; attualmente \`e stato suggerito l'uso di una
1285 modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
1286 una chiave che viene inserita all'inizio e alla fine degli altri campi.
1288 \subsection{Riservatezza}
1291 Per garantire una trasmissione riservata dei dati, \`e stata previsto la
1292 possibilit\`a di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
1293 \textit{Encripted Security Payload}. Questo viene realizzato usando con una
1294 apposita opzione che deve essere sempre l'ultima delle testate di estensione;
1295 ad essa segue il carico del pacchetto che viene criptato.
1297 Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
1298 quella mostrata in Tab~.\ref{tab:criptopack}, tutti i campi sono in chiaro
1299 fino al vettore di inizializzazione, il resto \`e crittografato.
1301 \renewcommand\arraystretch{1.2}
1305 \begin{tabular}{@{\vrule}p{24mm}@{\vrule}p{24mm}@{\vrule}
1306 p{24mm}@{\vrule}p{24mm}@{\vrule}}
1307 \multicolumn{4}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
1309 \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
1310 \multicolumn{4}{@{\vrule}c@{\vrule}}{Testata Principale}\\
1311 \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
1312 \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
1314 \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
1315 \multicolumn{4}{@{\vrule}c@{\vrule}}{Testate di estensione}\\
1316 \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
1317 \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
1319 \multicolumn{4}{@{\vrule}c@{\vrule}}
1320 {\centering Security Parameter Index}\\
1322 \multicolumn{4}{@{\vrule}c@{\vrule}}
1323 {\centering Vettore}\\
1324 \multicolumn{4}{@{\vrule}c@{\vrule}}
1325 {\centering di inizializzazione}\\
1327 \multicolumn{4}{@{\vrule}c@{\vrule}}{carico}\\
1328 \multicolumn{4}{@{\vrule}c@{\vrule}}{crittografato}\\
1329 \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
1331 & \multicolumn{3}{c@{\vrule}}{}\\
1334 \multicolumn{1}{@{\vrule}c}{}&
1335 \centering \raisebox{2mm}[0pt][0pt]{riempimento} &
1336 \centering lunghezza pad &\centering tipo carico\tabularnewline
1339 \caption{Schema di pacchetto crittografato}
1340 \label{tab:criptopack}
1343 \renewcommand\arraystretch{1} %default
1346 \section{Autoconfigurazione}
1347 \label{sec:autoconf}