X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=netlayer.tex;h=86f4276c22d57262a9f24f8e3df3e1fd5c350f4e;hp=2934e6382bc9af8f29d1ef41494f28610237c8c4;hb=5e54ad63881cd5bd7c71395d073127e41f1b68d6;hpb=d3360b59e957e86e2cc972f1841678feca8eff33 diff --git a/netlayer.tex b/netlayer.tex index 2934e63..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 @@ -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}