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]
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 dell'intestazione di IPv6 da
-confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del
+\figref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+confrontare con quella di IPv4 in \figref{fig:IP_ipv4_head}. La spiegazione del
significato dei vari campi delle due intestazioni è riportato rispettivamente
in \tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field})
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&\centering priority&
- \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
- \hline
- \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
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{L'intestazione o \textit{header} di IPv6}
- \label{tab:IP_ipv6head}
- \end{center}
-\end{table}
+% \begin{table}[htb]
+% \footnotesize
+% \begin{center}
+% \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
+% \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
+% \hline
+% \centering version&\centering priority&
+% \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
+% \hline
+% \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
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% source} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% IP address} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \hline
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% destination} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% IP address} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \hline
+% \end{tabular}
+% \caption{L'intestazione o \textit{header} di IPv6}
+% \label{tab:IP_ipv6head}
+% \end{center}
+% \end{table}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/ipv6_head}
+ \caption{L'intestazione o \textit{header} di IPv6.}
+ \label{fig:IP_ipv6head}
+\end{figure}
+
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
Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali
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
+l'intestazione di IPv4 (vedi \figref{fig:IP_ipv4_head}) mostra le seguenti
differenze:
\begin{itemize}
\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
\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
insieme al campo \textit{priority} (che recupera i bit di precedenza del
campo \textit{type of service}) per implementare la gestione di una
- ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di
+ ``qualità di servizio'' (vedi \secref{sec:IP_ipv6_qos}) che permette di
identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si
può provvedere un trattamento speciale.
\end{itemize}
-\begin{table}[htb]
- \footnotesize
+
+\begin{figure}[htb]
\centering
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&
- \centering head length&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &
- \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
- \parbox{52mm}{\centering fragment offset}}\\
- \hline
- \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}&
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{}p{128mm}@{}}{
- \centering options (if any)} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{L'intestazione o \textit{header} di IPv4}
-\label{tab:IP_ipv4head}
-\end{table}
+ \includegraphics[width=10cm]{img/ipv4_head}
+ \caption{L'intestazione o \textit{header} di IPv4.}
+ \label{fig:IP_ipv4_head}
+\end{figure}
\begin{table}[htb]
\footnotesize
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
-mostrato in \ntab.
+Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
+mostrato in \tabref{tab:IP_ipv6_uninaz}.
\begin{table}[htb]
\centering
Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
all'interno di un sito che non necessita di un prefisso globale; la struttura
-è mostrata in \ntab, questi indirizzi iniziano sempre per
-\texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del sito
-stesso; sono in sostanza gli equivalenti degli indirizzi riservati per reti
-private definiti su IPv4.
-Per entrambi gli indirizzi il campo \textit{Interface Id} è un
-identificatore che deve essere unico nel dominio in cui viene usato, un modo
-immediato per costruirlo è quello di usare il MAC-address delle schede di
-rete.
+è mostrata in \tabref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano sempre
+per \texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del
+sito stesso; sono in sostanza gli equivalenti degli indirizzi riservati per
+reti private definiti su IPv4. Per entrambi gli indirizzi il campo
+\textit{Interface Id} è un identificatore che deve essere unico nel dominio in
+cui viene usato, un modo immediato per costruirlo è quello di usare il
+MAC-address delle schede di rete.
\begin{table}[!h]
\centering
di compatibilità.
Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
-\ntab), questo sono indirizzi unicast che vengono usati per consentire ad
-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
-sull'host di origine).
+\tabref{tab:IP_ipv6_map}), questo sono indirizzi unicast che vengono usati per
+consentire ad 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 supportati sull'host di origine).
\begin{table}[!htb]
\centering
\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
\label{sec:IP_ipv6_multicast}
Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
-gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
-multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo.
+gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di multicast
+e il pacchetto viene inviato a tutte le interfacce di detto gruppo.
Un'interfaccia può appartenere ad un numero qualunque numero di gruppi di
multicast. Il formato degli indirizzi \textit{multicast} è riportato in
-\ntab:
+\tabref{tab:IP_ipv6_multicast}:
\begin{table}[htb]
\centering
transitorio.
\item \textsl{scop} è un numero di quattro bit che indica il raggio di
validità dell'indirizzo, i valori assegnati per ora sono riportati in
- \ntab.
+ \tabref{tab:IP_ipv6_multiscope}.
\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
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.
+presente; i valori possibili sono riportati in \tabref{tab:IP_ipv6_nexthead}.
\begin{table}[htb]
\begin{center}
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
Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
versione speciale del pacchetto in cui il numero di salti nell'intestazione
-principale è settato a zero, così come le opzioni che possono essere
+principale è impostato a zero, così come le opzioni che possono essere
modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
ai valori che deve avere all'arrivo.
\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 / blobdiff