\chapter{Il protocollo IP}
\label{cha:ip_protocol}
-L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981
+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
\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.
+CIDR, \textit{Classless Inter-Domain Routing}) in cui il limite fra i bit
+destinati a indicare il numero di rete e quello destinati a indicare l'host
+finale può essere piazzato in qualunque punto (vedi \tabref{tab:IP_ipv4cidr}),
+permettendo di accorpare più classi A su un'unica rete o suddividere una
+classe B e diminuendo al contempo il numero di indirizzi di rete da inserire
+nelle tabelle di instradamento dei router.
\section{I motivi della transizione}
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
+numeri diversi possibili, che sono molti di più dei computer attualmente
esistenti.
Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
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
+I cambiamenti apportati sono comunque notevoli e possono essere riassunti a
grandi linee nei seguenti punti:
\begin{itemize}
\item l'espansione delle capacità di indirizzamento e instradamento, per
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
+\item la semplificazione del formato dell'intestazione, eliminando o rendendo
opzionali alcuni dei campi di IPv4, per eliminare la necessità di
riprocessamento della stessa da parte dei router e contenere l'aumento di
dimensione dovuto ai nuovi indirizzi
\end{itemize}
-\section{La testata di IPv6}
+\section{L'intestazione di IPv6}
\label{sec:IP_ipv6head}
Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
protocollo per gestire la trasmissione dei pacchetti; in
-\tabref{tab:IP_ipv6head} è riportato il formato della testata di IPv6 da
+\tabref{tab:IP_ipv6head} è riportato il formato dell'intestazione 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})
+significato dei vari campi delle due intestazioni è riportato rispettivamente
+in \tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field})
\begin{table}[htb]
\footnotesize
\centering version&\centering priority&
\multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
\hline
- \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload lenght} &
+ \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} &
\multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} &
\multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
\hline
\multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
\hline
\end{tabular}
- \caption{La testata o \textit{header} di IPv6}
+ \caption{L'intestazione 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
+Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
+40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia
quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il
numero dei campi da 12 a 8.
\begin{table}[htb]
\begin{center}
\footnotesize
- \begin{tabular}{ l c p{8cm}}
+ \begin{tabular}{|l|c|p{8cm}|}
+ \hline
\textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
- \toprule
+ \hline
+ \hline
\textit{version} & 4 bit &
\textsl{versione}, nel caso specifico vale sempre 6\\
\textit{priority} & 4 bit &
\textsl{priorità}, vedi Sez.~\ref{sec:prio} \\
\textit{flow label} & 24 bit &
\textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\
- \textit{payload leght} & 16 bit &
+ \textit{payload length} & 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\\
+ l'intestazione, in byte. \\
+ \textit{next header} & 8 bit & \textsl{intestazione successiva},
+ identifica il tipo di pacchetto che segue l'intestazione di IPv6, usa
+ gli stessi valori del campo protocollo nell'intestazione di IPv4\\
\textit{hop limit} & 8 bit & \textsl{limite di salti},
- stesso significato del \textit{time to live} nella testata di IPv4,
+ stesso significato del \textit{time to live} nell'intestazione di IPv4,
è decrementato di uno ogni volta che un nodo ritrasmette il
pacchetto, se arriva a zero il pacchetto viene scartato \\
\textit{source IP} & 128 bit & \textsl{indirizzo di origine} \\
\textit{destination IP}& 128 bit & \textsl{indirizzo di destinazione}\\
- \bottomrule
+ \hline
\end{tabular}
\caption{Legenda per il significato dei campi dell'intestazione di IPv6}
\label{tab:IP_ipv6field}
\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:
+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 \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
+\item è stato eliminato il campo \textit{header length} in quanto le opzioni
+ sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
+ essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
\secref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
lunghezza all'interno.
-\item la testata e gli indirizzi sono allineati a 64 bit, questo rende più
+\item l'intestazione e gli indirizzi sono allineati a 64 bit, questo rende più
veloce il processo da parte di computer con processori a 64 bit.
\item i campi per gestire la frammentazione (\textit{identification},
\textit{flag} e \textit{fragment offset}) sono stati eliminati; questo
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
+ checksum che include, oltre alla loro intestazione 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
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
+ non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
sono state reimplementate (vedi il campo \textit{priority} al prossimo
punto) con altri metodi.
\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
\multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
\hline
\centering version&
- \centering head lenght&
+ \centering head length&
\multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total lenght} \\
+ \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total length} \\
\hline
\multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} &
\multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule
\begin{table}[htb]
\footnotesize
\begin{center}
- \begin{tabular}{l c p{9cm}}
+ \begin{tabular}{|l|c|p{9cm}|}
+ \hline
\textbf{Nome} & \textbf{Lunghezza} & \textbf{Significato} \\
- \toprule
+ \hline
+ \hline
\textit{version} & 4 bit & \textsl{versione}, nel caso
specifico vale sempre 4\\
- \textit{head lenght} & 4 bit & \textsl{lunghezza della testata},
+ \textit{head length} & 4 bit &\textsl{lunghezza dell'intestazione},
in multipli di 32 bit\\
\textit{type of service} & 8 bit & \textsl{tipo di servizio},
consiste in: 3 bit di precedenza,
correntemente ignorati; un bit non usato a 0; 4 bit che identificano
il tipo di servizio richiesto, uno solo dei quali può essere 1\\
- \textit{total lenght} & 16 bit & \textsl{lunghezza totale}, indica
+ \textit{total length} & 16 bit & \textsl{lunghezza totale}, indica
la dimensione del pacchetto IP in byte\\
\textit{identification} & 16 bit & \textsl{identificazione},
- assegnato alla creazione, è aumentato di uno all'origine alla
+ 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{hop limit}, vedi Tab.~\ref{tab:IP_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\\
+ l'intestazione di IPv4\\
+ \textit{header checksum} & 16 bit & \textsl{checksum di intestazione},
+ somma di controllo per l'intestazione\\
\textit{source IP} & 32 bit & \textsl{indirizzo di origine}\\
\textit{destination IP} & 32 bit & \textsl{indirizzo di destinazione}\\
- \bottomrule
+ \hline
\end{tabular}
\caption{Legenda per il significato dei campi dell'intestazione di IPv4}
\label{tab:IP_ipv4field}
\end{center}
\end{table}
-Oltre alle differenze precedenti, relative ai singoli campi nella testata,
+Oltre alle differenze precedenti, relative ai singoli campi nell'intestazione,
ulteriori caratteristiche che diversificano il comportamento di IPv4 da
quello di IPv6 sono le seguenti:
\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).
+ pacchetti più larghi della dimensione minima (576 byte).
\end{itemize}
\section{Gli indirizzi di IPv6}
gli altri valori restano riservati per la IANA.
\begin{table}[htb]
\begin{center}
- \begin{tabular}{l l l}
+ \begin{tabular}{|l|l|l|}
+ \hline
\textbf{Regione} & \textbf{Registro} & \textbf{Id} \\
- \toprule
+ \hline
+ \hline
Nord America &INTERNIC & \texttt{11000} \\
Europa & RIPE NCC & \texttt{01000} \\
Asia & APNIC & \texttt{00100} \\
Multi-regionale & IANA &\texttt{10000} \\
- \bottomrule
+ \hline
\end{tabular}
\caption{Valori dell'identificativo dei
Regional Register allocati ad oggi.}
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
+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]
\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.
+primo è usato per un singolo link; la struttura è mostrata in
+\tabref{tab:IP_ipv6_linklocal}, questi indirizzi iniziano sempre per
+\texttt{FE80} e vengono in genere usati per la configurazione automatica
+dell'indirizzo al bootstrap e per la ricerca dei vicini (vedi
+\ref{sec:IP_ipv6_autoconf}); un pacchetto che abbia tale indirizzo come
+sorgente o destinazione non deve venire ritrasmesso dai router.
Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
all'interno di un sito che non necessita di un prefisso globale; la struttura
\begin{table}[!htb]
\centering
\footnotesize
- \begin{tabular}[c]{c l c l}
- \multicolumn{4}{c}{\bf Gruppi di multicast} \\
- \toprule
+ \begin{tabular}[c]{|c|l|c|l|}
+ \hline
+ \multicolumn{4}{|c|}{\bf Gruppi di multicast} \\
+ \hline
+ \hline
0 & riservato & 8 & organizzazione locale \\
1 & nodo locale & 9 & non assegnato \\
2 & collegamento locale & A & non assegnato \\
5 & sito locale & D & non assegnato \\
6 & non assegnato & E & globale \\
7 & non assegnato & F & riservato \\
- \bottomrule
+ \hline
\end{tabular}
\caption{Possibili valori del campo \textsl{scop} di un indirizzo multicast.}
\label{tab:IP_ipv6_multiscope}
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.
+intestazione di instradamento o per identificare insiemi di router connessi a
+una particolare sottorete, o che forniscono l'accesso a un certo sotto
+dominio.
L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
\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.
+delle opzioni; queste ultime infatti sono state tolte dall'intestazione del
+pacchetto, e poste in apposite \textsl{intestazioni di estensione} (o
+\textit{extension header}) poste fra l'intestazione di IPv6 e l'intestazione
+del protocollo di trasporto.
Per aumentare la velocità di processo, sia dei dati del livello seguente che
di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di
-8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti.
+8 byte per mantenere l'allineamento a 64~bit di tutti le intestazioni
+seguenti.
Dato che la maggior parte di queste estensioni non sono esaminate dai router
durante l'instradamento e la trasmissione dei pacchetti, ma solo all'arrivo
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
+lunghezza arbitraria e non limitate a 40 byte; questo, insieme al modo in cui
vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
sicurezza, improponibili con IPv4.
Le estensioni definite al momento sono le seguenti:
\begin{itemize}
-\item \textbf{Hop by hop} devono seguire immediatamente 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{Hop by hop} devono seguire immediatamente l'intestazione
+ principale; indicano le opzioni che devono venire processate ad ogni
+ passaggio da un router, fra di esse è da menzionare la \textit{jumbo
+ payload} che segnala la presenza di un pacchetto di dati di dimensione
+ superiore a 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
\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
+che indica qual'è l'intestazione successiva a quella di IPv6; in assenza di
+opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
superiore, per cui il campo assumerà lo stesso valore del campo
\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
presente; i valori possibili sono riportati in \ntab.
\begin{table}[htb]
\begin{center}
\footnotesize
- \begin{tabular}{c l l}
+ \begin{tabular}{|c|l|l|}
+ \hline
\textbf{Valore} & \textbf{Keyword} & \textbf{Tipo di protocollo} \\
\hline
\hline
88 & IGRP & Internet Group Routing \\
89 & OSPF & Open Short Path First \\
255& & riservato \\
+ \hline
\end{tabular}
- \caption{Tipi di protocolli e testate di estensione}
+ \caption{Tipi di protocolli e intestazioni di estensione}
\label{tab:IP_ipv6_nexthead}
\end{center}
\end{table}
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular} {c l}
- Valore & tipo di traffico \\
- \toprule
+ \begin{tabular}{|c|l|}
+ \hline
+ \textbf{Valore} & \textbf{Tipo di traffico} \\
+ \hline
+ \hline
0 & traffico generico \\
1 & traffico di riempimento (es. news) \\
2 & trasferimento dati non interattivo (es. e-mail)\\
3 & riservato \\
4 & trasferimento dati interattivo (es. FTP, HTTP, NFS) \\
5 & riservato \\
- 6 & traffico interattivo (telnet, X)\\
- 7 & traffico di controllo (routing, SNMP) \\
- \bottomrule
+ \hline
\end{tabular}
\caption{Formato di un indirizzo \textit{site-local}.}
\label{tab:priority}
\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.
+sicurezza, in particolare i dati presenti nelle intestazioni dei vari
+protocolli sono assunti essere corretti, il che da adito alla possibilità di
+varie tipologie di attacco forgiando pacchetti false, inoltre tutti questi
+dati passano in chiaro sulla rete e sono esposti all'osservazione di chiunque
+si trovi in mezzo.
Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
riservatezza a un livello inferiore al primo (quello di applicazione), con
-IPv6 è stato progettata la possibilità di intervenire al livello 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.
+IPv6 è stato progettata la possibilità di intervenire al livello di rete (il
+terzo) prevedendo due apposite estensioni che possono essere usate per fornire
+livelli di sicurezza a seconda degli utenti. La codifica generale di questa
+architettura è riportata nell'RFC 2401.
Il meccanismo in sostanza si basa su due estensioni:
\begin{itemize}
-\item una testata di sicurezza (\textit{autentication header}) che garantisce
- al destinatario l'autenticità del pacchetto
+\item una intestazione 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}
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.
+multicast dovrà essere lo stesso per tutte le stazioni del gruppo.
\subsection{Autenticazione}
-Il primo meccanismo di sicurezza è quello della testata di autenticazione
+Il primo meccanismo di sicurezza è quello dell'intestazione 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
+L'intestazione di autenticazione ha il formato descritto in
+Tab.~\ref{tab:autent_head} il campo \textit{Next Header} indica l'intestazione
+successiva, con gli stessi valori del campo omonimo nell'intestazione
+principale di IPv6, il campo \textit{Length} indica la lunghezza
+dell'intestazione di autenticazione in numero di parole a 32 bit, il campo
+riservato deve essere posto a zero, seguono poi l'indice di sicurezza,
+stabilito nella associazione di sicurezza, e un numero di sequenza che la
+stazione sorgente deve incrementare di pacchetto in pacchetto.
+
+Completano l'intestazione i dati di autenticazione che contengono un valore di
+controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
-per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione
+per allineare l'intestazione a 64 bit. Tutti gli algoritmi di autenticazione
devono provvedere questa capacità.
\renewcommand\arraystretch{1.2}
@{\vrule}p{48mm}@{\vrule} }
\multicolumn{3}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
\hline
- \centering Next Header&\centering Lenght&
+ \centering Next Header&\centering Length&
\centering Reserved \tabularnewline
\hline
\multicolumn{3}{@{\vrule}c@{\vrule}}
\multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
\hline
\end{tabular}
- \caption{Formato della testata dell'estensione di autenticazione}
+ \caption{Formato dell'intestazione dell'estensione di autenticazione}
\label{tab:autent_estens}
\end{center}
\end{table}
-La testata di autenticazione può essere impiegata in due modi diverse
+L'intestazione di autenticazione può essere impiegata in due modi diverse
modalità: modalità trasporto e modalità tunnel.
La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
-singole che supportino l'autenticazione. In questo caso la testata di
-autenticazione è inserita dopo tutte le altre testate di estensione
+singole che supportino l'autenticazione. In questo caso l'intestazione di
+autenticazione è inserita dopo tutte le altre intestazioni di estensione
eccezion fatta per la \textit{Destination Option} che può comparire sia
prima che dopo.
& & & & & \\
\hline
\end{tabular*}
- \caption{Formato della testata dell'estensione di autenticazione}
+ \caption{Formato dell'intestazione dell'estensione di autenticazione}
\label{tab:autent_head}
\end{center}
\end{table}
\end{pspicture}
\end{center}
-La modalit`\a tunnel può essere utilizzata sia per comunicazioni fra stazioni
+La modalità 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.
+L'intestazione di autenticazione è una intestazione di estensione inserita
+dopo l'intestazione principale e prima del carico dei dati. La sua presenza
+non ha perciò alcuna influenza sui livelli superiori dei protocolli di
+trasmissione come il TCP.
-La procedura di autenticazione cerca di garantire l'autenticità del
-pacchetto nella massima estensione possibile, ma dato che alcuni campi della
-testata di IP possono variare in maniera impredicibile alla sorgente, il loro
-valore non può essere protetto dall'autenticazione.
+La procedura di autenticazione cerca di garantire l'autenticità del pacchetto
+nella massima estensione possibile, ma dato che alcuni campi dell'intestazione
+di IP possono variare in maniera impredicibile alla sorgente, il loro valore
+non può essere protetto dall'autenticazione.
Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
-versione speciale del pacchetto in cui il numero di salti nella testata
+versione speciale del pacchetto in cui il numero di salti nell'intestazione
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.
+modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
+ai valori che deve avere all'arrivo.
L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
ancora in fase di definizione; attualmente è stato suggerito l'uso di una
modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
una chiave che viene inserita all'inizio e alla fine degli altri campi.
+
\subsection{Riservatezza}
\label{sec:ecry}
Per garantire una trasmissione riservata dei dati, è stata previsto la
possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
\textit{Encripted Security Payload}. Questo viene realizzato usando con una
-apposita opzione che deve essere sempre l'ultima delle testate di estensione;
-ad essa segue il carico del pacchetto che viene criptato.
+apposita opzione che deve essere sempre l'ultima delle intestazioni di
+estensione; ad essa segue il carico del pacchetto che viene criptato.
Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
quella mostrata in Tab~.\ref{tab:criptopack}, tutti i campi sono in chiaro
\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}}{Intestazione 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}}{Intestazioni di estensione}\\
\multicolumn{4}{@{\vrule}c@{\vrule}}{...}\\
\multicolumn{4}{@{\vrule}c@{\vrule}}{}\\
\hline
\section{Autoconfigurazione}
\label{sec:IP_ipv6_autoconf}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: