Ulteriori correzioni all'appendice su IPv6.
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 22 Jul 2002 16:06:00 +0000 (16:06 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 22 Jul 2002 16:06:00 +0000 (16:06 +0000)
ChangeLog
gapil.tex
html/index.html
ipprot.tex
signal.tex

index 23d7b6b..0a1ddfe 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2002-07-22  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * ipprot.tex: Altre correzioni di Francesco Poli, anch'esse
+       riportate su questo.
+
 2002-07-11  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * ipprot.tex: Correzioni di Francesco Poli al vecchio documento su
index 2eeaa99..8e59179 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -21,8 +21,8 @@
 \usepackage{listings}
 \lstloadlanguages{C++}
 \usepackage{color} 
-\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
-\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
+%\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
+%\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 %
@@ -73,7 +73,7 @@
 \tableofcontents
 \clearemptydoublepage
 
-%\include{compatib}    % commentare per la stampa PS e PDF
+\include{compatib}    % commentare per la stampa PS e PDF
 
 \include{macro}
 \setcounter{secnumdepth}{-2}
index a5a9289..5f1f32d 100644 (file)
@@ -93,6 +93,12 @@ News
 <b>3 - luglio - 2002</b><br> Prima versione del sito, con rilascio della prima
       versione di GaPiL in un HTML decente.
 </td>
+<td bgcolor="lightblue"> 
+
+<b>22 - luglio - 2002</b><br> Nuova versione, aggiunte su I/O avanzato, IPC ed
+           altro, .
+</td>
+
 </tr>
 
 
index ce5ba6f..5573639 100644 (file)
@@ -41,8 +41,8 @@ quest'ultime assegnare i numeri dei singoli host.
 
 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]
@@ -341,7 +341,7 @@ differenze:
 \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
@@ -564,7 +564,7 @@ IPv4, un terzo tipo, gli indirizzi \textit{anycast} 
 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
@@ -656,7 +656,7 @@ suddivisione fra \textit{Provider Id}, che identifica i grandi fornitori di
 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.
@@ -700,7 +700,7 @@ degli indirizzi, allocando dei blocchi per i quali delegare l'autorit
 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]
@@ -815,7 +815,7 @@ Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
 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]
@@ -838,10 +838,10 @@ sull'host di origine).
 \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
@@ -911,8 +911,7 @@ Il prefisso di formato per tutti gli indirizzi \textit{multicast} 
   \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 
@@ -936,13 +935,48 @@ transitorio, all'interno del raggio di validit
 \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
@@ -952,9 +986,9 @@ configurato per tener conto del fatto.
 
 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
@@ -1007,7 +1041,7 @@ Le estensioni definite al momento sono le seguenti:
   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
@@ -1049,7 +1083,7 @@ presente; i valori possibili sono riportati in \ntab.
       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 \\
@@ -1168,7 +1202,7 @@ architettura 
 
 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.
@@ -1185,12 +1219,14 @@ di ogni comunicazione ed 
 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
@@ -1222,7 +1258,7 @@ devono provvedere questa capacit
     {\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}}{} \\
@@ -1235,7 +1271,6 @@ devono provvedere questa capacit
 \renewcommand\arraystretch{1} %default
 
 
-
 L'intestazione di autenticazione può essere impiegata in due modi diverse
 modalità: modalità trasporto e modalità tunnel.
 
@@ -1280,9 +1315,6 @@ non ha perci
 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
@@ -1361,6 +1393,75 @@ fino al vettore di inizializzazione, il resto 
 \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
index 0d645f6..c1b39a8 100644 (file)
@@ -2473,7 +2473,9 @@ nella forma classica il segnale sar
 tipiche dei segnali real-time (priorità e coda) saranno perse.
 
 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
-gestire l'attesa di segnali specifici su una coda; la prima di queste è
+gestire l'attesa di segnali specifici su una coda, esse servono in particolar
+modo nel caso dei thread, in cui si possono usare i segnali real-time come
+meccanismi di comunicazione elementare; la prima di queste funzioni è
 \func{sigwait}, il cui prototipo è:
 \begin{prototype}{signal.h}
   {int sigwait(const sigset\_t *set, int *sig)}
@@ -2514,7 +2516,6 @@ Altre due funzioni, usate prevalentemente con i thread, sono
   \item[\macro{EINTR}] Non si hanno privilegi appropriati per inviare il
     segnale al processo specificato.
   \item[\macro{ENOSYS}] Il processo \param{pid} non esiste.
-    \param{set}.
   \end{errlist}
   ed inoltre \macro{EFAULT}.}
 \end{functions}