From: Simone Piccardi <piccardi@gnulinux.it>
Date: Sat, 11 Aug 2001 21:05:15 +0000 (+0000)
Subject: Al posto delle vecchie appendici
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=cadf0f8e71e639a376e45e560c9c7f8ccf2eca04;p=gapil.git

Al posto delle vecchie appendici
---

diff --git a/ipprot.tex b/ipprot.tex
new file mode 100644
index 0000000..5c85730
--- /dev/null
+++ b/ipprot.tex
@@ -0,0 +1,1347 @@
+\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}
+
diff --git a/tcpprot.tex b/tcpprot.tex
new file mode 100644
index 0000000..48d2dd8
--- /dev/null
+++ b/tcpprot.tex
@@ -0,0 +1,3 @@
+\chapter{Il protocollo TCP}
+\label{cha:tcp_protocol}
+