%% ipprot.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2004 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",
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
+ sez.~\ref{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.
\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.).
+dall'\href{http://www.ietf.org/rfc/rfc719.txt}{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}
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.
+tab.~\ref{tab:IP_ipv4class}), per consentire dispiegamenti di reti di
+dimensioni diverse.
\begin{table}[htb]
\centering
\footnotesize
+ \begin{usepicture}
\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}
\omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
\cline{2-33}
-\end{tabular}
+ \end{tabular}
+ \end{usepicture}
\caption{Le classi di indirizzi secondo IPv4.}
\label{tab:IP_ipv4class}
\end{table}
è 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.
+Come si può notare però la suddivisione riportata in
+tab.~\ref{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
\begin{table}[htb]
\centering
\footnotesize
+ \begin{usepicture}
\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}
\multicolumn{20}{@{}c@{\vrule}}{\parbox[c]{60mm}{\centering host Id}} \\
\omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
\cline{2-33}
-\end{tabular}
+ \end{tabular}
+ \end{usepicture}
\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.
+finale può essere piazzato in qualunque punto (vedi
+tab.~\ref{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.
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.).
+dall'\href{http://www.ietf.org/rfc/rfc719.txt}{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}
\subsection{Principali caratteristiche di IPv6}
\label{sec:IP_ipv6over}
-Per rispondere alle esigenze descritte in \secref{sec:IP_whyipv6} IPv6 nasce
+Per rispondere alle esigenze descritte in sez.~\ref{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ù
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})
+fig.~\ref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+confrontare con quella di IPv4 in fig.~\ref{fig:IP_ipv4_head}. La spiegazione
+del significato dei vari campi delle due intestazioni è riportato
+rispettivamente in tab.~\ref{tab:IP_ipv6field} e tab.~\ref{tab:IP_ipv4field})
% \begin{table}[htb]
% \footnotesize
\textit{version} & 4 bit &
\textsl{versione}, nel caso specifico vale sempre 6\\
\textit{priority} & 4 bit &
- \textsl{priorità}, vedi Sez.~\ref{sec:prio} \\
+ \textsl{priorità}, vedi sez.~\ref{sec:prio} \\
\textit{flow label} & 24 bit &
- \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\
+ \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. \\
\end{center}
\end{table}
-Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali
+Abbiamo già anticipato in sez.~\ref{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
+l'intestazione di IPv4 (vedi fig.~\ref{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
+ sez.~\ref{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 è 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
+ ``\textsl{qualità di servizio}'' (vedi sez.~\ref{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{center}
\begin{tabular}{|l|c|p{9cm}|}
\hline
- \textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
+ \textbf{Nome} & \textbf{Bit} & \textbf{Significato} \\
\hline
\hline
- \textit{version} & 4 bit & \textsl{versione}, nel caso
+ \textit{version} & 4 & \textsl{versione}, nel caso
specifico vale sempre 4\\
- \textit{head length} & 4 bit &\textsl{lunghezza dell'intestazione},
+ \textit{head length} & 4 &\textsl{lunghezza dell'intestazione},
in multipli di 32 bit\\
- \textit{type of service} & 8 bit & \textsl{tipo di servizio},
+ \textit{type of service} & 8 & \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
+ \textit{total length} & 16 & \textsl{lunghezza totale}, indica
la dimensione del pacchetto IP in byte\\
- \textit{identification} & 16 bit & \textsl{identificazione},
+ \textit{identification} & 16 & \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 &
+ \textit{flag} & 3 &
\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},
+ \textit{fragmentation offset} & 13 & \textsl{offset di frammento},
indica la posizione del frammento rispetto al pacchetto originale\\
- \textit{time to live} & 16 bit & \textsl{tempo di vita},
+ \textit{time to live} & 16 & \textsl{tempo di vita},
ha lo stesso significato di
- \textit{hop limit}, vedi Tab.~\ref{tab:IP_ipv6field}\\
- \textit{protocol} & 8 bit & \textsl{protocollo}
+ \textit{hop limit}, vedi tab.~\ref{tab:IP_ipv6field}\\
+ \textit{protocol} & 8 & \textsl{protocollo}
identifica il tipo di pacchetto che segue
l'intestazione di IPv4\\
- \textit{header checksum} & 16 bit & \textsl{checksum di intestazione},
+ \textit{header checksum} & 16 & \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}\\
+ \textit{source IP} & 32 & \textsl{indirizzo di origine}\\
+ \textit{destination IP} & 32 & \textsl{indirizzo di destinazione}\\
\hline
\end{tabular}
\caption{Legenda per il significato dei campi dell'intestazione di IPv4}
\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.
+ sez.~\ref{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}).
+ sez.~\ref{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
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 \\
+ non assegnato & \texttt{1111 1110 0} & 1/512 \\
\hline
- unicast link-local & \texttt{1111 1100 10} & 1/1024 \\
- unicast site-local & \texttt{1111 1100 11} & 1/1024 \\
+ unicast link-local & \texttt{1111 1110 10} & 1/1024 \\
+ unicast site-local & \texttt{1111 1110 11} & 1/1024 \\
\hline
\hline
multicast & \texttt{1111 1111} & 1/256 \\
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
+di indirizzo; in tab.~\ref{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
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
+tab.~\ref{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
+comunicazioni globali, questi sono definiti
+nell'\href{http://www.ietf.org/rfc/rfc2073.txt}{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
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}.
+tab.~\ref{tab:IP_ipv6_unicast}.
\begin{table}[htb]
\centering
\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\\
+ \omit\vrule\hfill\vrule&\hspace{16mm} & & &\omit\hspace{76mm}\hfill\vrule\\
\centering 010&
\centering \textsl{Registry Id}&
\centering \textsl{Provider Id}&
i seguenti possibili valori per il \textsl{Registry Id};
gli altri valori restano riservati per la IANA.
\begin{table}[htb]
- \begin{center}
+ \centering
+ \footnotesize
\begin{tabular}{|l|l|l|}
\hline
\textbf{Regione} & \textbf{Registro} & \textbf{Id} \\
\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
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
+tab.~\ref{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.
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}.
+mostrato in tab.~\ref{tab:IP_ipv6_uninaz}.
\begin{table}[htb]
\centering
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.
+tab.~\ref{tab:IP_ipv6_linklocal}, questi indirizzi iniziano sempre con un
+valore nell'intervallo \texttt{FE80}--\texttt{FEBF} 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.
+è mostrata in tab.~\ref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano
+sempre con un valore nell'intervallo \texttt{FEC0}--\texttt{FEFF} 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
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
+potrebbe con4tinuare 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.
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
+tab.~\ref{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).
\end{table}
Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
- compatibili IPv6} (vedi \tabref{tab:IP_ipv6_comp}) usati nella transizione
+ compatibili IPv6} (vedi tab.~\ref{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.
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}:
+tab.~\ref{tab:IP_ipv6_multicast}:
\begin{table}[htb]
\centering
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}.
+ tab.~\ref{tab:IP_ipv6_multiscope}.
\end{itemize}
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
+indirizzi multicast, riportati in tab.~\ref{tab:multiadd} sono già riservati
per il funzionamento della rete.
\begin{table}[!htb]
\centering
\footnotesize
- \begin{tabular}[c]{l l r}
+ \begin{tabular}[c]{|l|l|l|}
\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\\
+ all-nodes & \texttt{FFxx:0:0:0:0:0:0:1} &
+ \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
+ all-routers & \texttt{FFxx:0:0:0:0:0:0:2} &
+ \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
+ all-rip-routers & \texttt{FFxx:0:0:0:0:0:0:9} &
+ \href{http://www.ietf.org/rfc/rfc2080.txt}{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} &
+ \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
\hline
\end{tabular}
\caption{Gruppi multicast predefiniti.}
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.
+ integrità dei pacchetti; è documentato
+ dall'\href{http://www.ietf.org/rfc/rfc1826.txt}{RFC~1826}.
\item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
- trasmesso; è documentato dall'RFC 1827.
+ trasmesso; è documentato
+ dall'\href{http://www.ietf.org/rfc/rfc1827.txt}{RFC~1827}.
\end{itemize}
La presenza di opzioni è rilevata dal valore del campo \textit{next header}
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}.
+presente; i valori possibili sono riportati in
+tab.~\ref{tab:IP_ipv6_nexthead}.
\begin{table}[htb]
\begin{center}
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.
+architettura è riportata
+nell'\href{http://www.ietf.org/rfc/rfc2401.txt}{RFC~2401}.
Il meccanismo in sostanza si basa su due estensioni:
\begin{itemize}
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,
+fig.~\ref{fig:autent_estens}: 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.
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
-
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=10cm]{img/ah_option}
+ \caption{Formato dell'intestazione dell'estensione di autenticazione.}
+ \label{fig:autent_estens}
+\end{figure}
L'intestazione di autenticazione può essere impiegata in due modi diverse
modalità: modalità trasporto e modalità tunnel.
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}
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=10cm]{img/IP_AH_packet}
+ \caption{Formato di un pacchetto IPv6 che usa l'opzione di autenticazione.}
+ \label{fig:AH_autent_head}
+\end{figure}
La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
-singole che con un gateway di sicurezza; in questa modalità
+singole che con un gateway di sicurezza; in questa modalità ...
L'intestazione di autenticazione è una intestazione di estensione inserita
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
+quella mostrata in fig.~\ref{fig:ESP_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
+
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=10cm]{img/esp_option}
+ \caption{Schema di pacchetto crittografato.}
+ \label{tab:ESP_criptopack}
+\end{figure}
+
\subsection{Autoconfigurazione}
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.
+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
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
+multicast \texttt{FF02::1} (vedi sez.~\ref{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.
projects / gapil.git / blobdiff