X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=netlayer.tex;h=86f4276c22d57262a9f24f8e3df3e1fd5c350f4e;hp=98e7747c61f4c66571dcb9f0148ad5fc3fc0ad0a;hb=5e54ad63881cd5bd7c71395d073127e41f1b68d6;hpb=0a667b5bd6c1988e132d900ce4c0fd3c9170576f

diff --git a/netlayer.tex b/netlayer.tex
index 98e7747..86f4276 100644
--- a/netlayer.tex
+++ b/netlayer.tex
@@ -32,10 +32,11 @@ nuova versione denominata IPv6.
 \label{sec:ip_protocol}
 
 L'attuale \textit{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
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
+dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{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 realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, etc.).
 
 
 \subsection{Introduzione}
@@ -207,11 +208,11 @@ apparecchio elettronico sarebbe stato inserito all'interno della rete.
 Per questo motivo si iniziò a progettare una nuova versione del protocollo 
 
 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
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI,
-etc.).
+dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{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 realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, etc.).
 
 
 \subsection{I motivi della transizione}
@@ -619,7 +620,8 @@ allocazione degli indirizzi unicast.
 \label{sec:IP_ipv6_unicast}
 
 Gli indirizzi \textit{provider-based} sono gli indirizzi usati per le
-comunicazioni globali, questi sono definiti nell'RFC 2073 e sono gli
+comunicazioni globali, questi sono definiti
+nell'\href{http://www.ietf.org/rfc/rfc2073.txt}{RFC~2073} e sono gli
 equivalenti degli attuali indirizzi delle classi da A a C.
 
 L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
@@ -864,7 +866,7 @@ che IPv6 siano supportati sull'host di origine).
 \label{tab:IP_ipv6_map}
 \end{table}
 
-Un secondo tipo di indirizzi di compatibilità sono gli \textit{IPv4
+Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
   compatibili IPv6} (vedi \tabref{tab:IP_ipv6_comp}) usati nella transizione
 da IPv4 a IPv6: quando un nodo che supporta sia IPv6 che IPv4 non ha un router
 IPv6 deve usare nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6
@@ -975,16 +977,20 @@ per il funzionamento della rete.
     \textbf{Uso}& \textbf{Indirizzi riservati} & \textbf{Definizione}\\
     \hline 
     \hline 
-    all-nodes & \texttt{FFxx:0:0:0:0:0:0:1} & RFC 1970\\
-    all-routers & \texttt{FFxx:0:0:0:0:0:0:2} & RFC 1970\\
-    all-rip-routers & \texttt{FFxx:0:0:0:0:0:0:9} & RFC 2080\\
-    all-cbt-routers & \texttt{FFxx:0:0:0:0:0:0:10} &\\
-    reserved &  \texttt{FFxx:0:0:0:0:0:1:0} & IANA \\
-    link-name &  \texttt{FFxx:0:0:0:0:0:1:1} &  \\
-    all-dhcp-agents & \texttt{FFxx:0:0:0:0:0:1:2} & \\
-    all-dhcp-servers & \texttt{FFxx:0:0:0:0:0:1:3} & \\
-    all-dhcp-relays & \texttt{FFxx:0:0:0:0:0:1:4} & \\
-    solicited-nodes &  \texttt{FFxx:0:0:0:0:1:0:0} & RFC 1970\\
+    all-nodes       & \texttt{FFxx:0:0:0:0:0:0:1}  & 
+                      \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
+    all-routers     & \texttt{FFxx:0:0:0:0:0:0:2}  & 
+                      \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
+    all-rip-routers & \texttt{FFxx:0:0:0:0:0:0:9}  & 
+                      \href{http://www.ietf.org/rfc/rfc2080.txt}{RFC~2080} \\
+    all-cbt-routers & \texttt{FFxx:0:0:0:0:0:0:10} & \\
+    reserved        & \texttt{FFxx:0:0:0:0:0:1:0}  & IANA \\
+    link-name       & \texttt{FFxx:0:0:0:0:0:1:1}  &  \\
+    all-dhcp-agents & \texttt{FFxx:0:0:0:0:0:1:2}  & \\
+    all-dhcp-servers& \texttt{FFxx:0:0:0:0:0:1:3}  & \\
+    all-dhcp-relays & \texttt{FFxx:0:0:0:0:0:1:4}  & \\
+    solicited-nodes & \texttt{FFxx:0:0:0:0:1:0:0}  & 
+                      \href{http://www.ietf.org/rfc/rfc1970.txt}{RFC~1970} \\
     \hline
   \end{tabular}
 \caption{Gruppi multicast predefiniti.}
@@ -1078,9 +1084,11 @@ Le estensioni definite al momento sono le seguenti:
   vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
   destinazione che riassembla i frammenti.
 \item \textbf{Authentication} gestisce l'autenticazione e il controllo di
-  integrità dei pacchetti; è documentato dall'RFC 162.
+  integrità dei pacchetti; è documentato
+  dall'\href{http://www.ietf.org/rfc/rfc1826.txt}{RFC~1826}.
 \item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
-  trasmesso; è documentato dall'RFC 1827.
+  trasmesso; è documentato
+  dall'\href{http://www.ietf.org/rfc/rfc1827.txt}{RFC~1827}.
 \end{itemize}
 
 La presenza di opzioni è rilevata dal valore del campo \textit{next header}
@@ -1225,7 +1233,8 @@ riservatezza a un livello inferiore al primo (quello di applicazione), con
 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.
+architettura è riportata
+nell'\href{http://www.ietf.org/rfc/rfc2401.txt}{RFC~2401}.
 
 Il meccanismo in sostanza si basa su due estensioni:
 \begin{itemize}