Passata generale di ispell

[gapil.git] / ipprot.tex

diff --git a/ipprot.tex b/ipprot.tex
index c02ba10d9be0307741c48a8f131c323715d11ce5..c366d89cbdd1c1f9ac1fd0b618354894f86f51f1 100644 (file)
--- a/ipprot.tex
+++ b/ipprot.tex
@@ -1,7 +1,7 @@
 \chapter{Il protocollo IP}
 \label{cha:ip_protocol}
 
 \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
 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,
 
 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
 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 
       \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\\
       \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
   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,
   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
 \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}
 \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
 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]
 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
 
 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
 
 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
 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.
 
 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
 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.
 
 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
 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
 
 \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
 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à.
 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}
 
     \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à 
 
 
 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.
 
 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}
 
 \subsection{Riservatezza}
 \label{sec:ecry}