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.
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]
è 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
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.
\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}
indica la posizione del frammento rispetto al pacchetto originale\\
\textit{time to live} & 16 & \textsl{tempo di vita},
ha lo stesso significato di
- \textit{hop limit}, vedi Tab.~\ref{tab:IP_ipv6field}\\
+ \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\\
\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
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}}
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
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 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
+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
-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
+è 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]
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]
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}
di integrità (ma senza riservatezza) dei pacchetti IP.
L'intestazione di autenticazione ha il formato descritto in
-\figref{fig:autent_estens}: il campo \textit{Next Header} indica
+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
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 \figref{fig:ESP_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.
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