\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}
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}
\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
\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
\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.}
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}
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}