\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
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
\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. \\
+ l'intestazione, in byte. \\
\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\\
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,
\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}
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]
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 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
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.
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
+collegamento (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.
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
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
+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
devono provvedere questa capacità.
\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à
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}
projects / gapil.git / blobdiff