Correzioni varie da Francesco Poli.
[gapil.git] / ipprot.tex
index a28e1d6..ce5ba6f 100644 (file)
@@ -157,12 +157,12 @@ di questi ultimi ed inefficienza nel trasporto.
 \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}
@@ -213,7 +213,7 @@ dimostrate valide, eliminando quelle inutili e aggiungendone poche altre
 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
@@ -221,7 +221,7 @@ grandi linee nei seguenti punti:
   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
@@ -236,15 +236,15 @@ grandi linee nei seguenti punti:
 \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
@@ -257,7 +257,7 @@ significato dei vari campi delle due testate 
     \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
@@ -276,13 +276,13 @@ significato dei vari campi delle due testate 
     \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.
@@ -301,14 +301,14 @@ numero dei campi da 12 a 8.
       \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 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{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} \\
@@ -321,17 +321,18 @@ numero dei campi da 12 a 8.
 \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
@@ -339,7 +340,7 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
   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
@@ -368,9 +369,9 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
     \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
@@ -406,16 +407,16 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
       \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 & 
@@ -429,9 +430,9 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
       \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}\\
       \hline
@@ -441,7 +442,7 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze:
   \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:
 
@@ -961,8 +962,9 @@ vuole usare (configurando gli indirizzi anycast per identificare i router di
 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
@@ -978,14 +980,15 @@ La materia 
 \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 byte 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
@@ -1000,10 +1003,11 @@ 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
@@ -1019,8 +1023,8 @@ Le estensioni definite al momento sono le seguenti:
 \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.
@@ -1053,7 +1057,7 @@ presente; i valori possibili sono riportati in \ntab.
       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}
@@ -1149,23 +1153,23 @@ pi
 \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) 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.
+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}
@@ -1181,23 +1185,23 @@ di ogni comunicazione ed 
 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.
+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 la testata i dati di autenticazione che contengono un valore di
+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}
@@ -1208,7 +1212,7 @@ devono provvedere questa capacit
         @{\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}}
@@ -1224,7 +1228,7 @@ devono provvedere questa capacit
     \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}
@@ -1232,12 +1236,12 @@ devono provvedere questa capacit
 
 
 
-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. 
 
@@ -1254,7 +1258,7 @@ 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}
@@ -1270,25 +1274,25 @@ La modalit
 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
@@ -1302,8 +1306,8 @@ una chiave che viene inserita all'inizio e alla fine degli altri campi.
 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
@@ -1318,12 +1322,12 @@ fino al vettore di inizializzazione, il resto 
     \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