-\chapter{Il protocollo IP}
-\label{cha:ip_protocol}
-
-L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981
-dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura
-hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
-dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI,
-etc.).
-
-
-\section{Introduzione}
-\label{sec:IP_intro}
-
-Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
-all'altro della rete; le caratteristiche essenziali con cui questo viene
-realizzato in IPv4 sono due:
-
-\begin{itemize}
-\item \textit{Universal addressing} la comunicazione avviene fra due host
- identificati univocamente con un indirizzo a 32 bit che può appartenere ad
- una sola interfaccia di rete.
-\item \textit{Best effort} viene assicurato il massimo impegno nella
- trasmissione, ma non c'è nessuna garanzia per i livelli superiori né
- sulla percentuale di successo né sul tempo di consegna dei pacchetti di
- dati.
-\end{itemize}
-
-Per effettuare la comunicazione e l'instradamento dei pacchetti fra le varie
-reti di cui è composta Internet IPv4 organizza gli indirizzi in una
-gerarchia a due livelli, in cui una parte dei 32 bit dell'indirizzo indica il
-numero di rete, e un'altra l'host al suo interno. Il numero di rete serve
-ai router per stabilire a quale rete il pacchetto deve essere inviato, il
-numero di host indica la macchina di destinazione finale all'interno di detta
-rete.
-
-Per garantire l'unicità dell'indirizzo Internet esiste un'autorità
-centrale (la IANA, \textit{Internet Assigned Number Authority}) che assegna i
-numeri di rete alle organizzazioni che ne fanno richiesta; è poi compito di
-quest'ultime assegnare i numeri dei singoli host.
-
-Per venire incontro alle diverse esigenze gli indirizzi di rete sono stati
-originariamente organizzati in \textit{classi}, (rappresentate in
-Tab.~\ref{tab:ipv4class}), per consentire dispiegamenti di reti di dimensioni
-diverse.
-
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {c@{\hspace{1mm}\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}}
- \omit&\omit& \multicolumn{7}{c}{7 bit}&\multicolumn{24}{c}{24 bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- classe A &\centering 0&
- \multicolumn{7}{@{}c@{\vrule}}{\parbox[c]{21mm}{\centering net Id}} &
- \multicolumn{24}{@{}c@{\vrule}}{\parbox[c]{72mm}{\centering host Id}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
- \multicolumn{33}{c}{ } \\
- \omit&\omit&\omit&
- \multicolumn{14}{c}{14 bit}&\multicolumn{16}{c}{16 bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- classe B&\centering 1&\centering 0&
- \multicolumn{14}{@{}c@{\vrule}}{\parbox{42mm}{\centering net Id}} &
- \multicolumn{16}{@{}c@{\vrule}}{\parbox{48mm}{\centering host Id}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
-
- \multicolumn{33}{c}{ } \\
- \omit&\omit&\omit&
- \multicolumn{21}{c}{21 bit}&\multicolumn{8}{c}{8 bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- classe C&\centering 1&\centering 1&\centering 0&
- \multicolumn{21}{@{}c@{\vrule}}{\parbox{63mm}{\centering net Id}} &
- \multicolumn{8}{@{}c@{\vrule}}{\parbox{24mm}{\centering host Id}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
-
-
- \multicolumn{33}{c}{ } \\
- \omit&\omit&\omit&\omit&
- \multicolumn{28}{c}{28 bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- classe D&\centering 1&\centering 1&\centering 1&\centering 0&
- \multicolumn{28}{@{}c@{\vrule}}{\parbox{63mm}{\centering
- multicast group Id}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
-
- \multicolumn{33}{c}{ } \\
- \omit&\omit&\omit&\omit&\omit&
- \multicolumn{27}{c}{27 bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- classe E&\centering 1&\centering 1&\centering 1&\centering 1&\centering 0&
- \multicolumn{27}{@{}c@{\vrule}}{\parbox{59mm}{\centering
- reserved for future use}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
-
-\end{tabular}
-\caption{Le classi di indirizzi secondo IPv4.}
-\label{tab:IP_ipv4class}
-\end{table}
-
-Le classi usate per il dispiegamento delle reti sono le prime tre; la classe D
-è destinata al (non molto usato) \textit{multicast} mentre la classe E è
-riservata per usi sperimentali e non viene impiegata.
-
-Come si può notare però la suddivisione riportata in \tabref{tab:IP_ipv4class}
-è largamente inefficiente in quanto se ad un utente necessita anche solo un
-indirizzo in più dei 256 disponibili con una classe A occorre passare a una
-classe B, con un conseguente spreco di numeri.
-
-Inoltre, in particolare per le reti di classe C, la presenza di tanti
-indirizzi di rete diversi comporta una crescita enorme delle tabelle di
-instradamento che ciascun router dovrebbe tenere in memoria per sapere dove
-inviare il pacchetto, con conseguente crescita dei tempi di processo da parte
-di questi ultimi ed inefficienza nel trasporto.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {c@{\hspace{1mm}\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
- p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}}
- \omit&
- \multicolumn{12}{c}{$n$ bit}&\multicolumn{20}{c}{$32-n$ bit} \\
- \cline{2-33}
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- CIDR &
- \multicolumn{12}{@{}c@{\vrule}}{\parbox[c]{36mm}{\centering net Id}} &
- \multicolumn{20}{@{}c@{\vrule}}{\parbox[c]{60mm}{\centering host Id}} \\
- \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
- \cline{2-33}
-\end{tabular}
-\caption{Uno esempio di indirizzamento CIDR.}
-\label{tab:IP_ipv4cidr}
-\end{table}
-
-Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il
-CIDR) in cui il limite fra i bit destinati a indicare il numero di rete e
-quello destinati a indicare l'host finale può essere piazzato in qualunque
-punto (vedi Tab.~\tabref{tab:IP_ipv4cidr}), permettendo di accorpare più
-classi A su un'unica rete o suddividere una classe B e diminuendo al contempo
-il numero di indirizzi di rete da inserire nelle tabelle di instradamento dei
-router.
-
-
-\section{I motivi della transizione}
-\label{sec:IP_whyipv6}
-
-Negli ultimi anni la crescita vertiginosa del numero di macchine connesse a
-internet ha iniziato a far emergere i vari limiti di IPv4; in particolare si
-è iniziata a delineare la possibilità di arrivare a una carenza di
-indirizzi disponibili.
-
-In realtà il problema non è propriamente legato al numero di indirizzi
-disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
-numeri diversi possibili, che sono molti di più dei computer attualemente
-esistenti.
-
-Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
-l'utilizzo delle classi di indirizzamento mostrate in precedenza, ha
-comportato che, nella sua evoluzione storica, il dispiegamento delle reti e
-l'allocazione degli indirizzi siano stati inefficienti; neanche l'uso del CIDR
-ha permesso di eliminare le inefficienze che si erano formate, dato che il
-ridispiegamento degli indirizzi comporta cambiamenti complessi a tutti i
-livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni
-sottorete.
-
-Diventava perciò necessario progettare un nuovo protocollo che permettesse
-di risolvere questi problemi, e garantisse flessibilità sufficiente per
-poter continuare a funzionare a lungo termine; in particolare necessitava un
-nuovo schema di indirizzamento che potesse rispondere alle seguenti
-necessità:
-
-\begin{itemize}
-\item un maggior numero di numeri disponibili che consentisse di non restare
- più a corto di indirizzi
-\item un'organizzazione gerarchica più flessibile dell'attuale
-\item uno schema di assegnazione degli indirizzi in grado di minimizzare le
- dimensioni delle tabelle di instradamento
-\item uno spazio di indirizzi che consentisse un passaggio automatico dalle
- reti locali a internet
-\end{itemize}
-
-
-\section{Principali caratteristiche di IPv6}
-\label{sec:IP_ipv6over}
-
-Per rispondere alle esigenze descritte in \secref{sec:IP_whyipv6} IPv6 nasce
-come evoluzione di IPv4, mantendone inalterate le funzioni che si sono
-dimostrate valide, eliminando quelle inutili e aggiungendone poche altre
-ponendo al contempo una grande attenzione a mantenere il protocollo il più
-snello e veloce possibile.
-
-I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
-grandi linee nei seguenti punti:
-\begin{itemize}
-\item l'espansione delle capacità di indirizzamento e instradamento, per
- supportare una gerarchia con più livelli di indirizzamento, un numero di
- nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
-\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
- si aggiungono agli usuali \textit{unycast} e \textit{multicast}
-\item la semplificazione del formato della testata, eliminando o rendendo
- opzionali alcuni dei campi di IPv4, per eliminare la necessità di
- riprocessamento della stessa da parte dei router e contenere l'aumento di
- dimensione dovuto ai nuovi indirizzi
-\item un supporto per le opzioni migliorato, per garantire una trasmissione
- più efficiente del traffico normale, limiti meno stringenti sulle
- dimensioni delle opzioni, e la flessibilità necessaria per introdurne di
- nuove in futuro
-\item il supporto per delle capacità di qualità di servizio (QoS) che
- permetta di identificare gruppi di dati per i quali si può provvedere un
- trattamento speciale (in vista dell'uso di internet per applicazioni
- multimediali e/o ``real-time'')
-\end{itemize}
-
-
-\section{La testata di IPv6}
-\label{sec:IP_ipv6head}
-
-Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
-protocollo per gestire la trasmissione dei pacchetti; in
-\tabref{tab:IP_ipv6head} è riportato il formato della testata di IPv6 da
-confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del
-significato dei vari campi delle due testate è riportato rispettivamente in
-\tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field})
-
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&\centering priority&
- \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
- \hline
- \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload lenght} &
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} &
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{La testata o \textit{header} di IPv6}
- \label{tab:IP_ipv6head}
- \end{center}
-\end{table}
-
-Come si può notare la testata di IPv6 diventa di dimensione fissa, pari a 40
-byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
-IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia
-quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il
-numero dei campi da 12 a 8.
-
-\begin{table}[htb]
- \begin{center}
- \footnotesize
- \begin{tabular}{ l c p{8cm}}
- \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
- \toprule
- \textit{version} & 4 bit &
- \textsl{versione}, nel caso specifico vale sempre 6\\
- \textit{priority} & 4 bit &
- \textsl{priorità}, vedi Sez.~\ref{sec:prio} \\
- \textit{flow label} & 24 bit &
- \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\
- \textit{payload leght} & 16 bit &
- \textsl{lunghezza del carico}, cioè del corpo dei dati che segue
- l'intestazione, in bytes. \\
- \textit{next header} & 8 bit & \textsl{testata successiva},
- identifica il tipo di pacchetto che segue la testata di IPv6, usa gli
- stessi valori del campo protocollo nella testata di IPv4\\
- \textit{hop limit} & 8 bit & \textsl{limite di salti},
- stesso significato del \textit{time to live} nella testata di IPv4,
- è decrementato di uno ogni volta che un nodo ritrasmette il
- pacchetto, se arriva a zero il pacchetto viene scartato \\
- \textit{source IP} & 128 bit & \textsl{indirizzo di origine} \\
- \textit{destination IP}& 128 bit & \textsl{indirizzo di destinazione}\\
- \bottomrule
- \end{tabular}
- \caption{Legenda per il significato dei campi dell'intestazione di IPv6}
- \label{tab:IP_ipv6field}
- \end{center}
-\end{table}
-
-Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali
-nella progettazione di IPv6 è stato quello di ridurre al massimo il tempo di
-processamento dei pacchetti da parte dei router, un confronto con la testata
-di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
-
-\begin{itemize}
-\item è stato eliminato il campo \textit{header lenght} in quanto le opzioni
- sono state tolte dalla testata che ha così dimensione fissa; ci possono
- essere più testate opzionali (\textsl{testate di estensione}, vedi
- \secref{sec:_IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
- lunghezza all'interno.
-\item la testata e gli indirizzi sono allineati a 64 bit, questo rende più
- veloce il processo da parte di computer con processori a 64 bit.
-\item i campi per gestire la frammentazione (\textit{identification},
- \textit{flag} e \textit{fragment offset}) sono stati eliminati; questo
- perché la frammentazione è un'eccezione che non deve rallentare il
- processo dei pacchetti nel caso normale.
-\item è stato eliminato il campo \textit{checksum} in quanto tutti i
- protocolli di livello superiore (TCP, UDP e ICMPv6) hanno un campo di
- checksum che include, oltre alla loro testata e ai dati, pure i campi
- \textit{payload lenght}, \textit{next header}, e gli indirizzi di origine e
- di destinazione; una checksum esiste anche per la gran parte protocolli di
- livello inferiore (anche se quelli che non lo hanno, come SLIP, non possono
- essere usati con grande affidabilità); con questa scelta si è ridotto di
- molti tempo di riprocessamento dato che i router non hanno più la
- necessità di ricalcolare la checksum ad ogni passaggio di un pacchetto per
- il cambiamento del campo \textit{hop limit}.
-\item è stato eliminato il campo \textit{type of service}, che praticamente
- non è mai stato utilizzato; una parte delle funzionalià ad esso delegate
- sono state reimplementate (vedi il campo \textit{priority} al prossimo
- punto) con altri metodi.
-\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
- insieme al campo \textit{priority} (che recupera i bit di precedenza del
- campo \textit{type of service}) per implementare la gestione di una
- ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di
- identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si
- può provvedere un trattamento speciale.
-\end{itemize}
-
-\begin{table}[htb]
- \footnotesize
- \centering
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&
- \centering head lenght&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total lenght} \\
- \hline
- \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} &
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule
- \parbox{52mm}{\centering fragment offset}}\\
- \hline
- \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}&
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{}p{128mm}@{}}{
- \centering options (if any)} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{L'intestazione o \textit{header} di IPv4}
-\label{tab:IP_ipv4head}
-\end{table}
-
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{l c p{9cm}}
- \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
- \toprule
- \textit{version} & 4 bit & \textsl{versione}, nel caso
- specifico vale sempre 4\\
- \textit{head lenght} & 4 bit & \textsl{lunghezza della testata},
- in multipli di 32 bit\\
- \textit{type of service} & 8 bit & \textsl{tipo di servizio},
- consiste in: 3 bit di precedenza,
- correntemente ignorati; un bit non usato a 0; 4 bit che identificano
- il tipo di servizio richiesto, uno solo dei quali può essere 1\\
- \textit{total lenght} & 16 bit & \textsl{lunghezza totale}, indica
- la dimensione del pacchetto IP in byte\\
- \textit{identification} & 16 bit & \textsl{identificazione},
- assegnato alla creazione, è aumentato di uno all'origine alla
- trasmissione di ciascun pacchetto, ma resta lo stesso per i
- pacchetti frammentati\\
- \textit{flag} & 3 bit &
- \textsl{flag} bit di frammentazione, uno indica se un
- pacchetto è frammentato, un'altro se ci sono ulteriori frammenti, e
- un'altro se il pacchetto non può essere frammentato. \\
- \textit{fragmentation offset} & 13 bit& \textsl{offset di frammento},
- indica la posizione del frammento rispetto al pacchetto originale\\
- \textit{time to live} & 16 bit & \textsl{tempo di vita},
- ha lo stesso significato di
- \textit{hop limit}, vedi Tab.~\ref{tab:ipv6field}\\
- \textit{protocol} & 8 bit & \textsl{protocollo}
- identifica il tipo di pacchetto che segue
- la testata di IPv4\\
- \textit{header checksum} & 16 bit & \textsl{checksum di testata}, somma
- di controllo per la testata\\
- \textit{source IP} & 32 bit & \textsl{indirizzo di origine}\\
- \textit{destination IP} & 32 bit & \textsl{indirizzo di destinazione}\\
- \bottomrule
- \end{tabular}
- \caption{Legenda per il significato dei campi dell'intestazione di IPv4}
- \label{tab:IP_ipv4field}
- \end{center}
-\end{table}
-
-Oltre alle differenze precedenti, relative ai singoli campi nella testata,
-ulteriori caratteristiche che diversificano il comportamento di IPv4 da
-quello di IPv6 sono le seguenti:
-
-\begin{itemize}
-\item il broadcasting non è previsto in IPv6, le applicazioni che lo usano
- dovono essere reimplementate usando il multicasting (vedi
- \secref{sec:IP_multicast}), che da opzionale diventa obbligatorio.
-\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
-\item i router non possono più frammentare i pacchetti lungo il cammino, la
- frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
- capi della comunicazione (usando un'apposita estensione vedi
- \secref{sec:IP_ipv6_extens}).
-\item IPv6 richiede il supporto per il \textit{path MTU discovery} (cioè il
- protocollo per la selezione della massima lunghezza del pacchetto); seppure
- questo sia in teoria opzionale, senza di esso non sarà possibile inviare
- pacchetti più larghi della dimensione minima (576 bytes).
-\end{itemize}
-
-\section{Gli indirizzi di IPv6}
-\label{sec:IP_ipv6_addr}
-
-Come già abbondantemente anticipato la principale novità di IPv6 è
-costituita dall'ampliamento dello spazio degli indirizzi, che consente di avere
-indirizzi disponibili in un numero dell'ordine di quello degli atomi che
-costituiscono la terra.
-
-In realtà l'allocazione di questi indirizzi deve tenere conto della
-necessità di costruire delle gerarchie che consentano un instradamento
-rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle
-reti, il che comporta una riduzione drastica dei numeri utilizzabili; uno
-studio sull'efficienza dei vari sistemi di allocazione usati in altre
-architetture (come i sistemi telefonici) è comunque giunto alla conclusione
-che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di
-fornire più di un migliaio di indirizzi per ogni metro quadro della
-superficie terrestre.
-
-
-\subsection{La notazione}
-\label{sec:IP_ipv6_notation}
-Con un numero di bit quadruplicato non è più possibile usare la notazione
-coi numeri decimali di IPv4 per rappresentare un numero IP. Per questo gli
-indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri
-esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come
-separatore; cioè qualcosa del tipo
-\texttt{5f1b:df00:ce3e:e200:0020:0800:2078:e3e3}.
-
-
-Visto che la notazione resta comunque piuttosto pesante esistono alcune
-abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si
-può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è
-zero si può omettere del tutto, così come un insieme di zeri (ma questo
-solo una volta per non generare ambiguità) per cui il precedente indirizzo
-si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
-
-Infine per scrivere un indirizzo IPv4 all'interno di un indirizzo IPv6 si
-può usare la vecchia notazione con i punti, per esempio
-\texttt{::192.84.145.138}.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}{|l|l|l|}
- \hline
- \centering \textbf{Tipo di indirizzo}
- & \centering \textbf{Prefisso} & {\centering \textbf{Frazione}} \\
- \hline
- \hline
- riservato & \texttt{0000 0000} & 1/256 \\
- non assegnato & \texttt{0000 0001} & 1/256 \\
- \hline
- riservato per NSAP & \texttt{0000 001} & 1/128\\
- riservato per IPX & \texttt{0000 010} & 1/128\\
- \hline
- non assegnato & \texttt{0000 011} & 1/128 \\
- non assegnato & \texttt{0000 1} & 1/32 \\
- non assegnato & \texttt{0001} & 1/16 \\
- \hline
- provider-based & \texttt{001} & 1/8\\
- \hline
- non assegnato & \texttt{010} & 1/8 \\
- non assegnato & \texttt{011} & 1/8 \\
- geografic-based& \texttt{100} & 1/8 \\
- non assegnato & \texttt{101} & 1/8 \\
- non assegnato & \texttt{110} & 1/8 \\
- non assegnato & \texttt{1110} & 1/16 \\
- non assegnato & \texttt{1111 0} & 1/32 \\
- non assegnato & \texttt{1111 10} & 1/64 \\
- non assegnato & \texttt{1111 110} & 1/128 \\
- non assegnato & \texttt{1111 1100 0} & 1/512 \\
- \hline
- unicast link-local & \texttt{1111 1100 10} & 1/1024 \\
- unicast site-local & \texttt{1111 1100 11} & 1/1024 \\
- \hline
- \hline
- multicast & \texttt{1111 1111} & 1/256 \\
- \hline
- \end{tabular}
- \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più
- significativi}
- \label{tab:IP_ipv6addr}
-\end{table}
-
-
-\subsection{La architettura degli indirizzi di IPv6}
-\label{sec:IP_ipv6_addr_arch}
-
-Come per IPv4 gli indirizzi sono identificatori per una singola (indirizzi
-\textit{unicast}) o per un insieme (indirizzi \textit{multicast} e
-\textit{anycast}) di interfacce di rete.
-
-Gli indirizzi sono sempre assegnati all'interfaccia, non al nodo che la
-ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può
-essere identificato attraverso uno qualunque degli indirizzi unicast delle sue
-interfacce. A una interfaccia possono essere associati anche più indirizzi.
-
-IPv6 presenta tre tipi diversi di indirizzi: due di questi, gli indirizzi
-\textit{unicast} e \textit{multicast} hanno le stesse caratteristiche che in
-IPv4, un terzo tipo, gli indirizzi \textit{anycast} è completamente nuovo.
-In IPv6 non esistono più gli indirizzi \textit{broadcast}, la funzione di
-questi ultimi deve essere reimplementata con gli indirizzi \textit{multicast}.
-
-Gli indirizzi \textit{unicast} identificano una singola interfaccia i
-pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia,
-gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che
-un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
-(nel senso di distanza di routing) delle interfacce del gruppo, gli indirizzi
-\textit{multicast} identificano un gruppo di interfacce tale che un pacchetto
-mandato a uno di questi indirizzi viene inviato a tutte le interfacce del
-gruppo.
-
-In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo
-di indirizzo; in \tabref{tab:IP_ipv6addr} sono riportati i valori di detti
-bit e il tipo di indirizzo che loro corrispondente. I bit più significativi
-costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla
-base di questo che i vari tipi di indirizzi vengono identificati. Come si
-vede questa architettura di allocazione supporta l'allocazione di indirizzi
-per i provider, per uso locale e per il multicast; inoltre è stato riservato
-lo spazio per indirizzi NSAP, IPX e per le connessioni; gran parte dello
-spazio (più del 70\%) è riservato per usi futuri.
-
-Si noti infine che gli indirizzi \textit{anycast} non sono riportati in
-\tabref{tab:IP_ipv6addr} in quanto allocati al di fuori dello spazio di
-allocazione degli indirizzi unicast.
-
-\subsection{Indirizzi unicast \textit{provider-based}}
-\label{sec:IP_ipv6_unicast}
-
-Gli indirizzi \textit{provider-based} sono gli indirizzi usati per le
-comunicazioni globali, questi sono definiti nell'RFC 2073 e sono gli
-equivalenti degli attuali indirizzi delle classi da A a C.
-
-L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
-evitare i problemi di crescita delle tabelle di instradamento e una procedura
-efficiente di allocazione la struttura di questi indirizzi è organizzata fin
-dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è
-stato suddiviso in una serie di campi secondo lo schema riportato in
-\tabref{tab:IP_ipv6_unicast}.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{6mm}
- @{\vrule}p{16mm}@{\vrule}p{24mm}
- @{\vrule}p{30mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{@{}c@{}}{3}&\multicolumn{1}{c}{5 bit}&
- \multicolumn{1}{c}{$n$ bit}&\multicolumn{1}{c}{$56-n$ bit}&
- \multicolumn{1}{c}{64 bit} \\
- \hline
- \omit\vrule\hfill\vrule&\hspace{16mm} & & &\omit\hspace{76mm}\hfill\vrule\\
- \centering 010&
- \centering \textsl{Registry Id}&
- \centering \textsl{Provider Id}&
- \centering \textsl{Subscriber Id}&
- \textsl{Intra-Subscriber} \\
- \omit\vrule\hfill\vrule& & & &\omit\hspace{6mm}\hfill\vrule\\
- \hline
- \end{tabular}
-\caption{Formato di un indirizzo unicast \textit{provider-based}.}
-\label{tab:IP_ipv6_unicast}
-\end{table}
-
-Al livello più alto la IANA può delegare l'allocazione a delle autorità
-regionali (i Regional Register) assegnando ad esse dei blocchi di indirizzi; a
-queste autorità regionali è assegnato un Registry Id che deve seguire
-immediatamente il prefisso di formato. Al momento sono definite tre registri
-regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la
-possibilità di allocare indirizzi su base regionale; pertanto sono previsti
-i seguenti possibili valori per il \textsl{Registry Id};
-gli altri valori restano riservati per la IANA.
-\begin{table}[htb]
- \begin{center}
- \begin{tabular}{l l l}
- \textbf{Regione} & \textbf{Registro} & \textbf{Id} \\
- \toprule
- Nord America &INTERNIC & \texttt{11000} \\
- Europa & RIPE NCC & \texttt{01000} \\
- Asia & APNIC & \texttt{00100} \\
- Multi-regionale & IANA &\texttt{10000} \\
- \bottomrule
- \end{tabular}
- \caption{Valori dell'identificativo dei
- Regional Register allocati ad oggi.}
- \label{tab:IP_ipv6_regid}
- \end{center}
-\end{table}
-
-L'organizzazione degli indirizzi prevede poi che i due livelli successivi, di
-suddivisione fra \textit{Provider Id}, che identifica i grandi fornitori di
-servizi, e \textit{Subscriber Id}, che identifica i fruitori, sia gestita dai
-singoli registri regionali. Questi ultimi dovranno definire come dividere lo
-spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di
-58~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
-al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
-numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
-l'autorità di allocare i \textit{Subscriber Id} al loro interno.
-
-L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla
-gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based}
-lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la
-modalità più immediata è quella di usare uno schema del tipo mostrato in
-\tabref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
-MAC-address a 48~bit dello standard ethernet, scritto in genere nell'hardware
-delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{64mm}@{\vrule}p{16mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{c}{64 bit}&\multicolumn{1}{c}{16 bit}&
- \multicolumn{1}{c}{48 bit}\\
- \hline
- \omit\vrule\hfill\vrule&\hspace{16mm}&\omit\hspace{48mm}\hfill\vrule\\
- \centering \textsl{Subscriber Prefix}&
- \centering \textsl{Subnet Id}&
- \textsl{Interface Id}\\
- \omit\vrule\hfill\vrule& &\omit\hspace{6mm}\hfill\vrule\\
- \hline
- \end{tabular}
-\caption{Formato del campo \textit{Intra-subscriber} per un indirizzo unicast
- \textit{provider-based}.}
-\label{tab:IP_ipv6_uninterf}
-\end{table}
-
-Qualora si dovesse avere a che fare con una necessità di un numero più
-elevato di sottoreti, il precedente schema andrebbe modificato, per evitare
-l'enorme spreco dovuto all'uso dei MAC-address, a questo scopo si possono
-usare le capacità di autoconfigurazione di IPv6 per assegnare indirizzi
-generici con ulteriori gerarchie per sfruttare efficacemente tutto lo spazio
-di indirizzi.
-
-Un registro regionale può introdurre un ulteriore livello nella gerarchia
-degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei
-registri nazionali, quest'ultimi poi avranno il compito di gestire la
-attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
-paese coperto dal registro nazionale con le modalità viste in precedenza.
-Una tale ripartizione andrà effettuata all'interno dei soliti 58~bit come
-mostrato in \ntab.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{3mm}
- @{\vrule}p{10mm}@{\vrule}p{12mm}@{\vrule}p{18mm}
- @{\vrule}p{18mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{@{}c@{}}{3}&\multicolumn{1}{c}{5 bit}&
- \multicolumn{1}{c}{n bit}&\multicolumn{1}{c}{m bit}&
- \multicolumn{1}{c}{56-n-m bit}&\multicolumn{1}{c}{64 bit} \\
- \hline
- \omit\vrule\hfill\vrule& & & & &\omit\hspace{64mm}\hfill\vrule\\
- \centering \texttt{3}&
- \centering \textsl{Reg.}&
- \centering \textsl{Naz.}&
- \centering \textsl{Prov.}&
- \centering \textsl{Subscr.}&
- \textsl{Intra-Subscriber} \\
- \omit\vrule\hfill\vrule &&&&&\\
- \hline
- \end{tabular}
-\caption{Formato di un indirizzo unicast \textit{provider-based} che prevede
- un registro nazionale.}
-\label{tab:IP_ipv6_uninaz}
-\end{table}
-
-
-\subsection{Indirizzi ad uso locale}
-\label{sec:IP_ipv6_linksite}
-
-Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo
-localmente (all'interno di un sito o di una sottorete), e possono avere una
-unicità locale o globale.
-
-Questi indirizzi sono pensati per l'uso all'interno di un sito per mettere su
-una comunicazione locale immediata, o durante le fasi di autoconfigurazione
-prima di avere un indirizzo globale.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{10mm}@{\vrule}p{54mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{c}{10} &\multicolumn{1}{c}{54 bit} &
- \multicolumn{1}{c}{64 bit} \\
- \hline
- \omit\vrule\hfill\vrule & & \omit\hspace{64mm}\hfill\vrule\\
- \centering \texttt{FE80}&
- \centering\texttt{0000 . . . . . 0000} &
- Interface Id \\
- \omit\vrule\hfill\vrule & &\\
- \hline
-\end{tabular}
-\caption{Formato di un indirizzo \textit{link-local}.}
-\label{tab:IP_ipv6_linklocal}
-\end{table}
-
-Ci sono due tipi di indirizzi, \textit{link-local} e \textit{site-local}. Il
-primo è usato per un singolo link; la struttura è mostrata in \curtab, questi
-indirizzi iniziano sempre per \texttt{FE80} e vengono in genere usati per la
-configurazione automatica dell'indirizzo al bootstrap e per la ricerca dei
-vicini (vedi \ref{sec:IP_ipv6_autoconf}); un pacchetto che abbia tale
-indirizzo come sorgente o destinazione non deve venire ritrasmesso dai router.
-
-Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
-all'interno di un sito che non necessita di un prefisso globale; la struttura
-è mostrata in \ntab, questi indirizzi iniziano sempre per
-\texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del sito
-stesso; sono in sostanza gli equivalenti degli indirizzi riservati per reti
-private definiti su IPv4.
-Per entrambi gli indirizzi il campo \textit{Interface Id} è un
-identificatore che deve essere unico nel dominio in cui viene usato, un modo
-immediato per costruirlo è quello di usare il MAC-address delle schede di
-rete.
-
-\begin{table}[!h]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{10mm}@{\vrule}p{38mm}@{\vrule}p{16mm}
- @{\vrule}c@{\vrule}}
- \multicolumn{1}{c}{10} &\multicolumn{1}{c}{38 bit} &
- \multicolumn{1}{c}{16 bit} &\multicolumn{1}{c}{64 bit} \\
- \hline
- \omit\vrule\hfill\vrule& & & \omit\hspace{64mm}\hfill\vrule\\
- \centering \texttt{FEC0}&
- \centering \texttt{0000 . . . 0000}&
- \centering Subnet Id &
- Interface Id\\
- \omit\vrule\hfill\vrule& & &\\
- \hline
-\end{tabular}
-\caption{Formato di un indirizzo \textit{site-local}.}
-\label{tab:IP_ipv6_sitelocal}
-\end{table}
-
-Gli indirizzi di uso locale consentono ad una organizzazione che non è
-(ancora) connessa ad Internet di operare senza richiedere un prefisso globale,
-una volta che in seguito l'organizzazione venisse connessa a Internet
-potrebbe continuare a usare la stessa suddivisione effettuata con gli
-indirizzi \textit{site-local} utilizzando un prefisso globale e la
-rinumerazione degli indirizzi delle singole macchine sarebbe automatica.
-
-\subsection{Indirizzi riservati}
-\label{sec:IP_ipv6_reserved}
-
-Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
-di compatibilità.
-
-Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
-\ntab), questo sono indirizzi unicast che vengono usati per consentire ad
-applicazioni IPv6 di comunicare con host capaci solo di IPv4; questi sono ad
-esempio gli indirizzi generati da un DNS quando l'host richiesto supporta solo
-IPv4; l'uso di un tale indirizzo in un socket IPv6 comporta la generazione di
-un pacchetto IPv4 (ovviamente occorre che sia IPv4 che IPv6 siano supportate
-sull'host di origine).
-
-\begin{table}[!htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{80mm}@{\vrule}p{16mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{c}{80 bit} &\multicolumn{1}{c}{16 bit} &
- \multicolumn{1}{c}{32 bit} \\
- \hline
- \omit\vrule\hfill\vrule& &\omit\hspace{32mm}\hfill\vrule\\
- \centering
- \texttt{0000 . . . . . . . . . . . . 0000} &
- \centering\texttt{FFFF} &
- IPv4 address \\
- \omit\vrule\hfill\vrule& &\\
- \hline
-\end{tabular}
-\caption{Formato di un indirizzo IPV4 mappato su IPv6.}
-\label{tab:IP_ipv6_map}
-\end{table}
-
-Un secondo tipo di indirizzi di compatibilità sono gli \textit{IPv4
- compatibili IPv6} (vedi \ntab) usati nella transizione da IPv4 a IPv6,
-quando un host che supporta sia IPv6 che IPv4 non ha un router IPv6 deve usare
-nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6 inviato a un tale
-indirizzo verrà automaticamente incapsulato in IPv4.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{80mm}@{\vrule}p{16mm}@{\vrule}p{32mm}@{\vrule}}
- \multicolumn{1}{c}{80 bit} &\multicolumn{1}{c}{16 bit} &
- \multicolumn{1}{c}{32 bit} \\
- \hline
- \omit\vrule\hfill\vrule& &\omit\hspace{32mm}\hfill\vrule\\
- \centering
- \texttt{0000 . . . . . . . . . . . . 0000} &
- \centering\texttt{0000} &
- \parbox{32mm}{\centering IPv4 address} \\
- \omit\vrule\hfill\vrule& &\\
- \hline
-\end{tabular}
-\caption{Formato di un indirizzo IPV4 mappato su IPv6.}
-\label{tab:IP_ipv6_comp}
-\end{table}
-
-Altri indirizzi speciali sono il \textit{loopback address}, costituito da 127
-zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico}
-costituito da tutti zeri (scritto come \texttt{0::0} o ancora più
-semplicemente come \texttt{:}) usato in genere quando si vuole indicare
-l'accettazione di una connessione da qualunque host.
-
-\subsection{Multicasting}
-\label{sec:IP_ipv6_multicast}
-
-Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
-gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
-multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo.
-Un'interfaccia può appartenere ad un numero qualunque numero di gruppi di
-multicast. Il formato degli indirizzi \textit{multicast} è riportato in
-\ntab:
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {@{\vrule}p{12mm}
- @{\vrule}p{6mm}@{\vrule}p{6mm}@{\vrule}c@{\vrule}}
- \multicolumn{1}{c}{8}&\multicolumn{1}{c}{4}&
- \multicolumn{1}{c}{4}&\multicolumn{1}{c}{112 bit} \\
- \hline
- \omit\vrule\hfill\vrule& & & \omit\hspace{104mm}\hfill\vrule\\
- \centering\texttt{FF}&
- \centering flag &
- \centering scop&
- Group Id\\
- \omit\vrule\hfill\vrule &&&\\
- \hline
- \end{tabular}
-\caption{Formato di un indirizzo \textit{multicast}.}
-\label{tab:IP_ipv6_multicast}
-\end{table}
-
-Il prefisso di formato per tutti gli indirizzi \textit{multicast} è
-\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente:
-
-\begin{itemize}
-\item \textsl{flag}: un insieme di 4 bit, di cui i primi tre sono riservati e
- posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un
- indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è
- transitorio.
-\item \textsl{scop} è un numero di quattro bit che indica il raggio di
- validità dell'indirizzo, i valori assegnati per ora sono riportati in
- \ntab.
-\end{itemize}
-
-Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che
-transitorio, all'interno del raggio di validità del medesimo.
-
-\begin{table}[!htb]
- \centering
- \footnotesize
- \begin{tabular}[c]{c l c l}
- \multicolumn{4}{c}{\bf Gruppi di multicast} \\
- \toprule
- 0 & riservato & 8 & organizzazione locale \\
- 1 & nodo locale & 9 & non assegnato \\
- 2 & collegamento locale & A & non assegnato \\
- 3 & non assegnato & B & non assegnato \\
- 4 & non assegnato & C & non assegnato \\
- 5 & sito locale & D & non assegnato \\
- 6 & non assegnato & E & globale \\
- 7 & non assegnato & F & riservato \\
- \bottomrule
- \end{tabular}
-\caption{Possibili valori del campo \textsl{scop} di un indirizzo multicast.}
-\label{tab:IP_ipv6_multiscope}
-\end{table}
-
-\subsection{Indirizzi \textit{anycast}}
-\label{sec:IP_anycast}
-
-Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
-gruppo di interfacce per quali un pacchetto indirizzato a questo tipo di
-indirizzo viene inviato al componente del gruppo più ``vicino'' secondo la
-distanza di instradamento calcolata dai router.
-
-Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast,
-usando uno dei formati disponibili, e per questo, sono da essi assolutamente
-indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce
-(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere
-configurato per tener conto del fatto.
-
-Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una
-destinazione su un gruppo di possibili interfacce selezionate. La sorgente non
-deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca
-al sistema di instradamento, (in sostanza la sorgente non ha nessun controllo
-sulla selezione).
-
-Gli indirizzi anycast, quando vengono usati come parte di una sequenza di
-instradamento, consentono ad esempio ad un nodo di scegliere quale fornitore
-vuole usare (configurando gli indirizzi anycast per identificare i router di
-uno stesso provider).
-
-Questi indirizzi pertanto possono essere usati come indirizzi intermedi in una
-testata di instradamento o per identificare insiemi di router connessi a una
-particolare sottorete, o che forniscono l'accesso a un certo sotto dominio.
-
-L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
-poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
-una serie di problematiche, visto che una connessione con uno di questi
-indirizzi non è possibile, dato che per una variazione delle distanze di
-routing non è detto che due pacchetti successivi finiscano alla stessa
-interfaccia.
-
-La materia è pertanto ancora controversa e in via di definizione.
-
-
-\section{Le estensioni}
-\label{sec:IP_ipv6_extens}
-
-Come già detto in precedenza IPv6 ha completamente cambiato il trattamento
-delle opzioni; queste ultime infatti sono state tolte dalla testata del
-pacchetto, e poste in apposite \textsl{testate di estensione} (o
-\textit{extension header}) poste fra la testata di IPv6 e la testata del
-protocollo di trasporto.
-
-Per aumentare la velocità di processo, sia dei dati del livello seguente che
-di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di
-8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti.
-
-Dato che la maggior parte di queste estensioni non sono esaminate dai router
-durante l'instradamento e la trasmissione dei pacchetti, ma solo all'arrivo
-alla destinazione finale, questa scelta ha consentito un miglioramento delle
-prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame
-di tutte quante.
-
-Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
-lunghezza arbitraria e non limitate a 40 bytes; questo, insieme al modo in cui
-vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
-sicurezza, improponibili con IPv4.
-
-Le estensioni definite al momento sono le seguenti:
-\begin{itemize}
-\item \textbf{Hop by hop} devono seguire immediatamente la testata principale;
- indicano le opzioni che devono venire processate ad ogni passaggio da un
- router, fra di esse è da menzionare la \textit{jumbo payload} che segnala
- la presenza di un pacchetto di dati di dimensione superiore a 64Kb.
-\item \textbf{Destination options} opzioni che devono venire esaminate al nodo
- di ricevimento, nessuna di esse è tuttora definita.
-\item \textbf{Routing} definisce una \textit{source route} (come la analoga
- opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il
- pacchetto deve passare.
-\item \textbf{Fragmentation} viene generato automaticamente quando un host
- vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
- destinazione che riassembla i frammenti.
-\item \textbf{Authentication} gestisce l'autenticazione e il controllo di
- integrità dei pacchetti; è documentato dall'RFC 162.
-\item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
- trasmesso; è documentato dall'RFC 1827.
-\end{itemize}
-
-La presenza di opzioni è rilevata dal valore del campo \textit{next header}
-che indica qual'è la testata successiva a quella di IPv6; in assenza di
-opzioni questa sarà la testata di un protocollo di trasporto del livello
-superiore, per cui il campo assumerà lo stesso valore del campo
-\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
-presente; i valori possibili sono riportati in \ntab.
-
-\begin{table}[htb]
- \begin{center}
- \footnotesize
- \begin{tabular}{c l l}
- \textbf{Valore} & \textbf{Keyword} & \textbf{Tipo di protocollo} \\
- \hline
- \hline
- 0 & & riservato\\
- & HBH & Hop by Hop \\
- 1 & ICMP & Internet Control Message (IPv4 o IPv6) \\
- 2 & ICMP & Internet Group Management (IPv4) \\
- 3 & GGP & Gateway-to-Gateway \\
- 4 & IP & IP in IP (IPv4 encapsulation) \\
- 5 & ST & Stream \\
- 6 & TCP & Trasmission Control \\
- 17 & UDP & User Datagram \\
- 43 & RH & Routing Header (IPv6) \\
- 44 & FH & Fragment Header (IPv6) \\
- 45 & IDRP & Inter Domain Routing \\
- 51 & AH & Autentication Header (IPv6) \\
- 52 & ESP & Encrypted Security Payload (IPv6) \\
- 59 & Null & No next header (IPv6) \\
- 88 & IGRP & Internet Group Routing \\
- 89 & OSPF & Open Short Path First \\
- 255& & riservato \\
- \end{tabular}
- \caption{Tipi di protocolli e testate di estensione}
- \label{tab:IP_ipv6_nexthead}
- \end{center}
-\end{table}
-
-Questo meccanismo permette la presenza di più opzioni in successione prima
-del pacchetto del protocollo di trasporto; l'ordine raccomandato per le
-estensioni è quello riportato nell'elenco precedente con la sola differenza
-che le opzioni di destinazione sono inserite nella posizione ivi indicata solo
-se, come per il tunnelling, devono essere esaminate dai router, quelle che
-devono essere esaminate solo alla destinazione finale vanno in coda.
-
-
-\section{Qualità di servizio}
-\label{sec:IP_ipv6_qos}
-
-Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un
-supporto per la qualità di servizio che è importante per applicazioni come
-quelle multimediali o ``real-time'' che richiedono un qualche grado di
-controllo sulla stabilità della banda di trasmissione, sui ritardi o la
-dispersione dei temporale del flusso dei pacchetti.
-
-
-\subsection{Etichette di flusso}
-\label{sec:IP_ipv6_flow}
-L'introduzione del campo \textit{flow label} può essere usata dall'origine
-della comunicazione per etichettare quei pacchetti per i quali si vuole un
-trattamento speciale da parte dei router come un una garanzia di banda minima
-assicurata o un tempo minimo di instradamento/trasmissione garantito.
-
-Questo aspetto di IPv6 è ancora sperimentale per cui i router che non
-supportino queste funzioni devono porre a zero il \textit{flow label} per i
-pacchetti da loro originanti e lasciare invariato il campo per quelli in
-transito.
-
-Un flusso è una sequenza di pacchetti da una particolare origine a una
-particolare destinazione per il quale l'origine desidera un trattamento
-speciale da parte dei router che lo manipolano; la natura di questo
-trattamento può essere comunicata ai router in vari modi (come un protocollo
-di controllo o con opzioni del tipo \textit{hop-by-hop}).
-
-Ci possono essere più flussi attivi fra un'origine e una destinazione, come
-del traffico non assegnato a nessun flusso, un flusso viene identificato
-univocamente dagli indirizzi di origine e destinazione e da una etichetta di
-flusso diversa da zero, il traffico normale deve avere l'etichetta di flusso
-posta a zero.
-
-L'etichetta di flusso è assegnata dal nodo di origine, i valori devono
-essere scelti in maniera (pseudo)casuale nel range fra 1 e FFFFFF in modo da
-rendere utilizzabile un qualunque sottoinsieme dei bit come chiavi di hash per
-i router.
-
-\subsection{Priorità}
-\label{sec:prio}
-
-Il campo di priorità consente di indicare il livello di priorità dei
-pacchetti relativamente agli altri pacchetti provenienti dalla stessa
-sorgente. I valori sono divisi in due intervalli, i valori da 0 a 7 sono usati
-per specificare la priorità del traffico per il quale la sorgente provvede
-un controllo di congestione cioè per il traffico che può essere ``tirato
-indietro'' in caso di congestione come quello di TCP, i valori da 8 a 15 sono
-usati per i pacchetti che non hanno questa caratteristica, come i pacchetti
-``real-time'' inviati a ritmo costante.
-
-Per il traffico con controllo di congestione sono raccomandati i seguenti
-valori di priorità a seconda del tipo di applicazione:
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular} {c l}
- Valore & tipo di traffico \\
- \toprule
- 0 & traffico generico \\
- 1 & traffico di riempimento (es. news) \\
- 2 & trasferimento dati non interattivo (es. e-mail)\\
- 3 & riservato \\
- 4 & trasferimento dati interattivo (es. FTP, HTTP, NFS) \\
- 5 & riservato \\
- 6 & traffico interattivo (telnet, X)\\
- 7 & traffico di controllo (routing, SNMP) \\
- \bottomrule
-\end{tabular}
-\caption{Formato di un indirizzo \textit{site-local}.}
-\label{tab:priority}
-\end{table}
-
-Per il traffico senza controllo di congestione la priorità più bassa
-dovrebbe essere usata per quei pacchetti che si preferisce siano scartati
-più facilmente in caso di congestione.
-
-
-\section{Sicurezza a livello IP}
-\label{sec:security}
-
-La attuale implementazione di Internet presenta numerosi problemi di
-sicurezza, in particolare i dati presenti nelle testate dei vari protocolli
-sono assunti essere corretti, il che da adito alla possibilità di varie
-tipologie di attacco forgiando pacchetti false, inoltre tutti questi dati
-passano in chiaro sulla rete e sono esposti all'osservazione di chiunque si
-trovi in mezzo.
-
-Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
-riservatezza a un livello inferiore al primo (quello di applicazione), con
-IPv6 è stato progettata la possibilità di intervenire al livello del
-collegamento (il terzo) prevendo due apposite estensioni che possono essere
-usate per fornire livelli di sicurezza a seconda degli utenti. La codifica
-generale di questa architettura è riportata nell'RFC 2401.
-
-Il meccanismo in sostanza si basa su due estensioni:
-\begin{itemize}
-\item una testata di sicurezza (\textit{autentication header}) che garantisce
- al destinatario l'autenticità del pacchetto
-\item un carico di sicurezza (\textit{Encrypted Security Payload}) che
- assicura che solo il legittimo ricevente può leggere il pacchetto.
-\end{itemize}
-
-Perché tutto questo funzioni le stazioni sorgente e destinazione devono
-usare una stessa chiave crittografica e gli stessi algoritmi, l'insieme degli
-accordi fra le due stazioni per concordare chiavi e algoritmi usati va sotto
-il nome di associazione di sicurezza.
-
-I pacchetti autenticati e crittografati portano un indice dei parametri di
-sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima
-di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
-multicast dovà essere lo stesso per tutte le stazioni del gruppo.
-
-\subsection{Autenticazione}
-Il primo meccanismo di sicurezza è quello della testata di autenticazione
-(\textit{autentication header}) che fornisce l'autenticazione e il controllo
-di integrità (ma senza riservatezza) dei pacchetti IP.
-
-La testata di autenticazione ha il formato descritto in
-Tab.~\ref{tab:autent_head} il campo \textit{Next Header} indica la testata
-successiva, con gli stessi valori del campo omonimo nella testata principale
-di IPv6, il campo \textit{Lengh} indica la lunghezza della testata di
-autenticazione in numero di parole a 32 bit, il campo riservato deve essere
-posto a zero, seguono poi l'indice di sicurezza, stabilito nella associazione
-di sicurezza, e un numero di sequenza che la stazione sorgente deve
-incrementare di pacchetto in pacchetto.
-
-Completano la testata i dati di autenticazione che contengono un valore di
-controllo di intgrità (ICV, \textit{Integrity Check Value}), che deve essere
-di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
-per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione
-devono provvedere questa capacità.
-
-\renewcommand\arraystretch{1.2}
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{@{\vrule}p{24mm}@{\vrule}p{24mm}
- @{\vrule}p{48mm}@{\vrule} }
- \multicolumn{3}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering Next Header&\centering Lenght&
- \centering Reserved \tabularnewline
- \hline
- \multicolumn{3}{@{\vrule}c@{\vrule}}
- {\centering Security Parameter Index (SPI)}\\
- \hline
- \multicolumn{3}{@{\vrule}c@{\vrule}}
- {\centering Sequence Number}\\
- \hline
- \multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{3}{@{\vrule}c@{\vrule}}{Autentication Data} \\
- \multicolumn{3}{@{\vrule}c@{\vrule}}
- {\centering ... } \\
- \multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{Formato della testata dell'estensione di autenticazione}
- \label{tab:autent_estens}
- \end{center}
-\end{table}
-\renewcommand\arraystretch{1} %default
-
-
-
-La testata di autenticazione può essere impiegata in due modi diverse
-modalità: modalità trasporto e modalità tunnel.
-
-La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
-singole che supportino l'autenticazione. In questo caso la testata di
-autenticazione è inserita dopo tutte le altre testate di estensione
-eccezion fatta per la \textit{Destination Option} che può comparire sia
-prima che dopo.
-
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular*}{90mm}{|c|c|c|c|c|c|}
- \hline
- & & & & & \\
- IP Head &
- \parbox[c]{28mm}{hop by hop, dest., \\
- routing, fragment}& AH &
- dest.opt & TCP & data \\
- & & & & & \\
- \hline
- \end{tabular*}
- \caption{Formato della testata dell'estensione di autenticazione}
- \label{tab:autent_head}
- \end{center}
-\end{table}
-\begin{center}
- \begin{pspicture}(0,0)(9,0.8)
- \pnode(0,0){A}
- \pnode(9,0.4){B}
- \ncline{<->}{A}{B}\ncput{copertura dell'autenticazione}
- \end{pspicture}
-\end{center}
-
-La modalit`\a tunnel può essere utilizzata sia per comunicazioni fra stazioni
-singole che con un gateway di sicurezza; in questa modalità
-
-
-La testata di autenticazione è una testata di estensione inserita dopo la
-testata principale e prima del carico dei dati. La sua presenza non ha
-perciò alcuna influenza sui livelli superiori dei protocolli di trasmissione
-come il TCP.
-
-
-
-
-
-La procedura di autenticazione cerca di garantire l'autenticità del
-pacchetto nella massima estensione possibile, ma dato che alcuni campi della
-testata di IP possono variare in maniera impredicibile alla sorgente, il loro
-valore non può essere protetto dall'autenticazione.
-
-Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
-versione speciale del pacchetto in cui il numero di salti nella testata
-principale è settato a zero, così come le opzioni che possono essere
-modificate nella trasmissione, e la testata di routing (se usata) è posta ai
-valori che deve avere all'arrivo.
-
-L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
-ancora in fase di definizione; attualmente è stato suggerito l'uso di una
-modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
-una chiave che viene inserita all'inizio e alla fine degli altri campi.
-
-\subsection{Riservatezza}
-\label{sec:ecry}
-
-Per garantire una trasmissione riservata dei dati, è stata previsto la
-possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
-\textit{Encripted Security Payload}. Questo viene realizzato usando con una
-apposita opzione che deve essere sempre l'ultima delle testate di estensione;
-ad essa segue il carico del pacchetto che viene criptato.
-
-Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
-quella mostrata in Tab~.\ref{tab:criptopack}, tutti i campi sono in chiaro
-fino al vettore di inizializzazione, il resto è crittografato.
-
-\renewcommand\arraystretch{1.2}
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{@{\vrule}p{24mm}@{\vrule}p{24mm}@{\vrule}
- p{24mm}@{\vrule}p{24mm}@{\vrule}}
- \multicolumn{4}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{Testata Principale}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
- \hline
- \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{Testate di estensione}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
- \hline
- \multicolumn{4}{@{\vrule}c@{\vrule}}
- {\centering Security Parameter Index}\\
- \hline
- \multicolumn{4}{@{\vrule}c@{\vrule}}
- {\centering Vettore}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}
- {\centering di inizializzazione}\\
- \hline
- \multicolumn{4}{@{\vrule}c@{\vrule}}{carico}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{crittografato}\\
- \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
- \cline{2-4}
- & \multicolumn{3}{c@{\vrule}}{}\\
- \cline{1-1}
- \cline{3-4}
- \multicolumn{1}{@{\vrule}c}{}&
- \centering \raisebox{2mm}[0pt][0pt]{riempimento} &
- \centering lunghezza pad &\centering tipo carico\tabularnewline
- \hline
- \end{tabular}
- \caption{Schema di pacchetto crittografato}
- \label{tab:criptopack}
- \end{center}
-\end{table}
-\renewcommand\arraystretch{1} %default
-
-
-\section{Autoconfigurazione}
-\label{sec:autoconf}
-
projects / gapil.git / commitdiff
