+%% ipprot.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
+
+
+
+\chapter{Il livello di rete}
+\label{cha:network_layer}
+
+In questa appendice prenderemo in esame i vari protocolli disponibili a
+livello di rete.\footnote{per la spiegazione della suddivisione in livelli dei
+ protocolli di rete, si faccia riferimento a quanto illustrato in
+ \secref{sec:net_protocols}.} Per ciascuno di essi forniremo una descrizione
+generica delle principlai caratteristiche, del formato di dati usato e quanto
+possa essere necessario per capirne meglio il funzionamento dal punto di vista
+della programmazione.
+
+Data la loro prevelenza il capitolo sarà sostanzialmente incentrato sui due
+protocolli principali esistenti su questo livello: l'\textit{Internet
+ Protocol} IP (che più propriamente si dovrebbe chiamare IPv4) ed la sua
+nuova versione denominata IPv6.
+
+
+\section{Il protocollo IP}
+\label{sec:ip_protocol}
+
+L'attuale \textit{Internet 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.).
+
+
+\subsection{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
+\tabref{tab:IP_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, \textit{Classless Inter-Domain Routing}) 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 \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{Il protocollo IPv6}
+\label{sec:ipv6_protocol}
+
+Negli anni '90 con la crescita del numero di macchine connesse su Internet si
+arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili, specie
+in vista di una prospettiva (per ora rivelatasi prematura) in cui ogni
+apparecchio elettronico sarebbe stato inserito all'interno della rete.
+
+Per questo motivo si iniziò a progettare una nuova versione del protocollo
+
+L'attuale Internet 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.).
+
+
+\subsection{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 attualmente
+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}
+
+
+\subsection{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 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 dell'intestazione, 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}
+
+
+\subsection{L'intestazione 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
+\figref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+confrontare con quella di IPv4 in \figref{fig:IP_ipv4_head}. La spiegazione del
+significato dei vari campi delle due intestazioni è 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 length} &
+% \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{L'intestazione o \textit{header} di IPv6}
+% \label{tab:IP_ipv6head}
+% \end{center}
+% \end{table}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/ipv6_head}
+ \caption{L'intestazione o \textit{header} di IPv6.}
+ \label{fig:IP_ipv6head}
+\end{figure}
+
+
+Come si può notare l'intestazione 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}|}
+ \hline
+ \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
+ \hline
+ \hline
+ \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 length} & 16 bit &
+ \textsl{lunghezza del carico}, cioè del corpo dei dati che segue
+ l'intestazione, in byte. \\
+ \textit{next header} & 8 bit & \textsl{intestazione successiva},
+ identifica il tipo di pacchetto che segue l'intestazione di IPv6, usa
+ gli stessi valori del campo protocollo nell'intestazione di IPv4\\
+ \textit{hop limit} & 8 bit & \textsl{limite di salti},
+ stesso significato del \textit{time to live} nell'intestazione 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}\\
+ \hline
+ \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 minimo il tempo di
+processamento dei pacchetti da parte dei router, un confronto con
+l'intestazione di IPv4 (vedi \figref{fig:IP_ipv4_head}) mostra le seguenti
+differenze:
+
+\begin{itemize}
+\item è stato eliminato il campo \textit{header length} in quanto le opzioni
+ sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
+ essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
+ \secref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
+ lunghezza all'interno.
+\item l'intestazione 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 intestazione e ai dati, pure i campi
+ \textit{payload length}, \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 funzionalità 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
+ ``\textsl{qualità di servizio}'' (vedi \secref{sec:IP_ipv6_qos}) che
+ permette di identificare i pacchetti appartenenti a un ``\textsl{flusso}''
+ di dati per i quali si può provvedere un trattamento speciale.
+\end{itemize}
+
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/ipv4_head}
+ \caption{L'intestazione o \textit{header} di IPv4.}
+ \label{fig:IP_ipv4_head}
+\end{figure}
+
+\begin{table}[htb]
+ \footnotesize
+ \begin{center}
+ \begin{tabular}{|l|c|p{9cm}|}
+ \hline
+ \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
+ \hline
+ \hline
+ \textit{version} & 4 bit & \textsl{versione}, nel caso
+ specifico vale sempre 4\\
+ \textit{head length} & 4 bit &\textsl{lunghezza dell'intestazione},
+ 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 length} & 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 della
+ 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:IP_ipv6field}\\
+ \textit{protocol} & 8 bit & \textsl{protocollo}
+ identifica il tipo di pacchetto che segue
+ l'intestazione di IPv4\\
+ \textit{header checksum} & 16 bit & \textsl{checksum di intestazione},
+ somma di controllo per l'intestazione\\
+ \textit{source IP} & 32 bit & \textsl{indirizzo di origine}\\
+ \textit{destination IP} & 32 bit & \textsl{indirizzo di destinazione}\\
+ \hline
+ \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 nell'intestazione,
+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_ipv6_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 byte).
+\end{itemize}
+
+\subsection{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|}
+ \hline
+ \textbf{Regione} & \textbf{Registro} & \textbf{Id} \\
+ \hline
+ \hline
+ Nord America &INTERNIC & \texttt{11000} \\
+ Europa & RIPE NCC & \texttt{01000} \\
+ Asia & APNIC & \texttt{00100} \\
+ Multi-regionale & IANA &\texttt{10000} \\
+ \hline
+ \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
+56~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 56~bit come
+mostrato in \tabref{tab:IP_ipv6_uninaz}.
+
+\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
+\tabref{tab:IP_ipv6_linklocal}, 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 \tabref{tab:IP_ipv6_sitelocal}, 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
+\tabref{tab:IP_ipv6_map}), 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 supportati 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 \tabref{tab:IP_ipv6_comp}) usati nella transizione
+da IPv4 a IPv6: quando un nodo 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
+\tabref{tab:IP_ipv6_multicast}:
+
+\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
+ \tabref{tab:IP_ipv6_multiscope}.
+\end{itemize}
+
+
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|c|l|}
+ \hline
+ \multicolumn{4}{|c|}{\bf Gruppi di multicast} \\
+ \hline
+ \hline
+ 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 \\
+ \hline
+ \end{tabular}
+\caption{Possibili valori del campo \textsl{scop} di un indirizzo multicast.}
+\label{tab:IP_ipv6_multiscope}
+\end{table}
+
+Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che
+transitorio, all'interno del raggio di validità del medesimo. Alcuni
+indirizzi multicast, riportati in \tabref{tab:multiadd} sono già riservati
+per il funzionamento della rete.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{l l r}
+ \hline
+ \textbf{Uso}& \textbf{Indirizzi riservati} & \textbf{Definizione}\\
+ \hline
+ \hline
+ all-nodes & \texttt{FFxx:0:0:0:0:0:0:1} & RFC 1970\\
+ all-routers & \texttt{FFxx:0:0:0:0:0:0:2} & RFC 1970\\
+ all-rip-routers & \texttt{FFxx:0:0:0:0:0:0:9} & RFC 2080\\
+ all-cbt-routers & \texttt{FFxx:0:0:0:0:0:0:10} &\\
+ reserved & \texttt{FFxx:0:0:0:0:0:1:0} & IANA \\
+ link-name & \texttt{FFxx:0:0:0:0:0:1:1} & \\
+ all-dhcp-agents & \texttt{FFxx:0:0:0:0:0:1:2} & \\
+ all-dhcp-servers & \texttt{FFxx:0:0:0:0:0:1:3} & \\
+ all-dhcp-relays & \texttt{FFxx:0:0:0:0:0:1:4} & \\
+ solicited-nodes & \texttt{FFxx:0:0:0:0:1:0:0} & RFC 1970\\
+ \hline
+ \end{tabular}
+\caption{Gruppi multicast predefiniti.}
+\label{tab:multiadd}
+\end{table}
+
+L'utilizzo del campo di \textit{scope} e di questi indirizzi predefiniti serve
+a recuperare le funzionalità del broadcasting (ad esempio inviando un
+pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si raggiungono tutti i
+nodi locali).
+
+
+\subsection{Indirizzi \textit{anycast}}
+\label{sec:IP_anycast}
+
+Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
+gruppo di interfacce: un pacchetto indirizzato a questo tipo di indirizzo
+viene inviato al componente del gruppo più ``\textsl{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
+intestazione 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.
+
+
+\subsection{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 dall'intestazione del
+pacchetto, e poste in apposite \textsl{intestazioni di estensione} (o
+\textit{extension header}) poste fra l'intestazione di IPv6 e l'intestazione
+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 byte per mantenere l'allineamento a 64~bit di tutti le intestazioni
+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 byte; 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 l'intestazione
+ 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 65535 byte.
+\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'è l'intestazione successiva a quella di IPv6; in assenza di
+opzioni questa sarà l'intestazione 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 \tabref{tab:IP_ipv6_nexthead}.
+
+\begin{table}[htb]
+ \begin{center}
+ \footnotesize
+ \begin{tabular}{|c|l|l|}
+ \hline
+ \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 & Authentication 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 \\
+ \hline
+ \end{tabular}
+ \caption{Tipi di protocolli e intestazioni 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.
+
+
+\subsection{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|}
+ \hline
+ \textbf{Valore} & \textbf{Tipo di traffico} \\
+ \hline
+ \hline
+ 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 \\
+ \hline
+\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.
+
+
+\subsection{Sicurezza a livello IP}
+\label{sec:security}
+
+La attuale implementazione di Internet presenta numerosi problemi di
+sicurezza, in particolare i dati presenti nelle intestazioni 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 di rete (il
+terzo) prevedendo 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 intestazione di sicurezza (\textit{authentication 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 dovrà essere lo stesso per tutte le stazioni del gruppo.
+
+\subsection{Autenticazione}
+\label{sec:auth}
+
+Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
+(\textit{authentication header}) che fornisce l'autenticazione e il controllo
+di integrità (ma senza riservatezza) dei pacchetti IP.
+
+L'intestazione di autenticazione ha il formato descritto in
+\tabref{tab:autent_head}: il campo \textit{Next Header} indica l'intestazione
+successiva, con gli stessi valori del campo omonimo nell'intestazione
+principale di IPv6, il campo \textit{Length} indica la lunghezza
+dell'intestazione 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 l'intestazione i dati di autenticazione che contengono un valore di
+controllo di integrità (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 l'intestazione 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 Length&
+ \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}}{Authentication Data} \\
+ \multicolumn{3}{@{\vrule}c@{\vrule}}
+ {\centering ... } \\
+ \multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
+ \hline
+ \end{tabular}
+ \caption{Formato dell'intestazione dell'estensione di autenticazione}
+ \label{tab:autent_estens}
+ \end{center}
+\end{table}
+\renewcommand\arraystretch{1} %default
+
+
+L'intestazione 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 l'intestazione di
+autenticazione è inserita dopo tutte le altre intestazioni 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 dell'intestazione 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à tunnel può essere utilizzata sia per comunicazioni fra stazioni
+singole che con un gateway di sicurezza; in questa modalità
+
+
+L'intestazione di autenticazione è una intestazione di estensione inserita
+dopo l'intestazione 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 dell'intestazione
+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 nell'intestazione
+principale è impostato a zero, così come le opzioni che possono essere
+modificate nella trasmissione, e l'intestazione 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 intestazioni 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}}{Intestazione Principale}\\
+ \multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
+ \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
+ \hline
+ \multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
+ \multicolumn{4}{@{\vrule}c@{\vrule}}{Intestazioni 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
+
+
+\subsection{Autoconfigurazione}
+\label{sec:IP_ipv6_autoconf}
+
+Una delle caratteristiche salienti di IPv6 è quella dell'autoconfigurazione,
+il protocollo infatti fornisce la possibilità ad un nodo di scoprire
+automaticamente il suo indirizzo acquisendo i parametri necessari per potersi
+connettere a internet.
+
+L'autoconfigurazione sfrutta gli indirizzi link-local; qualora sul nodo sia
+presente una scheda di rete che supporta lo standard IEEE802 (ethernet) questo
+garantisce la presenza di un indirizzo fisico a 48 bit unico; pertanto il nodo
+può assumere automaticamente senza pericoli di collisione l'indirizzo
+link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
+l'indirizzo hardware della scheda di rete.
+
+Nel caso in cui non sia presente una scheda che supporta lo standard IEEE802
+allora il nodo assumerà ugualmente un indirizzo link-local della forma
+precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
+casualmente; in questo caso la probabilità di collisione è di 1 su 300
+milioni. In ogni caso per prevenire questo rischio il nodo invierà un
+messaggio ICMP \textit{Solicitation} all'indirizzo scelto attendendo un certo
+lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
+procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
+richiedendo assistenza).
+
+Una volta ottenuto un indirizzo locale valido diventa possibile per il nodo
+comunicare con la rete locale; sono pertanto previste due modalità di
+autoconfigurazione, descritte nelle seguenti sezioni. In ogni caso
+l'indirizzo link-local resta valido.
+
+\subsection{Autoconfigurazione stateless}
+\label{sec:stateless}
+
+Questa è la forma più semplice di autoconfigurazione, possibile quando
+l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
+semplicemente il prefisso a quello assegnato dal provider per ottenere un
+indirizzo globale.
+
+La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
+iniziano si devono aggregare al gruppo multicast \textit{all-nodes}
+programmando la propria interfaccia per ricevere i messaggi dall'indirizzo
+multicast \texttt{FF02::1} (vedi \secref{sec:IP_ipv6_multicast}); a questo
+punto devono inviare un messaggio ICMP \textit{Router solicitation} a tutti i
+router locali usando l'indirizzo multicast \texttt{FF02::2} usando come
+sorgente il proprio indirizzo link-local.
+
+Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
+fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
+messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
+contiene anche l'informazione che autorizza un nodo a autocostruire
+l'indirizzo, nel qual caso, se il prefisso unito all'indirizzo link-local non
+supera i 128 bit, la stazione ottiene automaticamente il suo indirizzo
+globale.
+
+\subsection{Autoconfigurazione stateful}
+\label{sec:stateful}
+
+Benché estremamente semplice l'autoconfigurazione stateless presenta alcuni
+problemi; il primo è che l'uso degli indirizzi delle schede di rete è
+molto inefficiente; nel caso in cui ci siano esigenze di creare una gerarchia
+strutturata su parecchi livelli possono non restare 48~bit per l'indirizzo
+della singola stazione; il secondo problema è di sicurezza, dato che basta
+introdurre in una rete una stazione autoconfigurante per ottenere un accesso
+legale.
+
+Per questi motivi è previsto anche un protocollo stateful basato su un
+server che offra una versione IPv6 del DHCP; un apposito gruppo di multicast
+\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il
+nodo interrogherà il server su questo indirizzo di multicast con l'indirizzo
+link-local e riceverà un indirizzo unicast globale.
+
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / commitdiff