X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipprot.tex;h=c366d89cbdd1c1f9ac1fd0b618354894f86f51f1;hp=c02ba10d9be0307741c48a8f131c323715d11ce5;hb=e20a546af590a50e7ac47f68f6c7d4648bb4f31a;hpb=6b667429ed5d78c967b88bda7ee33be7077096f5

diff --git a/ipprot.tex b/ipprot.tex
index c02ba10..c366d89 100644
--- a/ipprot.tex
+++ b/ipprot.tex
@@ -1,7 +1,7 @@
 \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
@@ -175,7 +175,7 @@ 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
+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
@@ -301,7 +301,7 @@ numero dei campi da 12 a 8.
       \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\\
@@ -346,7 +346,7 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
   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,
@@ -453,7 +453,7 @@ 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}
@@ -659,7 +659,7 @@ 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
+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]
@@ -976,7 +976,7 @@ 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 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
@@ -985,7 +985,7 @@ 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
+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.
 
@@ -1147,7 +1147,7 @@ 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
+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.
 
@@ -1167,7 +1167,7 @@ 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.
+multicast dovrà essere lo stesso per tutte le stazioni del gruppo.
 
 \subsection{Autenticazione}
 Il primo meccanismo di sicurezza è quello della testata di autenticazione
@@ -1184,7 +1184,7 @@ 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
+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à.
@@ -1255,7 +1255,7 @@ prima che dopo.
     \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à 
 
 
@@ -1284,6 +1284,7 @@ ancora in fase di definizione; attualmente 
 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}