Per venire incontro alle diverse esigenze gli indirizzi di rete sono stati
originariamente organizzati in \textit{classi}, (rappresentate in
-Tab.~\ref{tab:IP_ipv4class}), per consentire dispiegamenti di reti di
-dimensioni diverse.
+\tabref{tab:IP_ipv4class}), per consentire dispiegamenti di reti di dimensioni
+diverse.
\begin{table}[htb]
\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 intestazione e ai dati, pure i campi
- \textit{payload lenght}, \textit{next header}, e gli indirizzi di origine e
+ \textit{payload length}, \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
essere usati con grande affidabilità); con questa scelta si è ridotto di
In IPv6 non esistono più gli indirizzi \textit{broadcast}, la funzione di
questi ultimi deve essere reimplementata con gli indirizzi \textit{multicast}.
-Gli indirizzi \textit{unicast} identificano una singola interfaccia i
+Gli indirizzi \textit{unicast} identificano una singola interfaccia: i
pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia,
gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che
un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
servizi, e \textit{Subscriber Id}, che identifica i fruitori, sia gestita dai
singoli registri regionali. Questi ultimi dovranno definire come dividere lo
spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di
-58~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
+56~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
l'autorità di allocare i \textit{Subscriber Id} al loro interno.
registri nazionali, quest'ultimi poi avranno il compito di gestire la
attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
paese coperto dal registro nazionale con le modalità viste in precedenza.
-Una tale ripartizione andrà effettuata all'interno dei soliti 58~bit come
+Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
mostrato in \ntab.
\begin{table}[htb]
applicazioni IPv6 di comunicare con host capaci solo di IPv4; questi sono ad
esempio gli indirizzi generati da un DNS quando l'host richiesto supporta solo
IPv4; l'uso di un tale indirizzo in un socket IPv6 comporta la generazione di
-un pacchetto IPv4 (ovviamente occorre che sia IPv4 che IPv6 siano supportate
+un pacchetto IPv4 (ovviamente occorre che sia IPv4 che IPv6 siano supportati
sull'host di origine).
\begin{table}[!htb]
\end{table}
Un secondo tipo di indirizzi di compatibilità sono gli \textit{IPv4
- compatibili IPv6} (vedi \ntab) usati nella transizione da IPv4 a IPv6,
-quando un host che supporta sia IPv6 che IPv4 non ha un router IPv6 deve usare
-nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6 inviato a un tale
-indirizzo verrà automaticamente incapsulato in 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
+inviato a un tale indirizzo verrà automaticamente incapsulato in IPv4.
\begin{table}[htb]
\centering
\ntab.
\end{itemize}
-Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che
-transitorio, all'interno del raggio di validità del medesimo.
+
\begin{table}[!htb]
\centering
\label{tab:IP_ipv6_multiscope}
\end{table}
+Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che
+transitorio, all'interno del raggio di validità del medesimo. Alcuni
+indirizzi multicast, riportati in \tabref{tab:multiadd} sono già riservati
+per il funzionamento della rete.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{l l r}
+ \hline
+ \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\\
+ \hline
+ \end{tabular}
+\caption{Gruppi multicast predefiniti.}
+\label{tab:multiadd}
+\end{table}
+
+L'utilizzo del campo di \textit{scope} e di questi indirizzi predefiniti serve
+a recuperare le funzionalità del broadcasting (ad esempio inviando un
+pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si raggiungono tutti i
+nodi locali).
+
+
\subsection{Indirizzi \textit{anycast}}
\label{sec:IP_anycast}
Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
-gruppo di interfacce per quali un pacchetto indirizzato a questo tipo di
-indirizzo viene inviato al componente del gruppo più ``vicino'' secondo la
-distanza di instradamento calcolata dai router.
+gruppo di interfacce: un pacchetto indirizzato a questo tipo di indirizzo
+viene inviato al componente del gruppo più ``vicino'' secondo la distanza di
+instradamento calcolata dai router.
Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast,
usando uno dei formati disponibili, e per questo, sono da essi assolutamente
Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una
destinazione su un gruppo di possibili interfacce selezionate. La sorgente non
-deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca
-al sistema di instradamento, (in sostanza la sorgente non ha nessun controllo
-sulla selezione).
+deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al
+sistema di instradamento (in sostanza la sorgente non ha nessun controllo
+sulla selezione).
Gli indirizzi anycast, quando vengono usati come parte di una sequenza di
instradamento, consentono ad esempio ad un nodo di scegliere quale fornitore
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.
+ superiore a 65535 byte.
\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
43 & RH & Routing Header (IPv6) \\
44 & FH & Fragment Header (IPv6) \\
45 & IDRP & Inter Domain Routing \\
- 51 & AH & Autentication Header (IPv6) \\
+ 51 & AH & Authentication Header (IPv6) \\
52 & ESP & Encrypted Security Payload (IPv6) \\
59 & Null & No next header (IPv6) \\
88 & IGRP & Internet Group Routing \\
Il meccanismo in sostanza si basa su due estensioni:
\begin{itemize}
-\item una intestazione di sicurezza (\textit{autentication header}) che
+\item una intestazione di sicurezza (\textit{authentication 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.
multicast dovrà essere lo stesso per tutte le stazioni del gruppo.
\subsection{Autenticazione}
+\label{sec:auth}
+
Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
-(\textit{autentication header}) che fornisce l'autenticazione e il controllo
+(\textit{authentication header}) che fornisce l'autenticazione e il controllo
di integrità (ma senza riservatezza) dei pacchetti IP.
L'intestazione di autenticazione ha il formato descritto in
-Tab.~\ref{tab:autent_head} il campo \textit{Next Header} indica l'intestazione
+\tabref{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
{\centering Sequence Number}\\
\hline
\multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{3}{@{\vrule}c@{\vrule}}{Autentication Data} \\
+ \multicolumn{3}{@{\vrule}c@{\vrule}}{Authentication Data} \\
\multicolumn{3}{@{\vrule}c@{\vrule}}
{\centering ... } \\
\multicolumn{3}{@{\vrule}c@{\vrule}}{} \\
\renewcommand\arraystretch{1} %default
-
L'intestazione di autenticazione può essere impiegata in due modi diverse
modalità: modalità trasporto e modalità tunnel.
trasmissione come il TCP.
-
-
-
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
\section{Autoconfigurazione}
\label{sec:IP_ipv6_autoconf}
+Una delle caratteristiche salienti di IPv6 è quella dell'autoconfigurazione,
+il protocollo infatti fornisce la possibilità ad un nodo di scoprire
+automaticamente il suo indirizzo acquisendo i parametri necessari per potersi
+connettere a internet.
+
+L'autoconfigurazione sfrutta gli indirizzi link-local; qualora sul nodo sia
+presente una scheda di rete che supporta lo standard IEEE802 (ethernet) questo
+garantisce la presenza di un indirizzo fisico a 48 bit unico; pertanto il nodo
+può assumere automaticamente senza pericoli di collisione l'indirizzo
+link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
+l'indirizzo hardware della scheda di rete.
+
+Nel caso in cui non sia presente una scheda che supporta lo standard IEEE802
+allora il nodo assumerà ugualmente un indirizzo link-local della forma
+precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
+casualmente; in questo caso la probabilità di collisione è di 1 su 300
+milioni. In ogni caso per prevenire questo rischio il nodo invierà un
+messaggio ICMP \textit{Solicitation} all'indirizzo scelto attendendo un certo
+lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
+procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
+richiedendo assistenza).
+
+Una volta ottenuto un indirizzo locale valido diventa possibile per il nodo
+comunicare con la rete locale; sono pertanto previste due modalità di
+autoconfigurazione, descritte nelle seguenti sezioni. In ogni caso
+l'indirizzo link-local resta valido.
+
+\subsection{Autoconfigurazione stateless}
+\label{sec:stateless}
+
+Questa è la forma più semplice di autoconfigurazione, possibile quando
+l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
+semplicemente il prefisso a quello assegnato dal provider per ottenere un
+indirizzo globale.
+
+La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
+iniziano si devono aggregare al gruppo multicast \textit{all-nodes}
+programmando la propria interfaccia per ricevere i messaggi dall'indirizzo
+multicast \texttt{FF02::1} (vedi \secref{sec:IP_ipv6_multicast}); a questo
+punto devono inviare un messaggio ICMP \textit{Router solicitation} a tutti i
+router locali usando l'indirizzo multicast \texttt{FF02::2} usando come
+sorgente il proprio indirizzo link-local.
+
+Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
+fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
+messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
+contiene anche l'informazione che autorizza un nodo a autocostruire
+l'indirizzo, nel qual caso, se il prefisso unito all'indirizzo link-local non
+supera i 128 bit, la stazione ottiene automaticamente il suo indirizzo
+globale.
+
+\subsection{Autoconfigurazione stateful}
+\label{sec:stateful}
+
+Benché estremamente semplice l'autoconfigurazione stateless presenta alcuni
+problemi; il primo è che l'uso degli indirizzi delle schede di rete è
+molto inefficiente; nel caso in cui ci siano esigenze di creare una gerarchia
+strutturata su parecchi livelli possono non restare 48~bit per l'indirizzo
+della singola stazione; il secondo problema è di sicurezza, dato che basta
+introdurre in una rete una stazione autoconfigurante per ottenere un accesso
+legale.
+
+Per questi motivi è previsto anche un protocollo stateful basato su un
+server che offra una versione IPv6 del DHCP; un apposito gruppo di multicast
+\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il
+nodo interrogherà il server su questo indirizzo di multicast con l'indirizzo
+link-local e riceverà un indirizzo unicast globale.
+
+
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff