%%
%% Dispense Amministrazione di rete
%% Servizi di base
%%
%% Copyright (C) 2002-2018 Simone Piccardi and Truelite Srl.
%%
%% This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
%% International License. To view a copy of this license, visit
%% \url{http://creativecommons.org/licenses/by-sa/4.0/} or send a letter to
%% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
%%
%% S. Piccardi Feb. 2002 
%%
%% netbase.tex: Concetti di base dell'amministrazione di rete
%%

\chapter{Amministrazione di base delle reti}
\label{cha:networks_base}


\section{Un'introduzione ai concetti fondamentali delle reti}
\label{sec:net_networks}

Il campo della comunicazione via rete è uno dei più vasti e complessi di tutta
l'informatica. Nel corso degli anni sono stati sviluppati molti mezzi (cavo,
fibra, radio), e molti protocolli (TCP/IP, AppleTalk, IPX, ecc.) che
permettessero di far comunicare fra loro computer diversi.

In generale con il termine di rete si identifica quella serie di meccanismi e
metodi di collegamento tramite i quali tanti singoli computer, chiamati
\textsl{nodi} o \textsl{stazioni} (in inglese \textit{host}) vengono messi in
comunicazione fra di loro in modo da potersi scambiare dati.

In questa sezione introduttiva esamineremo in breve alcuni concetti di base
relativi alle reti, a partire dai diversi criteri che vengono usati come base
per la loro classificazione, quale
l'estensione, %%%%% la tecnologia su cui sono basate,
la \textsl{topologia} con cui sono realizzate ed i protocolli di comunicazione
usati.


\subsection{L'estensione}
\label{sec:net_estension}

Una delle forme di classificazione di una rete più elementari, ed una delle
meno precise, è quella per estensione o \textit{area}. In origine, quando le
reti erano disponibili solo nei grandi centri di ricerca o nelle grandi
imprese, la classificazione era molto semplice e prevedeva soltanto le due
tipologie:
\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
\item[LAN] \textit{Local Area Network}, che indica le reti locali,
  realizzate su brevi distanze, all'interno di uno stesso edificio o gruppo
  limitrofo di edifici (in genere una università o la sede di una grande
  impresa) che di norma sono possedute e gestite da una sola organizzazione.
\item[WAN] \textit{Wide Area Network}, che indica in generale una rete di
  grande estensione, e a cui in genere si fa riferimento per indicare la
  struttura che connette varie reti locali, estendendosi potenzialmente su
  tutto il mondo (\textit{Internet} è un esempio di WAN). In questo caso la
  rete non è proprietà di una entità singola, ma viene gestita in comune da
  più enti o organizzazioni.
\end{basedescript}

Con il diffondersi dei computer e delle tecnologie di comunicazione, anche
questa classificazione delle reti si è evoluta, e la suddivisione per area di
estensione si è diversificata notevolmente, tanto che attualmente oltre alle
due precedenti sono state introdotte una lunga serie di altre tipologie, come
ad esempio:
\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
\item[MAN] \textit{Metropolitan Area Network}, che indica in genere una rete
  cittadina, di dimensione intermedia fra LAN e WAN, in cui varie reti locali
  vengono integrate preliminarmente fra di loro a livello di area
  metropolitana, grazie a delle infrastrutture dedicate. Viene di norma
  gestita da entità legate al governo della città.
\item[SAN] \textit{Storage Area Network}, che fa riferimento alle reti
  dedicate a fornire un sistema di stoccaggio dati comune ad un insieme di
  computer. In generale sono usate all'interno di singole organizzazioni e non
  sono da considerarsi propriamente delle reti di comunicazione.
\item[PAN] \textit{Personal Area Network}, che indica in genere quelle reti di
  comunicazione usate per connettere computer e dispositivi di uso personale
  (ad esempio il telefonino), su distanze di pochi metri, come il
  \textit{bluetooth}.
\item[DAN] \textit{Desktop Area Network}, che in genere fa riferimento alle
  reti di comunicazione usate per connettere vari dispositivi periferici ad un
  computer a brevissima distanza (la scrivania appunto) come le reti ad
  infrarossi IRDA.
\end{basedescript}

In generale comunque, la sola classificazione rilevante è la prima, fra LAN e
WAN.  Le altre si sovrappongono spesso fra di loro (come per DAN e PAN) o non
hanno a che fare, come la SAN (e le tecnologie di comunicazione usate per i
cluster, o all'interno dei computer per le varie CPU) con quello che
tratteremo in questo testo.


%% \subsection{Le tecnologie}
%% \label{sec:net_technology}

%% Al giorno d'oggi le tecnologie utilizzate per realizzare delle reti sono le
%% più svariate, sviluppate per far fronte alle più disparate richieste in
%% termini di funzionalità e caratteristiche (velocità di trasmissione dei dati,
%% distanze da coprire, costi di impianto, ecc.).

%% Pertanto una classificazione delle reti non può prescindere dalle tecnologie
%% hardware con le quali esse vengono realizzate, sia in termini del mezzo usato
%% per la comunicazione, che di metodologia di gestione dello stesso.  A
%% tutt'oggi il metodo di trasporto delle informazioni più usato è quello di
%% segnali elettrici, ed il cavo è l'oggetto fisico che più di ogni altro
%% realizza una rete; nuove tecnologie però si stanno affermando, e la fibra
%% ottica, le onde radio, il laser stanno emergendo come mezzi alternativi.

%% Un panorama delle tecnologie più comuni è il seguente:
%% \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
%% \item[\textit{Ethernet}] più che una tecnologia di comunicazione specifica
%%   identifica un protocollo, l'IEEE 802.3, riutilizzato anche con altri mezzi.
%%   Di norma pero si usa questo nome per alla tecnologia di trasmissione su cavo
%%   elettrico che usa questo protocollo. È la tecnologia dominante nella
%%   costruzione di LAN, offre una  velocità di trasmissione elevata
%%   (originariamente 10Mbit/s, oggi 100, 1000 o 10000 Mbit/s) su distanze
%%   fino a qualche 
%%   centinaio di metri, ed è basata su cavi elettrici (le versioni più
%%   recenti anche in fibra) di costo moderato. Può
%%   avere diverse topologie, ma quella predominante è quella a stella (tramite
%%   l'uso di switch).
%% \item[\textit{Token Ring}] Tecnologia creata dalla IBM negli anni 70, per la
%%   costruzione di LAN con una tipica topologia ad anello, è stata
%%   standardizzata dalle specifiche IEEE 802.5. Largamente superata dalle reti
%%   Ethernet, prevede una velocità di trasmissione di 4.16 Mbit/s, ed un massimo
%%   di 250 stazioni per anello, collegate tramite cavo \textit{twisted pair}.
%% \item[\textit{FDDI}] Rete a doppio anello in fibra, offre velocità fino a
%%   100Mbit/s e distanze fino a 200 km. Utilizza un protocollo derivato dallo
%%   standard IEEE 802.4.
%% \item[\textit{HSSI}]
%% \item[\textit{Frame Relay}]
%% \item[\textit{DSL}]
%% \item[\textit{Wi-Fi}]
%% \end{basedescript}


\subsection{La topologia}
\label{sec:net_topology}

Una classificazione generale applicabile a qualunque rete è quella basata
sulla sua topologia. La topologia (dal greco \textit{topos}) è una branca
della geometria che studia le proprietà delle connessioni fra oggetti
geometrici, e si applica pertanto anche alla struttura delle reti.

La classificazione riportata prevede solo alcune topologie di base, in genere
poi le reti sono costruite con l'interconnessione di reti diverse e possono
assumere delle topologie ibride rispetto a quelle qui elencate. Le topologie
fondamentali sono:
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\pushlabel}}

\item[\textit{point-to-point}] È la forma di connessione più semplice, ed in
  realtà in questo caso non si può neanche propriamente parlare di una rete;
  in quanto si realizza semplicemente una connessione diretta fra due
  macchine, che si vedono appunto come i due capi di una connessione
  punto-punto.

  È la topologia classica delle connessioni via \textit{modem},\footnote{con
    \textit{modem} si intende fare riferimento appunto ad un apparato che
    consente di collegare, appoggiandosi ad una tecnologia di connessione
    qualunque, due macchine; il caso più comune, da cui deriva il nome
    (abbreviazione di \textsl{modulatore-demodulatore}) è quello classico dei
    modem analogici che usano le linee telefoniche.} ma vale anche per altri
  tipi di collegamento fisico che consentono soltanto una trasmissione da un
  capo ad un altro (come quello tramite seriale o tramite porta parallela) in
  questo caso semplicemente si inviano i dati da una macchina verso l'altra e
  viceversa.

\item[\textit{bus}] È una rete che utilizza un canale centrale (detto
  \textit{backbone}) per connettere fra loro tutti i dispositivi. Il canale
  funziona come collettore cui ogni stazione si collega con un connettore
  inviandovi tutti i messaggi. Ogni stazione riceve tutto il traffico
  del canale, estraendone i messaggi a lei indirizzati.
  
  È la topologia classica delle vecchie reti Ethernet su BNC, fortunatamente
  ormai totalmente scomparse, ma si ritrova ad esempio nel caso delle
  connessioni tramite USB. In genere questo tipo di rete ha il vantaggio della
  facilità di installazione e di bassi costi per gli apparati, che non devono
  gestire politiche di distribuzione dei dati, ma è efficace solo per un
  numero limitato di stazioni, in quanto il canale deve distribuire ad ogni
  nodo tutto il traffico, compreso quello destinato agli altri, e può essere
  facilmente saturato.  Inoltre in caso di rottura del canale centrale tutto
  il traffico di rete è totalmente bloccato e l'intera rete non è usabile.

\item[\textit{ring}] È una rete in cui ogni stazione ha due stazioni vicine, a
  loro volta collegate ad un'altra stazione, fino a formare un anello.
  Ciascuna stazione comunica con le stazioni limitrofe, ed i messaggi vengono
  inoltrati lungo l'anello per essere ricevuti dalla stazione di destinazione.
  È potenzialmente più efficiente della struttura a \textit{bus} in quanto non
  è necessario che il messaggio attraversi tutto l'anello, ma solo la parte
  necessaria a raggiungere la destinazione. Anche in questo caso però la
  rottura di un cavo o di una stazione comporta l'inutilizzabilità dell'intera
  rete.

  Questa topologia di rete, un tempo era diffusa anche nella realizzazione di
  reti locali grazie alla tecnologia denominata \textit{token-ring},
  sviluppata e promossa dalla IBM. In questo ambito è oggi sostituita in
  maniera quasi completa dalle reti ethernet, ma viene invece utilizzata in
  maniera abbastanza estesa per i collegamenti in fibra ottica.
  
\item[\textit{star}] È una rete in cui esiste uno snodo centrale, un
  \textit{hub} o uno \textit{switch},\footnote{in realtà un \textit{hub}
    appartiene a questa topologia solo dal punto di vista delle connessioni
    fisiche, dato che poi tutto il traffico viene comunque reinviato a tutte
    le stazioni connesse.} cui vengono connesse le varie stazioni.  Richiede
  normalmente una maggiore estensione della cablatura, ma la rottura di un
  cavo non interrompe tutta la rete.  Inoltre usando uno \textit{switch} i
  pacchetti vengono smistati direttamente dalla stazione di origine alla
  destinazione, e non si soffre del problema del collo di bottiglia dovuto
  alla necessità di trasmettere tutti i dati ad ogni stazione collegata.

  Questa è la topologia utilizzata dalle versioni recenti delle reti ethernet,
  ed è probabilmente quella più comune nella realizzazione di reti locali.
  
\item[\textit{tree}] È una rete che integra in forma gerarchica più reti a
  stella. Viene in genere realizzata connettendo su una \textit{backbone} o su
  uno switch centrale diversi \textit{hub} o \textit{switch} periferici. In
  questo modo si possono aumentare le stazioni collegate superando i limiti
  sul numero di dispositivi collegati ad un singolo switch e limitare la
  quantità di traffico che deve passare per la \textit{backbone}.

\item[\textit{mesh}] È una rete che comporta la presenza di diversi percorsi
  possibili per la comunicazione. È in genere la modalità in cui vengono
  create le reti WAN, o i cosiddetti \textit{fabric switch}, in cui, per
  ottimizzare la velocità di trasmissione, si effettuano connessioni
  incrociate fra più \textit{switch}, così da avere strade diverse per il
  flusso dei dati, con un traffico più distribuito, che permette di comunicare
  con latenze inferiori.
\end{basedescript}


\subsection{I protocolli}
\label{sec:net_protocols}

Come abbiamo accennato parlare di reti significa parlare di un insieme molto
vasto ed eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico,
alla fibra ottica, alle comunicazioni via satellite o via radio. Per rendere
possibile la comunicazione attraverso un così variegato insieme di mezzi sono
stati adottati una serie di protocolli, il più famoso dei quali, quello alla
base del funzionamento di Internet, è il protocollo TCP/IP.

Una caratteristica comune dei protocolli di rete è il loro essere strutturati
in livelli sovrapposti. In questo modo ogni protocollo di un certo livello può
realizzare le sue funzionalità basandosi su un protocollo del livello
sottostante.  Questo modello di funzionamento è stato standardizzato dalla
\textit{International Standards Organization} (ISO) che ha preparato fin dal
1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
strutturato in sette livelli, secondo quanto riportato in
tab.~\ref{tab:net_osilayers}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|c|c|} 
    \hline
    \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
    \hline
    \hline
    Livello 7&\textit{Application}  &\textsl{Applicazione}\\ 
    Livello 6&\textit{Presentation} &\textsl{Presentazione} \\ 
    Livello 5&\textit{Session}      &\textsl{Sessione} \\ 
    Livello 4&\textit{Transport}    &\textsl{Trasporto} \\ 
    Livello 3&\textit{Network}      &\textsl{Rete}\\ 
    Livello 2&\textit{DataLink}     &\textsl{Collegamento Dati} \\
    Livello 1&\textit{Physical}     &\textsl{Connessione Fisica} \\
    \hline
\end{tabular}
\caption{I sette livelli del protocollo ISO/OSI}
\label{tab:net_osilayers}
\end{table}

\noindent La definizione di ciascuno di questi livelli è la seguente:
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
\item[\textsl{Applicazione}] Il livello di applicazione indica il livello
  finale in cui un utente interagisce con l'applicazione. Si indicano come
  esempi di questo livello le applicazioni per l'uso di telnet e FTP.
  
\item[\textsl{Presentazione}] Il livello di presentazione fornisce le
  funzionalità di codifica e conversione dei dati usate dal successivo livello
  di applicazione, come la rappresentazione dei caratteri, i formati dei dati
  (audio, video, immagini), gli schemi di compressione, la cifratura.
  
\item[\textsl{Sessione}] Il livello di sessione gestisce, crea e termina
  sessioni di comunicazione; è a questo livello che sono impostati, definiti e
  sincronizzati gli scambi di dati. Di norma è qui che sono definiti i
  protocolli di funzionamento dei singoli servizi (telnet, FTP, e-mail) che
  vengono offerti sulla rete.
  
\item[\textsl{Trasporto}] Il livello di trasporto fornisce la comunicazione
  tra le applicazioni che girano sulle due stazioni terminali; è
  sostanzialmente equivalente all'omonimo livello del modello TCP/IP
  illustrato più avanti.
  
\item[\textsl{Rete}] Il livello di rete si occupa dello smistamento dei
  singoli pacchetti su una rete interconnessa, ed è a questo livello che si
  definiscono gli indirizzi di rete che identificano macchine non in diretto
  collegamento fisico; è sostanzialmente equivalente all'omonimo livello del
  modello TCP/IP illustrato più avanti.

\item[\textsl{Collegamento Dati}] Il livello di collegamento dati è quello che
  fornisce una trasmissione affidabile dei dati su una connessione fisica.  A
  questo livello si definiscono caratteristiche come l'indirizzamento dei
  dispositivi, la topologia della rete, la sequenza dei pacchetti, il
  controllo del flusso e la notifica degli errori sul livello di connessione
  fisica (cioè delle singole stazioni collegate direttamente fra loro da una
  connessione fisica, e non attraverso i livelli superiori del protocollo). 
  
  La IEEE ha diviso questo livello in due ulteriori parti, il \textit{Logical
    Link Control} (LLC), definito nello standard IEEE 802.2, che gestisce le
  comunicazioni fra dispositivi all'interno di un singolo collegamento in una
  rete, ed il \textit{Media Access Control} (MAC) che gestisce l'accesso al
  mezzo fisico, e consente a dispositivi diversi di identificarsi univocamente
  in una rete: a questo livello sono definiti gli indirizzi fisici, detti
  appunto \textit{MAC address}, delle schede di rete (che tratteremo in
  sez.~\ref{sec:net_intro}).

\item[\textsl{Connessione fisica}] Il livello di connessione fisica si occupa
  delle caratteristiche materiali (elettriche, fisiche, meccaniche) e
  funzionali per attivare, disattivare e mantenere il collegamento fisico fra
  diverse reti di comunicazione. Sono definiti a questo livello
  caratteristiche come l'ampiezza e la temporizzazione dei segnali, il tipo
  dei connettori, la massima capacità di trasmissione, le distanze
  raggiungibili.
\end{basedescript}

Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
serie di protocolli X.25 per la commutazione di pacchetto. Nel frattempo però
era stato sviluppato un altro protocollo di comunicazione, il TCP/IP, su cui
si basa Internet, che è diventato uno standard de facto.  Il modello di
quest'ultimo, più semplice, viene chiamato anche modello DoD (sigla che sta
per \textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA
per conto del Dipartimento della Difesa Americano.

\begin{figure}[htb]
  \centering
  \includegraphics[width=12cm]{images/iso_tcp_comp}
  \caption{Confronto fra il modello OSI ed il modello TCP/IP nella loro
  relazione con il sistema.}
  \label{fig:net_osi_tcpip_comp}
\end{figure}

Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
(riassunti in tab.~\ref{tab:net_layers}). Un confronto fra i due modelli è
riportato in fig.~\ref{fig:net_osi_tcpip_comp}, dove viene evidenziata anche
la corrispondenza fra i rispettivi livelli, che comunque è approssimativa. Si
è indicato in figura anche fra quali livelli, nel sistema operativo, viene
inserita l'interfaccia di programmazione (i cosiddetti \textit{socket}) per
l'accesso alla rete.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|c|c|l|} 
    \hline
    \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
    \hline
    \hline
    Livello 4&\textit{Application} &\textsl{Applicazione}& 
    Telnet, FTP, etc. \\ 
    Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ 
    Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP)  \\ 
    Livello 1&\textit{Link} &\textsl{Collegamento}& 
    ethernet, PPP, \textit{Wi-Fi}  \\
    \hline
\end{tabular}
\caption{I quattro livelli del protocollo TCP/IP.}
\label{tab:net_layers}
\end{table}

Il nome del modello deriva dai due principali protocolli su cui è basata
Internet, il TCP (\textit{Transmission Control Protocol}) che copre il livello
3, e l'IP (\textit{Internet Protocol}) che copre il livello 2. Le funzioni dei
vari livelli sono le seguenti:

\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\textsl{Applicazione}] È relativo ai programmi di interfaccia con la
  rete, in genere questi vengono realizzati secondo il modello
  \textit{client-server},\footnote{si intende con questo una modalità di
    comunicazione in cui un programma di richiesta, detto \textit{client},
    interroga opportunamente un programma di servizio, detto \textit{server}.}
  realizzando una comunicazione secondo un protocollo che è specifico di
  ciascuna applicazione.
\item[\textsl{Trasporto}] Fornisce la comunicazione tra singole applicazioni
  che girano sulle stazioni terminali, regola il flusso delle informazioni,
  può fornire un trasporto affidabile, cioè con recupero degli errori o
  inaffidabile. I protocolli principali di questo livello sono il TCP e l'UDP.
\item[\textsl{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
  rete complessa e interconnessa, a questo stesso livello operano i protocolli
  per il reperimento delle informazioni necessarie allo smistamento, per lo
  scambio di messaggi di controllo e per il monitoraggio della rete. Il
  protocollo su cui si basa questo livello è IP (sia nella attuale versione,
  IPv4, che nella nuova versione, IPv6).
\item[\textsl{Collegamento}] È responsabile per l'interfacciamento al
  dispositivo elettronico che effettua la comunicazione fisica, gestendo
  l'invio e la ricezione dei pacchetti da e verso l'hardware.
\end{basedescript}

Quale dei due modelli usare è spesso una questione di gusti; il modello
ISO/OSI è più teorico e generale, il modello TCP/IP è più legato alla
struttura con cui la gestione della rete è implementata in un sistema
GNU/Linux. Per questo motivo, e data la sua maggiore semplicità, nel resto
del testo faremo riferimento solo a quest'ultimo.

\begin{figure}[!htb]
  \centering \includegraphics[width=12cm]{images/tcp_data_flux}
  \caption{Strutturazione del flusso dei dati nella comunicazione fra due
    applicazioni attraverso i protocolli della suite TCP/IP.}
  \label{fig:net_tcpip_data_flux}
\end{figure}

Per cercare di capire meglio le ragioni di tutta questa suddivisione in
livelli consideriamo un'analogia con quanto avviene nella spedizione di una
lettera per posta aerea in America.  Voi scrivete la vostra bella lettera su
un foglio, che mettete in una busta con l'indirizzo che poi imbucate.  Il
postino la raccoglierà dalla buca delle lettere per portarla al centro di
smistamento, dove in base alla sua destinazione sarà impacchettata insieme a
tutte quelle che devono essere inviate per posta aerea, e mandata al
successivo centro di raccolta. Qui sarà reimpacchettata insieme a quelle
provenienti dagli altri centri di smistamento ed imbarcata sull'aereo. Una
volta scaricate in America le varie lettere saranno spacchettate e
reimpacchettate per lo smistamento verso la destinazione finale. Qui un altro
postino prenderà la vostra e la metterà nella cassetta della posta del vostro
destinatario, il quale la aprirà e leggerà quello che gli avete scritto.

Questo è molto simile a quello che succede quando volete spedire dei dati via
rete, secondo il procedimento che è illustrato in
fig.~\ref{fig:net_tcpip_data_flux}. Ad ogni passaggio attraverso un livello
del protocollo al nostro pacchetto di dati viene aggiunta una intestazione
relativa al protocollo utilizzato in quel livello, si dice cioè che un
pacchetto di un protocollo viene ``\textsl{imbustato}'' nel protocollo
successivo. A differenza della posta in questo caso i pacchetti con i dati non
vengono disfatti ad ogni livello per passare in un pacchetto diverso, ma
vengono reimbustati pari pari al livello successivo, i vari
``\textsl{pacchetti}'' vengono disfatti (e la relativa intestazione rimossa)
solo quando si torna indietro ad un livello superiore.

Questo meccanismo fa si che il pacchetto ricevuto ad un livello \textit{n}
dalla stazione di destinazione sia esattamente lo stesso spedito dal livello
\textit{n} dalla stazione sorgente.  Tutto ciò rende facile progettare il
software in maniera modulare facendo riferimento unicamente a quanto
necessario ad un singolo livello, con la confidenza che questo poi sarà
trattato uniformemente da tutti i nodi della rete.



\section{Il TCP/IP}
\label{sec:net_tcp_ip}

Come accennato in sez.~\ref{sec:net_protocols} negli anni sono stati creati
molti tipi diversi di protocolli per la comunicazione via rete, in questo
testo però prenderemo in esame soltanto il caso di reti basate su TCP/IP, il
``\textsl{protocollo}''\footnote{in realtà non si tratta di un solo
  protocollo, ma di una \textit{suite} in cui sono inseriti vari protocolli,
  in modo da coprire in maniera sostanzialmente completa le più varie esigenze
  di comunicazione.}  più diffuso, quello su cui si basa
``\textit{Internet}'', e che ormai è diventato uno standard universale e
disponibile su qualunque sistema operativo.  In questa sezione ci limiteremo
ad introdurre i concetti fondamentali delle reti IP, la notazione e le
terminologie principali.


\subsection{Introduzione}
\label{sec:net_intro}

Dato che il protocollo è nato su macchine Unix, il TCP/IP è la modalità di
comunicazione nativa di GNU/Linux, e benché per compatibilità siano stati
implementati nel kernel anche parecchi altri protocolli di comunicazione (come
DECnet, AppleTalk, IPX), questo resta il principale ed il più usato e non
soltanto in ambiente Unix.

\begin{figure}[!htbp]
  \centering
  \includegraphics[width=12cm]{images/tcpip_overview}  
  \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
  \label{fig:net_tcpip_overview}
\end{figure}

Come illustrato in sez.~\ref{sec:net_protocols} l'insieme di protocolli che
costituisce il TCP/IP è strutturato, secondo l'omonimo modello, su 4 livelli;
a ciascuno di essi corrisponde un particolare compito, svolto da uno (o più)
protocolli specifici. In fig.~\ref{fig:net_tcpip_overview} si è riportata una
panoramica dei principali protocolli che costituiscono il TCP/IP e come questi
vengono suddivisi nei quattro livelli illustrati in precedenza.

\index{socket|(} 

L'interfaccia fondamentale usata dal sistema operativo per la comunicazione in
rete è quella dei cosiddetti \textit{socket}, nata nel 1983 a Berkeley e resa
pubblica con il rilascio di BSD 4.2. La flessibilità e la genericità
dell'interfaccia consente di utilizzare i socket con i più disparati
meccanismi di comunicazione, e non solo con l'insieme dei protocolli TCP/IP,
si ricordi infatti, come illustrato in sez.~\ref{sec:struct_file_vfs}, che
essi sono disponibili anche come oggetti sul filesystem (i cosiddetti
\textsl{socket locali}).

Con i socket infatti si può creare un canale di comunicazione fra due stazioni
remote, sul quale inviare i dati direttamente, senza doversi preoccupare di
tutto il procedimento di passaggio da un livello all'altro che viene eseguito
dal kernel. Tutte le applicazioni che forniscono i principali servizi su
Internet (pagine WEB, posta elettronica, connessione remota) sono realizzate a
livello di applicazione usando questa interfaccia. Solo per applicazioni
specialistiche per il controllo della rete il kernel mette a disposizione
delle ulteriori interfacce che permettono di accedere direttamente ai livelli
inferiori del protocollo.

Come mostrato in fig.~\ref{fig:net_tcpip_data_flux} i \textit{socket} fanno da
ponte fra il livello di applicazione e quello di trasporto; una volta inviati
su un socket i dati vengono passati (dal kernel) ad uno dei protocolli del
livello di trasporto, che sono quelli che si curano di trasmettere i dati
dall'origine alla destinazione, secondo le modalità specificate dal tipo di
socket scelto. Così se si è usato uno \textit{stream socket} basato sul TCP
quest'ultimo si curerà di stabilire la connessione con la macchina remota e
garantire l'affidabilità della comunicazione controllando eventuali errori,
ritrasmettendo i pacchetti persi e scartando quelli duplicati.\footnote{in
  questo caso dal punto di vista dell'utente la trasmissione dei dati è più
  simile ad un collegamento telefonico che ad un invio di lettere; useremo
  questa ed altre analogie nel seguito, ma si deve essere consapevoli che
  nessuna di esse è mai perfettamente congruente con il comportamento
  effettivo della rete.}  

\index{socket|)}

Al livello successivo sarà poi IP che curerà l'invio dei singoli pacchetti
sulla rete, ed è su questo livello che operano i vari dispositivi che su
Internet consentono lo smistamento dei pacchetti fino alla loro destinazione
finale. È a questo livello che sono definiti gli indirizzi IP che identificano
ogni macchina sulla rete.

Il livello finale è quello dell'interfaccia di rete usata per trasmettere i
pacchetti verso l'esterno, che a seconda dei casi può essere una scheda
Ethernet o l'interfaccia associata al modem; questo si incaricherà di
trasmettere i dati sulla rete fisica che connette la macchina all'esterno (sia
questa una rete locale o Internet) utilizzando anche qui gli opportuni
protocolli di comunicazione.

Benché quest'ultimo livello non faccia strettamente parte del protocollo
TCP/IP, è comunque importante approfondire brevemente le caratteristiche dei
protocolli di comunicazioni fisica usati sulle reti locali di tipo
\textit{broadcast}, che fanno riferimento alla famiglia di IEEE 802.x, e che
coprono le più diffuse tecnologie come appunto Ethernet dato che queste hanno
comunque importanti riflessi anche sulle caratteristiche del
TCP/IP. Esamineremo invece le connessioni punto-punto in
sez.~\ref{sec:net_PPP}.

\itindbeg{MAC~address}

Come accennato in sez.~\ref{sec:net_protocols} lo standard IEEE 802.2
definisce una modalità generica di comunicazione che fa ricorso a degli
indirizzi fisici denominati \textit{MAC address}. Questi indirizzi sono
realizzati come numeri a 48 bit,\footnote{è comunque già prevista una
  estensione a 64 bit denominata \textit{EUI-64} (dove EUI sta per
  \itindex{Extended~Unique~Identifier~(EUI)} \textit{Extended Unique
    Identifier}) mentre gli attuali vengono denominati \textit{MAC-48}, oppure
  \textit{EUI-48}.} e derivano dalle specifiche originali
del protocollo Ethernet, nonostante il loro utilizzo sia stato adottato da
moltissime altre tecnologie.

La notazione prevede che vengano espressi nella forma di 6 ottetti scritti in
cifre esadecimali separate dal carattere ``\texttt{:}'' (o alternativamente
dal ``\texttt{-}''). I primi tre ottetti indicano il produttore di una scheda,
sono assegnati dalla IEEE e vengono anche chiamati OUI
(\textit{Organizationally Unique Identifier}) i successivi tre ottetti sono a
scelta del produttore e possono essere qualunque, ma devono essere univoci per
ogni scheda prodotta. Ad esempio \texttt{00:19:99:58:dc:30} è il \textit{MAC
  address} di una scheda della Fujitsu.

Una ulteriore convenzione è che il secondo bit meno significativo del primo
ottetto viene utilizzato, se $0$, per indicare che l'indirizzo è fra quelli
utilizzati dai produttori, che vengono chiamati \textit{universally
  administered}. Se invece è $1$ si tratta di indirizzi detti \textit{locally
  administered}, che possono essere impostati dall'amministratore di rete; ad
esempio \texttt{00:0e:a6:f6:0a:6d} è l'indirizzo di una scheda di rete
virtuale usata per una macchina virtuale.

I \textit{MAC address} vengono usati per identificare la scheda che ha inviato
un pacchetto (con il \textit{MAC address} sorgente), e quella che lo deve
ricevere (con il \textit{MAC address} destinazione) e con questi viene gestita
la trasmissione dei pacchetti nella rete locale. In genere una scheda legge
solo i pacchetti destinati al suo \textit{MAC address}; inoltre l'indirizzo
(di destinazione) \texttt{FF:FF:FF:FF:FF:FF} è l'indirizzo di
\textit{broadcast}, che deve essere ricevuto da tutte le schede.

\itindend{MAC~address}

In fig.~\ref{fig:net_tcpip_overview} si sono riportati i protocolli principali
che costituiscono il TCP/IP. In questo testo copriremo solo quelli di utilità
più comune; una breve descrizione di quelli riportati in figura è comunque la
seguente:
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
  comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
  cui è costruita Internet. Usa indirizzi a 32 bit, e mantiene tutte le
  informazioni di instradamento e controllo per la trasmissione dei pacchetti
  sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
  quelli specifici di IPv6) vengono trasmessi attraverso di esso.
\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
  a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
  ampliato a 128 bit che consente più gerarchie di indirizzi,
  l'autoconfigurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
  che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
  Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
  vuole essere un sostituto ed una evoluzione.
\item[\textsl{TCP}] \textit{Transmission Control Protocol}. È un protocollo di
  trasporto orientato alla connessione che fornisce un trasporto affidabile
  per un flusso di dati bidirezionale fra due stazioni remote. Il protocollo
  ha cura di tutti gli aspetti del trasporto, come l'acknoweledgment, i
  timeout, la ritrasmissione, ecc. È usato dalla maggior parte delle
  applicazioni.
\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo di
  trasporto senza connessione, per l'invio di dati a pacchetti. Contrariamente
  al TCP il protocollo non è affidabile e non c'è garanzia che i pacchetti
  raggiungano la loro destinazione, si perdano, vengano duplicati, o abbiano
  un particolare ordine di arrivo.
\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
  protocollo usato a livello di rete per gestire gli errori e trasportare le
  informazioni di controllo fra \textsl{stazioni remote} e
  \textsl{instradatori} (cioè fra \textit{host} e \textit{router}). I messaggi
  sono normalmente generati dal software del kernel che gestisce la
  comunicazione TCP/IP, anche se ICMP può venire usato direttamente da alcuni
  programmi come \texttt{ping}. A volte ci si riferisce ad esso come ICMPv4
  per distinguerlo da ICMPv6, la versione usata con IPv6.
\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. È un
  protocollo di livello di rete usato per il \textit{multicasting}, cioè la
  trasmissione uno a molti.  Permette alle stazioni remote di notificare ai
  \textit{router} che supportano questa comunicazione a quale gruppo esse
  appartengono.  Come ICMP viene implementato direttamente sopra IP.
\item[\textsl{DHCP}] \textit{Dynamic Host Configuration Protocol}. È un
  protocollo (vedi sez.~\ref{sec:net_RARP}) che permette di inviare
  informazioni di configurazione alle stazioni presenti in una rete locale,
  come indirizzo IP, indirizzi di \textit{gateway} e server DNS, file per
  l'avvio via rete, ecc.
\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
  mappa un indirizzo IPv4 in un \textit{MAC address} sulla rete locale. Viene
  usato per le reti di tipo \textit{broadcast} (come Ethernet, Token Ring o
  FDDI). Torneremo su di esso in sez.~\ref{sec:net_arp}. Non serve in
  connessioni punto-punto.
\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
  protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
  mappando un indirizzo hardware in un indirizzo IP. Veniva usato per
  assegnare un indirizzo IP ad una macchina al suo avvio, ma è stato
  sostituito da altri protocolli specifici dedicati a questo (vedi
  sez.~\ref{sec:net_RARP}).
\item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
  Fornisce ed estende per IPv6 le funzionalità di ICMPv4, ricomprendendo anche
  quelle di IGMP e ARP, che con IPv6 non esistono più come protocolli a parte.
\item[\textsl{NDP}] \textit{Neighbor Discovery Protocol}. È il successore di
  \textsl{ARP} per IPv6, viene realizzato con pacchetti \textsl{ICMPv6}. Oltre
  alla risoluzione degli indirizzi fisici associati agli indirizzi IPv6 delle
  stazioni presenti sulla rete, consente anche di individuare il prefisso di
  rete, riconoscere i router presenti sulla stessa, individuare indirizzi
  duplicati e macchine non più 
  raggiungibili. % Esistono delle estensioni come \textsl{IND}
  % (\textsl{Inverse Neighbor Discovery}) equivalente di \textsl{RARP}, e il 
  % \textsl{SEND} (\textsl{Secure Neighbor Discovery Protocol}) che permette 
\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
  instradamento usato per comunicare lo stato fra \textit{gateway} vicini a
  livello di \textsl{sistemi autonomi}\footnote{vengono chiamati
    \textit{autonomous systems} i raggruppamenti al livello più alto della
    rete.}, con meccanismi che permettono di identificare i vicini,
  controllarne la raggiungibilità e scambiare informazioni sullo stato della
  rete. Viene implementato direttamente sopra IP.
\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È un protocollo di
  instradamento per \textit{router} su reti interne, che permette a questi
  ultimi di scambiarsi informazioni sullo stato delle connessioni e dei legami
  che ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
  generico di incapsulamento che permette di incapsulare un qualunque altro
  protocollo all'interno di IP. 
\item[\textsl{AH}] \textit{Authentication Header}. Fornisce l'autenticazione
  dell'integrità e dell'origine di un pacchetto IP. È una opzione nativa in
  IPv6 e viene implementato come protocollo a sé su IPv4. Fa parte della suite
  di IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP
  (vedi sez.~4.1.2 di \cite{SGL}).
\item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
  cifratura insieme all'autenticazione dell'integrità e dell'origine di un
  pacchetto IP. Come per AH è opzione nativa in IPv6 e viene implementato come
  protocollo a sé su IPv4. Anch'esso fa parte di IPSEC (vedi sez.~4.1.2 di
  \cite{SGL}).
\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo di
  livello di collegamento progettato per lo scambio di pacchetti su
  connessioni punto-punto.  Viene usato per configurare i collegamenti,
  definire i protocolli di rete usati ed incapsulare i pacchetti di dati. È un
  protocollo complesso con varie componenti (vedi sez.~\ref{sec:net_PPP}).
\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
  di collegamento che permette di trasmettere un pacchetto IP attraverso una
  linea seriale.
\end{basedescript}


\subsection{Gli indirizzi IP (IPv4 e IPv6)}
\label{sec:net_ip_addr}

Per poter comunicare fra loro due computer in rete devono potersi in qualche
modo riconoscere. Gli indirizzi IP, definiti dall'Internet Protocol visto in
sez.~\ref{sec:net_protocols}, svolgono esattamente questo ruolo, che è analogo
a quello del numero di telefono o dell'indirizzo di una casa. Essi devono
identificare univocamente un nodo della rete. Dato che a tutt'oggi la versione
più utilizzata del protocollo è IPv4, faremo nel seguito riferimento ad
indirizzo IP intendendo l'indirizzo previsto da questo protocollo, tratteremo
invece gli indirizzi IPv6, indicandoli esplicitamente come tali, nella parte
finale di questa sezione.

L'analogia più diretta è quella con il telefono; per poter telefonare occorre
avere un proprio numero di telefono e conoscere quello di colui che si vuole
chiamare.  L'indirizzo IP è l'equivalente del numero di telefono, solo che
invece che di un numero decimale composto da un numero variabile di cifre è un
numero binario ed ha una dimensione fissa di quattro byte. Come per i telefoni
ad un numero può corrispondere solo un telefono, ma normalmente ad un telefono
non possono essere associati più numeri, vedremo più avanti invece come ad uno
stesso computer (o a una stessa interfaccia di rete) possono essere assegnati
più indirizzi IP.

Di solito, visto che scrivere i numeri in formato binario è poco
comprensibile, si è soliti esprimere il numero che costituisce l'indirizzo IP
usando una apposita notazione che viene chiamata \textit{dotted decimal},
usando un numero decimale per ciascuno dei quattro byte che compongono
l'indirizzo, separati da un punto; un esempio di questa notazione potrebbe
essere qualcosa del tipo di \texttt{192.168.111.11}. È attraverso questo
numero che il vostro computer viene identificato univocamente su Internet.

Come per il telefono di casa ogni computer connesso ad Internet viene sempre
considerato come facente parte di una \textsl{rete}; la cosa è vera anche per
le reti private non connesse direttamente ad Internet (come quelle che
collegano i computer di un ufficio). Per proseguire nell'analogia si pensi
alle linee telefoniche interne di una ditta, usate per parlare tra uffici
interni.

Dato che Internet, come dice il nome, è un insieme di reti, anche queste
devono venire identificate. Questo è fatto attraverso altrettanti indirizzi
IP, che corrispondono alla parte \textsl{comune} di tutti gli indirizzi delle
macchine sulla stessa rete. Per proseguire nell'analogia con il telefono si
può pensare all'indirizzo di rete come al prefisso che serve per parlare con
un altra città o un altro stato, e che è lo stesso per tutti i telefoni di
quell'area.

La differenza con i prefissi è che un indirizzo di rete IP, quando lo si
scrive, deve essere completato da tanti zeri quanti sono necessari a
raggiungere la dimensione di 32 bit degli indirizzi normali; per riprendere il
precedente esempio di indirizzo IP, un possibile indirizzo di rete ad esso
relativo potrebbe essere \texttt{192.168.111.0}.

Questo meccanismo significa in realtà che ogni indirizzo su Internet, pur
essendo espresso sempre come un singolo numero, nei fatti è composto da due
parti, \textsl{l'indirizzo di rete}, che prende la parte superiore
dell'indirizzo e identifica la particolare sezione di Internet su cui si trova
la vostra rete e \textsl{l'indirizzo della stazione} (il cosiddetto
\textit{host}), che prende la parte inferiore del numero e che identifica la
macchina all'interno della vostra rete.

La situazione dunque è ancora analoga a quella di un numero di telefono che è
diviso in prefisso e numero locale.  Un prefisso è l'equivalente
dell'indirizzo di rete, l'indirizzo IP completo è quello che identifica il
singolo telefono, solo che in questo caso il numero di cifre (binarie) che si
usano per il \textsl{prefisso} non è fisso, e può anche essere cambiato a
seconda dei casi.

Per questo motivo, quando si configura una macchina, ad ogni indirizzo IP si
associa sempre anche quella che viene chiamata una \textit{netmask}: una
maschera binaria che permette di dire quali bit dell'indirizzo sono usati per
identificare la rete e quali per il nodo.  Questa viene espressa con la solita
notazione \textit{dotted decimal}, usando il numero binario costruito mettendo
un 1 ad ogni bit dell'indirizzo corrispondente alla rete e uno zero a quello
corrispondente alla stazione: nel caso dell'indirizzo in esempio si avrebbe
allora una \textit{netmask} uguale a \texttt{255.255.255.0}.

L'assegnazione degli indirizzi IP è gestita a livello internazionale dalla
IANA (\textit{Internet Assigned Number Authority}), che ha delegato la
gestione di parte delle assegnazioni ad altre organizzazioni regionali (come
INTERNIC, RIPE NCC e APNIC).  Originariamente, per venire incontro alle
diverse esigenze, gli indirizzi di rete erano stati organizzati in
\textsl{classi}, (riportate tab.~\ref{tab:IPv4_class}), per consentire
dispiegamenti di reti di dimensioni diverse.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|c|r@{\hspace{3mm}---\hspace{2mm}}r|r|}
    \hline
    \textbf{Classe}&\multicolumn{2}{|c|}{\textbf{Intervallo}}
    &\textbf{Netmask}\\
    \hline
    \hline
    A & \texttt{0.0.0.0}   & \texttt{127.255.255.255} &    \texttt{255.0.0.0}\\
    B & \texttt{128.0.0.0} & \texttt{191.255.255.255} &  \texttt{255.255.0.0}\\
    C & \texttt{192.0.0.0} & \texttt{223.255.255.255} &\texttt{255.255.255.0}\\
    D & \texttt{224.0.0.0} & \texttt{239.255.255.255} &    \texttt{240.0.0.0}\\
    E & \texttt{240.0.0.0} & \texttt{247.255.255.255} &                      \\
    \hline
  \end{tabular}
\caption{Le classi di indirizzi IP.}
\label{tab:IPv4_class}
\end{table}

\itindbeg{multicast}

Le classi usate per il dispiegamento delle reti di cui è attualmente composta
Internet sono le prime tre; la classe D è destinata al cosiddetto
\textit{multicast},\footnote{per poter utilizzare una comunicazione in
  \textit{multicast} una macchina deve registrarsi presso il \textit{router}
  per segnalare appunto a quale \textsl{gruppo di multicast} intende aderire;
  in questo modo il \textit{router} potrà reinviarle i pacchetti di
  \textit{multicast} ricevuti per esso.} che è una modalità di comunicazione
per consentire la spedizione simultanea di uno stesso pacchetto IP da una
stazione singola, che lo emette una volta sola, verso più stazioni
riceventi. Il \textit{multicast} permette di ottimizzare trasmissione dati da
uno verso molti e viene usato per distribuire contenuti; per utilizzare questa
modalità di comunicazione occorre operare su uno di questi indirizzi. Infine
la classe E è riservata per usi sperimentali e non viene impiegata.

\itindend{multicast}

Oggigiorno questa divisione in classi esiste più (perché come vedremo è molto
inefficiente), ma la nomenclatura resta per indicare la dimensione di una
rete; inoltre alcuni programmi cercano di calcolare automaticamente la
\textit{netmask} in base all'indirizzo IP, seguendo questa allocazione, e
questo alle volte può creare problemi, dato che non è detto che la rete in cui
si trova l'indirizzo in questione sia ancora classificabile in questo modo.

Una rete di classe A è una rete che comprende 16777216 (cioè $2^{24}$)
indirizzi IP ed ha \textit{netmask} \texttt{255.0.0.0}, una rete di classe B
comprende 65536 (cioè $2^{16}$) indirizzi ed ha \textit{netmask}
\texttt{255.255.0.0} e una rete di classe C comprende 256 (cioè $2^8$)
indirizzi ed ha \textit{netmask} \texttt{255.255.255.0}.  In realtà gli
indirizzi disponibili per le macchine non sono mai esattamente questi, perché
per ogni rete sono riservati l'indirizzo di rete e l'indirizzo di
\textit{broadcast} (che vedremo a breve).  Pertanto al totale teorico
precedente occorre sempre sottrarne due; questo significa ad esempio che con
una classe C si possono usare solo 254 indirizzi.

\itindbeg{Classless Inter-Domain Routing (CIDR)}

La suddivisione riportata in tab.~\ref{tab:IPv4_class} è estremamente
inefficiente in quanto se un utente necessita di anche solo un indirizzo in
più dei 254 disponibili con una classe C occorre passare ad una classe B, con
un conseguente enorme spreco di indirizzi (si passerebbe da 254 a 65534).

\begin{figure}[!htb]
\centering
\footnotesize
  \begin{minipage}[c]{12cm}
  \begin{tabular} {c@{\hspace{1mm}\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}
      p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}p{3mm}@{\vrule}}
    \omit&
    \multicolumn{20}{c}{$n$ bit}&\multicolumn{12}{c}{$32-n$ bit} \\
    \cline{2-33}
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    CIDR&
    \multicolumn{20}{@{}c@{\vrule}}{\parbox[c]{60mm}{\centering network prefix}} &
    \multicolumn{12}{@{}c@{\vrule}}{\parbox[c]{36mm}{\centering host identifier}} \\
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    \cline{2-33}
  \end{tabular}
\end{minipage}
\caption{Uno esempio di indirizzamento CIDR.}
\label{fig:IPv4_CIDR_addressing}
\end{figure}

Per questo nel 1993, con
l'\href{http://www.ietf.org/rfc/rfc1519.txt}{RFC~1519}, è stato introdotto un
indirizzamento senza classi detto CIDR (acronimo di \textit{Classless
  Inter-Domain Routing}) in cui il limite fra i bit destinati a indicare
l'indirizzo di rete e quelli destinati a indicare l'host finale può essere
piazzato in qualunque punto dei 32 bit totali, come illustrato in
fig.~\ref{fig:IPv4_CIDR_addressing}. In questo modo si possono accorpare più
classi C su un'unica rete o suddividere una classe B. È stata così introdotta
anche una nuova notazione, che permette di indicare la parte di rete
appendendo all'indirizzo l'indicazione del numero di bit riservati alla rete;
nel caso in esempio si avrebbe allora \texttt{192.168.111.11/24}.

\itindbeg{Classless Inter-Domain Routing (CIDR)}
\itindbeg{broadcast}

Oltre alla comunicazione fra due singoli nodi della rete, quella descritta
finora con l'analogia telefonica, su Internet è possibile un'altra modalità di
comunicazione, detta \textit{broadcast}.  In questo caso è un singolo nodo che
può inviare pacchetti che saranno ricevuti da tutti gli altri nodi presenti
nella sua stessa rete; questa modalità di comunicazione è analoga alla
trasmissione via radio, da cui deriva il nome (in inglese).

Per permettere questo tipo di comunicazione su ogni rete, oltre agli indirizzi
dei singoli nodi ed a quello della rete stessa, è necessario disporre di un
indirizzo riservato, che viene chiamato appunto indirizzo di
\textit{broadcast}. Questo per convenzione è sempre ottenuto mettendo ad 1
tutti i bit della porzione dell'indirizzo IP riservata all'host. È questo
indirizzo che deve essere utilizzato da una singola stazione quando vuole
inviare un messaggio contemporaneamente a tutti gli altri nodi presenti su
quella rete. Questo permette di usare direttamente le capacità di alcune
tecnologie di rete, come la Ethernet, che supportano questa modalità di
comunicazione.

La presenza di un indirizzo di \textit{broadcast} permette il funzionamento di
una serie di protocolli ausiliari del TCP/IP che devono poter scambiare e
ricevere informazioni con tutti i computer presenti (ad esempio quelli che
permettono di scoprire quali sono gli indirizzi realmente attivi), senza
doversi indirizzare a ciascuno di essi individualmente.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \multicolumn{1}{|c|}{\textbf{Indirizzo}}&
    \multicolumn{1}{|c|}{\textbf{Esempio}}\\
    \hline
    \hline
    Indirizzo completo  & \texttt{192.168.111.11} \\
    Maschera di rete    & \texttt{255.255.255.0}  \\
    Porzione di rete    & \texttt{192.168.111.}   \\
    Porzione del nodo  & \phantom{\texttt{192.168.111}}\texttt{.11} \\
    Indirizzo di rete   & \texttt{192.168.111.0}  \\
    Indirizzo broadcast & \texttt{192.168.111.255}\\
    \hline
  \end{tabular}
\caption{Specchietto riassuntivo della struttura degli indirizzi IP.}
\label{tab:IPv4_addresses}
\end{table}

In tab.~\ref{tab:IPv4_addresses} si è riassunta la struttura generica di un
indirizzo IP all'interno di una rete, con tutte le tipologie di indirizzi, ed
i vari valori numerici che possono essere richiesti nella configurazione di
una interfaccia di rete per l'uso di un indirizzo IP.

\itindend{broadcast}

Nella assegnazione di un indirizzo IP occorre tenere conto che alcuni
indirizzi sono riservati e non possono essere utilizzati su Internet. Ad
esempio dalla classe A è stata rimossa l'intera rete \texttt{127.0.0.0} che
viene associata alla speciale interfaccia di rete detta
\textit{loopback}.\footnote{è quella indicata dalla sigla \texttt{lo}, interna
  al singolo nodo, che serve per spedire pacchetti a se stessi.}  Si tratta di
una interfaccia virtuale che effettua la comunicazione localmente facendo
passare i pacchetti attraverso il kernel per farli comparire su se stessa (da
cui il suo nome); è convenzione seguita universalmente associare a questa
interfaccia l'indirizzo \texttt{127.0.0.1}, detto \textit{localhost}, che
viene utilizzato per comunicare, senza usare fisicamente la rete, quando un
programma che usa i socket TCP/IP deve fare riferimento ad un altro programma
che gira sulla stessa macchina.

Un altro indirizzo speciale è l'indirizzo nullo, \texttt{0.0.0.0}, che viene
usato per indicare un indirizzo generico non specificato. Lo si usa anche per
indicare l'insieme di tutti gli indirizzi possibili,\footnote{ed in effetti se
  lo si prende come indirizzo di rete corrisponde appunto alla rete che ha
  come host tutti i possibili indirizzi, e cioè Internet.} e per questo viene
anche usato per indicare la cosiddetta \textit{default route}, cioè la
destinazione verso cui inviare tutti i pacchetti con una destinazione al di
fuori della rete locale.

\begin{table}[!htbp]
\centering
\footnotesize
  \begin{tabular}{|c|r@{\hspace{3mm}---\hspace{2mm}}r|}
    \hline
    \textbf{Classe}&  \multicolumn{2}{|c|}{\textbf{Intervallo}}\\
    \hline
    \hline
    A & \texttt{10.0.0.0}    & \texttt{10.255.255.255} \\
    B & \texttt{172.16.0.0}  & \texttt{172.31.255.255} \\
    C & \texttt{192.168.0.0} & \texttt{192.168.255.255}\\
    \hline
  \end{tabular}
\caption{Le classi di indirizzi IP riservate per le reti private.}
\label{tab:net_ipv4_reserved}
\end{table}

Infine l'\href{http://www.ietf.org/rfc/rfc1918.txt}{RFC~1918} riserva una
serie di indirizzi per le cosiddette \textsl{reti private}, cioè per le reti
interne ad una organizzazione che non devono mai essere connesse direttamente
ad Internet.  Si tratta di una rete di classe A, 16 reti di classe B e 256
reti di classe C; i loro indirizzi sono riportati in
tab.~\ref{tab:net_ipv4_reserved}.

Originariamente si intendeva per \textit{reti private} proprio reti che non
dovevano essere interconnesse fra loro, ad uso esclusivo di comunicazione
interna. Oggi buona parte di queste reti possono collegarsi verso Internet,
attraverso l'uso del cosiddetto NAT (\textit{Network Address Translation}) che
consente di far uscire intere reti IP passando con un singolo indirizzo IP
pubblico,\footnote{l'argomento è trattato in sez.~3.2 di \cite{SGL}.} dove si
ha un accesso dall'interno verso Internet, e non viceversa.

Negli anni '90 con la crescita del numero di macchine connesse su Internet, e
prima dello sviluppo delle tecnologie di \textit{Network Address Translation},
si arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili,
specie in vista di una prospettiva (poi rivelatasi prematura) in cui ogni
apparecchio elettronico sarebbe stato inserito all'interno della rete. Per
questo motivo si iniziò a progettare una nuova versione del protocollo IP, che
poi, con un salto di versione, portò ad IPv6.

Dal punto di vista più superficiale il problema deriva dal fatto che con 32
bit si hanno $2^{32}$, cioè ``\textsl{solo}'' 4 miliardi circa, numeri diversi
possibili. In realtà questi ancora oggi sono di più degli apparati
effettivamente collegati in rete, ma la suddivisione di questi numeri con
l'utilizzo delle classi di indirizzamento di tab.~\ref{tab:IPv4_class}, ha
comportato che nella sua evoluzione storica il dispiegamento delle reti e
l'allocazione degli indirizzi siano stati inefficienti, e neanche l'uso del
CIDR ha permesso di eliminare le inefficienze che si erano formate.

Per molti anni la riallocazione delle reti e l'uso del NAT hanno reso meno
urgente il problema ma oggi la crescita dei dispositivi mobili connessi ad
Internet, e lo sviluppo delle tecnologie che consentono di costruire computer
di dimensioni microscopiche dotati di connessione, ha iniziato a far sentire
davvero il limite sul numero di indirizzi IPv4 disponibili: l'assegnazione
delle ultime reti IPv4 rimaste disponibili è stata effettuata dalla IANA il 3
febbraio 2011.

Per risolvere questi problemi il protocollo IPv6 è stato sviluppato come
evoluzione di IPv4, mantenendone inalterate le funzioni che si sono dimostrate
valide, eliminando quelle inutili e aggiungendone poche altre ponendo al
contempo una grande attenzione a mantenere il protocollo il più snello e
veloce possibile. I cambiamenti apportati sono comunque notevoli e possono
essere riassunti a grandi linee nei seguenti punti:
\begin{itemize*}
\item l'espansione delle capacità di indirizzamento e instradamento, per
  supportare una gerarchia con più livelli di indirizzamento, un numero di
  nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi;
\item il supporto diretto nel protocollo per la autoconfigurazione degli
  indirizzi (\textit{Stateless Address Autoconfiguration} o SLAAC) ed il
  consolidamento all'interno di ICMPv6 di molti protocolli ausiliari come ARP
  ed alcune funzionalità analoghe al DHCP con il \textit{Neighbor Discovery
    Protocol} (NDP).
\item la semplificazione del formato dei pacchetti e della divisione delle
  reti, con un supporto per le opzioni del protocollo migliorato, per
  garantire una trasmissione più efficiente del traffico normale, limiti meno
  stringenti sulle dimensioni delle opzioni, e la flessibilità necessaria per
  introdurne di nuove in futuro;
\item il supporto per delle capacità di qualità di servizio (QoS) che
  permetta di identificare gruppi di dati per i quali si può provvedere un
  trattamento speciale (in vista dell'uso di Internet per applicazioni
  multimediali e/o ``real-time'').
\end{itemize*}

Il cambiamento più importante resta comunque il primo, che ha visto passare il
numero di bit usati per indicare un indirizzo IPv6 da 32 a 128, cosa che
dovrebbe risolvere il problema dell'esaurimento se non in maniera definitiva
sicuramente in una prospettiva a lunghissimo termine; con questi numeri
infatti si hanno a disposizione svariate centinaia di migliaia di miliardi di
indirizzi per ogni metro quadro di superficie terrestre. Ma anche se questo è
un numero completamente teorico, che deve scontrarsi con eventuali
inefficienze di allocazione, si è comunque giunti alla conclusione che anche
nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di fornire più di
un migliaio di indirizzi per ogni metro quadro della superficie terrestre.

Dato che il numero di bit è quadruplicato, non è più possibile usare la
notazione coi numeri decimali di IPv4 per rappresentare un indirizzo IP. Per
questo gli indirizzi di IPv6 sono in genere scritti come sequenze di otto
sezioni di numeri esadecimali di quattro cifre cadauno (indicante un gruppo di
16 bit) usando i due punti come separatore. Un indirizzo IPv6 sarà così
espresso nella forma: \texttt{2001:0db8:0000:0000:0008:ba98:2078:e3e3}.

Visto che la notazione resta comunque piuttosto pesante esistono alcune
abbreviazioni; si può evitare di scrivere gli zeri iniziali delle singole
sezioni per cui l'indirizzo precedente si potrebbe abbreviare in
\texttt{2001:db8:0:0:8:ba98:2078:e3e3}. Se poi una intera sezione è nulla la
si può omettere del tutto, così come un insieme di più sezioni nulle
adiacenti, ma questo solo per quelle più a sinistra, per non generare
ambiguità.  Per questo motivo il precedente indirizzo si potrebbe scrivere
ancor più brevemente come \texttt{2001:db8::8:ba98:2078:e3e3}. La notazione
supporta esplicitamente anche l'indicazione contemporanea di un indirizzo e
della sua rete, scrivendoli nella forma \texttt{2001:db8::8:ba98:2078:e3e3/64}.

L'ampliamento del numero di indirizzi comporta anche una organizzazione
completamente diversa della loro allocazione; anzitutto essi sono stati
suddivisi in tre tipologie generali a seconda delle modalità con cui viene
effettuata la trasmissione e la consegna dei pacchetti, che vengono chiamate
\textit{addressing methods}, queste sono:
\begin{basedescript}{\desclabelwidth{1.8cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{unicast}] si tratta degli indirizzi utilizzati della tipologia
  di trasmissione più comune, quella uno ad uno fra due capi della
  comunicazione; gli indirizzi \textit{unicast} vengono assegnati ad una
  singola interfaccia di rete, ed il protocollo si cura di far arrivare i
  pacchetti inviati ad un indirizzo di questo tipo all'interfaccia di rete cui
  esso è assegnato.
\item[\textit{multicast}] si tratta degli indirizzi utilizzati per una
  trasmissione di uno a molti, che nel caso di IPv6 fa parte delle specifiche
  di base dal protocollo; l'invio di un pacchetto ad un indirizzo
  \textit{multicast} fa si che questo venga inoltrato a tutte le interfacce di
  rete che si sono registrate per la ricezione su quell'indirizzo.
\item[\textit{anycast}] è un nuovo tipo di indirizzamento introdotto con IPv6,
  che consente la comunicazione fra un nodo ed un altro facente parte di un
  gruppo; un indirizzo \textit{anycast} può essere assegnato a più macchine,
  ma la comunicazione è sempre uno ad uno, è compito del protocollo (con
  l'opportuno supporto da parte dei router) far sì che i pacchetti inviati a
  questo indirizzo arrivino ad una (in genere quella più vicina nella rete)
  delle macchine che hanno questo indirizzo. 
\end{basedescript}

Una seconda caratteristica di IPv6 è quella dello ``\textit{scope}'' di un
indirizzo, che indica l'\textsl{ambito} di validità dello stesso, definendo in
quale parte della rete viene utilizzato. Con IPv6 tutti gli indirizzi, eccetto
l'indirizzo generico ``\texttt{::}'',\footnote{come per IPv4 l'indirizzo
  generico è indicato con un valore nullo di tutti i bit, cosa che, usando la
  notazione compatta, consente di esprimerlo in questa forma.} hanno uno
\textit{scope}, che serve ad indicare ai router se deve essere instradato o
meno, e l'ambito di applicazione in cui si è garantiti che l'indirizzo sia
valido ed unico. Pertanto si parla di \textit{scope} ``\textit{global}'' per
gli indirizzi che sono validi globalmente su tutta la rete (e devono essere
inoltrati), mentre si parla di \textit{scope} ``\textit{link-local}'' per gli
indirizzi che validi solo all'interno di un collegamento fisico diretto su una
rete locale.\footnote{il concetto di indirizzo \textit{link-local} come
  indirizzo che non può mai essere usato al di fuori di una rete locale è
  comunque generale e valido anche al di là di IPv6, ad esempio sono
  classificati così i \textit{MAC Address} di \textit{Ethernet} e la classe di
  indirizzi \texttt{169.254.0.0/16} di IPv4.} Altri \textit{scope} comunemente
usati sono \textit{interface-local}, che indica l'ambito della singola
interfaccia, \textit{site-local} che indica l'ambito di una rete interna di un
sito, o \textit{organization-local} che indica l'ambito dell'insieme delle
reti dei siti di una stessa organizzazione.

\itindbeg{link-local~address (LLA)} 

Gli indirizzi \textit{unicast} hanno in genere \textit{scope}
``\textit{global}'' ma esistono alcune classi di indirizzi riservati che hanno
sempre \textit{scope} \textit{link-local}: la prima è quella costituita dal
\textit{localhost}, che in IPv6 si esprime come \texttt{::1/128} (cioè tutti
zeri con un 1 finale), la seconda è quella della classe \texttt{fe80::/10},
che costituisce i cosiddetti \textit{link-local addresses}. Agli indirizzi
\textit{anycast} (tolte le due eccezioni precedenti) si applicano gli stessi
\textit{scope} degli indirizzi \textit{unicast}, dal punto di vista del valore
degli indirizzi infatti gli indirizzi \textit{anycast} non sono distinguibili
dagli \textit{unicast}, la differenza nella consegna dei pacchetti dipende
dalla gestione fatta dai router.

Gli indirizzi \textit{link-local} della classe \texttt{fe80::/10} hanno una
rilevanza particolare per il funzionamento del protocollo, a prima vista si
potrebbero considerare una sorta di analogo degli indirizzi di
tab.~\ref{tab:net_ipv4_reserved} per le reti private, ma il loro significato è
piuttosto diverso; essi vengono assegnati obbligatoriamente ad ogni
interfaccia di rete su cui si abilita l'uso di IPv6 (anche quando questa ha un
indirizzo ``\textsl{normale}'') in quanto la loro presenza è necessaria al
funzionamento degli strati di gestione del protocollo come il \textit{Neighbor
  Discovery Protocol} e la \textit{Stateless Address Autoconfiguration}
(torneremo sull'argomento in sez.~\ref{sec:net_ndp_radvd}). In realtà fra
questi sono utilizzati soltanto quelli della sottoclasse \texttt{fe80::/64},
ed i rispettivi valori vengono assegnati utilizzando opportunamente il
\textit{MAC address} della scheda scheda di rete su cui viene abilitato IPv6.

\itindend{link-local~address (LLA)}

I veri equivalenti degli indirizzi IPv4 delle reti private di
tab.~\ref{tab:net_ipv4_reserved} erano quelli della classe \texttt{fec0::/10},
che la definizione originale indicava come indirizzi privati da usare
all'interno di un ``\textit{site}'', la definizione del quale però non era
chiara. A causa di questa ambiguità questa classe è stata deprecata nel 2004,
e dal 2005 gli stessi indirizzi, sono stati ricompresi nella classe
\texttt{fec0::/7} che è stata riassegnata per i cosiddetti \itindex{Unique
  Local Address (ULA)} \textit{Unique Local Address} (ULA), il cui
\textit{scope} è a livello di reti interne ad una organizzazione come
\textit{site-local} o \textit{organization-local}, e che sono i più vicini
equivalenti degli indirizzi di tab.~\ref{tab:net_ipv4_reserved}. 

\begin{figure}[!htbp]
\centering
\footnotesize
\begin{minipage}[c]{14cm}
  \begin{tabular} {c@{\hspace{1mm}\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}}
    \omit&
    \multicolumn{48}{c}{48 bit}&\multicolumn{16}{c}{16 bit}&
    \multicolumn{64}{c}{64 bit} \\
    \cline{2-129}
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    &
    \multicolumn{48}{@{}c@{\vrule}}{\parbox[c]{40mm}{\centering \textit{routing prefix}}} &
    \multicolumn{16}{@{}c@{\vrule}}{\parbox[c]{13mm}{\centering \textit{subnet ID}}} &
    \multicolumn{64}{@{}c@{\vrule}}{\parbox[c]{40mm}{\centering \textit{interface identifier}}}\\
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    \cline{2-129}
\end{tabular}
\end{minipage}
\caption{Indirizzo IPv6 \textit{unicast} generico.}
\label{fig:IPv6_generic_unicast}
\end{figure}


La forma più comune degli indirizzi IPv6, usata per gli indirizzi
\textit{unicast} e \textit{anycast}, prevede la divisione illustrata in
fig.~\ref{fig:IPv6_generic_unicast}. I 64 bit meno significativi, sono
denominati \itindex{interface~identifier} \textit{interface identifier} e
identificano, come suggerito dal nome, una macchina sull'interfaccia di rete a
cui si affaccia l'interfaccia; è previsto che possano essere assegnati in
maniera automatica (ad esempio usando il \textit{MAC address} della stessa).
Questo significa che in in IPv6 ogni rete ha sempre assegnati 64 bit per la
parte di \textit{host}, e non esiste più il concetto di \textit{netmask}. I 64
bit più significativi dell'indirizzo, detti \textit{network prefix} sono usati
per il \textit{routing} ed identificano la rete; sono a loro volta suddivisi
in due parti, un \textit{routing prefix} ed un \textit{subnet ID}.

\begin{figure}[!htbp]
\centering
\footnotesize
\begin{minipage}[c]{14cm}\setlength\tabcolsep{1.pt}
  \begin{tabular} {c@{\hspace{1mm}\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}
      p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}p{.9mm}@{\vrule}}
    \omit&
    \multicolumn{8}{c}{8}&\multicolumn{4}{c}{4}&\multicolumn{4}{c}{4}&
    \multicolumn{112}{c}{112 bit} \\
    \cline{2-129}
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    &
    \multicolumn{8}{@{}c@{\vrule}}{\textit{prefix}} &
    \multicolumn{4}{@{}c@{\vrule}}{\textit{fl}} &
    \multicolumn{4}{@{}c@{\vrule}}{\textit{sc}} &
    \multicolumn{112}{@{}c@{\vrule}}{\parbox[c]{40mm}{\centering \textit{group ID}}}\\
    \omit\hfill\vrule &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&&
                      &&&&&&&& &&&&&&&& &&&&&&&& &&&&&&&& \\
    \cline{2-129}
\end{tabular}
\end{minipage}
\caption{Indirizzi \textit{multicast} riservati.}
\label{fig:IPv6_multicast_reserved}
\end{figure}

La forma generica di un indirizzo \textit{multicast} è invece illustrata in
fig.~\ref{fig:IPv6_multicast_reserved}; il prefisso vale sempre \texttt{FF},
il valore dei successivi quattro bit di \textit{flag} è normalmente nullo,
mentre i successivi 4 bit indicano lo \textit{scope} dell'indirizzo che è
codificato con un valore numerico, ad esempio \textit{interface-local} ha
valore 1 ed i relativi indirizzi sono nella classe \texttt{FF01::/8},
\textit{link-local} ha valore 2 e gli indirizzi sono nella classe
\texttt{FF02::/8}, \textit{site-local} ha valore 5 con classe
\texttt{FF05::/8}.

\begin{table}[!htbp]
\centering
\footnotesize
  \begin{tabular}{|c|l|l|}
    \hline
    \textbf{Indirizzo}& \textbf{Significato}&\textbf{\textit{Scope}}\\
    \hline
    \hline
    \texttt{ff01::1}    & Tutti i nodi  & (\textit{interface-local}) \\
    \texttt{ff02::1}    & Tutti i nodi  & (\textit{link-local})\\
    \texttt{ff01::2}    & Tutti i router & (\textit{interface-local})\\
    \texttt{ff02::2}    & Tutti i router & (\textit{link-local})\\
    \texttt{ff05::2}    & Tutti i router & (\textit{site-local})\\
    \hline
  \end{tabular}
  \caption{I principali indirizzi di \textit{multicast} riservati ad uso del
    protocollo.}
\label{tab:IPv6_main_multicast}
\end{table}

Si noti poi che con IPv6 non esiste più l'indirizzo di \textit{broadcast}. La
funzionalità, grazie proprio alla disponibilità degli indirizzi
\textit{link-local}, viene fornita ricorrendo al \textit{multicast} che fa
parte delle specifiche di base dal protocollo. Pertanto per inviare un
pacchetto a tutte le macchine della propria rete basterà usare l'indirizzo di
\textit{multicast} riservato \texttt{ff02::1}, che raccoglie tutti i nodi
della propria rete locale. Un elenco di alcuni indirizzi di \textit{multicast}
riservati di ausilio al funzionamento del protocollo è illustrata in
tab.~\ref{tab:IPv6_main_multicast}.

\begin{table}[!htbp]
\centering
\footnotesize
  \begin{tabular}[c]{|l|l|}
    \hline
    \textbf{Rete}&  \textbf{Descrizione} \\
    \hline
    \hline
    \texttt{::/0}         & l'indirizzo generico\\
    \texttt{::1/128}      & il \textit{localhost}\\
    \texttt{::ffff:0:0/96}& gli indirizzi IPv4 mappati su IPv6\\
    \texttt{fe80::/10}    & gli indirizzi \textit{link-local} (LLA)\\
    \texttt{fc00::/7}     & gli indirizzi \textit{unique-local} (ULA)\\
    \texttt{ff00::/8}     & gli indirizzi di \textit{multicast}\\
    \texttt{2001:db8:/32} & gli indirizzi riservati agli esempi\\
    \hline
  \end{tabular}
\caption{Gli indirizzi IPv6 riservati.}
\label{tab:net_ipv6_main_address}
\end{table}

Infine gli indirizzi IPv4 vengono mappati su IPv6 con una classe di indirizzi
specifica nella forma \texttt{::ffff:0:0/96} (detti \textit{IPv4 mapped
  address} in cui ci sono 80 bit a zero, seguiti da 16 bit a uno e dai 32 bit
dell'indirizzo IPv4. Per questi vale la ulteriore notazione di poter esprimere
le ultime due cifre di un indirizzo IPv6 in notazione dotted decimal, pertanto
l'indirizzo IPv4 \texttt{192.168.1.1} verrebbe espresso come
\texttt{::ffff:192.168.1.1}. Una forma alternativa, chiamata \textit{IPv4
  compatible address} prevede soltanto zeri iniziali usa cioè la classe
\texttt{::0/96}, ed in tal caso il precedente indirizzo diverrebbe
\texttt{::192.168.1.1}, questa forma è deprecata e non deve essere usata. Un
elenco dei principali indirizzi IPv6 è illustrato in
tab.~\ref{tab:net_ipv6_main_address}.



\subsection{L'instradamento o \textit{routing}}
\label{sec:net_routing}

\itindbeg{routing}

L'identificazione di un nodo sulla rete effettuata tramite l'indirizzo IP è
solo il primo passo per poter stabilire effettivamente una comunicazione. Una
volta che si sappia la destinazione finale infatti, occorre sapere anche come
poterci arrivare. Il lavoro di smistamento e reindirizzamento verso la loro
destinazione finale dei pacchetti di dati che vengono trasmessi via rete è
quello che in termini tecnici viene chiamato \textsl{instradamento}, in
inglese \textit{routing}.

Il \textit{routing} è uno degli argomenti più complessi delle tecnologie di
rete, ma qui lo tratteremo soltanto nei suoi aspetti più elementari. In
generale il problema si può dividere in due: nella parte relativa alla propria
rete locale, ed in quello che succede una volta usciti da essa.  Il
funzionamento del \textit{routing} per la trasmissione dei pacchetti su
Internet comporta una serie di problematiche estremamente complesse, per cui
ci limiteremo ad una semplice descrizione funzionale, ma dal punto di vista di
una rete locale tutto si riduce al problema di come fare arrivare
all'\textsl{esterno} i pacchetti che escono dai singoli computer in essa
presenti.

\itindbeg{router}

In questo caso si può ancora fare riferimento all'analogia telefonica: si può
pensare alla propria rete locale come alla rete telefonica interna di una
ditta; per poter uscire e telefonare all'esterno occorre in qualche modo
passare dal centralino. Su Internet le macchine che fanno da ``centralino'' e
permettono il collegamento di reti diverse smistando fra di esse i pacchetti
loro destinati sono dette \textit{router}.

\itindbeg{default~gateway} 

In una rete locale il ruolo del centralino è svolto dal cosiddetto
\textit{default gateway}, questa è la macchina che nella vostra rete fa da
ponte verso l'esterno, ed in generale indica la macchina che vi consente di
raggiungere Internet.  Tutte le telefonate dirette fuori (cioè tutti i
pacchetti di dati che devono uscire dalla rete locale per andare su Internet)
devono passare da questa macchina; per questo quando installate una macchina
in una rete locale dovete sempre sapere l'indirizzo del \textit{default
  gateway}.

La differenza coi numeri telefonici sta però nel fatto che l'indicazione di
usare un centralino non si può inserire all'interno del numero che si compone
(ad esempio mettendo un 0 o un 1 all'inizio dello stesso), ma in questo caso
deve essere proprio specificato il numero completo della macchina che fa da
ponte, che anch'essa avrà un suo indirizzo IP. Un'altra differenza è che con
il TCP/IP quando si deve far arrivare un pacchetto da una rete ad un altra,
anche se non si dovesse uscire su Internet (ad esempio due reti interne
diverse), deve essere sempre utilizzato un \textit{gateway}, cioè una macchina
che possa fare da ``\textsl{cancello di ingresso}'' per i pacchetti destinati
a quella rete.

Una volta usciti dalla rete locale la situazione si complica molto, ed in
questo caso l'analogia telefonica non ci aiuta, perché il collegamento
telefonico nasce a \textsl{commutazione di linea}. Per realizzarlo cioè si
mettevano effettivamente in collegamento elettrico (la cosiddetta
\textsl{continuità galvanica}) i due telefoni con una serie di
selettori. Internet invece è progettata per funzionare a \textsl{commutazione
  di pacchetto}: i dati inviati vengono spezzati in pacchetti e passati da un
nodo della rete all'altro fino ad arrivare alla loro destinazione finale, dove
vengono riassemblati.  Non esiste cioè una connessione diretta fra due nodi,
anche se poi i programmi usano delle funzionalità che permettono di lavorare
come se le cose fossero così.

Per questo, come dice poi lo stesso nome di \textsl{instradamento},
un'analogia che illustra più chiaramente i concetti del \textit{routing} è
quella delle reti stradali.  Ad esempio quando lavoravo per l'INFN mi capitava
spesso di dover andare al CERN.  Per farlo prendevo l'autostrada a Firenze
Sud, a Firenze Nord cambiavo sulla Firenze Mare, uscendo a Lucca per fare il
raccordo per prendere l'autostrada per Genova, da Genova proseguivo per
Alessandria, cambiavo di nuovo per Torino, dove fatta la circonvallazione
prendevo l'autostrada per il traforo del Monte Bianco. Da lì il raccordo porta
sull'autostrada per Ginevra, nella cui periferia sono i laboratori del CERN.

Come si può notare si tratta di un bel percorso complicato, che comporta il
passaggio da diversi svincoli, incroci e caselli autostradali.  Quando si
invia un pacchetto su Internet succede qualcosa di molto simile, e anche lui
deve passare attraverso degli analoghi dei ``\textsl{caselli}''.  Quello che
succede ad esempio quando ci si collega con un modem e si inizia a navigare un
sito web, è che i pacchetti che escono dal proprio computer vengono inviati al
\textit{router} del vostro provider che vi fa da \textit{default gateway}
(l'equivalente del casello). Da lì prenderanno la strada opportuna per
arrivare al \textit{router} del provider a cui è collegato il server web del
sito, che li manderà a quest'ultimo.

\itindend{default~gateway}

In tutto questo percorso i pacchetti passeranno per una serie di altri
\textit{router} che sanno che strada devono prendere i pacchetti per poter
arrivare alla destinazione finale. La differenza fra i caselli o svincoli
stradali ed i \textit{router} è che questi ultimi sanno indicare da soli ai
pacchetti la strada su cui devono andare per arrivare a destinazione. In
realtà sono ancora più intelligenti, e sono in grado di far prendere ai
pacchetti la strada più veloce, tenendo conto di eventuali ingorghi,
incidenti, interruzioni del traffico ecc.  Così se il tunnel del Monte Bianco
viene chiuso, quando si arriva a Torino il ``\textit{router}'' farà deviare
automaticamente verso il Frejus.

\itindend{router}
\itindend{routing}


\subsection{I servizi e le porte}
\label{sec:net_ports}

\index{porte|(} 

Finora abbiamo parlato quasi esclusivamente di indirizzi IP, ma come accennato
nell'introduzione (si ricordi quanto detto in sez.~\ref{sec:net_protocols})
\textit{Internet Protocol} è solo uno dei protocolli di Internet, e copre
soltanto il \textsl{livello di rete}. Abbiamo già visto che per poter
effettuare delle comunicazioni fra loro i programmi devono poter creare delle
connessioni, e per far questo si deve usare l'interfaccia dei socket, che sono
basati invece sui protocolli del \textsl{livello di trasporto}, come TCP ed
UDP.

Occorre perciò introdurre un'altra delle caratteristiche del protocollo
TCP/IP, relativa stavolta al \textsl{livello di trasporto}, senza comprendere
la quale mancherebbero le basi per poter spiegare il funzionamento di
quest'ultimo: quella delle \textsl{porte}. Anche in questo caso l'analogia
telefonica ci viene, sia pure in maniera molto parziale, in aiuto. Finora
infatti abbiamo parlato degli indirizzi IP come se fossero dei numeri di
telefono, ma questo riguarda solo la parte del protocollo che viene usato per
effettuare la trasmissione fra due computer, e cioè il protocollo IP.

Allora come su un numero di telefono può rispondere una persona (se solleva la
cornetta), una segreteria telefonica, un fax, o un altro computer (se c'è
attaccato un modem), lo stesso accade anche per Internet. Su un indirizzo IP
possono cioè rispondere diversi \textsl{servizi}, corrispondenti a forme di
comunicazione diversa, ed occorre identificare quello a cui ci si vuole
rivolgere.

L'analogia telefonica risulta in questo caso molto debole perché di solito per
usufruire dei servizi citati ci vogliono apparecchi diversi, anche se talvolta
si trovano oggetti che assommano più di uno di essi. Per questo un'altra
analogia più appropriata potrebbe essere quella di pensare alle \textsl{porte}
come ai canali della filodiffusione,\footnote{per chi non ha idea di che cosa
  sia, si tratta di una specie di radio via telefono, usata per trasmettere
  musica quando le radio avevano una pessima qualità, ma che oggi non esiste
  praticamente più.} cioè a delle specie di ``\textsl{frequenze}'' diverse su
cui sintonizzate il vostro telefono, sulle quali trovate i contenuti più
diversi.

Ma anche questa analogia è molto parziale, perché nel caso della
filodiffusione il segnale non viene da un altro telefono, ma dal fornitore del
servizio telefonico, e si può solo ascoltare, ed un canale alla volta, mentre
con Internet si può sia ascoltare che trasmettere, da e verso qualunque altro
``corrispondente'', utilizzando in contemporanea un numero arbitrario di
canali.\footnote{in realtà a voler essere pignoli, il numero di canali
  contemporanei per singolo corrispondente può essere al massimo 65535 (pari a
  $2^{16}-1$) e non totalmente arbitrario.}

Tutto questo è possibile perché, come spiegato in sez.~\ref{sec:net_intro}, il
TCP/IP è un insieme di protocolli, ed IP (quello degli indirizzi) è solo la
parte che serve a gestire la trasmissione dei pacchetti da una macchina
all'altra. Per poter effettuare uno scambio di dati fra due programmi che
comunicano via rete sono disponibili gli altri protocolli, che sono quelli che
consentono di stabilire un canale di comunicazione diretto fra una
applicazione ad un'altra.

È per questo motivo che nei protocolli del livello di \textsl{trasporto}, come
UDP e TCP, è stato introdotto il concetto delle \textsl{porte}, cioè un numero
ulteriore (oltre a quello dell'indirizzo) che permetta di identificare le due
applicazioni che stanno usando il protocollo ai due capi della
comunicazione. In questo modo diventa possibile gestire più connessioni
contemporanee tra le stesse macchine (destinate a servizi diversi o
provenienti da applicazione diverse) e tenere separati i pacchetti ad esse
relative. In realtà poi per UDP sarebbe più corretto parlare di canali di
comunicazione, non essendoci in senso stretto una connessione vera e propria
come per il TCP, il quale, oltre all'invio dei pacchetti, permette anche di
assicurare una comunicazione affidabile.
 
Questo significa che quando si vuole inviare della posta elettronica si
comunicherà con la macchina che fornisce il servizio di spedizione utilizzando
una certa porta, mentre quando si vuole leggere una pagina web se ne userà
un'altra, diversa dalla precedente, effettuando con i servizi che si
contattano degli scambi di dati specifici di ciascuno di essi, che vanno a
costituire l'ultimo livello della struttura mostrata in
fig.~\ref{fig:net_osi_tcpip_comp}, quello di \textsl{applicazione}.

Si tenga conto però che in questa forma il concetto di porta può essere
fuorviante, in quanto con porta si rischia di intendere una qualche forma di
accesso permanente che può essere aperto o chiuso. In realtà non esiste
nessuna forma di accesso permanente e lo scambio di dati avviene solo se si
hanno da ambo le parti (lato server e lato client) gli strumenti per
effettuarlo.

Questo significa che non sarà mai possibile sfondare una ``\textsl{porta}''
sul vostro computer, se su di essa non c'è un programma di servizio a ricevere
i dati, così come non possono spaccarvi i timpani urlando alla radio, se è
spenta. Per questo forse sarebbe più chiaro parlare di frequenza, su cui si
può trasmettere o ascoltare, ed in cui ciascuno può essere la trasmittente (il
server) o il ricevente (il client) o anche entrambi allo stesso tempo (ad
esempio nei sistemi \textit{peer to peer}).

Bussando ad una porta (o sintonizzandosi su quella frequenza a seconda
dell'analogia che si preferisce) si potranno scambiare, attraverso l'opportuno
protocollo di applicazione, i dati relativi al servizio associato. Dal punto
di vista del TCP/IP si potrebbe usare un numero di porta qualsiasi, ma la
standardizzazione ha portato ad associare alcuni numeri di porta a dei servizi
specifici: la porta 25 alla posta elettronica, la porta 80 al web, ecc.

Si tenga presente inoltre che come c'è una porta per indicare quale servizio
si vuole raggiungere sulla macchina di destinazione, ci deve essere anche una
porta che identifichi il programma che ha fatto la richiesta sulla macchina di
origine. Questo perché se ad esempio si lanciassero due istanze di un browser
sulla propria macchina andando a leggere lo stesso sito, si avrebbe una
situazione in cui si contatta un server web a partire da uno stesso indirizzo
IP di origine, andando verso lo stesso indirizzo IP e la stessa porta di
destinazione. Ma il proprio kernel deve essere in grado di poter separare i
pacchetti di risposta alle due istanze del browser (che potrebbero leggere
pagine diverse) e per questo le porte non esistono soltanto per i servizi di
destinazione ma anche per i programmi che li contattano.

Questo significa che nella comunicazione con i protocolli del livello di
trasporto (sia con TCP che con UDP) ogni client invierà i suoi pacchetti di
richiesta e riceverà i pacchetti di risposta dal server utilizzando anch'esso
una sua porta, che viene chiamata \index{porte!sorgente} \textsl{porta
  sorgente}. Quella che viene usata per identificare un servizio che si vuole
contattare, di cui si è parlato finora e che in genere è quella che si intende
quando si parla semplicemente di porta, viene invece chiamata
\index{porte!destinazione} \textsl{porta destinazione}.

A differenza di quanto avviene con la porta destinazione, i cui numeri sono
standardizzati, in genere la porta sorgente viene assegnata automaticamente
dal kernel quando un programma crea una connessione. Per questo motivo viene
chiamata anche \index{porte!effimere} \textsl{porta effimera} (o
\textit{ephemeral port}) proprio in quanto non necessita di avere un valore
predeterminato, ed il suo utilizzo è limitato alla durata di una connessione.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|c|l|}
    \hline
    \textbf{Porta}&\textbf{Protocollo}&\textbf{Servizio}\\
    \hline
    \hline
    \texttt{20}  &TCP& FTP (\textit{File Transfer Protocol}) dati.\\
    \texttt{21}  &TCP& FTP (\textit{File Transfer Protocol}) comandi.\\
    \texttt{22}  &TCP& SSH (\textit{Secure Shell}).\\
    \texttt{23}  &TCP& Telnet.\\
    \texttt{25}  &TCP& SMTP (\textit{Simple Mail Transport Protocol}).\\
    \texttt{53}  &UDP& DNS (\textit{Domain Name Service}).\\
    \texttt{67}  &UDP& DHCP (\textit{Dynamic Host Configuration Protocol}) client.\\
    \texttt{68}  &UDP& DHCP (\textit{Dynamic Host Configuration Protocol}) server.\\
    \texttt{80}  &TCP& HTTP (\textit{Hyper Test Transfer Protocol}).\\
    \texttt{110} &TCP& POP3 (\textit{Post Office Protocol} v.3).\\
    \texttt{111} &TCP/UDP& RPC (\textit{Remote procedure call}).\\
    \texttt{123} &UDP& NTP (\textit{Network Time Protocol}).\\
    \texttt{143} &TCP& IMAP (\textit{Internet Message Access Protocol}).\\
    \texttt{161} &UDP& SNMP (\textit{Simple Network Management Protocol}).\\
    \texttt{389} &TCP& LDAP (\textit{Lightweight Directory Access Protocol}).\\
    \texttt{443} &TCP& HTTPs (HTTP su SSL).\\
    \texttt{631} &TCP& IPP (\textit{Internet Printing Protocol}).\\
    \texttt{993} &TCP& IMAPs (IMAP su SSL).\\
    \texttt{995} &TCP& POP3s (POP3 su SSL).\\
    \hline
  \end{tabular}
  \caption{I numeri di porta dei principali servizi.}
  \label{tab:net_port_number}
\end{table}

In un sistema Unix le prime 1024 porte (di destinazione) sono dette
\index{porte!riservate} \textsl{riservate} in quanto solo l'amministratore può
mettervi in ascolto dei servizi. La corrispondenza fra queste porte ed i
servizi che ci devono essere installati è regolata a livello internazionale:
nessuno vi obbliga a rispettare la convenzione, ma se mettete la posta
elettronica sulla porta 80 e il web sulla 25 avrete certamente delle grosse
difficoltà a comunicare con gli altri, dato che in genere i browser cercano i
siti sulla porta 80, la posta viene inviata usando la porta 25.

Al di sopra della porta 1024 qualunque utente può mettere un suo servizio,
avviando un demone che si metta in ascolto sulla porta che preferisce. Alcune
di queste però sono state usate tradizionalmente da servizi molto diffusi, per
cui in certi casi si potrebbero avere dei conflitti. Come vedremo in
sez.~\ref{sec:net_name_files} c'è un elenco che associa i numeri di porta ai
servizi che li utilizzano, che viene mantenuto nel file
\texttt{/etc/services}, si sono riportati i valori associati ai servizi più
rilevanti in tab.~\ref{tab:net_port_number}.

\index{porte|)}


\section{La configurazione di base}
\label{sec:net_config}

La configurazione della rete è una materia alquanto complessa e di una vastità
impressionante; in particolare essendo numerosissimi, e spesso molto
complessi, i servizi di rete, sono altrettanto numerose e complesse le
configurazioni che si possono affrontare. In questa sezione però affronteremo
solo la configurazione di base della rete, e non dei vari servizi che possono
essere realizzati su di essa.

In particolare vedremo come effettuare le varie impostazioni relative all'uso
e alla gestione dei tre livelli più bassi del protocollo TCP/IP, che sono la
base su cui è costruito tutto il resto, ed esamineremo sia i comandi
tradizionali con i quali si effettua la configurazione manuale della
rete\footnote{i comandi \texttt{ifconfig}, \texttt{route}, \texttt{arp}
  infatti sono da anni dichiarati deprecati, in favore del comando generico
  \texttt{ip} (vedi sez.~\ref{sec:net_adv_config}) che consente sia di
  sostituirli che di effettuare le configurazioni delle funzionalità più
  avanzate del kernel; nonostante questo il loro utilizzo per le operazioni di
  base resta estremamente comune.}, che i file di configurazione usati nel
procedimento di avvio per la configurazione automatica delle interfacce.


\subsection{L'assegnazione degli indirizzi ed il comando \texttt{ifconfig}}
\label{sec:net_ifconfig}

Il primo passo per poter utilizzare la rete è quello di assegnare ad una
interfaccia di rete il suo indirizzo IP.  Il comando che consente di fare
questo è \index{comando!\texttt{ifconfig}} \texttt{ifconfig}, che permette
anche di impostare le varie caratteristiche delle interfacce di rete.  Quello
che serve nella maggior parte dei casi sono soltanto le opzioni che permettono
di attivare e disattivare una interfaccia.

Se usato senza opzioni e senza specificare una interfaccia il comando mostra
lo stato di tutte le interfacce attive. Questo è il primo passo da fare sempre
prima di qualunque configurazione per vedere lo stato del sistema, ed anche
dopo per controllare che sia tutto a posto. Un risultato possibile è il
seguente:
\begin{Console}
root@havnor:~# \textbf{ifconfig}
eth0      Link encap:Ethernet  HWaddr 00:19:99:0e:67:ae  
          inet addr:192.168.0.234  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::219:99ff:fe0e:67ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:117369393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:101518535 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2812934074 (2.6 GiB)  TX bytes:1134332202 (1.0 GiB)
          Interrupt:16 Base address:0x6000 

eth0:0    Link encap:Ethernet  HWaddr 00:19:99:0e:67:ae  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:16 

eth1      Link encap:Ethernet  HWaddr 00:90:27:2c:19:e4  
          inet addr:192.168.168.1  Bcast:192.168.168.255  Mask:255.255.255.0
          inet6 addr: fe80::290:27ff:fe2c:19e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1301606994 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2505164903 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1274648067 (1.1 GiB)  TX bytes:3870531783 (3.6 GiB)
          Interrupt:17 Memory:c0020000-c0040000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10226970 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10226970 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1385547296 (1.2 GiB)  TX bytes:1385547296 (1.2 GiB)
\end{Console}
\label{sec:net_ifconfig_out}

Se si specifica come argomento il nome di una interfaccia il comando mostra
solo lo stato dell'interfaccia specificata, se invece si vuole lo stato di
tutte le interfacce esistenti sulla propria macchina comprese quelle non
attive, che normalmente non vengono mostrate anche se presenti, occorre
specificare l'opzione \texttt{-a}.

Nell'esempio precedente si è illustrata la situazione di una macchina su cui
risultano 3 interfacce di rete. Due di esse (\texttt{eth0} e \texttt{eth1})
corrispondono a due schede di rete Ethernet, la terza (\texttt{lo}) è una
interfaccia logica, la cosiddetta interfaccia di \textit{loopback}, che viene
usata per le comunicazioni locali, e che deve essere sempre attivata anche per
i computer non connessi in rete. In questo caso tutte le interfacce fisiche
sono di tipo \textit{broadcast}, manca nell'esempio un caso, che troveremo più
avanti in sez.~\ref{sec:net_PPP}, di una interfaccia impostata per una
connessione \textsl{punto-punto}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Valore}&\textbf{Tipo indirizzo}\\
    \hline
    \hline
    \texttt{UP}          & l'interfaccia è attiva. \\
    \texttt{NOARP}       & il protocollo ARP (vedi sez.~\ref{sec:net_arp}) non
                           è attivo sull'interfaccia.\\  
    \texttt{RUNNING}     & l'interfaccia sta funzionando.  \\
    \texttt{MULTICAST}   & sull'interfaccia è attivato il \textit{multicast}.\\
    \texttt{BROADCAST}   & sull'interfaccia è attivato il \textit{broadcast}.\\
    \texttt{POINTOPOINT} & l'interfaccia è in modalità punto-punto.\\
    \texttt{LOOPBACK}    & l'interfaccia è in modalità \textit{loopback}.\\
    \texttt{MTU}         & \textit{Maximum Transfer Unit}
                           dell'interfaccia.\footnotemark \\
    \hline
  \end{tabular}
\caption{Stati riportati nella terza riga del comando \texttt{ifconfig} e
    relativo significato. }
\label{tab:net_ifconfig_states}
\end{table}

\footnotetext{la \textit{Maximum Transfer Unit} di una interfaccia di rete è la
  massima dimensione che un pacchetto può avere per poter essere trasmesso
  sulla rete su cui si affaccia la suddetta interfaccia, questa dipende dalla
  tecnologia sottostante, ed in genere per una interfaccia Ethernet vale 1500
  byte; torneremo su questo in sez.~\ref{sec:net_traceroute}.}

Si può notare come il comando riporti le varie caratteristiche delle singole
interfacce: nella prima riga viene scritto il tipo di collegamento fisico, e,
se presente per quel tipo di interfaccia, anche l'indirizzo fisico. Dalla
seconda riga viene riportato il tipo ed il valore dell'indirizzo associato
all'interfaccia, nel caso sono presenti sia un indirizzo IPv4 ordinario che
l'indirizzo IPv6 \textit{link-local} ottenuto dall'indirizzo fisico della
scheda di rete.  A questi segue una riga che indica lo stato corrente della
stessa, in cui sono elencate una serie di valori il cui elenco e relativo
significato è riportato in tab.~\ref{tab:net_ifconfig_states}. Infine sulle
righe seguenti vengono stampate una serie di altre informazioni statistiche
relative al traffico sostenuto dall'interfaccia.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
   \hline
    \textbf{Valore}&\textbf{Tipo indirizzo}\\
    \hline
    \hline
    \texttt{inet} & Indirizzo IPv4.  \\
    \texttt{inet6}& Indirizzo IPv6.  \\
    \texttt{ax25} & Indirizzo AX25.  \\
    \texttt{ddp}  & Indirizzo AppleTalk.  \\
    \texttt{ipx}  & Indirizzo Novell IPX.  \\
    \texttt{netrom}  & Indirizzo AMPR Packet radio.  \\
    \hline
  \end{tabular}
\caption{Valori del parametro opzionale per indicare il tipo di indirizzo con
  \texttt{ifconfig}.} 
\label{tab:net_ifconfig_aftype}
\end{table}

% TODO mettere esempio di uso con IPv6, se funzionasse...

A parte il caso in cui si legge la configurazione generica, il comando
richiede sempre come primo argomento il nome dell'interfaccia su cui operare;
quando si intende impostare un indirizzo sulla stessa è possibile specificarne
il tipo con un argomento opzionale da specificare prima del relativo valore.
I valori possibili per questo argomento sono riportati in
tab.~\ref{tab:net_ifconfig_aftype} ed il valore di default, sottinteso quando
non si specifica nulla, è \texttt{inet}, che indica il protocollo IPv4.

Normalmente questo argomento non viene mai specificato in quanto il caso più
comune di utilizzo del comando \texttt{ifconfig} è appunto quello
dell'impostazione di un indirizzo IP. Da qui in avanti inoltre, se non
specificato altrimenti, intenderemo sempre IPv4 tutte le volte che si parlerà
di IP in maniera generica.

Il risultato del comando riportato a pag.~\pageref{sec:net_ifconfig_out} ci
mostra anche che l'interfaccia \texttt{eth0} è \textit{multihomed}; su di essa
cioè sono presenti due indirizzi diversi, riportati nelle due sezioni separate
introdotte dalle stringhe \texttt{eth0} ed \texttt{eth0:0}. Con
\texttt{ifconfig} l'assegnazione di ulteriori indirizzi su una qualunque
interfaccia di rete (il cosiddetto \itindex{IP~aliasing} \textit{IP aliasing})
si deve fare utilizzando delle interfacce ``\textsl{virtuali}'' nella forma
\texttt{eth0:\textsl{N}} dove \texttt{\textsl{N}} è un numero
intero.\footnote{si tenga presente che con l'uso del nuovo comando \texttt{ip
    address} è possibile assegnare indirizzi multipli alla stessa interfaccia
  senza dover specificare una interfaccia virtuale nella forma appena vista;
  in tal caso però non se ne troverà traccia nell'output di
  \texttt{ifconfig}.} Si noti comunque come le statistiche siano riportate
solo per la prima istanza, in quanto esse non possono che essere uniche per
ciascuna interfaccia.

Prima di configurare una interfaccia è opportuno verificare che essa non sia
già attiva, perché quando si assegna un indirizzo IP un valore precedente sarà
sovrascritto.  Il comando \texttt{ifconfig \textsl{iface}} (dove
\texttt{\textsl{iface}} è il nome della singola interfaccia che si vuole
controllare, ad esempio \texttt{eth0}) ci mostrerà lo stato dell'interfaccia,
dando un errore nel caso il supporto nel kernel non sia attivato o
l'interfaccia non esista. Qualora invece si voglia disattivare una interfaccia
attiva si potrà usare il comando:
\begin{Example}
ifconfig eth0 down
\end{Example}
specificando l'opzione \texttt{down}, mentre per riattivarla, mantenendo le
impostazioni che c'erano in precedenza, si potrà utilizzare il comando:
\begin{Example}
ifconfig eth0 up
\end{Example}

Quando invece si deve assegnare un indirizzo la sintassi dipende dal tipo di
collegamento, nell'esempio precedente abbiamo tutte interfacce relative a reti
di tipo \textit{broadcast} che si affacciano su una rete locale ed in questo
caso si potrà assegnare un indirizzo ad una interfaccia ed allo stesso tempo
attivarla con il comando:
\begin{Example}
ifconfig eth0 192.168.1.100 
\end{Example}
in cui è sottintesa l'opzione \texttt{up} poiché si dà per scontato che
assegnare un indirizzo IP ad una interfaccia implichi anche la volontà di
utilizzarla.

Si ricordi però che in questo caso ad ogni indirizzo IP è sempre associata una
rete IP, che nel comando precedente sembra non comparire. Questo è dovuto al
fatto che, se non viene specificato esplicitamente, il comando
\texttt{ifconfig} assegna automaticamente all'interfaccia la maschera di rete
corrispondente alla classe a cui appartiene l'indirizzo IP, secondo la
suddivisione tradizionale di tab.~\ref{tab:IPv4_class}, che nel caso sarebbe
pari a \texttt{255.255.255.0}, dato che l'indirizzo è di classe C.

Quando questa scelta non è corretta si può specificare la rete su cui si
affaccia l'interfaccia, indicando esplicitamente la maschera di rete da
utilizzare con un comando del tipo:
\begin{Example}
ifconfig eth0 192.168.1.100 netmask 255.255.0.0
\end{Example}

Gli esempi precedenti fanno tutti riferimento al caso più comune, quello di
una interfaccia per una rete di tipo \textit{broadcast} che viene usata per
mettere in comunicazione più macchine su una rete locale. Ma come accennato
esistono anche modalità di comunicazione diverse, ed in particolare la
sintassi è diversa in caso di collegamenti punto-punto, in cui non esiste una
rete locale e due macchine si parlano direttamente, e ciascuna macchina deve
essere configurata per dire alla relativa interfaccia quali sono gli IP
utilizzati ai due estremi del collegamento.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Direttiva}&\textbf{Significato}\\
    \hline
    \hline
    \texttt{\textsl{[-]}arp}& attiva e disattiva (apponendo o no il
                         \texttt{-}) l'uso del protocollo ARP (vedi
                         sez.~\ref{sec:net_arp}) per l'interfaccia. Il default
                         è \texttt{arp}.\\ 
    % \texttt{media \textsl{type}}& seleziona il tipo di collegamento (in genere
    %                      il cavo), tramite il parametro \texttt{\textsl{type}}
    %                      (che può assumere ad esempio valori come
    %                      \texttt{10base2}, \texttt{10baseT}, ecc.); di solito
    %                      viene impostato automaticamente usando il default che
    %                      è \texttt{auto}.\\
    \texttt{multicast}&  abilita il \textit{multicast}
                         sull'interfaccia, normalmente viene selezionato
                         automaticamente quando si attiva l'interfaccia.\\ 
    \texttt{\textsl{[-]}promisc}& attiva e disattiva (apponendo o no il
                         \texttt{-}) la cosiddetta ``\textsl{modalità
                           promiscua}''\footnotemark\index{modo~promiscuo}  
                         per l'interfaccia.\\
    \texttt{netmask \textsl{mask}}& imposta la maschera di rete che deve 
                         essere specificata in notazione \textit{dotted
                           decimal} come illustrato in
                         sez.~\ref{sec:net_ip_addr}.\\
    \texttt{broadcast \textsl{addr}}& imposta l'indirizzo di
                         \textit{broadcast} che deve essere specificato in
                          notazione \textit{dotted decimal}.\\ 
    \texttt{up}&         attiva l'interfaccia.\\
    \texttt{down}&       disattiva l'interfaccia.\\
    \texttt{pointopoint \textsl{addr}}&  imposta l'interfaccia in modalità
                         \textsl{punto-punto} impostando al contempo
                         l'indirizzo assegnato all'altro estremo.\\
    \texttt{hw \textsl{class addr}}& imposta il 
                         \textit{MAC address} associato all'interfaccia, il
                         parametro \texttt{\textsl{class}} indica il tipo di
                         interfaccia, e normalmente è \texttt{ether}.\\
    \hline
  \end{tabular}
  \caption{Principali direttive del comando \texttt{ifconfig}.}
\label{tab:net_ifconfig_options}
\end{table}

\footnotetext{si chiama così una modalità di funzionamento di una interfaccia
  di rete su una rete \textit{broadcast} per cui essa riceve tutti i pacchetti
  che vede passare e non soltanto quelli diretti agli indirizzi ad essa
  assegnati.}


In questo caso non si potrà utilizzare la direttiva \texttt{netmask}, non
essendoci una rete locale, mentre occorrerà specificare l'indirizzo dell'altro
capo della connessione. Per questo occorre usare la direttiva
\texttt{pointopoint}, e se ad esempio si vuole realizzare un collegamento fra
due PC con un cavo seriale, si dovrà utilizzare un comando analogo al
seguente:
\begin{Example}
ifconfig slip0 192.168.0.1 pointopoint 192.168.0.2
\end{Example}
ed ovviamente si dovrà usare un comando analogo, con gli indirizzi invertiti,
sulla seconda macchina.

In quest'ultimo caso l'uso esplicito di \texttt{ifconfig} è però molto meno
diffuso, in quanto la configurazione di una interfaccia \textsl{punto-punto}
nella maggioranza dei casi è associato all'uso delle le connessioni via modem,
e queste normalmente vengono gestite direttamente ad un livello più alto
attraverso l'uso di appositi programmi, come vedremo in
sez.~\ref{sec:net_PPP}.

Gli esempi precedenti ci mostrano anche la sintassi generica dell'invocazione
del comando \texttt{ifconfig}. Esso prevede nella forma più comune la
specificazione nei primi due argomenti dell'interfaccia di rete e di un
indirizzo, mentre negli argomenti successivi possono essere indicati una serie
di ulteriori direttive e relativi parametri che consentono di impostare le
varie caratteristiche dell'interfaccia. Queste ultime possono essere anche
modificate in un secondo tempo, nel qual caso sarà sufficiente utilizzare come
primo argomento il nome dell'interfaccia, seguito dalle relative direttive di
controllo.


In tab.~\ref{tab:net_ifconfig_options} si sono elencate le principali
direttive di configurazione disponibili per \texttt{ifconfig}, con il formato
e la presenza di un eventuale parametro. Si tenga presente che non tutte le
direttive possono essere applicabili a qualunque tipo di interfaccia, occorre
infatti che la funzionalità sottostante sia disponibile.  Per un elenco
completo di tutte le direttive, che normalmente vengono lasciate al valore di
default, si rimanda comunque alla lettura della pagina di manuale, accessibile
al solito con \texttt{man ifconfig}.


\itindbeg{routing}

\subsection{L'impostazione dell'instradamento ed il comando \texttt{route}}
\label{sec:net_route}

Avere attivato una interfaccia di rete ed averle assegnato un indirizzo IP è
solo il primo passo; perché sia possibile utilizzare la rete occorre anche
impostare \textsl{l'instradamento} dei pacchetti. Per questo si usa il comando
\index{comando!\texttt{route}} \texttt{route}, che si chiama così proprio
perché serve a specificare le strade che essi possono prendere per arrivare a
destinazione.

\index{tabella~di~instradamento|(}

Il comando permette di manipolare la \textsl{tabella di instradamento} (o
\textit{routing table}) del protocollo IP. Questa è una tabella usata e
mantenuta dal kernel per decidere come smistare i pacchetti in uscita e in
transito. In sostanza la tabella contiene le associazioni fra le possibili
destinazioni di un pacchetto e l'interfaccia di rete che deve essere usata
perché questo possa raggiungerle, e per questo le voci che ne fanno parte
usualmente vengono chiamate ``\textsl{rotte}''.

In generale le rotte impostate esplicitamente con \texttt{route} vengono dette
\textsl{rotte statiche}, in quanto una volta impostate non vengono più
cambiate, in contrapposizione alle \textsl{rotte dinamiche} che vengono
impostate dai cosiddetti \textsl{demoni di routing},\footnote{abbiamo
  accennato in sez.~\ref{sec:net_protocols} alla presenza di protocolli usati
  dai \textit{router} per scambio delle informazioni, i \textsl{demoni di
    routing} sono programmi che implementano questi protocolli e aggiornano
  automaticamente la tabella di instradamento con le informazioni ottenute.}
che modificano continuamente le rotte presenti nella tabella di instradamento
per tenere conto delle condizioni della rete.

In realtà se è disponibile una sola interfaccia, e non si esce dalla rete
locale, non c'è bisogno di eseguire esplicitamente \texttt{route}. Infatti
tutte le volte che si assegna un indirizzo ad una interfaccia, la rotta per la
rete a cui detto indirizzo è associato (detta anche \textsl{rotta diretta})
viene creata automaticamente. La cosa vale anche in caso di collegamento
\textsl{punto-punto}, solo che in tal caso viene inserita una rotta per la
singola macchina che si trova all'altro capo della connessione, usando l'IP
specificato come parametro per la direttiva \texttt{pointopoint} di
\texttt{ifconfig}. Il problema si pone quando la struttura della rete è più
complicata, e non c'è solo la rete locale o collegamenti diretti.


\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
%    \texttt{-C}& opera sulla cache di instradamento del kernel.  \\
%    \texttt{-F}& opera direttamente sulla tabella di instradamento
%                 \index{tabella~di~instradamento} (il default).\\
    \texttt{-A}& usa gli indirizzi della famiglia passata come parametro; il
                 default è \texttt{inet} per gli indirizzi IP, ma si possono
                 usare gli stessi valori usati da \texttt{ifconfig} riportati
                 in tab.~\ref{tab:net_ifconfig_aftype}.\\
    \texttt{-e}& usa il formato di \texttt{netstat} (vedi
                 sez.~\ref{sec:net_netstat}), ripetuto due volte stampa più
                 informazioni.\\
    \texttt{-n}& non effettua la risoluzione degli indirizzi.\\
    \texttt{-v}& esegue le operazioni in maniera \textsl{prolissa}.\\
    \hline
  \end{tabular}
\caption{Principali opzioni a riga di comando per l'uso di \texttt{route}.}
\label{tab:net_route_option}
\end{table}

Il comando \texttt{route} prende come primo argomento due direttive che ne
specificano le operazioni: \texttt{add}, che permette di aggiungere una voce
alla tabella, e \texttt{del} che ne permette la cancellazione. Se non si
specifica nessuna di queste due direttive il comando viene usato soltanto per
mostrare lo stato corrente della tabella e non si possono utilizzare nessuna
delle ulteriori direttive. Le principali opzioni riconosciute dal comando sono
riportate in tab.~\ref{tab:net_route_option}.

In generale la direttiva \texttt{add} prevede sempre una fra le due opzioni
\texttt{-net}, per indicare che si intende aggiungere una voce riferita ad una
rete, e \texttt{-host} per indicare la destinazione verso una singola
stazione. A queste deve seguire l'indirizzo, di rete o di nodo, della
destinazione, espresso in forma o numerica (usualmente in notazione
\textit{dotted decimal}) o simbolica.\footnote{quest'ultima però richiede che
  sia disponibile una \textsl{risoluzione} dello stesso (tratteremo
  l'argomento in sez.~\ref{sec:net_name_resolution}) cosa che non sempre è
  possibile, pertanto è preferibile usare sempre la forma numerica.}

Nel caso si sia indicata una rete si deve inoltre specificare sempre anche la
relativa \textit{netmask} indicandola (in notazione \textit{dotted decimal})
come parametro per la ulteriore direttiva \texttt{netmask}.  Se per
raggiungere la rete è necessario passare da un \textit{gateway} (nella nostra
analogia il centralino per quella destinazione), questo deve essere indicato
come argomento per l'ulteriore direttiva \texttt{gw}. In genere questo è
sempre necessario per impostare il cosiddetto \textit{default gateway}, cioè
il \textit{gateway} che si usa per uscire verso tutta Internet. Inoltre si può
indicare esplicitamente anche l'interfaccia di rete da utilizzare con la
direttiva \texttt{dev}, seguita dal nome dell'interfaccia.

Le rotte nella tabella di instradamento sono automaticamente ordinate per
dimensione della rete di destinazione, a partire da quella più specifica per
arrivare alla più generica ed il kernel invia un pacchetto in uscita sulla
prima rotta che comprende nella sua destinazione l'indirizzo IP a cui esso è
destinato. Questo vuol dire che la rotta associata al \textit{default
  gateway}, che per definizione ha come destinazione tutta Internet, essendo
la più vasta possibile, quando presente viene sempre utilizzata per ultima.

\index{tabella~di~instradamento|)}

Le altre principali direttive del comando \texttt{route} sono riportate in
tab.~\ref{tab:net_route_directives}; in genere queste sono opzionali e vengono
impostate automaticamente agli opportuni valori predefiniti corrispondenti
all'interfaccia cui la rotta fa riferimento, oppure sono appannaggio dei
demoni di \textit{routing} ed inutilizzate per le rotte statiche.  Fa
eccezione la direttiva \texttt{reject} che viene utilizzata per impostare una
cosiddetta \textit{blocking route}, cioè una rotta che fa sì che il tentativo
di inviare i dati su quella rete fallisca con un errore di instradamento. In
genere la si usa per bloccare l'accesso dei pacchetti a certe reti prima di
arrivare alla \textit{default route}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Direttiva}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{netmask \textsl{n.n.n.n}}& imposta la maschera di rete.\\
    \texttt{gw \textsl{n.n.n.n}}     & imposta l'indirizzo di un 
                                       \textit{gateway}. \\ 
    \texttt{reject}                  & installa una rotta bloccata.\\
    \texttt{metric \textsl{N}}       & imposta il valore del campo
                                       \texttt{Metric}.\\
    \texttt{mss \textsl{N}}          & imposta la \textit{Maximum Segment
                                         Size} per i pacchetti TCP che usano la
                                       rotta (in byte).\\ 
    \texttt{window \textsl{N}}       & imposta la dimensione della
                                       \textit{advertising window} del TCP per
                                       la rotta (in byte).\\ 
    \texttt{irtt \textsl{T}}         & imposta il \textit{Round Trip Time}
                                       iniziale per la rotta (in
                                       millisecondi).\\ 
    \texttt{mod,dyn,reinstate}       & flag diagnostici usati dai demoni di 
                                       \textit{routing}.\\
    \texttt{dev \textsl{iface}}      & imposta l'interfaccia usata per
                                       raggiungere la destinazione.\\
    \hline
  \end{tabular}
  \caption{Direttive del comando \texttt{route}.}
  \label{tab:net_route_directives}
\end{table}

Le opzioni di base \texttt{-net} e \texttt{-host} valgono anche per la
direttiva di cancellazione \texttt{del}, la differenza è che mentre con
\texttt{add} devono essere specificate interamente le caratteristiche della
rotta che si vuole aggiungere, per cancellarne una già presente basta
identificare univocamente la voce relativa perché il comando abbia effetto.

Il concetto fondamentale del \textit{routing} è che ciascun nodo sulla rete
quando deve inviare un pacchetto deve sapere se questo può raggiungere
direttamente la destinazione, come avviene nel caso di una rotta diretta
relativa alla propria rete locale o a macchine per cui si ha un collegamento
fisico, o se invece per inviare il pacchetto verso quella destinazione è
necessario rivolgersi ad un nodo limitrofo (il \textit{gateway}) che sia in
grado di mandarlo a destinazione.

In sostanza per ciascun pacchetto che una macchina deve smistare deve essere
disponibile la ``segnaletica stradale'' che indichi da quale parte svoltare
per arrivare a destinazione. In realtà quando si ha a che fare con una rete
locale le cose sono molto più semplici, e, tornando all'analogia telefonica,
tutto quello che serve è sapere qual'è il numero del centralino per uscire (il
\textit{gateway}) e quali sono i numeri interni.

\begin{figure}[htb]
  \centering \includegraphics[width=11cm]{images/schema_rete}
  \caption{Schema di una rete di prova.}
  \label{fig:net_schema_rete}
\end{figure}

Per chiarire meglio questi concetti supponiamo di avere la rete schematizzata
in fig.~\ref{fig:net_schema_rete}, che prenderemo come riferimento per i
prossimi esempi, e vediamo come deve essere configurato l'instradamento per le
varie macchine di cui la rete è composta. In questo caso si vede che un ruolo
particolare è rivestito dalla macchina \texttt{havnor}, che ha due interfacce
ed è posta a cavallo fra due reti diverse. Nel nostro esempio essa dovrà fare
da ponte fra le due reti,\footnote{tecnicamente si parla di un \textit{bridge}
  quando si ha a che fare con un apparato che fa da \textsl{ponte} fra due
  sotto-reti fisiche passando i pacchetti dall'una all'altra a livello di
  \textit{datalink} (in genere sui protocolli della famiglia IEEE 802.x), in
  maniera completamente trasparente ai livelli superiori; Linux può essere
  utilizzato anche in questo modo, abilitando l'opportuno supporto nel kernel,
  qui però stiamo parlando semplicemente del passaggio di un pacchetto da una
  interfaccia ad un'altra a livello di rete, che invece è il lavoro svolto dai
  \textit{router}.} passando i pacchetti da una interfaccia ad un'altra, e
svolgerà quindi un ruolo di \textit{gateway}.

Perché una macchina possa passare pacchetti di rete da una interfaccia ad
un'altra deve però essere attivato nel kernel il cosiddetto \textit{IP
  forwarding}, che di default è disabilitato. Questo si può fare attraverso
l'interfaccia del \textit{sysctl} (trattata in sez.~\ref{sec:sysctl_conf}), o
usando direttamente i file con cui questa viene rappresentata nel filesystem
\texttt{/proc}. Nel caso specifico per abilitare l'\textit{IP forwarding}
basterà eseguire il comando:
\begin{Example}
echo 1 > /proc/sys/net/ipv4/ip_forward
\end{Example}
\index{filesystem~\texttt{/proc}!\texttt{/proc/sys/net/ipv4/ip\_forward}}

Una volta fatto questo potremo passare a configurare le rotte della rete in
fig.~\ref{fig:net_schema_rete} usando \texttt{route}. Il primo passo è sempre
quello di controllare la situazione corrente. Quando è invocato senza
parametri il comando mostra il contenuto corrente della \textsl{tabella di
  instradamento}. Ad esempio, nel caso illustrato in
fig.~\ref{fig:net_schema_rete}, andando su \texttt{havnor}
avremo:\label{sec:net_route_example}
\begin{Console}
root@havnor:~# \textbf{route -n}
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
\end{Console}
dove si è usata l'opzione \texttt{-n} per avere una stampa con i valori
numerici per gli indirizzi, con l'uscita del comando che mostra le voci
presenti nella tabella di instradamento. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Nome}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{Destination}&  rete o nodo di destinazione.\\
    \texttt{Gateway}    &  indirizzo del \textit{gateway} (\texttt{0.0.0.0} 
                           se non impostato).\\
    \texttt{Genmask}    &  \textit{netmask} della rete di destinazione \\
    \texttt{Flags}      &  flag associati alla rotta (vedi 
                           tab.~\ref{tab:net_route_flags}).\\
    \texttt{Metric}     &  metrica della rotta (distanza dalla destinazione in
                           numero di salti).\\
    \texttt{Ref}        &  numero di riferimenti nella tabella di
                           instradamento (non usato nel kernel).\\
    \texttt{Use}        &  numero di verifiche sulla rotta.\\
    \texttt{Iface}      &  interfaccia verso cui sono inviati i pacchetti.\\
    \texttt{MSS}        &  valore di default per l'MSS (la \textit{Maximum
                             Segment Size}) delle connessioni TCP su questa
                           rotta.\\ 
    \texttt{Window}     &  default per la \textit{window size} delle
                           connessioni TCP su questa rotta. \\
    \texttt{irtt}       &  valore iniziale dell'RTT (\textit{Round Trip Time})
                           per il protocollo TCP.\\
    % \texttt{HH}         &  numero di voci ARP e rotte in cache che fanno
    %                        riferimento allo stessa intestazione hardware.\\
    % \texttt{Arp}        &  flag che indica se l'indirizzo hardware per la
    %                        rotta in cache è aggiornato. \\
    \hline
  \end{tabular}
\caption{Nomi della colonna e relativo significato per le varie informazioni
    riportate nell'uscita del comando \texttt{route}. }
\label{tab:net_route_infos}
\end{table}

Se non specificato altrimenti il comando tenta anche di risolvere (vedi
sez.~\ref{sec:net_name_resolution}) i nomi delle macchine e delle reti.
L'output usa la formattazione appena mostrata in cui la prima colonna
identifica la destinazione, la seconda il \textit{gateway}, la terza la
sottorete coperta dalla destinazione, la quarta lo stato della rotta e
l'ultima l'interfaccia usata per l'invio dei pacchetti. Il significato delle
altre colonne è associato agli aspetti più sofisticati del \textit{routing},
quelli gestiti dai \textit{routing daemon}. Uno specchietto delle principali
informazioni mostrate dal comando è in tab.~\ref{tab:net_route_infos},
maggiori dettagli sono nella pagina di manuale.

Nell'esempio mostrato in precedenza si può notare come ci siano tre diverse
destinazioni associate a tre diverse sotto-reti, due delle quali fanno capo
alla stessa interfaccia (quella che in sez.~\ref{sec:net_ifconfig} abbiamo
visto essere \textit{multihomed}). Per tutte queste sotto-reti, che sono
accessibili direttamente da una interfaccia locale, non esiste un
\textit{gateway} e questo è indicato dall'uso dell'indirizzo generico in
seconda colonna.

L'ultima riga indica la \textsl{rotta di default} e presenta il
\textit{default gateway} con l'indicazione dell'indirizzo della macchina (che
come accennato deve essere raggiungibile con le rotte precedenti) a cui devono
essere inviati i pacchetti che devono uscire su Internet. Come abbiamo già
accennato in sez.~\ref{sec:net_ip_addr} l'indirizzo di rete nullo con
\textit{netmask} nulla corrisponde ad una rete in cui tutti e 32 i bit
disponibili sono utilizzati come indirizzi delle macchine al suo interno, e
quindi questa rotta indica appunto tutta Internet.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Simbolo}&\textbf{Significato}\\
    \hline
    \hline
    \texttt{U} & la rotta è attiva.  \\
    \texttt{H} & la destinazione è una macchina singola. \\
    \texttt{G} & usa un \textit{gateway}. \\
    \texttt{R} & rotta reintegrata da un instradamento dinamico.\\
    \texttt{D} & installata dinamicamente da un demone o da una redirezione. \\
    \texttt{M} & modificata da un demone o una redirezione.\\
    \texttt{A} & installata da \texttt{addrconf}.\\
    \texttt{C} & voce nella cache.\\
    \texttt{!} & rotta bloccata (impedisce l'instradamento per la destinazione
                 specificata).\\
    \hline
  \end{tabular}
\caption{Significato dei simboli utilizzati nella colonna \texttt{Flags} del
    comando \texttt{route}. }
\label{tab:net_route_flags}
\end{table}

Per tutti gli altri computer nella rete, che hanno una sola interfaccia di
rete, una volta assegnato l'indirizzo con \texttt{ifconfig}, tutto quello che
resta da fare è solo specificare qual'è l'indirizzo del \textit{default
  gateway} che si usa per uscire su Internet (di solito quello del
\textit{router} fornito dal provider). Nel caso della rete di esempio
illustrata in fig.~\ref{fig:net_schema_rete} questo si può fare con il
comando:
\begin{Example}
route add default gw 192.168.0.1
\end{Example}
che ovviamente deve essere eseguito dall'amministratore, in quanto cambiare i
contenuti della tabella di instradamento è una operazione privilegiata.

Il comando dovrà essere ripetuto per tutte le macchine mostrate nel tratto di
rete di sinistra in fig.~\ref{fig:net_schema_rete}, ma vedremo in
sez.~\ref{sec:net_DHCP} come queste impostazioni possono essere automatizzate
usando il servizio DHCP. L'effetto di questo comando è quello di creare su
ciascuna di esse una \textsl{rotta di default}, identica a quella riportata
nell'ultima riga dell'esempio di tabella di instradamento di
pag.~\pageref{sec:net_route_example}, perché \texttt{default} non è altro che
l'abbreviazione di ``\texttt{-net 0.0.0.0 netmask 0.0.0.0}''.

Le macchine sulla rete \texttt{192.168.168.0} però hanno il problema di non
poter vedere direttamente il \textit{router}, dato che questo è posto sulla
rete \texttt{192.168.0.0}. Inoltre esse non possono neanche essere raggiunte
delle macchine di quella rete, che non hanno un accesso diretto alla rete
\texttt{192.168.168.0}. In questo caso infatti i pacchetti, per poter passare
da una rete all'altra, devono attraversare \texttt{havnor}, che, con le sue
due interfacce di rete, fa da \textit{router} fra i due tratti.

Come in tutti i casi in cui l'accesso ad una certa rete è condizionato al
passaggio da una macchina specifica che fa da \textit{router}, si deve allora
specificare una rotta statica che indichi anche quest'ultima come
\textit{gateway} per quella rete. Così se da \texttt{lorbaner} si vuole
accedere a \texttt{gont}, vi si dovrà impostare una rotta statica con:
\begin{Console}
root@lorbaner:~# \textbf{route add -net 192.168.168.0 netmask 255.255.255.0 gw 192.168.0.234}
\end{Console}
che dice che per i pacchetti destinati alla rete \texttt{192.168.168.0} si
deve usare come \textit{gateway} la macchina \texttt{192.168.0.234}. In questo
modo, essendo la rotta per la rete \texttt{192.168.168.0} più specifica di
quella di default questi, invece che a \texttt{roke}, verrebbero inviati ad
\texttt{havnor}, che può reinviarli a destinazione avendo una interfaccia su
quella rete.

Questo però non è detto sia sufficiente, perché consente solo ai pacchetti che
partono da \texttt{lorbaner} di raggiungere \texttt{gont}, ma per poter
realizzare un collegamento effettivo fra le due macchine devono anche poter
tornare indietro le risposte.  Si deve allora anche dire a \texttt{gont} come
fare a raggiungere la rete \texttt{192.168.0.0} sui cui lui non ha accesso
diretto.  Per far questo si potrebbe pensare di impostare anche in questo caso
una rotta statica per questa rete con un comando analogo al precedente come:
\begin{Console}
root@gont:~# \textbf{route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.168.1}
\end{Console}

Questo sarebbe certamente sufficiente ad ottenere il risultato di garantire la
comunicazione fra \texttt{lorbaner} e \texttt{gont}, ma resta aperto il
problema di come impostare il \textit{default gateway} di \texttt{gont}. Se
infatti tentasse di usare direttamente l'indirizzo di \texttt{roke}
(\texttt{192.168.0.1}) non essendo questo raggiungibile direttamente, si
avrebbe un errore, anche se adesso è presente una rotta per quella rete.

Si può però utilizzare di nuovo \texttt{havnor} che ha, come risulta nella
tabella di instradamento illustrata nell'esempio di
pag.~\pageref{sec:net_route_example}, anche una rotta per raggiungere
Internet, e che è raggiungibile direttamente, impostando la rotta di default
con il comando:
\begin{Console}
root@gont:~# \textbf{route add default gw 192.168.168.1}
\end{Console}
e questo risolverebbe il problema in quanto stavolta \texttt{havnor}
riceverebbe i pacchetti indirizzati verso Internet e li invierebbe lui a
\texttt{roke}.\footnote{di nuovo perché poi le risposte possano tornare
  indietro occorre anche che \texttt{roke} possa raggiungere la rete
  \texttt{192.168.168.0}, cosa che si fa inserendo anche su di esso una rotta
  statica come fatto per \texttt{lorbaner}. }

Ma a questo punto il precedente comando risulta inutile, in quanto la rete
\texttt{192.168.0.0} è senz'altro compresa nella rotta di default, ed il
\textit{gateway} è lo stesso. Pertanto basterebbe quest'ultimo comando per
assicurare il collegamento sia verso le macchine della rete
\texttt{192.168.0.0} che verso Internet.  La differenza starebbe nel fatto che
nel primo caso \texttt{havnor} potrebbe inviare il pacchetto direttamente a
destinazione mentre nel secondo dovrebbe passare da \texttt{roke}, ma questo,
per quanto concerne la configurazione di \texttt{gont}, è del tutto
irrilevante.


\itindend{routing}


\subsection{La configurazione della rete all'avvio del sistema}
\label{sec:net_address_config}

Nelle sezioni precedenti abbiamo esaminato i comandi che consentono di
eseguire manualmente la configurazione della rete su una macchina Linux, nelle
operazioni ordinarie essi però non vengono usati direttamente quasi mai, in
quanto la configurazione viene effettuata quasi sempre in maniera automatica.
In realtà i casi più comuni che si presentano sono sostanzialmente due:
\begin{itemize}
\item Un collegamento diretto ad Internet con una connessione attraverso un
  modem analogico, ISDN o ADSL connesso alla macchina stessa.\footnote{si
    tenga presente che si sta parlando di \textsl{modem}, anche nel caso di
    ADSL, nel caso si abbia invece un \textsl{router} ADSL, come avviene ormai
    sempre più spesso, si ricade nel caso successivo.} In questo caso il
  collegamento può anche non essere permanente, nel qual caso lo si potrà o
  dovrà attivare a richiesta con un opportuno programma.
\item Un collegamento all'interno di una rete locale, usualmente effettuato
  tramite una scheda di rete Ethernet. In questo caso il collegamento, almeno
  quello alla rete locale, è permanente, e viene generalmente attivato dagli
  script di avvio.
\end{itemize}

In entrambi i casi sono comunque richiesti alcuni dati necessari a configurare
la rete. Nel primo caso questi devono essere stati forniti dal provider; ad
esempio nel caso di un modem analogico serve il numero telefonico da
contattare, ed in genere è anche prevista una qualche modalità di
autenticazione che richiede username e password del proprio account. A questi
dati si possono eventualmente aggiungere quelli relativi alla inizializzazione
del modem utilizzato, anche se ormai tutte le distribuzioni sono in grado di
eseguire un riconoscimento automatico nella maggior parte dei casi.

In questo caso non è necessario preoccuparsi di conoscere in anticipo
l'indirizzo IP assegnato alla propria macchina in quanto sarà il programma di
connessione, in genere utilizzando il comando \texttt{pppd} che tratteremo in
sez.~\ref{sec:net_pppd}, ad utilizzare le informazioni che gli vengono fornite
dal provider per eseguire la configurazione della rete. Al più ci potrà essere
da configurare a mano, per quei pochi provider che non forniscono
l'informazione, gli indirizzi dei DNS (torneremo su questo in
sez.~\ref{sec:net_resolv}).

Nel secondo caso invece sono necessarie le informazioni relative alla rete
all'interno di cui ci si trova, che potrebbe anche essere semplicemente quella
fornita dall'interfaccia Ethernet del proprio \textit{router} ADSL, ed in
particolare l'indirizzo IP da assegnare alla macchina, la \textit{netmask}, e
l'indirizzo del \textit{gateway}. In realtà se sulla rete è disponibile un
server DHCP (torneremo sull'argomento in sez.~\ref{sec:net_DHCP}) l'indirizzo
non dovrà essere specificato a mano, ma potrà essere impostato automaticamente
grazie ad esso.  Tutti i programmi di configurazione prevedono questa
possibilità, nel qual caso non è necessario fornire nessuna informazione
specifica, se non quella di usare il DHCP.

Si tenga presente inoltre che nel caso si debba creare una propria rete
locale, di cui poi si sarà gli amministratori, si dovrà anche effettuare la
scelta degli indirizzi che si vogliono utilizzare al suo interno prima di
assegnarli alle varie macchine. In questo caso è sempre opportuno usare una
delle reti appartenenti alle classi riservate elencate in
tab.~\ref{tab:net_ipv4_reserved}, che la IANA ha destinato appositamente a
questo scopo, e che non vengono mai assegnati a macchine pubbliche su
Internet.

Questa è una regola da seguire sempre anche per una rete di cui non è previsto
alcun accesso ad Internet, per la quale in teoria si potrebbe pensare di usare
indirizzi qualunque. Usare degli indirizzi pubblici per una rete privata è
comunque sbagliato perché la volta che si dovesse fare accedere ad Internet
una delle macchine di questa rete, gli indirizzi pubblici presenti su Internet
corrispondenti alla propria rete privata non sarebbero mai raggiungibili.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|c|l|l|}
    \hline
    \textbf{Distribuzione}& \textbf{Script di avvio} & \textbf{Altre
      distribuzioni}\\ 
    \hline
    \hline
    Debian & \texttt{/etc/init.d/networking} & Ubuntu, Mint \\
    RedHat & \texttt{/etc/init.d/network}    & SuSE, Scientific Linux\\
    \hline
  \end{tabular}
\caption{Gli script di inizializzazione della rete per varie distribuzioni.}
\label{tab:net_init_scripts}
\end{table}

A parte il caso di connessioni non permanenti da attivare a richiesta, in
generale la rete viene configurata nelle fasi iniziali della procedura di
avvio del sistema tramite gli opportuni script (vedi
sez.~\ref{sec:struct_sysv_init}) in modo da garantirne l'accesso al successivo
avvio dei servizi che la usano.\footnote{questo non è sempre vero nel caso di
  sistemi desktop in cui in genere la configurazione viene eseguita al
  rilevamento di una possibile connessione da opportuni programmi di gestione
  integrati nell'ambiente desktop stesso; non tratteremo qui questa casistica
  che dipende dal programma utilizzato per eseguire questo compito.} Ogni
distribuzione utilizza una sua versione di questi script ed in
tab.~\ref{tab:net_init_scripts} si sono riportati quelli usati dalle
distribuzioni più diffuse.

A loro volta gli script leggono da opportuni file di configurazione tutte le
informazioni necessarie, come le interfacce da configurare, gli IP ad esse
assegnati e le \textit{netmask} delle relative reti, l'indirizzo del
\textit{default gateway}, la presenza di eventuali ulteriori rotte statiche,
ecc. Pertanto per modificare in maniera permanente le impostazioni della rete
si devono modificare i file in cui sono memorizzate le informazioni usate
dagli script di avvio. Eventuali modifiche provvisorie si possono sempre
effettuare con i singoli comandi illustrati nelle sezioni precedenti, ma
ovviamente al successivo riavvio tutti i cambiamenti saranno perduti.

Anche i file di configurazione della rete variano da distribuzione a
distribuzione, così come può essere diverso il loro formato. Prenderemo in
esame due dei casi più comuni, Debian e RedHat le cui scelte, così come per
gli script di avvio, sono riprese anche da altre distribuzioni, sempre secondo
lo schema di tab.~\ref{tab:net_init_scripts}. In genere i programmi di
configurazione automatica (o i vari programmi grafici per la configurazione)
non fanno altro che leggere e modificare i valori che stanno su questi file
con una qualche interfaccia semplificata. Dato che si tratta come sempre di
file di testo, è comunque sufficiente saper usare un editor qualunque.

\begin{basedescript}{\desclabelwidth{1.7cm}}
\item[Debian] Il file di configurazione delle interfacce è
  \index{configurazione!\texttt{/etc/network/interfaces}}
  \texttt{/etc/network/interfaces}, il cui formato è descritto in dettaglio
  dalla omonima pagina di manuale accessibile con \texttt{man interfaces}. Il
  file consente di controllare con grande flessibilità la configurazione delle
  interfacce, ed è in genere suddiviso in sezioni introdotte da opportune
  parole chiave, le principali delle quali sono riportate in
  tab.~\ref{tab:net_network_interfaces}. Ciascuna sezione può richiedere
  eventuali ulteriori direttive di configurazione che in genere si specificano
  scrivendole con una indentazione sulle righe successive alla parola chiave
  che definisce la relativa sezione.

  \begin{table}[htb]
    \centering
    \footnotesize
    \begin{tabular}{|l|p{8cm}|}
      \hline
      \textbf{Direttiva}& \textbf{Significato}\\ 
      \hline
      \hline
      \texttt{auto}         & dichiara una lista di interfacce che devono
                              essere avviata automaticamente all'avvio (dal
                              comando \texttt{ifup -a}).\\
      \texttt{allow-hotplug}& dichiara una lista di interfacce che devono essere
                              configurate automaticamente tramite
                              \textit{hotplug} (vedi
                              sez.~\ref{sec:udev_hotplug}).\\
      \texttt{mapping}      & definisce le modalità per creare una
                              corrispondenza fra un nome logico assegnato ad
                              una interfaccia di rete ed una specifica
                              interfaccia fisica.\\
      \texttt{iface}        & dichiara la configurazione di una interfaccia.\\
      \hline
    \end{tabular}
    \caption{Principali direttive che identificano le diverse sezioni di
      \texttt{/etc/network/interfaces}.} 
    \label{tab:net_network_interfaces}
  \end{table}

  Un esempio del contenuto di questo file, nel caso di una macchina con una
  sola interfaccia di rete a cui si vuole assegnare un indirizzo fisso,
  configurandone al contempo i parametri per l'accesso ad Internet, potrebbe
  essere il seguente:
  \begin{FileExample}[label=/etc/network/interfaces]
    auto lo eth0
    iface lo inet loopback
    iface eth0 inet static
        address 172.16.1.12
        netmask 255.255.255.0
        gateway 172.16.1.1
  \end{FileExample}

  La prima riga, introdotta dalla parola chiave \texttt{auto}, dice quali sono
  le interfacce da attivare automaticamente all'avvio del sistema, che possono
  essere specificate sia insieme, come nell'esempio, che in altrettante righe
  distinte. Le due righe seguenti, introdotte dalla parola chiave
  \texttt{iface}, servono a impostare i parametri di ciascuna interfaccia. Per
  ciascuna interfaccia deve essere fornita una riga in cui specificarne il
  nome, ed a seguire la famiglia di protocolli usata e le modalità di
  configurazione da indicare con opportune parole chiave separate da spazi.

  Nel caso dell'esempio la famiglia di protocolli utilizzata per entrambe le
  interfacce (\texttt{lo} e \texttt{eth0}) è sempre \texttt{inet}, che indica
  l'usuale TCP/IP con IPv4, ma sarebbe stato possibile usare anche
  \texttt{ipx} per indirizzi IPX, o \texttt{inet6} per IPv6.

  La configurazione delle due interfacce differisce invece nelle modalità con
  cui questa viene effettuata, ed a seconda di quale si è scelta potrà essere
  necessario indicare ulteriori parametri di configurazione; le principali
  modalità disponibili sono sostanzialmente le seguenti:
  \begin{basedescript}{\desclabelwidth{1.7cm}}
  \item[\texttt{loopback}] configurazione per il \textit{localhost}, si usa
    soltanto per l'interfaccia di loopback e non è necessario indicare
    altro.
  \item[\texttt{dhcp}] si richiedono i dati di configurazione ad un server
    DHCP con una opportuna richiesta tramite questo protocollo (torneremo
    sull'argomento in sez.~\ref{sec:net_DHCP}).
  \item[\texttt{manual}] l'interfaccia non deve essere configurata di default,
    la si usa ad esempio per interfacce che fanno parte di un \textit{bridge}.
  \item[\texttt{static}] si assegnano i valori in maniera statica secondo i
    parametri specificati nelle righe seguenti.
  \end{basedescript}
  per le prime due modalità non occorre specificare altro,\footnote{in realtà
    con \texttt{dhcp} si possono passare delle richieste specifiche al server
    (vedi sez.~\ref{sec:net_DHCP_client}) utilizzando alcuni parametri, ma in
    genere questi non vengono mai utilizzati, essendo sufficienti i valori di
    default.}, mentre se si sceglie una assegnazione statica dell'indirizzo IP
  con \texttt{static} si dovranno impostare gli opportuni parametri nelle
  righe seguenti, che di solito si indentano per maggiore chiarezza, come
  nell'esempio.
  
  Nel caso in esempio si sono indicati l'indirizzo, la maschera di rete e
  l'indirizzo del \textit{default gateway} utilizzando rispettivamente le
  parole chiave \texttt{address}, \texttt{netmask} e \texttt{gateway}.
  Quest'ultimo deve essere specificato una volta sola, per l'interfaccia da
  cui è raggiungibile. Si sono riassunte in
  tab.~\ref{tab:net_iface_static_options} le principali direttive disponibili.

  \begin{table}[!htb]
    \centering
    \footnotesize
    \begin{tabular}{|l|l|}
      \hline
      \textbf{Direttiva}& \textbf{Significato}\\ 
      \hline
      \hline
      \texttt{address} & indirizzo dell'interfaccia.\\
      \texttt{netmask} & \textit{netmask} della rete.\\
      \texttt{network} & indirizzo di rete (opzionale).\\
      \texttt{gateway} & \textit{default gateway}.\\
      % \texttt{up}      & .\\
      % \texttt{pre-up}  & .\\
      % \texttt{down}    & .\\
      % \texttt{pre-down}& .\\
      \texttt{broadcast}& indirizzo di \textit{broadcast} (opzionale).\\
      \texttt{hwaddress}& \textit{MAC address} da assegnare alla scheda.\\
      \hline
    \end{tabular}
    \caption{Principali direttive per la configurazione in modalità
      \texttt{static}.}  
    \label{tab:net_iface_static_options}
  \end{table}

  Per ciascuna interfaccia, indipendentemente dal tipo di indirizzi o dalla
  modalità di configurazione, possono inoltre essere specificati dei comandi
  da chiamare contestualmente all'attivazione e alla disattivazione
  dell'interfaccia, questo si fa in maniera analoga alla precedente
  indicazione di parametri, usando le parole chiave \texttt{up},
  \texttt{pre-up}, \texttt{down}, \texttt{post-down} seguite dal comando, che
  verrà eseguito rispettivamente dopo e prima dell'attivazione e prima e dopo
  la disattivazione.

  Si tenga presente poi che le interfacce associate alle connessioni
  punto-punto effettuate tramite modem non vengono normalmente menzionate in
  questo file, trattandosi in genere di connessioni non permanenti attivate a
  richiesta. Con la diffusione dei modem ADSL però nelle versioni più recenti
  è possibile attivare una connessione punto-punto permanente usando la nuova
  modalità \texttt{ppp}. In questo caso viene comunque utilizzata una
  configurazione esistente di \texttt{pppd} (tratteremo l'argomento in
  sez.~\ref{sec:net_pppd}), ed occorrerà specificare sulla riga seguente la
  direttiva \texttt{provider} con argomento il nome del file di direttive
  sotto \texttt{/etc/ppp/peers} che deve essere usato.

 
\item[RedHat] i file per la configurazione all'avvio delle interfacce di rete
  sono mantenuti nella directory \texttt{/etc/sysconfig/network-scripts}, e ce
  n'è uno per interfaccia con un nome del tipo \texttt{ifcfg-\textsl{iface}},
  dove \texttt{\textsl{iface}} è il nome dell'interfaccia da
  configurare. Ciascuno di questi contiene poi i relativi parametri, indicati
  sempre nella forma di assegnazione di un valore ad una variabile di
  shell,\footnote{in effetti si tratta proprio di questo, il file viene letto
    dagli script di avvio che usano queste variabili di shell per effettuare
    la configurazione.}  il cui significato è espresso in maniera evidente dal
  relativo nome per gran parte di esse.

  Il contenuto del file dipende in genere dal tipo di interfaccia, a seconda
  dei parametri necessari alla configurazione delle interfacce di quel
  tipo. Il caso più comune è quello delle interfacce di tipo Ethernet (ma i
  parametri sono identici per altre tecnologie simili); in questo caso una
  variabile sempre presente deve essere \texttt{DEVICE} che definisce il nome
  dell'interfaccia e deve corrispondere a quello del nome del file. Una
  seconda variabile fondamentale è \texttt{BOOTPROTO} che indica se deve
  essere usato un protocollo di auto-configurazione, coi valori \texttt{bootp}
  o \texttt{dhcp} dai nomi dei rispettivi protocolli, (vedi
  sez.~\ref{sec:net_RARP}) oppure una configurazione statica, con il valore
  \texttt{none}. Un'altra variabile importante è \texttt{ONBOOT} che segnala,
  con il valore \texttt{yes}, che l'interfaccia deve essere configurata
  automaticamente all'avvio.

  Pertanto nel caso si debba usare l'autoconfigurazione all'avvio con il
  protocollo DHCP un esempio del contenuto del file \texttt{ifcfg-eth0},
  relativo alla prima interfaccia Ethernet, potrebbe essere il seguente:
  \begin{FileExample}[label=ifcfg-eth0]
    DEVICE=eth0
    BOOTPROTO=dhcp
    ONBOOT=yes
  \end{FileExample}

  Se viceversa si volesse effettuare una configurazione statica si dovrebbero
  specificare in altrettante variabili l'indirizzo IP, la \textit{netmask}, e
  l'indirizzo di \textit{broadcast} (rispettivamente \texttt{IPADRR},
  \texttt{NETMASK} e \texttt{BROADCAST}), inoltre si dovrebbe indicare un
  eventuale \textit{default gateway} con la variabile \texttt{GATEWAY}; in tal
  caso un possibile esempio del contenuto del file \texttt{ifcfg-eth0}
  potrebbe essere il seguente:
  \begin{FileExample}[label=ifcfg-eth0]
    DEVICE=eth0
    BOOTPROTO=none
    ONBOOT=yes
    IPADDR=172.16.1.12
    NETMASK=255.255.255.0
    GATEWAY=172.16.1.1
    BROADCAST=172.16.1.255
    USERCTL=no
  \end{FileExample}
  dove è definita anche la variabile \texttt{USERCTL} che serve a marcare (se
  assegnato al valore \texttt{yes}) le interfacce che anche agli utenti
  normali possono attivare e disattivare con il comando \texttt{ifup}. Un
  elenco delle principali variabili di controllo è riportato in
  tab.~\ref{tab:net_ifcfg_iface}.

  \begin{table}[!htb]
    \centering
    \footnotesize
    \begin{tabular}{|l|p{8cm}|}
      \hline
      \textbf{Variabile}& \textbf{Significato}\\ 
      \hline
      \hline
      \texttt{BOOTPROTO}& protocollo di auto-configurazione (\texttt{bootp},
                          \texttt{DHCP}).\\ 
      \texttt{BROADCAST}& indirizzo di \textit{broadcast}.\\
      \texttt{DEVICE}   & nome dell'interfaccia.\\
      \texttt{GATEWAY}  & indirizzo IP del \textit{default gateway}.\\
      \texttt{HWADDR}   & indica il \textit{MAC address} della scheda (da
                          usare su macchine con più schede per essere sicuri 
                          dell'assegnazione all'interfaccia corretta).\\
      \texttt{IPADDR}   & indirizzo IP da assegnare alla macchina.\\
      \texttt{NETMASK}  & \textit{netmask} per la rete locale.\\
      \texttt{NETWORK}  & indirizzo della rete (opzionale).\\
      \texttt{ONBOOT}   & attivazione (\texttt{yes}) o meno (\texttt{no})
                          all'avvio.\\ 
      \texttt{USERCTL}  & attivazione (\texttt{yes}) o meno (\texttt{no}) da
                          parte di un utente non privilegiato.\\
      \hline
    \end{tabular}
    \caption{Principali variabili di controllo per i file
      \texttt{ifcfg-eth\textsl{N}}.} 
    \label{tab:net_ifcfg_iface}
  \end{table}

\end{basedescript}

Anche se gli script di avvio ed i file di configurazione variano da
distribuzione a distribuzione sono in genere disponibili due comandi
standardizzati,\footnote{in realtà solo su Debian si tratta di un vero e
  proprio comando, mentre su RedHat e SuSE si tratta di un semplice script di
  shell.}  \index{comando!\texttt{ifup}} \texttt{ifup} e
\index{comando!\texttt{ifdown}} \texttt{ifdown}, che consentono
rispettivamente di attivare o disattivare un'interfaccia, eseguendo al
contempo la sua configurazione secondo quanto previsto nei file di
configurazione della rete appena trattati.  Nella loro forma generica questi
comandi prendono come unico argomento il nome dell'interfaccia da attivare o
disattivare, le varie distribuzioni poi hanno realizzato versioni di questi
comandi che possono prevedere altri parametri o opzioni, per i quali si
consiglia di consultare la relativa pagina di manuale.


\subsection{Comandi di configurazione avanzata}
\label{sec:net_adv_config}

Finora abbiamo trattato le configurazioni più elementari della rete, in cui i
tradizionali comandi \texttt{ifconfig} e \texttt{route} sono più che
sufficienti. Anche se il loro uso continua a persistere, visto che comunque
vanno bene nella gran parte dei casi, questi comandi sono stati indicati come
deprecati per molti anni dato che non sono in grado di gestire configurazioni
di rete più complesse: ad esempio avendo due router indipendenti per arrivare
su Internet non consentono di definire una configurazione che consenta di
utilizzarli entrambi.

Come loro sostituto è stato introdotto il comando \index{comando!\texttt{ip}}
\texttt{ip}, un comando generico in grado di consentire la gestione di tutte
le funzionalità di rete più avanzate. Data la sua ampiezza questo comando
richiede che si usi il primo argomento come una sorta di sottocomando per
indicare su quale ``\textsl{oggetto}'' operare; ad esempio si potranno
configurare gli indirizzi di rete con \texttt{ip address} e le rotte con
\texttt{ip route}. Si sono riassunti gli ``\textsl{oggetti}'' (o sottocomandi)
più rilevanti in tab.~\ref{tab:ip_command_subcommands}.

Il comando supporta anche alcune opzioni, che devono essere specificate prima
di indicare un oggetto, la più rilevante (per l'elenco completo si consulti
\texttt{man ip}) è \texttt{-f} seguita dal nome del protocollo su cui si vuole
operare, secondo i valori di tab.~\ref{tab:net_ifconfig_aftype}. Il comando
infatti cerca di desumere il protocollo dagli argomenti che gli vengono
passati, e qualora questo non sia possibile usa IPv4 come default, ma ci sono
casi in cui occorre usare l'opzione per dare una indicazione esplicita, o si
vuole ridurre le informazioni stampate ai soli dati del protocollo
specificato.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{10cm}|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{address}  & manipola gli indirizzi di rete associati alle schede.\\
    \texttt{help}     & consente di ottenere la documentazione di un altro
                        sottocomando.\\
    \texttt{neighbour}& manipola la tabella di ARP e sostituisce il comando
                        \texttt{arp} (vedi sez.~\ref{sec:net_arp}).\\
    \texttt{link}     & manipola le caratteristiche di una interfaccia al
                        livello di collegamento fisico.\\
    \texttt{route}    & manipola le tabelle di \textit{routing} e sostituisce
                        il comando \texttt{route}.\\
    \texttt{rule}     & manipola le regole di \textit{routing}, che consentono
                        di realizzare politiche di \textit{routing}
                        complesse.\\
    \hline
  \end{tabular}
  \caption{Identificativi dei principali oggetti del comando \texttt{ip}.}
  \label{tab:ip_command_subcommands}
\end{table}

La sintassi prevede che non sia necessario scrivere per intero il primo
argomento ma, fintanto che non c'è ambiguità, solo le prime lettere. Come
secondo argomento deve essere specificata una azione da compiere, che dipende
dall'oggetto specificato nel primo. Oltre a quelle specifiche sono previste
alcune azioni generiche, presenti per la gran parte degli oggetti, come
\texttt{add} per aggiungere, \texttt{delete} per rimuovere e \texttt{show}
(omonima di \texttt{list}) per fare un elenco; si sono riassunte le principali
in tab.~\ref{tab:ip_command_actions}. Se non si indica nulla viene utilizzata
come default \texttt{show}.  Negli argomenti successivi devono essere indicate
eventuali ulteriori direttive di configurazione, espresse nella forma di
elenco di coppie ``\texttt{direttiva valore}'' separate da spazi; l'ordine in
cui le si esprimono non ha rilevanza.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|l|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{add}   & aggiunge un oggetto (indirizzo, rotta, regola, ecc). \\
    \texttt{del}   & rimuove un oggetto (indirizzo, rotta, regola, ecc). \\
    \texttt{flush} & rimuove tutti i contenuti (indirizzi, rotte, regole,
                     ecc). \\ 
    \texttt{show}  & elenca i contenuti (indirizzi, rotte, regole, ecc). \\
%    \texttt{} & . \\
    \hline
  \end{tabular}
  \caption{Principali azioni generiche disponibili per i vari sottocomandi di
    \texttt{ip}.}
  \label{tab:ip_command_actions}
\end{table}

La configurazione degli indirizzi di rete si effettua con \texttt{ip address},
che in sostanza è il sostituto di \texttt{ifconfig}. Se invocato senza
ulteriori argomenti il comando mostra l'elenco di tutte le interfacce e dei
relativi indirizzi. In tutti gli altri casi occorre indicare su quale
interfaccia operare con l'ulteriore direttiva \texttt{dev}; questa indicazione
è obbligatoria anche per visualizzare le caratteristiche di una singola
interfaccia, ad esempio:
\begin{Console}
root@hogen:~# \textbf{ip addr show dev eth0}
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:2b:62:7b:62:db brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.10/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::762b:62ff:fe7b:62db/64 scope link 
       valid_lft forever preferred_lft forever
\end{Console}
elenca sia il \textit{MAC address} della scheda che i due indirizzi assegnati
sull'interfaccia \texttt{eth0} della macchina \texttt{hogen}; quello IPv4,
classificato come \texttt{scope global} per indicarne la validità come
indirizzo generico, e quello IPv6 classificato come \texttt{scope link} in
quanto è quello \textit{link-local} associato direttamente alla scheda di
rete.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{10cm}|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{broadcast} & indica esplicitamente l'indirizzo di
                         \textit{broadcast}, si possono usare i valori
                         ``\texttt{+}'' e ``\texttt{-}'' per ottenerlo portando
                         rispettivamente a 1 e a 0 tutti i bit della parte 
                         locale (i meno significativi) dell'indirizzo,
                         se non si indica si sottintende ``\texttt{+}''. \\
    \texttt{dev}   & indica l'interfaccia su cui operare. \\
    \texttt{label} & indica una etichetta da associare all'indirizzo, consente
                     di mantenere la compatibilità con \texttt{ifconfig} per
                     gli \textit{IP alias} usando stringhe nella forma
                     \texttt{\textsl{ifname}:\textsl{N}}.\\
    \texttt{local} & il default, indica l'indirizzo (locale) da assegnare
                     all'interfaccia; normalmente viene omesso.\\
    \texttt{peer}  & indica l'indirizzo dell'altro capo di una connessione
                     punto-punto.\\
%    \texttt{} & . \\
    \hline
  \end{tabular}
  \caption{Principali direttive per \texttt{ip address}.}
  \label{tab:ip_address_directives}
\end{table}

Per assegnare un indirizzo di rete alla scheda occorre specificare l'azione
\texttt{add} seguita dall'indirizzo, che può essere sia IPv4 che IPv6
(andrebbe indicato con la direttiva \texttt{local} ma questo è il default e si
può omettere). Inoltre l'interfaccia deve essere sempre indicata con la
direttiva \texttt{dev}. Nel caso di configurazione di connessione punto-punto
occorrerà impostare l'indirizzo dell'altro capo della connessione con la
direttiva \texttt{peer \textsl{ADDRESS}}, si sono riassunte le principali
in tab.~\ref{tab:ip_address_directives}. A differenza di \texttt{ifconfig}
non è necessaria una direttiva separata per indicare la \textit{netmask},
basterà indicarla esprimendo l'indirizzo in notazione CIDR, seguito da una
``\texttt{/}'' e dal numero di bit, un esempio del comando è il seguente:
\begin{Example}
ip addr add 192.168.0.11/24 dev eth0
\end{Example}

La differenza più importante è però nella gestione dell'\textit{IP aliasing}:
non esistono più infatti nomi ``\textsl{speciali}'' per l'interfaccia, come
\texttt{eth0:1}, da usare per gli indirizzi aggiuntivi e basta semplicemente
ripetere l'assegnazione indicando un altro indirizzo, che verrà aggiunto; una
volta eseguito il comando precedente su \texttt{hogen}, il risultato sarà:
\begin{Console}
root@hogen:~# \textbf{ip -f inet addr show dev eth0}
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.0.10/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.0.11/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
\end{Console}

Si tenga presente che tutti gli indirizzi aggiunti ad una scheda che sono
nella stessa rete di uno già presente ne diventano dei secondari, marcati,
come nell'esempio precedente, ``\texttt{secondary}''. La conseguenza è che
vengono rimossi automaticamente quando viene rimosso il loro primario. Inoltre
gli indirizzi così assegnati non vengono riconosciuti da \texttt{ifconfig}, a
meno che non vi si aggiunga una etichetta con la ulteriore direttiva
\texttt{label} indicando un nome nella forma tradizionale. Pertanto se si
fosse voluto mantenere la visibilità con \texttt{ifconfig} si sarebbe dovuto
aggiungere l'indirizzo con il comando:
\begin{Example}
ip addr add 192.168.0.11/24 dev eth0 label eth0:1
\end{Example}

La cancellazione degli indirizzi si effettua invece usando l'azione
\texttt{del}; se non si specifica altro (ma l'interfaccia deve comunque essere
indicata con \texttt{dev}) verrà rimosso il primo indirizzo, altrimenti lo si
dovrà indicare sul resto della riga di comando, usando la stessa sintassi di
\texttt{add}. Si possono anche cancellare tutti gli indirizzi assegnati in un
colpo solo con l'azione \texttt{flush}, selezionando eventualmente una singola
interfaccia su cui operare con \texttt{dev}.

Si noti però come \texttt{ip addr} non copra tutte le funzionalità di
\texttt{ifconfig} che, oltre ad impostare gli indirizzi di una interfaccia,
consente anche di configurarne le caratteristiche relative al livello di
collegamento fisico, come modificare la MTU, o attivarla o disattivarla,
bloccare l'uso del protocollo ARP (vedi sez.~\ref{sec:net_arp}). Queste
funzionalità sono state scorporate dalla gestione degli indirizzi e vengono
coperte dal comando \texttt{ip link}. Al solito, se eseguito senza ulteriori
argomenti, verrà eseguita l'azione di default \texttt{show}, che mostra lo
stato delle interfacce, riportando solo i dati relativi al livello fisico che
vengono mostrati anche con \texttt{ip addr}:

\begin{Console}
root@hogen:~# \textbf{ip link}
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 74:2b:62:7b:62:db brd ff:ff:ff:ff:ff:ff
\end{Console}

Benché si possano utilizzare le azioni \texttt{add} e \texttt{del} per creare
vari tipi di interfacce virtuali ed assegnar loro opportune proprietà, l'uso
più comune del comando è con l'azione \texttt{set} che consente di impostare
le caratteristiche di una interfaccia fisica, che al solito deve essere
indicata con la direttiva \texttt{dev}. In particolare le due direttive
\texttt{up} e \texttt{down} servono per mandare rispettivamente su e giù una
interfaccia, come le analoghe di \texttt{ifconfig}. Si può poi usare la
direttiva \texttt{mtu} per impostarne la \textit{Maximum Transfer Unit} (vedi
sez.~\ref{sec:net_traceroute}), o assegnargli un nome diverso con la direttiva
\texttt{name}, si sono riassunte le principali direttive supportate da
\texttt{set} in tab.~\ref{tab:ip_link_set_directives}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{10cm}|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{address}&imposta l'indirizzo fisico (\textit{MAC address})
                     dell'interfaccia.\\ 
    \texttt{arp}   & abilita o disabilita (seguito da \texttt{on} o
                     \texttt{off}) l'uso del protocollo ARP (vedi
                     sez.~\ref{sec:net_arp} sull'interfaccia.\\
    \texttt{broadcast}&imposta l'indirizzo di \textit{broadcast} del livello
                     fisico. \\
    \texttt{dev}   & indica l'interfaccia su cui operare. \\
    \texttt{down}  & disattiva l'interfaccia.\\
    \texttt{multicast}& abilita o disabilita (seguito da \texttt{on} o
                     \texttt{off}) l'uso del \textit{multicast} 
                     sull'interfaccia.\\
    \texttt{mtu}   & imposta il valore della \textit{Maximum Transfer Unit}
                     dell'interfaccia.\\ 
    \texttt{txqlen}& modifica la lunghezza della coda di trasmissione
                     dell'interfaccia.\\
    \texttt{up}    & attiva l'interfaccia.\\
%    \texttt{} & .\\
    \hline
  \end{tabular}
  \caption{Principali direttive per \texttt{ip link}.}
  \label{tab:ip_link_set_directives}
\end{table}

La gestione delle rotte di instradamento viene invece effettuata con
\texttt{ip route}, che ricomprende le funzionalità di \texttt{route}. Di nuovo
se non si specifica altro il comando assume l'azione \texttt{show} e stampa
l'elenco delle rotte nella tabella di \textit{routing}
``\textsl{principale}'', un esempio del risultato è il seguente:
\begin{Console}
root@gont:~# \textbf{ip route} 
default via 192.168.168.1 dev eth0 
192.168.168.0/24 dev eth0  proto kernel  scope link  src 192.168.168.10 
\end{Console}

\itindbeg{advanced routing} 

E già qui iniziano ad emergere le differenze rispetto alla gestione illustrata
in sez.~\ref{sec:net_route}: infatti con \texttt{route} si è sempre parlato di
tabella di \textit{routing} in maniera generica, e adesso ci si può
legittimamente chiedere cosa significhi ``\textsl{principale}''. Il fatto è
che in realtà in sez.~\ref{sec:net_route} abbiamo fatto una semplificazione
drastica, corrispondente alla situazione precedente la creazione
dell'infrastruttura per il \textit{routing} avanzato (il cosiddetto
\textit{advanced routing} di \textit{iproute2}) quando è stata introdotta la
possibilità di avere più tabelle di \textit{routing}. 

Nei kernel recenti infatti sono disponibili ben 255 tabelle di
\textit{routing}, le cui ultime tre (contraddistinte dai valori numerici 253,
254 e 255) sono riservate ed hanno un ruolo speciale.  L'ultima, la 255, viene
gestita direttamente dal kernel che, tutte le volte che questi vengono
aggiunti con \texttt{ip address}, vi crea automaticamente le rotte relative
agli indirizzi locali ed agli indirizzi di \textit{broadcast}.  Per questo
motivo viene denominata \texttt{local}, e benché sia possibile farlo, non c'è
nessun motivo di modificarla.

La tabella di \textit{routing} principale, denominata \texttt{main}, è invece
la 254; è qui che vengono inserite le rotte impostate con \texttt{route} nella
gestione ``\textsl{tradizionale}'' degli indirizzi. Infine la terza tabella
riservata è la 253, denominata \texttt{default}, che di norma è vuota ed è
stata destinata, come indica il nome, a mettere le rotte da usare se non si è
avuta corrispondenza in nessuna delle altre tabelle. Dato che la
configurazione ordinaria (che va sulla \texttt{main}) comporta usualmente una
rotta di default, questa evenienza non accade mai, per cui in genere non ci
sono motivi per utilizzarla.

\itindend{advanced routing}

Quando si usa \texttt{ip}, che può controllare tutta l'infrastruttura del
\textit{routing} avanzato di Linux, il comando fa sempre riferimento alla
tabella \texttt{main}, ed è per questo che prima si è parlato di tabella di
\textit{routing} ``\textsl{principale}''; è comunque possibile operare su una
tabella qualsiasi specificandola con la direttiva \texttt{table}, cui far
seguire il nome o il numero. I tre nomi citati sono predefiniti in
\index{configurazione!\texttt{/etc/iproute2/rt\_tables}}
\texttt{/etc/iproute2/rt\_tables}, dove se ne possono aggiungere altri nella
forma di un numero seguito da un nome separato da spazi, con la solita
convenzione di usare il ``\texttt{\#}'' come commento.

A parte \texttt{show}, già illustrata, le due azioni principali di \texttt{ip
  route} sono \texttt{add} e \texttt{del}, che consentono di aggiungere o
rimuovere una rotta e prendono sostanzialmente gli stessi argomenti. Entrambe
richiedono che si indichi la destinazione con un indirizzo di rete o di una
macchina con la direttiva \texttt{to}, che essendo il default si può
omettere. Gli indirizzi di rete (IPv4 o IPv6) devono sempre essere indicati
con la notazione CIDR, se non si specifica una estensione l'indirizzo verrà
sempre considerato come l'indirizzo di una singola stazione. Esiste inoltre il
valore riservato \texttt{default} usato per indicare tutta Internet (cioè
\texttt{0/0} per IPv4 o \texttt{::/0} per IPv6).

Infine all'indirizzo di destinazione può essere preposto l'indicatore del tipo
di rotta, identificato da una parola chiave. Il default, che indica una rotta
ordinaria e normalmente si omette, è \texttt{unicast}; ma si possono usare i
tipi \texttt{blackhole} per scartare i pacchetti silenziosamente o
\texttt{unreachable} e \texttt{prohibit} per scartarli con un errore
rispettivamente di rete irraggiungibile o proibita.\footnote{questo provoca la
  emissione di due diversi tipi di pacchetti ICMP che notificano l'errore (di
  rete irraggiungibile o vietata) all'IP sorgente di un pacchetto che ha come
  destinazione detta rete.} Ci sono altri tipi per la descrizione dei quali si
rimanda alla documentazione del comando accessibile con \texttt{man ip-route}.

La direttiva che consente di indicare quale indirizzo utilizzare come
\textit{gateway} è invece \texttt{via}, ed in genere occorre anche indicare
l'interfaccia da usare con \texttt{dev}. Ad esempio per impostare il
\textit{default gateway} con il comando \texttt{ip} si dovrà eseguire qualcosa
del tipo:
\begin{Example}
ip route add default via 192.168.0.1 dev eth0
\end{Example}
mentre per impostare il \textit{gateway} per una sottorete si dovrà usare
qualcosa del tipo:
\begin{Example}
ip route add 192.168.168.0/24 via 192.168.0.234 dev eth0
\end{Example}

Una direttiva che inoltre può risultare molto utile quando si utilizzano più
indirizzi IP sulla stessa macchina è \texttt{src}, che consente di indicare
quale di essi deve essere usato come indirizzo sorgente per i pacchetti in
uscita attraverso quella rotta. Il comando consente inoltre di impostare
metriche, \textit{Maximum Transfer Unit} e \textit{Round Trip Time} iniziale
dei pacchetti con le direttive \texttt{metric}, \texttt{mtu} e \texttt{rtt};
si sono riassunte in tab.~\ref{tab:ip_route_directives} le direttive
principali, e di nuovo si rimanda alla documentazione per i dettagli.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|l|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{dev} & indica l'interfaccia di uscita. \\
    \texttt{metric} & indica la metrica della rotta. \\
    \texttt{mtu} & indica la \textit{Maximum Transfer Unit} della rotta. \\
    \texttt{rtt} & indica \textit{Round Trip Time} iniziale. \\
    \texttt{src} & indica l'indirizzo sorgente da usare per quella rotta. \\
    \texttt{table} & indica su quale tabella operare. \\
    \texttt{to}  & indica la destinazione, ed essendo il default è normalmente
                   omesso. \\
    \texttt{via} & indica il \textit{gateway} da usare per una destinazione. \\
%    \texttt{} & . \\
    \hline
  \end{tabular}
  \caption{Principali direttive per \texttt{ip route}.}
  \label{tab:ip_route_directives}
\end{table}

Si possono infine cancellare tutte le rotte disponibili con l'azione
\texttt{flush}, cui passare eventualmente l'indicazione di una interfaccia con
\texttt{dev} per restringere la cancellazione a quest'ultima.  Oltre alle
azioni generiche di tab.~\ref{tab:ip_command_actions}, \texttt{ip route}
supporta anche due comode azioni specifiche, \texttt{save} e \texttt{restore}
che consentono rispettivamente di salvare su un file, e ripristinare dallo
stesso, il contenuto di una tabella.

\itindbeg{advanced routing} 

Visto che fino ad adesso, anche negli esempi di \texttt{ip route}, abbiamo
sempre fatto riferimento alle rotte della tabella \texttt{main}, ci si può
chiedere a cosa servono e come vengano utilizzate le altre tabelle. Per
capirlo occorre però una visione più approfondita di come viene gestito
l'instradamento con la nuova infrastruttura dell'\textit{advanced routing}, e
come entrino in gioco le singole tabelle per ottenere la decisione finale
sulla strada che dovrà seguire un pacchetto. Infatti a differenza del
\textit{routing} tradizionale, in cui la decisione veniva presa esclusivamente
in base alla destinazione di un pacchetto, con il nuovo \textit{routing}
avanzato è possibile inserire criteri che consentono di effettuare delle
scelte in base anche agli altri parametri di un pacchetto come l'indirizzo
sorgente, il \textit{Type of Service} (TOS) \itindex{Type of Service (TOS)}
del pacchetto IP,\footnote{si tratta di un campo dedicato presente in tutti i
  pacchetti IP, che indica, con un valore numerico di 8 bit, una tipologia di
  traffico a cui il pacchetto appartiene; viene appunto usato dai router per
  classificare i pacchetti prendere decisioni al loro riguardo.} o le
marcature (i cosiddetti \itindex{firewall~mark} \textit{firewall mark})
attivabili con il \textit{netfilter} di Linux.\footnote{questa funzionalità,
  utilizzabile con il comando \texttt{iptables}, viene trattata in dettaglio,
  insieme a tutto quello che riguarda il \textit{netfilter}, nel terzo
  capitolo di \cite{SGL}.}

La nuova infrastruttura prevede che a fianco delle tabelle sia disponibile,
all'interno di quello che viene chiamato \textit{Routing Policy Data Base}
(RPDB), un insieme di regole che vengono ordinate per numero crescente da 0 a
32767. Ciascun regola è composta da un selettore, che consente di scegliere a
quali pacchetti applicarla, e da un esito, che dipende dal tipo di regola, ma
che normalmente consiste nell'indicazione di quale tabella di \textit{routing}
usare per instradarli. Ma oltre all'instradamento si possono impostare (con la
direttiva \texttt{type}) regole per scartare i pacchetti, usando nomi analoghi
a quelli già visti per i tipi di rotte di \texttt{ip route}
(\texttt{prohibit}, \texttt{blackhole}, ecc.). Il tipo di default è
\texttt{unicast} (che si può anche omettere, come la direttiva \texttt{type})
che indica come esito la richiesta di esaminare una tabella di instradamento.

Per decidere l'instradamento il kernel esamina tutte le regole in ordine
crescente a partire dalla numero 0 (che per questo ha la massima priorità), e
se trova una corrispondenza con il relativo selettore prova ad utilizzare le
rotte nella tabella indicata dalla regola stessa (o effettua quant'altro
previsto dal tipo di regola). Se nella tabella è presente una rotta valida per
il pacchetto questa verrà immediatamente utilizzata e la decisione sul
\textit{routing} conclusa, altrimenti il kernel proseguirà la scansione
andando ad esaminare la regola successiva.

All'avvio del sistema vengono preimpostate tre regole, che sono quelle che
consentono l'instradamento tradizionale, queste possono essere stampate con il
comando \texttt{ip rule}, che come i precedenti se non si scrive nulla
sottintende l'azione \texttt{show}; il risultato in tal caso sarà:
\begin{Console}
root@hogen:~# \textbf{ip rule}
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default 
\end{Console}

La regola 0, che ha la priorità più alta, è riservata e non può essere né
cancellata né modificata. Il risultato del comando precedente ci dice che essa
si applica ai pacchetti con un indirizzo sorgente qualunque (cioè a tutti) per
i quali viene consultata la tabella \texttt{local}. Come accennato in
precedenza questa è la tabella predefinita mantenuta dal kernel che contiene
gli indirizzi assegnati alle interfacce e quelli di \textit{broadcast} e la
regola serve appunto a gestire l'instradamento dei pacchetti quando si va
verso un proprio indirizzo IP o si esegue un \textit{broadcast}.

Le altre due regole, che sono quelle con i due valori massimi, e quindi con la
priorità più bassa, sono invece modificabili e cancellabili, anche se
normalmente non c'è alcun motivo per farlo. Di nuovo vengono selezionati tutti
i pacchetti per i quali si consulta prima la tabella di \textit{routing}
principale (\texttt{main}) e poi quella con gli eventuali default
(\texttt{default}). Per quanto detto in precedenza questo significa che se non
si sono aggiunte altre regole verranno usate le rotte impostate su
\texttt{main} con i comandi tradizionali (o con \texttt{ip route} senza
indicare una tabella) e la cosa si chiuderà lì, visto che normalmente
\texttt{default} è vuota e comunque verrebbe consultata solo se non viene
trovata una rotta su \texttt{main}.  \itindend{advanced routing}

La gestione avanzata del \textit{routing} viene fatta pertanto aggiungendo,
con \texttt{add}, ulteriori regole ad una priorità più elevata di queste
ultime due (vale a dire con un valore numerico inferiore). La priorità può
essere indicata esplicitamente con la direttiva \texttt{priority} seguita da
un numero, mentre se non si specifica nulla viene utilizzato il valore
numerico immediatamente precedente a quello più basso già presente. In
sostanza di default il comando assume che la regola che si immette sia a
priorità più alta rispetto a quelle già presenti.

Inserendo una nuova regola in questo modo si può fare in modo che i pacchetti
selezionati dalla stessa vengano instradati secondo le rotte inserite in una
tabella creata ad hoc, da indicare con la direttiva \texttt{table} (o col
sinonimo \texttt{lookup}). La gran parte delle direttive attiene alle modalità
con cui si possono selezionare i pacchetti, si può allora usare \texttt{from}
per indicare una selezione sugli indirizzi sorgente, \texttt{to} per
selezionare sugli indirizzi di destinazione, \texttt{tos} per usare il campo
TOS dei pacchetti, e \texttt{fwmark} per usare una etichetta del
\textit{netfilter} (il \textit{firewall mark}); si sono elencate le principali
direttive di selezione nella seconda parte di
tab.~\ref{tab:ip_rule_directives}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{10cm}|}
    \hline
    \textbf{Oggetto} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{lookup}&sinonimo di \texttt{table}. \\
    \texttt{priority}& indica la priorità della regola (con un valore
                       numerico). \\ 
    \texttt{table}& indica la tabella di instradamento da usare per i
                    pacchetti selezionati dalla regola, si può specificare
                    o il valore numerico o un nome configurato in
                    \texttt{/etc/iproute2/rt\_tables}.\\
    \texttt{type} & indica il tipo di regola, il default è \texttt{unicast}
                    ed in genere si omette completamente, altri valori
                    possibili sono \texttt{blackhole}, \texttt{unreachable}
                    e \texttt{prohibit} che consentono di scartare
                    in vari modi i pacchetti selezionati dalla regola.\\
    \hline
    \texttt{from} & indica una selezione per indirizzo sorgente, sia di una
                    macchina singola che di una sottorete.\\
    \texttt{fwmark}&indica una selezione per il valore di un \textit{firewall
                    mark} impostato dal \textit{netfilter}.\\
    \texttt{iif}  & indica una selezione per l'interfaccia di ingresso di un
                    pacchetto.\\ 
    \texttt{oif}  & indica una selezione per l'interfaccia di uscita di un
                    pacchetto (è disponibile solo per i pacchetti generati
                    sulla macchina stessa).\\
    \texttt{to}  &  indica una selezione indirizzo di destinazione. \\
    \texttt{tos} &  indica una selezione per il valore del campo TOS dei
                    pacchetti IP.\\
%    \texttt{} & . \\
    \hline
  \end{tabular}
  \caption{Principali direttive per \texttt{ip rule}.}
  \label{tab:ip_rule_directives}
\end{table}

Per capire meglio il funzionamento del comando ipotizziamo di avere, nella
situazione di fig.~\ref{fig:net_schema_rete}, un secondo \textit{router} con
indirizzo \texttt{192.168.0.2}. Sulla macchina \texttt{havnor} si può allora
impostare una regola che indichi di usarlo per le macchine della rete
\texttt{192.168.168.0/24}. Per quanto appena detto, l'operazione deve essere
compiuta in due passi, il primo è quello di selezionare tutti questi pacchetti
ed indicare una tabella ad hoc per la loro gestione, questo si potrà fare con
il comando:
\begin{Example}
ip rule add from 192.168.168.0/24 table 100 prio 1000
\end{Example}
e si otterrà come risultato che:
\begin{Console}
root@havnor:~# \textbf{ip rule}
0:	from all lookup local 
1000:	from 192.168.168.0/24 lookup 100 
32766:	from all lookup main 
32767:	from all lookup default 
\end{Console}
a questo punto si tratta di indicare per quei pacchetti un diverso
\textit{default gateway} usando la nuova tabella di \textit{routing}, questo
si fa semplicemente con:
\begin{Example}
ip route add default via 192.168.0.2 dev eth0 table 100
\end{Example}

% La documentazione del programma può essere ottenuta direttamente usando
% \texttt{ip help} 


% TODO trattare il comando ip


\section{Il sistema della risoluzione dei nomi}
\label{sec:net_name_resolution}

Nella sezione precedente abbiamo trattato la configurazione di basso livello
della rete, relativa alla parte di protocolli gestita direttamente dal
kernel. Una delle funzionalità di base di Internet però è quella che consente
di individuare un nodo sulla base di un nome simbolico invece che tramite il
suo indirizzo IP. Esamineremo in questa sezione la configurazione del servizio
di risoluzione dei nomi, che è quello che consente di fare tutto ciò.  Vedremo
come questa funzionalità sia fornita direttamente dalle librerie del sistema e
quali sono i file di configurazione che ne controllano il comportamento.


\subsection{Introduzione al \textit{resolver}}
\label{sec:net_resolver_intro}

\itindbeg{resolver}

Benché i protocolli di rete funzionino esclusivamente usando gli indirizzi IP,
è piuttosto raro che quando si intende utilizzare un servizio su Internet si
debba fornire il valore numerico di uno di essi. Questo avviene perché uno dei
servizi di base per il funzionamento della rete è quello della risoluzione dei
nomi, grazie al quale è possibile identificare un sito o un qualunque nodo
della rete attraverso un nome simbolico che poi sarà \textsl{risolto} nel
relativo indirizzo IP.

I nomi dei nodi di Internet, i cosiddetti \index{nome~a~dominio} \textsl{nomi
  a dominio}, vengono indicati con una forma specifica, come
\texttt{nome.dominio.it}, che prevede la possibilità di raggruppare tutti i
nodi che fanno capo ad una stessa organizzazione sotto un suffisso comune,
detto appunto \textsl{dominio} (tratteremo i dettagli di tutto questo in
sez.~\ref{sec:net_DNS_intro}); nel caso in esempio il dominio è
\texttt{dominio.it} mentre \texttt{nome} è il nome del nodo. Il nome del nodo
viene normalmente chiamato \textit{hostname}, anche se in realtà
l'\textit{hostname} è più precisamente il nome di una macchina in quanto tale,
esso infatti è comunque definito, indipendentemente dal fatto che essa sia
parte di una rete o di un dominio, anche se di solito, quando la si mette in
rete, viene usato anche come nome del nodo.

\index{nome~a~dominio|(} 

Su Internet la risoluzione dei nomi viene realizzata attraverso un apposito
servizio, il cosiddetto \textit{Domain Name Service} (da qui in avanti DNS)
che tratteremo più approfonditamente nel cap.~\ref{cha:DNS}. Questo servizio è
in sostanza un enorme database distribuito, interrogabile via rete, che
associa un nome simbolico (nella forma di un nome a dominio) al corrispondente
indirizzo IP (in realtà il servizio DNS fornisce anche molte altre
informazioni, ma torneremo su questo in sez.~\ref{sec:net_RR_zones}). Qualora
sia necessaria una risoluzione si può interrogare il DNS; ogni programma che
vuole accedere ad un nodo attraverso il suo nome invece che con il suo
indirizzo IP è quindi un client per questo servizio.

Dato che la risoluzione dei nomi è un servizio usato da un gran numero di
programmi diversi, in un sistema unix-like questo viene effettuato tramite una
serie di funzioni, inserite direttamente nelle librerie standard del C, che
vanno a costituire quell'insieme di funzionalità che viene chiamato
\textit{resolver} e che permette di ottenere le associazioni fra nodi della
rete ed i nomi identificativi associati agli stessi. Si tenga presente che
tutto ciò non riguarda soltanto l'associazione fra nome a dominio e indirizzo
IP, ma anche quella fra numero di porta e nome del corrispondente servizio ed
altro ancora.

\index{nome~a~dominio|)}
 
\begin{figure}[htb]
  \centering
  \includegraphics[width=9cm]{images/resolver}
  \caption{Schema di funzionamento delle funzioni del \textit{resolver}.}
  \label{fig:net_resolver_schema}
\end{figure}

Per questo prima di trattare del DNS in quanto servizio fornito sulla rete,
dovremo prendere in considerazione i file di configurazione usati dalle
funzioni di libreria del \textit{resolver}, che sono quelle che svolgono in
maniera generica il servizio di risoluzione dei nomi, e che non
necessariamente eseguono questo compito rivolgendosi ad un server DNS. Le
librerie infatti consentono di mantenere le informazioni relative alla
risoluzione su diversi supporti, definendo una interfaccia astratta che viene
usata dai programmi, secondo l'architettura illustrata in
fig.~\ref{fig:net_resolver_schema}.

Se restiamo nella nostra analogia telefonica, il sistema del \textit{resolver}
è in sostanza il meccanismo che ci porta dal conoscere il nome del
destinatario all'avere il suo numero di telefono. Come per il telefono questo
può avvenire in più modi, si può andare a cercare sulla rubrica, che nel caso
è realizzata dal file \texttt{/etc/hosts} (vedi sez.~\ref{sec:net_hosts}), si
può cercare nell'elenco del telefono, oppure ci si può rivolgere ad un server
DNS, che è più simile al servizio ``12'' cui si chiedevano i numeri degli
abbonati.\footnote{anche se oggi non esiste più, continueremo a fare
  riferimento al vecchio numero, così da evitare pubblicità ad uno degli
  attuali fornitori di servizio, che se ne son già fatta fin troppa da soli.}
L'uso del DNS ha anche il vantaggio (come il servizio 12 rispetto ad una
rubrica) che qualora una associazione fra nome e indirizzo IP dovesse cambiare
questa viene aggiornata automaticamente.

Per questo motivo una delle informazioni che di norma vengono richieste nella
configurazione manuale della rete è l'indirizzo IP del server DNS (ogni
provider ne mette a disposizione almeno uno) che dovrà essere usato per
ottenere la risoluzione dei nomi consentendo così la normale navigazione su
Internet in cui si contattano i server con il loro nome a dominio. Ogni
distribuzione prevede un suo sistema, e molte volte queste informazioni sono
richieste anche in fase di installazione.

\itindend{resolver}


\subsection{I file di configurazione del \textit{resolver}}
\label{sec:net_resolv}

Abbiamo già visto come in un sistema unix-like, oltre alla risoluzione dei
\index{nome~a~dominio} nomi a dominio, esista la necessità di poter effettuare
molte altre associazioni fra valori simbolici e numerici, come quelle fra
numero di porta e nome del servizio, fra \textit{user ID} e nome di login
dell'utente, ecc.  Siccome questo tipo di corrispondenze possono essere
mantenute in diversi modi, le librerie del C del progetto GNU prevedono una
modularizzazione di questi servizi, attraverso il sistema del \textit{Name
  Service Switch}, che abbiamo trattato in sez.~\ref{sec:base_nsswitch_conf}.

Come avevamo accennato allora questo sistema si applica anche ai nomi relativi
alla rete, per i quali sono state previste una opportuna serie di classi; un
estratto della sezione del file \texttt{/etc/nsswitch.conf} che concerne
queste configurazioni è il seguente:
\begin{FileExample}[label=/etc/nsswitch.conf]
...
hosts:          files dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
...
\end{FileExample}

Nel caso di risoluzione dei nomi a dominio \index{nome~a~dominio} la riga che
interessa è quella relativa a \texttt{hosts} (torneremo sulle altre in
sez.~\ref{sec:net_name_files}). L'impostazione riportata nel precedente
esempio ci dice che prima si dovrà andare a risolvere i nomi usando i file
locali standard (cioè \texttt{/etc/hosts}) e poi il DNS. Se si volessero
mettere le corrispondenze fra macchine locali e nomi su un server LDAP si
potrebbe modificare questa linea come:
\begin{FileExample}[label=/etc/nsswitch.conf]
hosts:          files ldap dns
\end{FileExample}
nel qual caso, prima di interrogare il DNS, il \textit{Name Service Switch}
provvederebbe ad effettuare una ricerca su LDAP.  A meno di non avere una
esigenza specifica di questo tipo, in genere non ci sono motivi per modificare
il contenuto di questo file.

Il sistema del \textit{resolver} però è antecedente all'introduzione del
\textit{Name Service Switch} ed a lungo è stato controllato da una sua
specifica serie di file di configurazione che consentivano, come vedremo,
anche di scegliere l'ordine in cui viene effettuata la ricerca dei dati sui
vari supporti per effettuare la risoluzione. Dato che la configurazione
classica consentiva solo la scelta fra i file locali ed il DNS questo aspetto
oggi viene gestito dal \textit{Name Service Switch}, che consente una scelta
su un numero arbitrario di supporti diversi; gli altri file vengono comunque
utilizzati e sono quelli che permettono di controllare le modalità con cui si
effettuano le interrogazioni al servizio DNS.

Il principale file di configurazione del \textit{resolver} è
\index{configurazione!\texttt{/etc/resolv.conf}} \texttt{/etc/resolv.conf}, su
cui vengono mantenute le informazioni di base necessarie al funzionamento
dello stesso. Il file contiene la lista degli indirizzi IP dei server DNS a
cui ci si rivolge quando si vuole effettuare una risoluzione e l'indicazione
del dominio locale.  Il formato del file è molto semplice, una serie di righe
nella forma di una direttiva seguita da un valore (separato da spazi) con le
righe vuote e quelle che iniziano per ``\texttt{\#}'' che vengono ignorate. Un
possibile esempio del suo contenuto è il seguente:
\begin{FileExample}[label=/etc/resolv.conf]
search truelite.it
nameserver 127.0.0.1
nameserver 62.48.34.25
\end{FileExample}

La direttiva \texttt{nameserver} serve ad indicare l'indirizzo IP di un server
DNS a cui rivolgersi per la risoluzione dei \index{nome~a~dominio} nomi a
dominio. Se ne possono specificare più di uno e la risoluzione di un nome
verrà eseguita interrogandoli in sequenza, nell'ordine in cui essi sono stati
specificati.  Si possono indicare fino ad un massimo di 3 diversi server e
l'indirizzo deve sempre essere fornito in forma numerica, anche qualora si
disponesse di una risoluzione statica su \texttt{/etc/hosts}, dato che il
\textit{resolver} non può risolvere un nome senza aver prima interpretato
correttamente il contenuto di questo file.

La direttiva \texttt{search} specifica una lista (separata da spazi) di domini
in cui cercare i nomi delle macchine quando sono indicati in forma non
qualificata.\footnote{per forma qualificata di un nome a dominio si intende un
  nome completo del tipo \texttt{freedom.softwarelibero.it}, usare una forma
  non qualificata all'interno del dominio \texttt{softwarelibero.it} sarebbe
  usare semplicemente \texttt{freedom}.} Di norma si specifica come argomento
solo il dominio locale, così quando si effettua la ricerca su un nome, gli
viene aggiunto automaticamente quel dominio come suffisso. In questo modo si
può specificare solo l'\textit{hostname} di un computer sulla rete locale, e
la ricerca verrà eseguita automaticamente come se lo si fosse scritto con il
nome completo. Il tutto, se se ne è indicato più d'uno, verrà ripetuto per
ciascuno dei domini presenti nella lista.

Il proprio dominio locale può comunque anche essere indicato direttamente con
la direttiva \texttt{domain}, che indica il dominio in cui vengono cercati i
nomi espressi in forma non qualificata, cui viene automaticamente aggiunto il
dominio così specificato. In genere questa direttiva è alternativa alla
precedente. Un elenco delle principali direttive usate nel file è riportato in
tab.~\ref{tab:net_resolv.conf}; una descrizione più dettagliata e completa si
può trovare nella pagina di manuale, ottenibile con \texttt{man resolv.conf}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Direttiva} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{nameserver}& definisce l'IP di un server DNS da utilizzare per la
                         successiva risoluzione dei nomi. \\
    \texttt{search}    & lista dei domini su cui effettuare una ricerca
                         preventiva. \\
    \texttt{domain}    & nome del dominio locale, se assente viene determinato
                         sulla base di quanto specificato con
                         \texttt{/etc/hostname}.\\ 
    \hline
  \end{tabular}
  \caption{Direttive del file \texttt{resolv.conf}.}
  \label{tab:net_resolv.conf}
\end{table}

In genere le informazioni mantenute su \texttt{/etc/resolv.conf}, come il
dominio locale e l'IP dei server DNS, vengono fornite in fase di installazione
o di configurazione iniziale della rete.  In sostanza è in questo file che
viene indicato qual'è il numero di telefono del servizio ``12'' a cui ci si
rivolge; ogni provider ne mette a disposizione almeno uno, e come vedremo nel
cap.~\ref{cha:DNS} è possibile anche installarsi un server DNS locale.

Per una macchina posta in una rete locale questi valori di norma devono essere
impostati manualmente, a meno di non usare il servizio DHCP (vedi
sez.~\ref{sec:net_DHCP_client}) per l'impostazione automatica. In genere
questo viene fatto dal programma di configurazione della rete, che, quando vi
chiede dominio e DNS, va a creare automaticamente questo file, inserendovi le
direttive \texttt{search} e \texttt{nameserver} con i valori da voi forniti.

Se invece si sta usando un collegamento punto-punto con un modem o una ADSL
sono i programmi che lanciano la connessione (cioè \texttt{pppd} o l'eventuale
interfaccia a quest'ultimo, vedi sez.~\ref{sec:net_pppd}) che usano le
informazioni ottenute dal provider durante la fase di negoziazione del
collegamento, e riscrivono al volo questo file; in questo caso può servire
aggiungere al volo in un secondo tempo qualche altro DNS (ce ne sono di
pubblici) qualora quello del provider avesse problemi.

Il secondo file di configurazione principale del \textit{resolver} è
\index{configurazione!\texttt{/etc/host.conf}} \texttt{/etc/host.conf}, che
controlla le modalità di funzionamento delle funzioni che eseguono la
risoluzione dei nomi. Al solito le righe vuote od inizianti per
``\texttt{\#}'' vengono ignorate, le altre devono contenere una parola chiave
che esprime una direttiva, che può essere seguita o meno da un valore. Un
esempio comune del contenuto di questo file è il seguente:
\begin{FileExample}[label=/etc/host.conf]
order hosts,bind
multi on
\end{FileExample}

La direttiva \texttt{order} controlla la sequenza in cui viene effettuata la
risoluzione dei nomi, nell'esempio si dice che deve prima essere usato il file
\texttt{/etc/hosts} (vedi sez.~\ref{sec:net_hosts}), e poi possono essere
eseguite eventuali interrogazioni ai DNS esterni. Ad oggi questa parte viene
gestita, come accennato, dal \textit{Name Service Switch}, ma si abbia cura,
per evitare ambiguità, di usare una configurazione coerente, oppure si eviti
di impostarla.

La direttiva \texttt{multi} permette di ottenere come risposta tutti gli
indirizzi validi di una stazione che compare più volte in \texttt{/etc/hosts},
invece di avere solo il primo, non conviene attivarla nel caso di che questo
file risulti molto voluminoso, in quanto comporta un impatto negativo sulle
prestazioni.

Oltre a queste due le altri principali direttive (ed il relativo significato)
sono riportate in tab.~\ref{tab:net_host_conf}. Tutte prendono come argomenti
i valori \texttt{on} ed \texttt{off}, che attivano e disattivano il
comportamento richiesto. Quando non vengono esplicitamente utilizzate, il
comportamento di default è equivalente ad \texttt{off}. Per l'elenco completo
ed i dettagli su tutte le direttive si può al solito consultare la pagina di
manuale con \texttt{man host.conf}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Direttiva} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{multi}     & ritorna tutti gli indirizzi corrispondenti presenti
                         in \texttt{/etc/hosts} e non solo il primo, prende i
                         valori \texttt{on} o \texttt{off} (il default).\\
    \texttt{nospoof}   & attiva un controllo 
                         \textit{antispoofing}\footnotemark  elementare
                         chiedendo la risoluzione inversa dell'IP ricevuto e
                         fallendo in caso di mancata corrispondenza, prende i
                         valori \texttt{on} o \texttt{off} (il default).\\
    \texttt{order}     & indica come ed in che ordine viene eseguita una
                         ricerca, prevede i valori \texttt{bind},
                         \texttt{hosts} e \texttt{nis} da indicare separati da
                         virgole se se ne specifica più di uno.\\
    \texttt{reorder}   & riordina gli indirizzi in modo da restituire per
                         primi quelli locali, prende i valori \texttt{on} o
                         \texttt{off} (il default).\\ 
    \texttt{spoofalert}& se \texttt{nospoof} è attivo inserisce un avviso
                         degli errori rilevati nei log di sistema, prende i
                         valori \texttt{on} o \texttt{off} (il default).\\
    \hline
  \end{tabular}
  \caption{Principali direttive del file \texttt{host.conf}.}
  \label{tab:net_host_conf}
\end{table}

\footnotetext{con \textit{spoofing} si intende in genere quella tecnica che
  prevede la creazione di pacchetti IP con indirizzo sorgente falsificato, per
  cercare di impersonare una macchina diversa.}


\subsection{La gestione locale dei nomi}
\label{sec:net_hosts}

Normalmente il primo metodo utilizzato dal \textit{resolver} per effettuare
una corrispondenza fra nomi simbolici e indirizzi IP è utilizzare il contenuto
di \index{configurazione!\texttt{/etc/hosts}} \texttt{/etc/hosts}.  Questo
file contiene un elenco di nomi di macchine, associati al relativo indirizzo
IP.  Lo si usa quindi come un'agenda del telefono per specificare gli
indirizzi delle macchine per le quali si ha una mappa \textsl{statica} degli
indirizzi, ad esempio le macchine di una rete privata che non vanno su
Internet, ma che volete risolvere col nome che gli avete assegnato.

Il formato del file è molto semplice, al solito le righe vuote od inizianti
per ``\texttt{\#}'' sono ignorate mentre le altre righe devono contenere,
separati da spazi o caratteri di tabulazione, l'indirizzo IP, il nome completo
(in termini di dominio, quello che viene detto FQDN, \textit{Fully Qualified
  Domain Name}, vedi sez.~\ref{sec:net_DNS_intro}) ed una eventuale lista di
nomi alternativi. Un possibile esempio di questo file è il seguente:
\begin{FileExample}[label=/etc/hosts]
127.0.0.1       localhost
192.168.168.1   havnor.gnulinux.it     havnor

# private nets
192.168.168.10  gont.gnulinux.it       gont
192.168.168.11  oppish.gnulinux.it     oppish

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
\end{FileExample}
che associa agli IP delle macchine che in fig.~\ref{fig:net_schema_rete} sono
sulla rete secondaria di \texttt{havnor} i relativi nomi.

Ovviamente usare questo file è la maniera più semplice per identificare una
macchina su una rete locale, lo svantaggio è che deve essere presente su ogni
macchina, e quando il numero di nodi coinvolti aumenta, diventa sempre più
complicato il lavoro di tenerli tutti aggiornati e coerenti fra loro.  Per
questo vedremo in sez.~\ref{sec:net_DNS_domain} come fare lo stesso lavoro
attraverso un server DNS locale.

Benché il file faccia riferimento a delle caratteristiche tipiche dell'uso
della rete, esso deve essere presente anche quando la macchina non è
fisicamente in rete perché l'interfaccia di \textit{loopback} viene comunque
utilizzata da molti programmi, che fanno riferimento a questo file per la
risoluzione del nome \texttt{localhost}, ad essa associato, sull'indirizzo
\texttt{127.0.0.1}.

\itindbeg{hostname}

Un caso particolare di gestione dei nomi è quello che riguarda il nome che
contraddistingue la macchina stessa, comunemente detto
\textit{hostname}. Benché l'\textit{hostname} abbia di solito più significato
quando si è collegati in rete, come accennato il nome di una macchina è una
proprietà del tutto indipendente dalla presenza in rete della stessa, e viene
riportato anche da vari comandi di sistema non attinenti alla rete (come
\texttt{uname}) nel prompt della shell o nelle schermate di avvio.

Di norma buona parte delle distribuzioni chiedono il nome della macchina in
fase di installazione e lo memorizzano in un opportuno file di configurazione:
nel caso di Debian il nome viene semplicemente scritto nel file
\texttt{/etc/hostname}, RedHat usa la variabile \texttt{HOSTNAME} nel file
\texttt{/etc/sysconfig/network}, altre distribuzioni possono fare scelte
diverse.  Questo file viene usato negli script di avvio per leggere il nome
della macchina quando questo viene impostato con il comando \texttt{hostname}
o utilizzato direttamente nell'avvio con \texttt{systemd}. Perciò si deve
essere consapevoli che cambiare il contenuto del file su cui è memorizzato non
cambia il nome della macchina fintanto che non si chiama direttamente anche
\texttt{hostname} o si rieseguono gli script di avvio.

Se invocato direttamente il comando \index{comando!\texttt{hostname}}
\texttt{hostname} si limita a stampare il nome della macchina, mentre può
impostare un nome diverso se quest'ultimo viene passato come argomento, se
invece si usa l'opzione \texttt{-F} il comando legge il nome da un file (ad
esempio è con questa opzione che gli script di avvio di Debian usano il
contenuto di \texttt{/etc/hostname}). Si può richiedere anche la stampa del
nome a dominio completo con l'opzione \texttt{-{}-fqdn}, questo però dipende
dal fatto che si sia configurato il \textit{resolver} per effettuare la
risoluzione dei nomi, e non può essere modificato dal comando
stesso.\footnote{quello che succede è che il comando esegue la risoluzione del
  nome della macchina (ottenuto con \texttt{hostname}) sul
  \textit{resolver} e riporta il risultato ottenuto; in genere detta
  risoluzione viene inserita in fase di installazione in \texttt{/etc/hosts}
  insieme all'IP della stessa, per cui di fatto in tal caso detto file
  contiene anche la configurazione del proprio dominio locale.}

Il comando può essere invocato anche come \texttt{dnsdomainname} che invece
permette di ottenere il nome del dominio di cui si fa parte. Anche in questo
caso non è possibile modificarne il valore con il comando, in quanto di nuovo
questo valore viene sempre determinato tramite il \textit{resolver} sulla base
della configurazione di quest'ultimo. Per le altre opzioni del comando ed per
una descrizione completa si può fare riferimento alla pagina di manuale,
accessibile con \texttt{man hostname}.

\itindend{hostname}


\subsection{La gestione degli altri nomi di rete}
\label{sec:net_name_files}

Come accennato in sez.~\ref{sec:net_resolv} oltre alle associazioni fra
indirizzo IP e nome simbolico di una macchina, esistono una serie di altre
informazioni (si faccia riferimento a quanto riportato in
tab.~\ref{tab:cfg_NSS_classes}) relative a protocolli e servizi di rete, di
norma identificate da valori numerici, ai quali poi viene assegnato un
corrispondente nome simbolico come facilitazione mnemonica.

Queste corrispondenze oggi sono gestite tutte tramite il \textit{Name Service
  Switch}, ma quasi sempre, come risulta dall'estratto di configurazione
citato in sez.~\ref{sec:net_resolv}, vengono utilizzati i file statici su cui
tradizionalmente\footnote{cioè prima che si passasse all'uso del \textit{Name
    Service Switch}, quando le informazioni erano appunto ricavate
  direttamente dalla scansione di questi file.} esse venivano mantenute, per
questo motivo nel resto della sezione tratteremo soltanto del formato di
questi file.

In sez.~\ref{sec:net_ports} abbiamo già accennato come la corrispondenza fra i
servizi di rete ed i numeri di porta loro assegnati venga mantenuta nel file
\index{configurazione!\texttt{/etc/services}} \texttt{/etc/services}; è al
contenuto di questo file che fanno riferimento tutti i programmi che vogliono
utilizzare il nome simbolico di un servizio al posto del valore numerico della
porta ad esso associato.

Di norma questo non è un file che sia necessario modificare, ma è utile
conoscerne il contenuto. Il formato del file è molto semplice, un elenco di
numeri di porta a ciascuno dei quali è associato un nome simbolico che
individua il servizio ad esso associato dalle convenzioni internazionali o
dall'uso comune. Un estratto di questo file, preso da una Debian Squeeze, è il
seguente:
\begin{FileExample}[label=/etc/services]
...
ftp-data        20/tcp
ftp             21/tcp
fsp             21/udp          fspd
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp
telnet          23/tcp
smtp            25/tcp          mail
time            37/tcp          timserver
time            37/udp          timserver
rlp             39/udp          resource        # resource location
nameserver      42/tcp          name            # IEN 116
whois           43/tcp          nicname
tacacs          49/tcp                          # Login Host Protocol (TACACS)
tacacs          49/udp
re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
re-mail-ck      50/udp
domain          53/tcp                          # name-domain server
domain          53/udp
mtp             57/tcp                          # deprecated
tacacs-ds       65/tcp                          # TACACS-Database Service
tacacs-ds       65/udp
bootps          67/tcp                          # BOOTP server
bootps          67/udp
bootpc          68/tcp                          # BOOTP client
bootpc          68/udp
tftp            69/udp
gopher          70/tcp                          # Internet Gopher
gopher          70/udp
rje             77/tcp          netrjs
finger          79/tcp
www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol
...
\end{FileExample}

Come per buona parte dei file di configurazione, righe vuote e tutto quello
che segue il carattere ``\texttt{\#}'' viene considerato un commento ed
ignorato; ogni riga ha il formato:
\begin{Example}
nome           numero/protocollo    alias
\end{Example}
dove \texttt{nome} é l'identificativo simbolico del servizio, \texttt{numero}
è il numero di porta ad esso assegnato, \texttt{protocollo} indica se il
servizio usa UDP o TCP, mentre \texttt{alias} è una lista (separata da spazi)
di eventuali altri nomi associati allo stesso servizio.

Un secondo file che mantiene corrispondenze fra valori numerici e nomi è
\index{configurazione!\texttt{/etc/networks}} \texttt{/etc/networks}, che è
l'analogo di \texttt{/etc/hosts} per quanto riguarda le reti. Anche queste,
come le singole stazioni, possono essere identificate da un nome, e di nuovo
le corrispondenze statiche fra nome e indirizzo IP della rete vengono
mantenute in questo file, il cui formato, come descritto dalla pagina di
manuale accessibile con \texttt{man networks}, è composto da tre campi
separati da spazi.

Il primo campo indica il nome simbolico della rete, il secondo campo il suo
indirizzo, nella notazione \textit{dotted decimal} (tralasciando opzionalmente
gli eventuali \texttt{.0} finali), ed il terzo campo un eventuale alias
(questo campo è opzionale).  Al solito le righe vuote e tutto quello che segue
un \texttt{\#} viene ignorato. Un esempio del contenuto di questo file
potrebbe essere:
\begin{FileExample}[label=/etc/networks]
localnet 192.168.1.0
\end{FileExample}
\noindent il contenuto di questo file viene utilizzato da comandi come
\texttt{netstat} o \texttt{route} per mostrare i nomi simbolici al posto dei
valori numerici; si tenga conto però che con questo file viene supportata solo
la corrispondenza con reti espresse nella notazione tradizionale per classi di
tipo A, B o C, e che la notazione in formato CIDR non funziona.

Un altro file contenente corrispondenze fra valori numerici e nomi simbolici è
\index{configurazione!\texttt{/etc/protocols}} \texttt{/etc/protocols}, che
associa il numero usato per indicare all'interno dei pacchetti IP il
protocollo di trasporto usato nello strato successivo (si ricordi quanto detto
in sez.~\ref{sec:net_protocols}) ad un nome identificativo del protocollo
stesso (come TCP e UDP).

Il formato di questo file è identico a quello di \texttt{/etc/networks}; sono
supportati tre campi divisi da spazi, in cui il primo identifica il nome
simbolico, il secondo il valore numerico che identifica il protocollo ed il
terzo un alias.  Un esempio di questo file è il seguente (l'estratto è preso
da una Debian):
\begin{FileExample}[label=/etc/protocols]
...
ip      0       IP              # Internet protocol, pseudo protocol number
#hopopt 0       HOPOPT          # IPv6 Hop-by-Hop Option [RFC1883]
icmp    1       ICMP            # Internet control message protocol
igmp    2       IGMP            # Internet Group Management
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
egp     8       EGP             # exterior gateway protocol
igp     9       IGP             # any private interior gateway (Cisco)
pup     12      PUP             # PARC universal packet protocol
udp     17      UDP             # user datagram protocol
...
\end{FileExample}

Al solito le righe vuote e tutto quello che segue un carattere ``\texttt{\#}''
viene ignorato; come per tutti gli altri file analoghi la descrizione completa
del formato è riportata nella rispettiva pagina di manuale, accessibile con
\texttt{man protocols}.



\section{Altre tipologie di connessioni di rete}
\label{sec:net_PPP}

Finora abbiamo trattato delle configurazioni di rete facendo riferimento alla
casistica tipica di una rete locale basata sulle ordinarie schede Ethernet; in
questa sezione esamineremo invece la configurazione della rete per altre
tecnologie di connessione, come le interfacce punto-punto che si usano per
collegarsi tramite un modem o le interfacce \textit{wireless} che si usano per
collegarsi con un \textit{access-point}.


\subsection{Cenni sul protocollo PPP}
\label{sec:net_PPP_protocol}

\itindbeg{Point~to~Point~Protocol (PPP)}

Per le configurazioni di base illustrate in sez.~\ref{sec:net_config} abbiamo
sempre fatto riferimento al caso di una macchina inserita all'interno di una
rete locale, con il caso più comune dell'uso di schede Ethernet, per cui ad
una interfaccia non viene associato solo un indirizzo IP, ma anche una
maschera di rete.

In generale però questo non è vero, ed è infatti possibile collegarsi ad
Internet attraverso un modem, analogico o ADSL che sia.  In tal caso la
comunicazione verso l'esterno non avviene attraverso il passaggio per una rete
locale, ma direttamente con una macchina posta all'altro capo della
connessione, con quello che si chiama un collegamento \textsl{punto-punto}.

In sez.~\ref{sec:net_intro} abbiamo visto che esiste un apposito protocollo
del livello di collegamento fisico, il \textit{Point to Point Protocol}
(comunemente detto PPP) su cui è possibile innestare tutti i protocolli dei
livelli successivi.  Nel caso specifico PPP è un protocollo generico che
permette di inviare dati su diverse tipologie di collegamenti fisici,
mantenendo una stessa struttura generale, che consente di creare e gestire
connessioni punto-punto.

Il protocollo si compone di tre parti, un metodo generico per incapsulare dati
su un collegamento fisico, un protocollo estensibile per il controllo del
collegamento fisico (il \textit{Link Control Protocol} o LCP) ed una famiglia
di protocolli (il \textit{Network Control Protocols} o NCP) per stabilire e
configurare le connessioni coi protocolli di livello superiore.

In generale PPP fa riferimento ad un qualche meccanismo sottostante di
trasmissione (che sia un modem analogico, ISDN o ADSL) sopra il quale
costruisce uno strato ulteriore che gli permette di incapsulare i protocolli
di livello superiore. L'uso più tipico di questo protocollo è comunque quello
che viene fatto con i modem analogici o ADSL, per i quali permette di gestire
la creazione della connessione verso il fornitore del servizio di connessione
e la configurazione della relativa interfaccia.

\itindend{Point~to~Point~Protocol (PPP)}


\subsection{Il demone \texttt{pppd}}
\label{sec:net_pppd}

Delle tre parti illustrate in sez.~\ref{sec:net_PPP_protocol} di cui è
composto il protocollo PPP, l'incapsulazione dei dati è gestita direttamente
dal kernel. Il relativo supporto è abilitato di default in tutte le
distribuzioni, ed in genere da questo punto di vista non c'è da fare niente,
se non assicurarsi, qualora si sia ricompilato il proprio kernel (vedi
sez.~\ref{sec:kernel_compile}) di aver incluso quanto necessario nella sezione
\textit{Network device support}. Tutto il resto è affidato ad un apposito
demone, \index{demone!\texttt{pppd}} \texttt{pppd}, che si cura di fornire il
controllo del collegamento, l'autenticazione, e la parte dell'NCP che riguarda
la configurazione e la gestione del protocollo IP su PPP, compresa
l'impostazione di una interfaccia di rete e delle eventuali rotte ad essa
associate.

Il programma può essere lanciato direttamente dalla riga di comando
passandogli come argomenti le varie direttive che ne controllano il
comportamento, ma in genere l'invocazione avviene attraverso un opportuna
interfaccia che consente di passargli le opzioni di
configurazione.\footnote{abbiamo ad esempio accennato in
  sez.~\ref{sec:net_address_config} come con Debian questo possa essere fatto
  direttamente da \texttt{/etc/network/interfaces}.} Di default infatti, se
invocato senza nessun argomento, le direttive vengono lette all'avvio del
demone dal file \index{configurazione!\texttt{/etc/ppp/options}}
\texttt{/etc/ppp/options}. Le direttive, nella documentazione del programma,
vengono chiamate \textsl{opzioni}, qui le chiamiamo così per evitare
confusione con le normali opzioni dei comandi ordinari.

Alternativamente si può specificare un singolo argomento che indichi il
dispositivo da usare per la connessione. Questo deve essere indicato con il
relativo file di dispositivo, che in genere è la seriale a cui è agganciato il
modem, espresso in forma di pathname sia assoluto che relativo rispetto a
\texttt{/dev}. In questo caso le ulteriori direttive saranno lette dal file
\texttt{/etc/ppp/options.\textsl{ttyname}}, ed è così possibile scegliere
automaticamente configurazioni diverse per i diversi dispositivi; se ad
esempio si usa il comando:
\begin{Example}
pppd /dev/ttyS0
\end{Example}
le direttive saranno lette dal file \texttt{options.ttyS0}.

Inoltre può risultare utile consentire anche agli utenti normali di attivare
una connessione. In genere \texttt{pppd} è \textit{suid} per root ed
eseguibile per gli utenti che fanno parte di un opportuno gruppo (\texttt{dip}
nel caso di Debian). Per questo motivo è prevista una forma diversa di avvio
del demone eseguita utilizzando la direttiva \texttt{call} a cui far seguire
un nome che indichi il fornitore di servizi (il \textit{provider}) che si
vuole utilizzare.

In questa forma infatti l'uso del comando è consentito anche ad un utente
normale e le direttive saranno lette da un file con quel nome posto nella
directory \index{configurazione!\texttt{/etc/ppp/peers}}
\texttt{/etc/ppp/peers}.\footnote{che è anche il metodo usato da Debian per
  fare eseguire il comando all'avvio con \texttt{/etc/network/interfaces}.}
In realtà un utente potrebbe eseguire comunque il comando, nel qual caso esso
farebbe riferimento alle direttive presenti nel file \texttt{.ppprc} della sua
home, ma questo file non può contenere direttive privilegiate ed è pertanto
sottoposto a restrizioni che lo rendono poco pratico (per i dettagli si
consulti la pagina di manuale). Così se ad esempio
\texttt{/etc/ppp/peers/adsl} contiene le opzioni per chiamare il proprio
provider con un modem ADSL, potremo attivare la connessione con:
\begin{Example}
pppd call adsl
\end{Example}

Una volta lanciato \texttt{pppd} esegue le operazioni necessarie a stabilire
una connessione. Le modalità con cui questo avviene dipendono però dal tipo di
linea che si usa, ad esempio se si ha un modem analogico agganciato al
telefono occorrerà effettuare una chiamata telefonica ed ottenere la linea
prima che \texttt{pppd} possa entrare in azione. Essendo possibili diverse
modalità la eventuale preparazione della linea viene sempre delegata ad un
programma esterno con l'uso della direttiva \texttt{connect}; questa richiede
come argomento una riga di comando che verrà eseguita in una shell, fintanto
che il comando non sarà eseguito con successo, \texttt{pppd} non farà alcun
accesso alla linea.

Nel caso di collegamenti telefonici tramite modem analogico per la
preparazione della linea si fa normalmente ricorso all'uso del comando
\index{comando!\texttt{chat}} \texttt{chat}, ed un esempio possibile della sua
invocazione potrebbe essere tramite una direttiva del tipo:
\begin{Example}
connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
\end{Example}

In questo caso \texttt{chat} viene usato per dare le istruzioni al modem e
verificare la riuscita della chiamata. Le opzioni più importanti del comando
sono \texttt{-f} che permette di indicare un file che contiene le istruzioni
da eseguire, e \texttt{-v} che permette di registrare i risultati della
comunicazione a scopo di controllo. Il comando opera leggendo dal file
indicato (il cosiddetto ``\textsl{chat script}'') le istruzioni con le quali
gestire la comunicazione iniziale con il modem.

Uno script di chat è usualmente composto da una serie di coppie di valori, in
cui il primo valore indica quello che ci si attende di sentire dal dispositivo
ed il secondo quanto si deve scrivere in risposta.  Le coppie si scrivono
usualmente una per riga in due campi separati da spazi per maggiore
leggibilità ma si possono scrivere anche spezzate su più righe (nel qual caso
il ritorno a capo vale come separatore) o su una sola riga; questo comporta
che se si vuole aspettare o inviare un valore che contiene spazi occorrerà
esprimerlo scritto fra virgolette.  Alla ricezione del valore specificato nel
primo campo viene inviata la stringa indicata nel secondo,\footnote{il default
  è inviare la stringa seguita da un ritorno a capo, si può disabilitare
  questo comportamento aggiungendo il carattere di controllo ``\texttt{\bslash
    c}''.} in questo modo si può controllare il modem ed inviare comandi e
dati sulla linea in una specifica sequenza.

In realtà oltre alle normali coppie di valori di attesa/risposta, il comando
supporta anche alcune istruzioni chiave; ad esempio con \texttt{ABORT} usato
come valore di attesa si definiscono le condizioni in cui viene abortita la
connessione, specificate nel valore di risposta con altrettante parole chiave,
come \texttt{BUSY}, \texttt{VOICE}, \texttt{"NO DIALTONE"}, ecc. che valgono
indipendentemente dal momento in cui la condizione si va a verificare nella
sequenza delle istruzioni (per i valori possibili si consulti la pagina di
manuale).

Esistono inoltre delle sequenze di controllo, introdotte dalla solita barra
rovescia ``\texttt{\bslash}'', che consentono di inserire caratteri speciali
come il ritorno a capo, o, con l'espressione ``\texttt{\bslash T}'', un valore
arbitrario (in genere usato per indicare il numero di telefono), passato al
comando \texttt{chat} con l'opzione \texttt{-T}. Al solito per i dettagli
sulle opzioni e sulle altre istruzioni di controllo si consulti la pagina di
manuale.

Un esempio elementare di \textit{chat script}, estratto dal file
\texttt{/etc/chatscripts/pap} che viene distribuito con Debian Lenny, è il
seguente, dove si sono omesse le righe di commento, introdotte al solito dal
carattere ``\texttt{\#}'':
\begin{FileExample}[label=/etc/chatscripts/pap]
ABORT		BUSY
ABORT		VOICE
ABORT		"NO CARRIER"
ABORT		"NO DIALTONE"
ABORT		"NO DIAL TONE"
""		ATZ
OK		ATDT\T
CONNECT		""
\end{FileExample}

Si noti come dopo aver definito le varie condizioni di interruzione, si inizia
lo script non aspettandosi niente (questo il significato della stringa vuota
\verb|""|) a cui si risponde con il comando \texttt{ATZ} del
modem.\footnote{non tratteremo qui i cosiddetti \textsl{Comandi Hayes} (o
  comandi AT) usati dai modem per gestire le linee telefoniche, per un
  riferimento si consulti
  \url{http://en.wikipedia.org/wiki/Hayes_command_set}.} Alla risposta
\texttt{OK} si esegue il comando \texttt{ATDT}, che esegue la telefonata al
numero telefonico indicato con l'opzione \texttt{-T} di \texttt{chat}. L'uso
di \texttt{-T} è del tutto opzionale, si sarebbe potuto scrivere
esplicitamente il numero di telefono all'interno dello script di chat.  Alla
risposta \texttt{CONNECT} lo script finisce e il controllo passa direttamente
a \texttt{pppd} che a questo punto si suppone sia in grado di parlare con il
corrispettivo dall'altra parte.

Si tenga presente che uno script siffatto non è detto sia sempre corretto, ad
esempio alcuni provider richiedevano una procedura di login prima di attivare
il proprio demone \texttt{pppd} sull'altro capo della connessione, questo
poteva comportare la necessità di ulteriori linee come:
\begin{FileExample}[label=/etc/chatscripts/pap]
ogin: username
ssword: password
\end{FileExample}
in cui alla richiesta di \texttt{login:} viene inviato un username, ed alla
successiva richiesta di \texttt{password:} viene inviata la password. Si noti
come in quest'ultimo esempio a \texttt{chat} basti una corrispondenza parziale
nella richiesta per inviare una risposta; la ragione di tutto ciò origina nei
difetti presenti ai tempi delle prime connessioni via modem che talvolta
provocavano la perdita dei primi caratteri inviati; usando una corrispondenza
parziale la procedura poteva proseguire senza errori.

Oggi le connessioni via modem analogico sono sempre meno comuni, ma la
precedente trattazione resta valida per tutte le connessioni eseguite tramite
linee seriali, come quelle associate a varie schede di comunicazione GSM o
GPRS, o alle connessioni effettuate tramite emulazione di una seriale sul
collegamento \textit{bluetooth} al proprio cellulare.

La situazione è invece del tutto diversa se si ha a che fare con un modem
ADSL, in tal caso infatti non si dovrà affatto effettuare una telefonata o la
preparazione della linea, per cui non sarà più necessario invocare
\texttt{chat}. In questo caso la configurazione varia a seconda del tipo di
modem utilizzato e dal tipo di protocollo (principalmente PPPoA, più raro
PPPoE) ed i dettagli eccedono quanto sia possibile trattare qui.

Se la connessione viene stabilita regolarmente, il demone \texttt{pppd} si
incaricherà di creare una nuova interfaccia di comunicazione (il default è
l'uso di \texttt{ppp0}) associata alla connessione ed opportunamente
configurata in modalità punto-punto; si avrà cioè qualcosa del tipo:
\begin{Console}
anarres:~# \textbf{ifconfig} 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8890912 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8890912 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3729080730 (3.4 GiB)  TX bytes:3729080730 (3.4 GiB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:151.49.5.174  P-t-P:151.6.144.72  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:9178  Metric:1
          RX packets:73874097 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72996070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:1180778093 (1.0 GiB)  TX bytes:3882710341 (3.6 GiB)
\end{Console}

Se poi si è utilizzata la direttiva \texttt{defaultroute} il programma si
incaricherà anche di impostare automaticamente una rotta di default per far
passare dalla interfaccia il traffico diretto verso Internet,\footnote{come
  già spiegato in sez.~\ref{sec:net_route} la creazione di una rotta per
  l'altro capo della connessione punto-punto avviene automaticamente alla
  configurazione dell'interfaccia.} mentre con la direttiva
\texttt{usepeerdns} si richiede l'impostazione automatica dei DNS forniti dal
provider con la creazione automatica di un opportuno \texttt{resolv.conf}
all'attivazione del collegamento ed il ripristino del precedente alla sua
conclusione.

Inoltre tutte le volte che l'attivazione di un collegamento ha successo viene
lanciato lo script \texttt{/etc/ppp/ip-up} che si cura eseguire una serie di
azioni programmate relative alla presenza di una nuova connessione (ad esempio
far scaricare la posta). In generale questo script si limita ad eseguire tutti
gli script posti in \texttt{/etc/ppp/ip-up.d} con il comando
\texttt{run-parts} che abbiamo già visto in sez.~\ref{sec:crontab}. Allo
stesso modo, quando la connessione viene chiusa viene lanciato lo script
\texttt{/etc/ppp/ip-down} che esegue quelli presenti in
\texttt{/etc/ppp/ip-down.d}, dopo di che l'interfaccia di rete viene
disattivata.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Direttiva} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{call \textsl{name}}& usa le opzioni contenute nel file
                             \texttt{\textsl{name}} in
                             \texttt{/etc/ppp/peers}.\\ 
    \texttt{connect \textsl{script}}& usa lo script \texttt{\textsl{script}}
                             (di norma \texttt{chat}) per preimpostare la
                             linea.\\
    \texttt{crtscts}       & attiva il controllo di flusso hardware sulle porte
                             seriali.\\
    \texttt{defaultroute}  & aggiunge una rotta di default alla tabella di
                             instradamento usando l'indirizzo IP ricevuto sulla
                             connessione.\\ 
    \texttt{lock}          & crea un file di lock per la seriale.\\
    \texttt{demand}        & crea la connessione a richiesta quando vede del
                             traffico.\\
    \texttt{usepeerdns}    & chiede alla connessione gli indirizzi di due
                             server DNS, che vengono passati allo script 
                             \texttt{/etc/ppp/ip-up} nelle variabili di
                             ambiente \texttt{DNS1} e \texttt{DNS2} ed usati
                             per la creazione di un file \texttt{resolv.conf}
                             che li usi come server DNS.\\
    \texttt{debug}         & abilita il debugging, è utile per avere più
                             informazioni quando la connessione non funziona.\\
    \hline
  \end{tabular}
  \caption{Principali opzioni per il demone \texttt{pppd}.}
  \label{tab:net_pppd_options}
\end{table}

In tab.~\ref{tab:net_pppd_options} si sono riportate le direttive di
configurazione più significative di \texttt{pppd}, insieme ad una loro breve
descrizione. L'elenco completo, ed i dettagli relativi a ciascuna di esse sono
al solito disponibili nella pagina di manuale del comando, accessibile con
\texttt{man pppd}.


\subsection{I meccanismi di autenticazione}
\label{sec:net_pppd_authentication}

Al di là della possibile necessità di autenticarsi per l'accesso direttamente
sulla linea seriale (come mostrato nell'esempio riguardante \texttt{chat}) il
demone \texttt{pppd} prevede una sua procedura di autenticazione diretta,
disponibile quando stabilisce la comunicazione con il suo corrispettivo
all'altro lato della connessione. Questa autenticazione può avvenire secondo
due protocolli, il \textit{Password Authentication Protocol} (noto come PAP)
ed il \textit{Challenge Handshake Authentication Protocol} (noto come CHAP).

Il PAP è un protocollo più elementare e prevede che il client invii un
username ed una password in chiaro sulla linea; si è così esposti ad una
eventuale intercettazione telefonica. Il CHAP invece prevede l'invio da parte
del server di una \textsl{sfida} nella forma di un pacchetto che contiene il
nome del server, così che il client può rispondere con un pacchetto che
contenga un \textit{hash} crittografico del pacchetto di sfida cui si è
aggiunto il valore di un segreto condiviso (la password) così da comprovare la
conoscenza del segreto senza inviarlo sulla linea.

Le informazioni di autenticazione usate dal demone \texttt{pppd} per i due
protocolli vengono mantenute in due file, \texttt{/etc/ppp/pap-secrets} e
\texttt{/etc/ppp/chap-secrets}, che hanno lo stesso formato. Un esempio del
contenuto di uno questi file è il seguente:
\begin{FileExample}[label=/etc/ppp/pap-secrets]
# INBOUND connections
# UserIDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd!
guest   frijole "*"     -
master  frijole "*"     -
root    frijole "*"     -
support frijole "*"     -
stats   frijole "*"     -
# OUTBOUND connections
piccardi *       password
\end{FileExample}

Il file prevede quattro campi separati da spazi; il primo campo indica
l'username usato dal client, il secondo il nome del server, il terzo il
segreto condiviso, il quarto, opzionale, una lista degli IP da cui è possibile
effettuare il collegamento (un ``\texttt{-}'' indica nessun IP), si possono
indicare delle sotto-reti in notazione CIDR ed usare un ``\texttt{!}''
iniziale per negare la selezione.
 
I nomi di client e server possono contenere caratteri qualunque, ma gli spazi
e gli asterischi devono essere protetti scrivendoli fra virgolette; il valore
\texttt{"*"} indica un nome qualsiasi e fa da carattere jolly. Se il campo
della password inizia con il carattere ``\texttt{@}'' si indica che
quest'ultima deve essere letta dal file il cui nome è specificato dal resto
della stringa.

Dato che il collegamento è punto-punto il procedimento di autenticazione è
simmetrico: ogni demone può chiedere all'altro di autenticarsi; per questo i
file contengono sia le informazioni per essere autenticati presso gli altri
che per autenticarli.  Di norma però, a meno di non gestire un provider, si
deve solo essere autenticati, per questo il default è che \texttt{pppd} non
esegue richieste di autenticazione, ma si limita a rispondere a quelle che gli
vengono fatte.

% TODO uso di /etc/ppp/peers da utente normale e permessi pppd


\subsection{La connettività \textit{Wi-Fi}}
\label{sec:net_wireless}

Una delle tecnologie di rete con sempre maggiore diffusione, per il vantaggio
di non richiedere la presenza di una infrastruttura cablata per realizzare la
comunicazione, è quella legata alle tecnologie basate sulla trasmissione dati
via radio, che viene indicata in maniera generica come \textit{wireless}. In
realtà le tecnologie \textsl{senza fili} sono molte ma quella che tratteremo
in questa sezione e nelle successive è quella che viene più propriamente
indicata come \textit{Wi-Fi} (dal nome adottato dal relativo consorzio di
produttori) e che fa riferimento allo standard di comunicazione IEEE 802.11
nelle sue numerose varianti.

A differenza di quanto visto per PPP in questo caso si tratta, come si può
capire dall'uso di uno standard della stessa famiglia di quello delle
classiche reti Ethernet cablate, di una tecnologia pensata per la
realizzazione di reti locali; pertanto molti dei concetti già visti per quel
protocollo di collegamento fisico (come il \textit{MAC address}) si applicano
anche a queste tecnologie.

La maggiore differenza con Ethernet in questo caso, a parte l'assenza di
connessioni via cavo, è che il protocollo prevede a livello di collegamento
fisico dei meccanismi di autenticazione e di cifratura dei dati, onde impedire
che chiunque possa collegarsi ad una rete \textit{wireless} altrui o leggerne
i dati. Inoltre fa sempre parte del protocollo il supporto per creare e
gestire una rete locale senza fili (quella che si suole chiamare una
\textit{Wireless LAN} o WLAN) in cui le macchine comunicano fra loro
utilizzando un opportuno \textsl{punto di accesso}.

Nell'uso effettivo una rete \textit{Wi-Fi} presenta poi anche delle altre
differenze più sottili rispetto ad una Ethernet ordinaria, come ad esempio il
fatto che, non essendovi una connessione diretta fra tutte le macchine che ne
fanno parte, si possono avere situazioni in cui una macchina ne vede altre
due, ma queste non si vedono fra di loro. Inoltre la tecnologia supporta
diverse modalità operative, compresa la possibilità di connessioni dirette fra
macchine senza dover creare una vera rete locale.

\itindbeg{access~point}
Per tutti questi motivi quando si ha a disposizione una scheda di rete
\textit{Wi-Fi} la semplice assegnazione di un indirizzo, come si farebbe per
una scheda Ethernet non è sufficiente. In genere infatti una rete WLAN è
gestita grazie all'uso di uno o più dispositivi che ne curano l'assemblaggio,
detti \textit{access point} (o in breve AP) dato che appunto svolgono il ruolo
di \textsl{punti di accesso} alla rete stessa.

In questo caso si tratta di apparati specifici, spesso dotati anche di
connessione Ethernet, il cui ruolo può essere sia quello di fare da
\textsl{ponte} fra la rete \textit{Wi-Fi} e quella Ethernet,\footnote{proprio
  nel senso di un \textit{bridge} analogo a quello con cui si possono unire
  due tratti di rete Ethernet.} sia quello di fornire il supporto per la
creazione di una WLAN estesa in cui le singole macchine possono collegarsi per
poi comunicare fra loro (anche quando le loro interfacce non siano in grado di
vedersi direttamente) con la capacità ulteriore di gestire il cosiddetto
\textit{roaming}, in cui una macchina opera sulla stessa WLAN passando da un
\textit{access point} all'altro, per poter coprire una area più vasta.
\itindend{access~point}

Per poter entrare nella rete, e comunicare poi con le altre macchine che ne
fanno parte, è in genere necessario prima collegarsi, o meglio, per usare il
gergo utilizzato dal protocollo, \textsl{associarsi}. Vedremo che questo
comporta una serie di passi, fra cui è prevista la scelta della rete
(trattandosi di onde radio possono sussistere reti diverse nello stesso
spazio), delle modalità di collegamento e delle eventuali restrizioni di
accesso.

Dato che per la natura stessa delle trasmissioni radio più \textit{access
  point} possono essere raggiungibili da una stessa interfaccia, ciascuna rete
\textit{Wi-Fi} viene identificata da un opportuno identificativo denominato
\itindex{Extended Service Set ID (ESSID)} ESSID (\textit{Extended Service Set
  ID}), una stringa alfanumerica che la distingue dalle altre presenti nello
stesso spazio e che in genere viene impostata sull'\textit{access point} (o
sugli \textit{access point}, se si costruisce una rete con più celle) che la
gestiscono.

Uno dei passi che consente l'uso di una rete \textit{Wi-Fi} è proprio quello
relativo alla impostazione su una interfaccia di questo valore, che consente
di scegliere a quale, fra le eventuali reti disponibili, ci si vuole
\textsl{associare}. In questo caso una interfaccia di rete \textit{Wi-Fi} deve
essere configurata per operare nel cosiddetto \textit{infrastructure mode},
cioè in una modalità operativa in cui essa diventa parte di una WLAN.  In
realtà questa modalità può essere usata in due modi diversi, o come
\textit{server} che fornisce un punto di accesso (il cosiddetto \textit{AP
  infrastructure mode} o \textit{manager mode}),\footnote{in questo caso si
  vuole fare da \textit{access point}, cosa che, se la propria interfaccia di
  rete supporta questa modalità, è sempre possibile anche se occorre usare del
  software aggiuntivo, \texttt{hostapd}, che fornisca i servizi necessari alla
  gestione di una WLAN.} o come macchina \textit{client} che fa parte della
rete (il cosiddetto \textit{station infrastructure mode} o \textit{managed
  mode}). Quest'ultimo che è il caso più comune, quello in cui ci si vuole
collegare ad un rete messa a disposizione da altri.

Oltre a questa, che è la più comune, esistono altre modalità di uso di una
rete \textit{Wi-Fi}; ad esempio si può utilizzare l'\textit{ad-hoc mode} per
creare una connessione fra diverse schede quando non sia disponibile un
\textit{access-point}; in questo caso ciascuna macchina diventa responsabile
di gestire la propria rete, e non esiste un \textit{access point} che la
governa. Una ulteriore modalità di utilizzo di una scheda \textit{Wi-Fi} è il
cosiddetto \textit{monitor mode}, usato per leggere in maniera passiva (cioè
senza trasmettere nulla) i pacchetti che vengono ricevuti, e che in genere
viene utilizzato per analizzare il traffico.


\subsection{I \textit{wireless tool} di Linux}
\label{sec:wifi_wireless_tool}

Uno dei problemi maggiori nella gestione delle interfacce \textit{wireless} è
quello della loro estrema varietà e della complessità dei meccanismi necessari
al loro funzionamento. Sono state infatti realizzate diverse varianti dello
stesso standard IEEE 802.11, anche incompatibili fra di loro per frequenze
radio o modalità operative. Inoltre sono disponibili diversi meccanismi di
autenticazione e cifratura, anche perché quelli introdotti con la prima
versione dello standard si sono dimostrati del tutto inefficaci e facilmente
vulnerabili.

Questo ha comportato anche una discreta confusione anche nelle diverse
realizzazioni del supporto fornito dal kernel per queste tecnologie, con
implementazioni concorrenti delle varie parti dei protocolli a seconda del
tipo di scheda, ed un proliferare di soluzioni ad hoc, a cui si aggiungono le
problematiche dovute al fatto che non tutte le schede sono in grado di
supportare tutte le modalità operative in maniera nativa.  Da alcuni anni è
comunque in corso una ristrutturazione completa,\footnote{l'evoluzione del
  supporto del kernel per le tecnologie \textit{Wi-Fi} è molto complesso e non
  staremo a percorrerlo, basti sapere che al momento queste sono state
  suddivise in tre sezioni distinte, la nuova interfaccia di configurazione
  delle schede interna al kernel, denominata \textit{cfg80211}, la nuova
  interfaccia di configurazione verso le applicazioni in \textit{user-space},
  denominata \textit{nl80211}, e l'interfaccia per la delegazione di alcune
  funzionalità di gestione a programmi in \textit{user-space}, denominata
  \textit{mac80211}. } con la creazione di una infrastruttura univoca per
tutto quello che non riguarda la gestione fisica del dispositivo.

Benché nella ristrutturazione del supporto per le reti \textit{Wi-Fi} sia in
corso una anche transizione verso nuovi strumenti di
amministrazione,\footnote{questi sono realizzati attraverso un nuovo comando
  generico, \texttt{iw}, che consente di configurare i vari aspetti tramite
  altrettanti sotto-comandi in analogia al comando \texttt{ip} di
  sez.~\ref{sec:net_adv_config}.} la loro diffusione comunque è ancora
limitata, per cui tratteremo solo l'interfaccia classica delle cosiddette
\textit{Wireless Extension} e dei relativi \textit{wireless-tools}, che resta
tutt'ora supportata da tutte le schede anche se non viene più ulteriormente
sviluppata.

Il primo comando fornito dai \textit{wireless-tools} è
\index{comando!\texttt{iwconfig}} \texttt{iwconfig}, che consente di
effettuare le impostazioni di una interfaccia di rete per quanto riguarda i
parametri specifici di una rete \textit{wireless}. Il comando ha una sintassi
simile a quella di \texttt{ifconfig} e richiede come primo argomento il nome
di una interfaccia di rete. Se invocato senza altri argomenti stampa le
caratteristiche di quella interfaccia o la stringa \textit{no wireless
  extension} se questa non è una interfaccia di rete \textit{wireless}. Si può
invocare il comando anche senza nessun argomento nel qual caso stamperà le
caratteristiche di tutte le interfacce di rete presenti. Un esempio tipico di
questo comando è:
\begin{Console}
anarres:~# \textbf{iwconfig} 
lo        no wireless extensions.

eth0      no wireless extensions.

eth1      IEEE 802.11b  ESSID:"Laneed"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:90:FE:72:4D:87   
          Bit Rate:11 Mb/s   Sensitivity:1/0  
          Retry limit:8   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=40/70  Signal level=-62 dBm  Noise level=-98 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:239715
          Tx excessive retries:202  Invalid misc:0   Missed beacon:0
\end{Console}
in cui si può notare come le prime due interfacce di rete (il
\textit{loopback} ed una scheda Ethernet ordinaria) non hanno supporto
\textit{wireless}, mentre la seconda scheda ha il supporto per la versione
\textit{IEEE 802.11b} del protocollo.

Il comando, oltre alla versione del protocollo, stampa il valore dell'ESSID a
cui la scheda è associata, a questo seguono altre informazioni, come il modo
(nel caso specifico \textit{Managed}, si ricordi quanto appena detto in
sez.~\ref{sec:net_wireless}) la frequenza del canale usato ed il \textit{MAC
  Address} dell'\textit{access point} e tutta una serie di ulteriori
informazioni, fra cui è sempre opportuno tenere sotto controllo quelle
relative alla qualità del segnale, riportate sulla settima riga, dato che se
questa cala eccessivamente si potrà perdere la connessione, o avere grossi
problemi di traffico.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Parametro} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{essid}  & imposta il valore dell'ESSID, prende una stringa o il
                      valore speciale \texttt{any} che su alcune schede
                      consente di utilizzare qualunque ESSID (il cosiddetto
                      ESSID promiscuo).\\
    \texttt{mode}   & imposta la modalità operativa dell'interfaccia, i valori
                      possibili sono: \texttt{Managed}, nodo connesso ad una
                      rete di \textit{access point}; \texttt{Ad-Hoc}, rete
                      senza \textit{access point} e con una sola cella;
                      \texttt{Master} nodo che agisce come \textit{access
                        point}; \texttt{Repeater}, nodo che agisce come
                      ripetitore di pacchetti; \texttt{Secondary}, nodo che
                      agisce come ripetitore o \textit{access point} di
                      backup; \texttt{Monitor}, nodo non associato a nessuna
                      rete che ascolta passivamente. \\
    \texttt{rate}   & per le schede che supportano diverse velocità di
                      trasmissione imposta quella da usare (espressa in forma
                      bit al secondo o in automatico con \texttt{auto}).\\
    \texttt{key}    & imposta le chiavi di cifratura, espresse in forma
                      esadecimale: indicando solo la chiave questa diventerà
                      quella attiva, altrimenti si può appendervi un indice
                      numerico fra parentesi quadre (\texttt{[N]}) per
                      memorizzarla; indicando solo l'indice si rende la
                      relativa chiave attiva, indicando \texttt{open} si
                      consente l'uso di sessioni non cifrate, mentre
                      aggiungendo \texttt{restricted} si richiede l'uso di
                      sole sessioni cifrate.\\
%    \texttt{enc}    & .\\
    \texttt{freq}   & imposta la frequenza di trasmissione fra quelle
                      disponibili (alternativa a \texttt{channel}).\\
    \texttt{channel}& imposta il canale di trasmissione fra quelli disponibili
                       (alternativa a \texttt{freq}).\\
%    \texttt{} & .\\
    \hline
  \end{tabular}
  \caption{Principali parametri operativi impostabili con \texttt{iwconfig}.}
  \label{tab:iwconfig_interface_parameters}
\end{table}

Oltre alla stampa dello stato di una interfaccia, il comando consente anche di
impostare i vari parametri funzionali della stessa, in questo caso deve essere
specificato come primo argomento il nome dell'interfaccia seguito dal nome del
parametro e dal relativo valore come ultimo argomento. Ad esempio col
parametro \texttt{essid} si imposta l'ESSID della rete a cui si vuole che la
scheda si associ, mentre con \texttt{mode} si imposta la sua modalità
operativa. Si sono riportati in tab.~\ref{tab:iwconfig_interface_parameters} i
parametri più rilevanti, per una trattazione completa si consulti la pagina di
manuale.

Oltre a \texttt{iwconfig} i \textit{wireless-tools} forniscono un secondo
comando, \index{comando!\texttt{iwlist}} \texttt{iwlist}, che viene utilizzato
per ottenere informazioni relative all'interfaccia ed alla rete. Il comando
richiede in genere come primo argomento l'interfaccia da usare (ma se non
specificato le prova tutte) seguita dalla operazione da eseguire. Ad esempio
con \texttt{scanning} si può ottenere la lista degli \textit{access point} e
delle celle \textit{ad-hoc} raggiungibili dall'interfaccia, con le relative
informazioni, come ESSID, frequenze/canali utilizzati, qualità del segnale
ecc.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Argomento} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{scan} & esegue una scansione per la ricerca delle reti
                    \textit{Wi-Fi} raggiungibili e riporta le relative
                    informazioni.\\
    \texttt{freq} & stampa la lista delle frequenze di trasmissione
                    disponibili e dei relativi canali associati.\\
    \texttt{chan} & come \texttt{freq}.\\
    \texttt{keys} & elenca le chiavi di cifratura impostate sul dispositivo.\\
%    \texttt{} & .\\
    \hline
  \end{tabular}
  \caption{Principali argomenti di \texttt{iwlist}.}
  \label{tab:iwlist_argument}
\end{table}

Si è riportato in tab.~\ref{tab:iwlist_argument} un elenco delle principali
richieste eseguibili con \texttt{iwlist}, ma al solito per tutti i dettagli e
l'elenco completo si consulti la relativa pagina di manuale.



\section{I comandi diagnostici}
\label{sec:net_diagnostic}

Una volta eseguita la configurazione di base della rete in genere è opportuno
controllarne il funzionamento, cosa che può essere fatta utilizzando un
qualunque programma che usa un servizio di rete (il modo più comune è lanciare
un browser). In caso di malfunzionamento, o comunque per eseguire controlli
più approfonditi, sono disponibili i comandi che tratteremo in questa sezione,
che possono essere utilizzati per verificare il buon funzionamento della rete
nei suoi vari aspetti.


\subsection{Il comando \texttt{ping}}
\label{sec:net_ping}

Una volta configurate le interfacce di rete in genere il primo controllo che
si va ad effettuare per vedere se la rete funziona è quello di
``\textsl{pingare}'' (orribile inglesismo di cui non sono riuscito a trovare
una traduzione) un'altra macchina. Il nome e la terminologia derivano
dall'analogia con gli impulsi sonori usati dai \textit{sonar} ma nella nostra
analogia telefonica potremmo dire che questo equivale a telefonare ad un
numero per sentire se dà la linea.

Il comando \index{comando!\texttt{ping}} \texttt{ping} permette di inviare un
pacchetto ICMP (abbiamo accennato a questo protocollo in
sez.~\ref{sec:net_intro}) di tipo \textit{echo request}. Il protocollo IP
prevede che la macchina che riceve un pacchetto di questo tipo debba
rispondere con l'emissione di un altro pacchetto ICMP, di tipo \textit{echo
  reply} che \texttt{ping} si incaricherà di ricevere, mostrando anche il
tempo intercorso fra l'invio e la risposta.

Il comando si invoca in genere passando come argomento l'indirizzo IP della
macchina bersaglio. Si può usare anche il nome simbolico, ma in tal caso
oltre al collegamento verso la macchina bersaglio deve funzionare anche la
risoluzione dei nomi, cosa che in genere richiede la raggiungibilità del
server DNS,\footnote{in realtà si può usare anche il nome pure in assenza di
  DNS, ma esso deve essere scritto in \texttt{/etc/hosts} (vedi
  sez.~\ref{sec:net_hosts}) o risolvibile altrimenti.} e se per un qualche
motivo questo non fosse raggiungibile (o fosse lui a non funzionare) non si
otterrebbe nessuna risposta anche con il resto della rete a posto. Un esempio
dell'uso di \texttt{ping} è il seguente:
\begin{Console}
piccardi@havnor:~$ \textbf{ping 192.168.168.10}
PING 192.168.168.20 (192.168.168.20): 56 data bytes
64 bytes from 192.168.168.20: icmp_seq=0 ttl=255 time=0.7 ms
64 bytes from 192.168.168.20: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 192.168.168.20: icmp_seq=2 ttl=255 time=0.3 ms

--- 192.168.168.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.4/0.7 ms
\end{Console}
%$

Il comando invia un pacchetto al secondo; nell'esempio riceve sempre risposta,
e riporta quindi il tempo che è intercorso fra l'invio e la ricezione. Quando
viene fermato (nel caso dell'esempio con \texttt{C-c}) stampa anche una
statistica riassuntiva.  L'esempio ci mostra che la macchina con IP
\texttt{192.168.168.10} è attiva ed è raggiungibile. Il comando prende una
serie di opzioni, le principali delle quali sono riportate in
tab.~\ref{tab:net_ping_option} insieme al loro significato; per un elenco
completo si può fare riferimento alla pagina di manuale.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-c \textsl{count}} & invia solo \texttt{\textsl{count}} pacchetti
                          e poi esce stampando la statistica senza bisogno di
                          interruzione esplicita.\\
    \texttt{-f}         & invia i pacchetti alla velocità con cui tornano
                          indietro, o 100 al secondo, stampando un 
                          ``\texttt{.}'' per ogni pacchetto inviato ed un
                          backspace per ogni pacchetto ricevuto, così da
                          visualizzare le perdite; solo l'amministratore può
                          usare questa opzione che carica pesantemente la
                          rete.\\ 
    \texttt{-i \textsl{wait}}& aspetta \texttt{\textsl{wait}} secondi invece
                          di uno fra l'invio di un pacchetto ed il
                          successivo.\\
    \texttt{-n}         & non effettua la risoluzione di nomi e indirizzi.\\
    \texttt{-p \textsl{pattern}} & si possono specificare fino a 16 byte con
                          cui riempire il \textsl{carico} del pacchetto. Il
                          valore \texttt{\textsl{pattern}} deve essere
                          specificato come numero esadecimale. Si usa questa
                          opzione per diagnosticare eventuali problemi di
                          corruzione dei dati.\\
    \texttt{-q}         & sopprime tutte le stampe eccetto le statistiche
                          finali.\\
    \texttt{-s \textsl{size}}& invia pacchetti di dimensione \texttt{size}
                          invece dei 56 byte usati per default.\\
    \hline
  \end{tabular}
  \caption{Principali opzioni del comando \texttt{ping}.}
  \label{tab:net_ping_option}
\end{table}

Si tenga presente comunque che quello che si può effettuare con \texttt{ping}
è solo un controllo preliminare, se non si riceve risposta il motivo può
dipendere da moltissimi fattori: da un errore di configurazione, dall'aver
usato un indirizzo IP sbagliato, dalla non risposta della macchina che si
vuole controllare (ad esempio potrebbe essere spenta), da una mancanza di
connessione sulla rete, dal fatto che uno dei \textit{router} che devono
inoltrare i pacchetti per raggiungere la destinazione può avere un
malfunzionamento.  Se però va tutto bene se non altro si può concludere che la
rete è attiva e funzionante ed evitare di controllare se il cavo è attaccato.


\subsection{I comandi \texttt{traceroute}, \texttt{tracepath} e \texttt{mtr}}
\label{sec:net_traceroute}

Un secondo comando molto utile per controllare il funzionamento di un
collegamento sulla rete è \index{comando!\texttt{traceroute}}
\texttt{traceroute}, che serve, come dice il nome, a tracciare la strada che
fanno i pacchetti per arrivare ad una destinazione su Internet.

Il comando sfrutta una caratteristica del protocollo IP che prevede, nelle
informazioni associate a ciascun pacchetto, un campo chiamato TTL che viene
decrementato ogni volta che il pacchetto attraversa un \textit{router} (in
quello che in gergo viene chiamato un \textit{hop}). Quando il valore si
annulla il protocollo richiede che il \textit{router} scarti il pacchetto ed
invii un messaggio ICMP (di tipo \textit{time exceeded}) al mittente, per
evitare che i pacchetti persi nei cosiddetti \textit{routing loop} continuino
a circolare sulla rete, con spreco di banda.

Di default \texttt{traceroute} invia una serie di pacchetti UDP con TTL
crescente a partire da 1, così da ricevere un ICMP \textit{time exceeded} da
ogni \textit{router} attraversato per giungere a destinazione. In questo modo
si può tracciare tutta la strada fatta da un pacchetto guardando gli indirizzi
da cui arrivano queste risposte. Il default del comando è di inviare tre
pacchetti sonda per ogni valore progressivo del TTL ed aspettare una risposta
fino a 5 secondi. Un esempio del suo utilizzo è il seguente:
\begin{Console}
gil:~# \textbf{traceroute www.debian.it}
traceroute to www.debian.it (213.254.12.146), 30 hops max, 40 byte packets
 1  vl12.core1.net.playnet.it (62.48.34.7)  0.908 ms  0.852 ms  1.065 ms
 2  vl26.mix.net.playnet.it (62.48.45.255)  7.808 ms  7.800 ms  7.788 ms
 3  g-2-5.gw-border.uli.it (62.212.3.113)  7.723 ms  7.745 ms  7.734 ms
 4  f0-1.gw-mix.uli.it (62.212.3.126)  11.920 ms  11.923 ms  11.912 ms
 5  itgate.mix-it.net (217.29.66.65)  7.672 ms  7.663 ms  7.650 ms
 6  213.254.31.245 (213.254.31.245)  16.320 ms  15.637 ms  15.605 ms
 7  213.254.0.13 (213.254.0.13)  13.045 ms  12.159 ms  12.145 ms
 8  picard.linux.it (213.254.12.146)  16.342 ms  16.342 ms  16.335 ms
\end{Console}

Il comando stampa la strada fatta dai pacchetti per arrivare a destinazione,
riportando in ordine progressivo per numero di \textit{hop} l'indirizzo IP (ed
il nome, se risolto) di ciascun \textit{router} attraversato, seguito dai
tempi di risposta per i tre pacchetti inviati. Si tenga presente che è normale
avere rotte diverse, specie in caso di linee ridondate, per cui per un certo
\textit{hop} si possono ricevere risposte da \textit{router} diversi, che
verranno elencati sulla stessa linea.

Il comando risulta particolarmente utile quando si è appurato che la propria
rete funziona almeno a livello di collegamento locale, ma non si riesce a
raggiungere un qualche indirizzo su Internet. Esso infatti consente di
verificare se il problema può essere imputato al fatto che la strada che
prendono i pacchetti in uscita è interrotta o se si sono formati dei
\textit{routing loop}, cioè situazioni in cui, per un qualche errore di
configurazione, i pacchetti vengono reinviati in cerchio attraverso una serie
di \textit{router} senza poter mai arrivare a destinazione; in tal caso
infatti si osserverà il ripetersi della presenza di questi \textit{router}
nell'output di \texttt{traceroute}.

Si tenga presente però che il fatto che non si riceva risposta dalla
destinazione finale non comporta necessariamente che questa sia
irraggiungibile, è infatti un caso comune avere dei firewall lungo il percorso
che possono bloccare o scartare i pacchetti UDP inviati dal comando. In tal
caso, quando per un certo \textit{hop} non viene ricevuta una risposta, il
comando stampa una serie di asterischi. Il comando inoltre si ferma soltanto
quando riceve una risposta dalla destinazione finale, che può riconoscere
perché in tal caso, proprio per distinguerlo dalla scadenza durante il
percorso, il codice del pacchetto ICMP \textit{time exceeded} è diverso. Se
anche la destinazione finale non dovesse rispondere, il comando prosegue a
cercare la strada fino ad un numero massimo di 30 \textit{hop}, un default che
può essere cambiato con l'opzione \texttt{-m}.

Per cercare di superare questo tipo di difficoltà è possibile richiedere a
\texttt{traceroute} l'uso di pacchetti di tipo diverso, ad esempio con
l'opzione \texttt{-I} si può richiedere l'uso di pacchetti ICMP (come quelli
di \texttt{ping}) mentre per le versioni più recenti si può invocare il
comando come \texttt{tcptraceroute} o con l'opzione \texttt{-T} per fargli
eseguire le richieste con pacchetti TCP.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-i \textsl{iface}}&invia i pacchetti con l'indirizzo
                               dell'interfaccia \texttt{\textsl{iface}}; ha
                               senso solo quando ci sono più indirizzi sulla
                               stessa macchina.\\
    \texttt{-I} & invia pacchetti ICMP invece che UDP.\\
    \texttt{-l} & stampa anche il TTL dei pacchetti ricevuti come risposta,
                  utile per verificare la presenza di un \textit{routing}
                  asimmetrico.\\
%    \texttt{-f first}  & imposta il valore del TTL del primo pacchetto.\\
    \texttt{-m \textsl{N}}&    imposta a \texttt{\textsl{N}} il valore massimo
                               del TTL usato (il default è di 30 hop). \\
    \texttt{-n} & non effettua la risoluzioni di nomi e indirizzi.\\
    \texttt{-p \textsl{port}}& specifica una diversa porta iniziale (al posto
                               del default di 33434).\footnotemark \\
    \texttt{-s \textsl{source}}&usa l'indirizzo \texttt{\textsl{source}} come
                               indirizzo sorgente dei pacchetti inviati.\\
    \texttt{-T} & invia pacchetti TCP invece che UDP.\\
    \texttt{-w \textsl{time}}& imposta il numero di secondi
                               \texttt{\textsl{time}} da attendere per
                               ricevere una risposta.\\
    \hline
  \end{tabular}
  \caption{Opzioni principali del comando \texttt{traceroute}.}
  \label{tab:net_traceroute_option}
\end{table}

\footnotetext{il valore viene usato come numero di porta di destinazione solo
  per TCP ed UDP mentre per ICMP indica il numero di sequenza; per UDP (il
  default) viene usata normalmente la porta 33434 per il primo \textit{hop} ed
  il numero viene incrementato di uno per ogni \textit{hop} successivo, mentre
  per il TCP viene usata la porta 80, i dettagli sulle modalità di controllo
  avanzate dei pacchetti sonda inviati si trovano sulla pagina di manuale.}

Il comando richiede sempre come argomento l'indirizzo (numerico o simbolico)
di cui si vuole tracciare la rotta, ed opzionalmente la dimensione dei
pacchetti da usare; oltre a quelle citate supporta altre numerose opzioni, che
permettono di impostare varie caratteristiche dei pacchetti sonda inviati e
delle modalità di risposta. Al solito si sono riportate le più significative
in tab.~\ref{tab:net_traceroute_option}; per le restanti si faccia riferimento
alla pagina di manuale.

Una alternativa a \texttt{traceroute} è
\index{comando!\texttt{tracepath}}\texttt{tracepath}, che effettua lo stesso
tipo di controllo, anche se con un numero molto inferiore di opzioni. Il
comando di nuovo richiede come argomento l'indirizzo IP (o il nome) della
macchina di destinazione e traccia la strada dei pacchetti. Si può usare
l'opzione \texttt{-n} per impedire la risoluzione inversa degli indirizzi IP e
si può specificare come secondo argomento la porta da utilizzare per i
pacchetti sonda; per tutti i dettagli sul funzionamento si consulti al solito
la pagina di manuale.

A differenza di \texttt{traceroute}, \texttt{tracepath} consente di utilizzare
soltanto pacchetti sonda UDP, ma oltre all'indirizzo dei \textit{router}
attraversati ed ai tempi di risposta, stampa anche le eventuali variazioni di
MTU (\textit{Maximum Transfer Unit}) trovate sulla rotta. Un esempio del suo
utilizzo è il seguente:
\begin{Console}
gil:~# \textbf{tracepath www.debian.it}
 1:  gil.truelite.it (62.48.34.24)                          0.185ms pmtu 1500
 1:  vl12-gw.sw100.net.playnet.it (62.48.34.1)              2.721ms 
 1:  vl12-gw.sw100.net.playnet.it (62.48.34.1)              2.184ms 
 2:  po2-24.asr2.playnet.it (62.48.45.102)                  0.722ms 
 3:  vl27.mix.net.playnet.it (62.48.45.251)                10.717ms 
 4:  g-2-5.gw-border.uli.it (62.212.3.113)                 10.747ms 
 5:  f0-1.gw-mix.uli.it (62.212.3.126)                      9.968ms 
 6:  itgate.mix-it.net (217.29.66.65)                      11.172ms 
 7:  po1.Rumba-Monster.edge.TRN.itgate.net (213.254.0.19)  13.707ms asymm  8 
 8:  213.254.12.157 (213.254.12.157)                       13.953ms 
 9:  picard.linux.it (213.254.12.146)                      12.446ms reached
     Resume: pmtu 1500 hops 9 back 57 
\end{Console}


La conoscenza di questo valore può essere molto utile per diagnosticare
problemi sulla rete, infatti, come accennato in sez.~\ref{sec:net_ifconfig},
ogni tecnologia di rete supporta una dimensione massima dei pacchetti che
possono attraversarla, e la sua conoscenza è di fondamentale importanza nel
\textit{routing} dei pacchetti perché questi non possono essere trasmessi se
eccedono questa dimensione.\footnote{per questo motivo il protocollo TCP/IP
  prevede opportune contromisure e meccanismi per determinare automaticamente
  il valore della \textit{Path MTU} di una connessione, per maggiori dettagli
  si consultino le sezioni 3.2.3 e 3.4.4 di \cite{SGL} e 12.3.5 di
  \cite{GaPiL}.}

Se per un qualche problema l'impostazione dei valori della MTU da usare per
arrivare a destinazione (la cosiddetta \textit{Path MTU}) non viene rilevata
correttamente, ci si può trovare di fronte a malfunzionamenti della rete
difficilmente comprensibili in cui questa pare funzionare a tratti (cioè
fintanto che non si inviano o richiedono pacchetti di dimensione superiore
alla \textit{Path MTU}) per poi bloccarsi in maniera apparentemente casuale.

\begin{figure}[!htb]
\centering
\includegraphics[scale=0.5]{images/mtr1}
\caption{Schermata dei risultati del comando \texttt{mtr}.}
\label{fig:net_mtr}
\end{figure}

Esiste infine un terzo programma, \index{comando!\texttt{mtr}} \texttt{mtr},
analogo di \texttt{traceroute} e \texttt{tracepath} ma disponibile anche in
versione con interfaccia grafica, che consente di mostrare dinamicamente lo
stato della strada percorsa dai pacchetti, fornendo allo stesso tempo una
serie di statistiche relative al loro inoltro, unificando in sostanza le
funzionalità dei due comandi e di \texttt{ping}.

Il comando prende come argomento l'indirizzo numerico o simbolico della
macchina da tracciare, ed invia una serie continua di pacchetti ICMP di tipo
\textit{echo request} con TTL crescente, così può misurare sia il tempo di
percorrenza che la strada seguita. Inoltre il comando, a meno di non averne
preimpostato un numero specifico con l'opzione \texttt{-c}, esegue
indefinitamente la ripetizione dell'invio dei pacchetti, raccogliendo e
stampando in tempo reale una serie di statistiche relative alla rotta da esso
tracciata. In questo caso si potrà terminare il programma con la solita
interruzione (con \texttt{C-c}) o premendo il tasto ``\texttt{q}''.

Un esempio dell'uscita del programma, invocato in modalità testo con l'opzione
\texttt{-t}, è riportato in fig.~\ref{fig:net_mtr}, le colonne mostrano le
macchine attraversate (la cui risoluzione avviene in tempo reale), la
percentuale di perdita dei pacchetti su ciascun tratto, e le statistiche sui
tempi di trasmissione rilevati. Le opzioni principali di \texttt{mtr} sono
riportate in tab.~\ref{tab:net_mtr_option}, per l'elenco completo si consulti
la pagina di manuale.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-a \textsl{addr}}& usa l'indirizzo \texttt{\textsl{addr}} per
                               forzare l'invio dei pacchetti in uscita sulla
                               relativa interfaccia.\\
    \texttt{-c \textsl{count}}&ripete \texttt{\textsl{count}} cicli di invio e
                               poi termina automaticamente (senza \texttt{-r}
                               però la schermata con i risultati viene
                               cancellata alla terminazione del programma).\\
    \texttt{-i \textsl{time}}& imposta un numero di secondi \texttt{time} da 
                               far passare fra un invio ed il successivo (il
                               default è 1).\\
    \texttt{-n} & non effettua la risoluzioni di nomi e indirizzi.\\
    \texttt{-r} & abbinato a \texttt{-c} stampa la statistica finale
                  dei risultati ottenuti alla fine dei cicli.\\
    \texttt{-t} & forza l'uso dell'interfaccia testuale.\\
    \texttt{-u} & invia pacchetti UDP invece che ICMP.\\
    \hline
  \end{tabular}
  \caption{Opzioni principali del comando \texttt{mtr}.}
  \label{tab:net_mtr_option}
\end{table}


Il grande vantaggio di \texttt{mtr} è che fornisce un monitoraggio continuo
dello stato della linea, e consente così, in particolar modo grazie alla
presenza dell'ordinamento dei tempi di attraversamento dei vari
\textit{router} e alla statistica dei pacchetti perduti, di identificare quali
sono i tratti più problematici del traffico verso una certa macchina.


\subsection{Il comando \texttt{netstat}}
\label{sec:net_netstat}

Un altro utile comando diagnostico, che permette di visualizzare una grande
quantità di informazioni relative alla rete, è
\index{comando!\texttt{netstat}} \texttt{netstat}. Il comando è piuttosto
complesso dato che permette di ottenere informazioni riguardo a tutte le
funzionalità del sistema concernenti la rete, anche se lo scopo per cui viene
usato più spesso è quello di visualizzare tutte le connessioni attive su una
macchina.

Il comando prevede che la prima opzione indichi il tipo di informazione da
mostrare, l'elenco di quelle disponibili è riportato in
tab.~\ref{tab:net_netstat_type_options}, ma se non se ne indica nessuna viene
assunto il comportamento di default che è quello di mostrare la lista di tutti
i socket aperti nel sistema.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-g}& mostra le informazioni relative ai gruppi di
                 \textit{multicast} di cui si fa parte.\\
    \texttt{-i}& mostra le informazioni relative alle interfacce di rete,
                 equivalente all'uso di \texttt{ifconfig} senza argomenti.\\
    \texttt{-M}& mostra le informazioni relative alle connessioni mascherate 
                 dal firewall (funziona solo con i kernel della serie 2.2.x).\\
    \texttt{-r}& mostra le informazioni relative alla tabella di
                 instradamento (equivalente all'uso di \texttt{route} senza
                 argomenti)\\ 
    \texttt{-s}& mostra delle statistiche sommarie sull'uso dei vari
                 protocolli di rete.\\
    \hline
  \end{tabular}
  \caption{Opzioni del comando \texttt{netstat} per il controllo del tipo di
    informazioni da visualizzare.}
  \label{tab:net_netstat_type_options}
\end{table}


Quando viene usato con le opzioni di default il comando mostra le informazioni
riguardo a \textsl{tutti} i socket aperti. La lista comprende anche i socket
locali, che sono usati da vari programmi come meccanismo di
intercomunicazione, e che non hanno nulla a che fare con la rete. Per questo
motivo è opportuno specificare le opzioni \texttt{-t} per richiedere di
visualizzare solo i socket TCP o \texttt{-u} per vedere quelli UDP, che sono
quelli che riguardano le connessioni con la rete esterna.  Un possibile
esempio del risultato di \texttt{netstat} è allora il seguente:
\begin{Console}
root@gont:~# \textbf{netstat -t}
tcp        0      0 ppp-42-241-98-62.:32798 serverone.firenze:imaps ESTABLISHED
\end{Console}
che mostra una connessione attiva verso un server di posta.

Invocato in questa maniera il comando riporta solo i dati relativi ai socket
attivi, in realtà oltre a questi saranno presenti anche i socket per i quali
non ci sono connessioni in corso, ma che sono in ascolto, in attesa di
riceverne.  Questi vengono mostrati soltanto se si usa l'opzione \texttt{-a};
nel qual caso il precedente risultato sarebbe stato:
\begin{Console}
root@gont:~# \textbf{netstat -at}
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:printer               *:*                     LISTEN
tcp        0      0 *:5865                  *:*                     LISTEN
tcp        0      0 *:webcache              *:*                     LISTEN
tcp        0      0 *:tproxy                *:*                     LISTEN
tcp        0      0 gont.earthsea.ea:domain *:*                     LISTEN
tcp        0      0 localhost:domain        *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:ipp                   *:*                     LISTEN
tcp        0      0 *:nntp                  *:*                     LISTEN
tcp        0      0 *:smtp                  *:*                     LISTEN
tcp        0      0 ppp-42-241-98-62.:32798 serverone.firenze:imaps ESTABLISHED
\end{Console}

Infine usando l'opzione \texttt{-n} i risultati verranno stampati con tutti
gli indirizzi ed i numeri delle porte espressi in forma numerica, senza che ne
sia effettuata la risoluzione (quella di cui abbiamo parlato in
sez.~\ref{sec:net_name_resolution}) nei rispettivi nomi simbolici. Le altre
principali opzioni di controllo, non rientranti in quelle già illustrate in
tab.~\ref{tab:net_netstat_type_options}, sono riportate in
tab.~\ref{tab:net_netstat_options}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-a}& mostra i dati relativi sia ai socket attivi che a quelli in
                 ascolto.\\ 
    \texttt{-c}& ripete continuamente il comando ogni secondo.\\
    \texttt{-e}& stampa informazioni addizionali, può essere ripetuto due
                 volte per avere ancora più informazioni.\\
    \texttt{-l}& mostra i dati relativi ai socket in ascolto (di default non
                 vengono mostrati).\\
    \texttt{-n}& non esegue la risoluzione di indirizzi e porte.\\
    \texttt{-t}& mostra i dati relativi ai socket TCP.\\
    \texttt{-u}& mostra i dati relativi ai socket UDP.\\
    \hline
  \end{tabular}
  \caption{Opzioni principali del comando \texttt{netstat}.}
  \label{tab:net_netstat_options}
\end{table}

Quando si usa \texttt{netstat} per verificare lo stato delle connessioni di
rete, il comando genera una tabella con una voce per ciascuna di esse, come
illustrato negli esempi precedenti. Il campo \textsf{Proto} riporta il
protocollo della connessione. I campi \textsf{Local Address} e \textsf{Foreign
  Address} indicano gli indirizzi locale e remoto della stessa, che nel caso
di socket su Internet sono nella forma:
\begin{Example}
indirizzo:porta
\end{Example}
dove un asterisco indica un indirizzo o una porta qualunque. Il campo
\textsf{State} indica lo stato della connessione.  Una spiegazione dettagliata
del significato dei valori di questo campo va di nuovo al di là delle finalità
di questo testo, e richiede una trattazione approfondita del protocollo
TCP/IP,\footnote{una trattazione completa è in \cite{TCPIll1}, una sintesi si
  può trovare nelle appendici di \cite{GaPiL}.} per cui ci limiteremo ad
alcune note panoramiche.

Delle varie righe quelle che meritano attenzione sono quelle relative agli
stati \texttt{LISTEN} ed \texttt{ESTABLISHED}.  Lo stato \texttt{LISTEN}
indica la presenza di un programma in ascolto sulla vostra macchina in attesa
di connessione, nell'esempio precedente ce ne sono vari, corrispondenti a
servizi come la posta, le news, il DNS, la stampa via rete. Gli indirizzi di
norma non sono specificati in quanto la connessione può essere effettuata su
uno qualunque degli indirizzi disponibili sulle interfacce locali, e a partire
da un qualunque indirizzo esterno. Lo stato \texttt{ESTABLISHED} indica le
connessioni stabilite ed attive, e riporta nei campi degli indirizzi i numeri
di IP e porta dei due capi della connessione.  Altri stati che possono essere
riportati dal comando sono \texttt{FIN\_WAIT}, \texttt{TIME\_WAIT}, che si
riferiscono a connessioni che si stanno chiudendo.

Si noti anche che quando si esegue \texttt{netstat} con l'opzione \texttt{-u}
per rilevare lo stato dei socket UDP, nella tabella risultante il campo
\textsf{State} è vuoto anche quando ci sono servizi in ascolto, in quanto lo
stato è definito soltanto per i socket TCP.


% TODO trattare il comando ss e eventuali affini per l'analisi dei socket

\subsection{Il protocollo ARP ed il comando \texttt{arp}}
\label{sec:net_arp}

Come accennato in sez.~\ref{sec:net_intro} il protocollo ARP viene usato (dal
kernel) per associare ad un indirizzo fisico presente sulla rete locale,
quello che per gran parte delle reti è il cosiddetto \textit{MAC address}, al
corrispondente indirizzo IP, cosicché il kernel possa sapere a quale scheda
(Ethernet nel caso più comune) mandare i pacchetti.

In realtà il protocollo viene utilizzato tutte le volte che il kernel deve
inviare un pacchetto IP verso l'esterno su una rete di tipo Ethernet (o con
funzionalità equivalenti come il token ring o l'FDDI).  Le possibilità sono
sempre due, o si deve comunicare con un indirizzo IP nella stessa sottorete,
nel qual caso si invierà il pacchetto direttamente al destinatario tramite
l'indirizzo fisico della sua scheda di rete, o si deve inviare il pacchetto
altrove passando attraverso un \textit{gateway}, nel qual caso dalla tabella
di \textit{routing} si otterrà l'indirizzo IP di quest'ultimo, che sarà usato
per ricavare il \textit{MAC address} della scheda a cui inviare il pacchetto.

Il protocollo viene usato per mandare delle richieste in \textit{broadcast}
che vengono ricevute da tutte le schede su una stessa LAN. Queste hanno la
tipica forma ``\textsl{devi dire chi è \texttt{X.X.X.X} a \texttt{Y.Y.Y.Y}}''
dove \texttt{X.X.X.X} è l'indirizzo IP che si vuole risolvere, ed
\texttt{Y.Y.Y.Y} è quello del richiedente.  Quest'ultimo viene automaticamente
identificato dato che il suo \textit{MAC address} è riportato come indirizzo
sorgente nel pacchetto di richiesta, così che la macchina la cui interfaccia
ha l'IP \texttt{X.X.X.X} può rispondere direttamente con un messaggio del tipo
``\textsl{\texttt{X.X.X.X} è \texttt{NN:NN:NN:NN:NN:NN}}'' trasmettendo il suo
\textit{MAC address} direttamente al richiedente.

In questo modo una macchina può interrogare le sue vicine sulla stessa LAN e
costruire un elenco di corrispondenze. Per evitare di oberare la rete di
richieste le corrispondenze trovate vengono mantenute per un certo tempo in
quella che viene chiamata la \textit{ARP cache} del kernel, e rinnovate solo
dopo che sono scadute. In generale non è necessario nessun intervento di
configurazione diretto per la gestione di questo protocollo, ma esistono
comunque esigenze per cui può risultare utile esaminare ed eventualmente
modificare manualmente la \textit{ARP cache}.\footnote{in particolare è ben
  noto un attacco che consiste di inserire corrispondenze arbitrarie nella
  \textit{ARP cache} con pacchetti ARP ``\textsl{falsi}'', la tecnica si
  chiama \textit{ARP poisoning} ed è trattata con maggiori dettagli nella
  sezione 5.4 di \cite{SGL}, se si sospetta questo tipo di attacco esaminare
  la \textit{ARP cache} può risultare utile.}

Ad esempio una tecnica che impiega questo protocollo è quella del cosiddetto
\textit{proxy ARP}, usata quando si divide in due reti separate una rete che
prima era unica, introducendo un \textit{router} a separare i due nuovi
rami. Dato che un \textit{router} non trasmette i pacchetti a livello di
collegamento fisico, impostando su di esso un \textit{proxy ARP} si fa sì che
alle richieste ARP per gli IP posti sul nuovo tratto di rete al di là del
\textit{router} venga comunque risposto, fornendo l'indirizzo fisico della
scheda del \textit{router}. In questo modo, anche se non si è impostato su
tutte le macchine una opportuna rotta statica per la nuova configurazione
della rete, il \textit{router} riceverà i pacchetti destinati al nuovo tratto,
e potrà inoltrarli.

Il comando che permette di esaminare e modificare la \textit{ARP cache} del
kernel è \index{comando!\texttt{arp}} \texttt{arp}.\footnote{con il nuovo
  comando \texttt{ip} si può usare anche \texttt{ip neigh}, che non abbiamo
  trattato in sez.~\ref{sec:net_adv_config}, ma il cui uso è analogo agli
  altri comandi della famiglia, per la sintassi si rimanda comunque alla
  pagina di manuale, accessibile con \texttt{man ip-neighbour}.}  Se chiamato
senza opzioni il comando mostra il contenuto corrente della cache effettuando
la risoluzione inversa degli indirizzi IP, un esempio del suo risultato
potrebbe essere il seguente:
\begin{Console}
root@gont:~# \textbf{arp}
Address                  HWtype  HWaddress           Flags Mask            Iface
oppish.earthsea.ea       ether   00:48:54:3A:9A:20   C                     eth0
havnor.earthsea.ea       ether   00:48:54:6A:4E:FB   C                     eth0
roke.earthsea.ea                 (incomplete)                              eth0
\end{Console}
in cui per ciascuna riga è riportata la corrispondenza fra l'indirizzo IP di
una macchina (o il nome, se risolto) e l'indirizzo fisico, con ulteriori
informazioni come l'interfaccia di rete da cui essa è raggiungibile, oppure,
in caso di richiesta senza risposta come per la terza voce, la dicitura
\texttt{incomplete}.

Le due operazioni fondamentali del comando sono la cancellazione (con
l'opzione \texttt{-d}) e l'inserimento (con l'opzione \texttt{-s}) di una voce
nella \textit{ARP cache}, nel caso della cancellazione occorre specificare
l'indirizzo IP (o il nome) della macchina da rimuovere, con qualcosa come:
\begin{Example}
arp -d oppish
\end{Example}
mentre se si vuole inserire una voce in più si dovranno specificare almeno
indirizzo e \textit{MAC address}, ad esempio con un comando come:
\begin{Example}
arp -s lorbaner 00:48:54:AA:9A:20
\end{Example}

Si tenga presente però che una voce inserita in questo modo nella \textit{ARP
  cache}, a meno che non si passi al comando come ulteriore argomento la
direttiva \texttt{temp}, diventa ``\textsl{statica}'' e non scade
più.%\footnote{con la
% stessa opzione si può usare il comando anche per importare
%   un \textit{proxy ARP}, usando la parola \texttt{pub} (per
%   \textit{publish}) come secondo argomento, che indica al kernel di fornire
%   risposte alle interrogazioni ARP per quell'indirizzo.}
Questo significa che per quella voce il protocollo ARP non verrà più usato e
sarà sempre utilizzata l'associazione statica che si è impostata. 

La conseguenza è che la macchina su cui si è effettuata tale operazione non
sarà più in grado di accorgersi di eventuali variazioni del \textit{MAC
  address} di altre macchine, ad esempio dovute ad un cambio di scheda di
rete, che a quel punto diventeranno completamente irraggiungibili,
indipendentemente dalle impostazioni che si potranno effettuare su
quest'ultime al riguardo di interfacce ed indirizzi. Dato che questo tipo di
problemi sono assai difficili da diagnosticare, è in genere sconsigliato
effettuare una impostazione di voci statiche.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-d \textsl{host}} & cancella la voce relativa al nodo
                                \texttt{\textsl{host}}.\\ 
    \texttt{-f \textsl{file}} & legge i valori da immettere nella cache dal
                                file \texttt{\textsl{file}}.\\
    \texttt{-i \textsl{iface}}& stampa le voci corrispondenti alla sola
                                interfaccia \texttt{iface}.\\ 
    \texttt{-n} & non effettua la risoluzioni di nomi e indirizzi.\\ 
    \texttt{-s \textsl{host hwadd}}& inserisce una voce nella cache, associando
                                al nodo \texttt{\textsl{host}} l'indirizzo
                                hardware \texttt{\textsl{hwadd}}.\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni del comando \texttt{arp}.}
  \label{tab:net_arp_option}
\end{table}

A parte le due già citate, l'opzione più comune per il comando \texttt{arp} è
\texttt{-n}, che disabilita la risoluzione degli indirizzi. Le altre opzioni
principali sono riportate in tab.~\ref{tab:net_arp_option}, ed al solito per
l'elenco completo ed i dettagli di funzionamento si può fare ricorso alla
pagina di manuale del comando, accessibile con \texttt{man arp}.

Si tenga presente inoltre che come per la risoluzione dei nomi in indirizzi IP
(vedi sez.~\ref{sec:net_name_files}) è possibile impostare delle voci statiche
per la \textit{ARP cache} tramite un opportuno file di configurazione. Il file
è \index{configurazione!\texttt{/etc/ethers}} \texttt{/etc/ethers}, che
contiene delle corrispondenze nella forma:
\begin{Example}
MAC-address indirizzo-IP
\end{Example}
ed al posto dell'indirizzo IP si può anche specificare un nome simbolico,
posto che questo sia risolvibile. Il formato dei \textit{MAC address} è quello
solito di sei byte esadecimali separati dal carattere ``\texttt{:}'' con cui
vengono mostrati anche nell'uscita di \texttt{ifconfig}; un possibile
contenuto di \texttt{/etc/ethers} sarà cioè qualcosa del tipo:
\begin{FileExample}[label=/etc/ethers]
08:00:20:00:61:CA  129.168.1.245
\end{FileExample}

%Inserire delle voci statiche nella  \textit{ARP cache} però può risultare 
% TODO: trattare arping (qui?)




\subsection{I servizi RPC}
\label{sec:net_rpc_services}

\itindbeg{Remote~Procedure~Call (RPC)} 

In sez.~\ref{sec:net_ports} abbiamo visto come normalmente i servizi di rete
vengano forniti utilizzando una porta, il cui valore li identifica
univocamente. Con il crescere del numero di servizi che potevano essere resi
disponibili questa assegnazione statica ha iniziato ad essere percepita come
problematica, in quanto le porte possibili sono solo 65535, numero che si
potrebbe esaurire con una certa facilità se se ne dovesse assegnarne una ad
ogni servizio possibile.

A prima vista il problema può sembrare poco realistico, visto il numero non
poi così ampio dei servizi di rete classici, ma quando si iniziò a pensare ad
una modalità per rendere eseguibili via rete delle funzioni generiche
attraverso opportuni servizi (i cosiddetti \textit{Remote Procedure Call} o
servizi RPC), il problema dell'assegnare una porta statica ad ogni funzione
che ci si poteva inventare divenne significativo, per cui si dovette
progettare anche un meccanismo che ne consentisse l'allocazione dinamica.

Il concetto che sta dietro le \textit{Remote Procedure Call} è quello di un
meccanismo di intercomunicazione generico basato sui protocolli di trasporto
(sia TCP che UDP), che permetta ad un processo che gira su una certa macchina
di accedere a dei servizi (nella forma di chiamate a funzioni esterne) in
maniera trasparente rispetto alla rete. In sostanza una sorta di libreria
eseguita via rete, in cui si demanda l'elaborazione dei dati ad una macchina
remota, che restituirà i risultati attraverso la rete.

Ciascun servizio RPC è fornito da un apposito demone, in ascolto su una porta
non definita a priori, in modo da poterne definire quanti se ne vuole, ma di
impiegare delle porte solo per quelli effettivamente utilizzati. Un programma
che voglia utilizzare un servizio RPC deve prima rivolgersi ad un servizio
speciale, il \textit{portmapper}, che registra i servizi attivi ed è in grado
di indicare la porta su cui sono forniti.

Il servizio del \textit{portmapper} è l'unico a cui viene assegnata una porta
fissa, la 111, che corrisponde al nome \texttt{sunrpc}. I servizi RPC infatti
sono stati introdotti per la prima volta da Sun per i suoi sistemi Unix, da
cui questo nome per il servizio associato al \textit{portmapper}. Tutti gli
altri servizi RPC quando si avviano si registrano presso il
\textit{portmapper} utilizzando un numero identificativo interno, ed indicano
la porta su cui sono in ascolto; in sez.~\ref{sec:net_NFS_server} vedremo che
NFS utilizza questa infrastruttura.

In sostanza nel caso di servizi RPC si fa effettuare al \textit{portmapper}
una risoluzione dinamica fra un servizio che è stato registrato dal rispettivo
server ed il numero di porta che questo sta utilizzando.  In questo modo è
possibile richiedere il servizio usando il numero identificativo, che è
completamente indipendente dal numero di porta e non soggetto ai limiti di
quest'ultimo.  

La lista dei servizi RPC viene mantenuta in un apposito file
\index{configurazione!\texttt{/etc/rpc}} \texttt{/etc/rpc} che è l'analogo di
\texttt{/etc/services}, ed in realtà anche in questo caso si può usare il
\textit{Name Service Switch} per utilizzare altri supporti, anche se in
pratica non viene mai fatto. Il formato del file prevede tre campi separati da
spazi: il primo indica il nome ufficiale del servizio RPC, il secondo il
numero identificativo ad esso associato, il terzo la lista, separata da spazi,
degli alias del nome ufficiale. Un esempio di questo file, preso da una Debian
Squeeze, è:
\begin{FileExample}[label=/etc/rpc]
# This file contains user readable names that can be used in place of rpc
# program numbers.

portmapper      100000  portmap sunrpc
rstatd          100001  rstat rstat_svc rup perfmeter
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd
etherstatd      100010  etherstat
rquotad         100011  rquotaprog quota rquota
...
\end{FileExample}

Per poter usufruire dei servizi RPC è pertanto necessario attivare il servizio
\textit{portmapper} e questo viene usualmente fatto direttamente dagli script
di avvio attraverso l'uso dal demone \index{demone!\texttt{portmap}}
\texttt{portmap}. Dato che questo demone è essenziale al funzionamento dei
servizi RPC, esso viene installato di default da quasi tutte le distribuzioni.

Per una maggiore sicurezza, se viene usato solo per servizi utilizzati
localmente, sarebbe opportuno lanciarlo con l'opzione \texttt{-i} che permette
di indicare un indirizzo specifico su cui porsi in ascolto, facendogli
utilizzare esclusivamente il \texttt{localhost}.\footnote{e questo è il
  default di Debian e della gran parte delle distribuzioni.} Per le altre
opzioni si faccia riferimento come al solito alla pagina di manuale.

Se il \textit{portmapper} è attivo si può verificare il funzionamento dei
servizi RPC con il comando \index{comando!\texttt{rpcinfo}}
\texttt{rpcinfo}. Questo, se invocato con l'opzione \texttt{-p}, prende come
argomento l'indirizzo di un nodo (se non si indica nulla usa la macchina
locale) e stampa una lista di tutti i servizi registrati; un esempio potrebbe
essere: 
\begin{Console}
piccardi@hain:~$ \textbf{rpcinfo -p}
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp    787  status
    100024    1   tcp    790  status
\end{Console}
%$

Il comando consente anche, con l'opzione \texttt{-u}, di interrogare un nodo
per la presenza di uno specifico servizio (passato come secondo argomento) e
di inviare richieste in \textit{broadcast} sulla rete per rilevare la presenza
di altre macchine che forniscono servizi RPC (nel qual caso occorrerà passare
come argomenti il numero del servizio e quello di versione).  Per maggiori
dettagli e l'elenco completo delle opzioni si faccia riferimento alla pagina
di manuale.

\itindend{Remote~Procedure~Call (RPC)}



\section{I client dei servizi di base}
\label{sec:net_simple_client}

Una volta che se ne sia completata la configurazione e verificato il
funzionamento, l'utilizzo della rete avviene attraverso l'accesso ai servizi
che su di essa vengono forniti. In generale i servizi di base sono forniti
tutti secondo un'architettura \textit{client-server} in cui c'è un programma
che serve a fornire il servizio ed uno che serve ad utilizzarlo. Affronteremo
più avanti la configurazione lato server di alcuni di questi servizi, qui ci
limiteremo a trattare alcuni fra i client.


\subsection{I comandi \texttt{telnet} e \texttt{netcat}}
\label{sec:net_telnet}

Uno dei servizi di base un tempo più utilizzato sulla rete era quello del
\textit{telnet}, nato per eseguire delle connessioni con cui poter operare via
rete su un terminale su una macchina remota. Dato che tutti i dati vengono
trasmessi in chiaro sulla rete, password comprese, questo uso è assolutamente
da evitare, ed a questo scopo oggi viene completamente sostituito dal comando
\texttt{ssh}, che tratteremo in sez.~\ref{sec:net_SSH_client}.

In ogni caso il comando \index{comando!\texttt{telnet}} \texttt{telnet}
continua ad esistere, e può essere usato allo scopo originale su una rete
locale sicura o quando non esiste una versione di SSH per la macchina in
questione, come accade per vari apparati di rete, che forniscono un accesso
alla console di amministrazione solo in questo modo. Un suo uso più
interessante però è quello diagnostico, allo scopo di verificare la
accessibilità e la funzionalità dei servizi.

Il comando prende come argomento la macchina cui collegarsi ed opzionalmente
la porta, specificata per numero o per nome del servizio. Non specificando
nessuna porta il comando si collega sulla porta 23, che corrisponde al
servizio standard \textit{telnet}, mostrando, qualora sia attivo il relativo
server, una schermata di login (o quanto previsto).

Il comando supporta varie opzioni, per lo più relative alle modalità di
gestione della sessione di terminale remota. Dato che questo uso è
assolutamente sconsigliabile non le riportiamo neanche, i più curiosi possono
consultare la pagina di manuale accessibile con \texttt{man telnet}. Di norma
si usa il comando indicando semplicemente un indirizzo ed una porta, ad esempio:
\begin{Console}
piccardi@oppish:~$ \textbf{telnet localhost 25}
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 oppish.earthsea.ea ESMTP Postfix (Debian/GNU)
\end{Console}
%$
in questo caso lo si è usato per connettersi alla porta 25 della propria
macchina, per verificare che il relativo servizio SMTP (cioè il server per la
ricezione e la trasmissione della posta elettronica) sia attivo: si noti che
si è poi anche ottenuta la risposta del server che nel caso in questione è
\textit{Postfix}.

Con la stessa sintassi si può usare il comando per verificare la presenza e
l'attività dei servizi sulle relative porte. Anche se non si riceve nessuna
risposta (ad esempio perché il servizio interrogato necessita di una richiesta
prima di rispondere), la presenza della riga \texttt{Connected} indicherà che
la connessione è riuscita ed è attiva.  Se invece tentiamo di collegarci verso
una porta su cui non è attivo nessun server otterremo un errore di connessione
rifiutata del tipo:
\begin{Console}
piccardi@oppish:~$ \textbf{telnet localhost 80} 
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
\end{Console}
%$
con un ritorno pressoché immediato alla riga di comando. 

Questo è il comportamento normale, ma quando la macchina contattata è protetta
da un firewall normalmente tutti i pacchetti in ingresso non diretti ai
servizi consentiti vengono scartati; questo comporta che un tentativo di
connessione su una porta senza servizi sia completamente ignorato. In questa
evenienza, non ricevendo nessuna risposta,\footnote{il protocollo TCP prevede,
  in caso di connessione su una porta su cui non ci sono servizi, l'invio di
  un pacchetto di risposta al client che ha effettuato il tentativo per
  notificare l'errore; è grazie alla ricezione di questo pacchetto che
  \texttt{telnet} riporta l'errore di connessione rifiutata mostrato
  nell'esempio precedente, ma se il tentativo di connessione viene scartato a
  priori non si riceverà neanche la risposta di errore.} il comando
\texttt{telnet} resta bloccato in attesa fino alla scadenza del timeout (il
default è circa 30 secondi), riportando poi un errore di connessione.

Un secondo comando che si può utilizzare per effettuare una verifica sui
servizi è \index{comando!\texttt{netcat}} \texttt{netcat}, che può essere
invocato anche in forma più compatta con \index{comando!\texttt{nc}}
\texttt{nc}. Il grande vantaggio rispetto a \texttt{telnet} è che mentre
quest'ultimo funziona soltanto su TCP, \texttt{netcat} può essere anche usato
su UDP, e permette quindi di controllare anche i servizi che usano questo
protocollo.

Inoltre \texttt{netcat}, come suggerisce il nome stesso, si limita a leggere e
scrivere i dati su delle connessioni di rete associando \textit{standard
  input} e \textit{standard output} alla connessione su cui lavora, supporta
quindi la redirezione ed il \textit{pipelining}, ed è particolarmente adatto
ad essere utilizzato anche all'interno di script.  Questo non è possibile con
\texttt{telnet}, che associa alla connessione un terminale, ed è quindi
soggetto alla \index{disciplina~di~linea} \textsl{disciplina di linea} di
quest'ultimo.\footnote{si chiama \textsl{disciplina di linea} la modalità con
  cui il dispositivo di terminale gestisce l'I/O, ad esempio il fatto che
  l'input è bufferizzato linea per linea.}  Inoltre \texttt{telnet} interpreta
alcuni caratteri come caratteri di controllo (eliminandoli dal flusso dei
dati) e scrive alcuni dei suoi messaggi interni sullo \textit{standard
  output}.

Al contrario \texttt{nc} preserva rigorosamente il flusso dei dati, e se da
una parte questo lo rende meno adatto all'amministrazione via rete (ma non lo
sarebbe comunque, non essendo prevista la cifratura della connessione),
dall'altra lo rende uno strumento molto flessibile per inviare e ricevere dati
dalla rete, e manipolarli usando la riga di comando, tanto che la pagina di
manuale lo classifica come ``il \textsl{coltellino svizzero} del TCP/IP''.

La forma più elementare di invocazione del comando è identica a quella di
\texttt{telnet}, in cui si specifica il nome di una macchina (o il suo
indirizzo) e la porta che si desidera contattare. Ripetendo l'esempio
precedente avremo:
\begin{Console}
piccardi@hain:~$ \textbf{nc localhost 25}
220 hain.truelite.it ESMTP Postfix (Debian/GNU)
\end{Console}
%$
e come si può notare in questo caso non viene scritto niente che non sia
quanto stato ricevuto dalla rete; se si vogliono avere i messaggi diagnostici
occorre utilizzare l'opzione \texttt{-v}, che li stamperà rigorosamente sullo
\textit{standard error}. Inoltre ripetendo due volte l'opzione il comando
diventa più prolisso. Se il servizio che si vuole contattare usa il protocollo
UDP basterà utilizzare l'opzione \texttt{-u}.

Un'altra caratteristica interessante del programma è che si possono
specificare più porte di destinazione, ed i dati verranno inviati e letti su
tutte quante. Questo permette anche di eseguire una scansione elementare per
la presenza di servizi attivi, che potrebbe essere realizzata con qualcosa
del tipo:
\begin{Example}
echo QUIT | nc -w 1 localhost 25 1-1024 6000-7000
\end{Example}
dove si è usata l'opzione \texttt{-w}, che consente di specificare un tempo
massimo di durata in secondi, per chiudere le connessioni che altrimenti
resterebbero aperte.

Un'altra caratteristica interessante di \texttt{netcat} è che può essere
utilizzato in \textit{listen mode} (cioè come ``\textsl{server}'') usando
l'opzione \texttt{-l} che mette il programma in ascolto sulla porta
specificata con l'opzione \texttt{-p}. In tal caso sarà possibile collegarsi
da remoto al programma, che scriverà sullo \textit{standard output} quanto
ricevuto sulla connessione.

In questo modo ad esempio è possibile trasferire un file via rete redirigendo
lo \textit{standard output} del comando, utilizzando \texttt{nc} sull'altro
capo della connessione per inviarlo. Infine usando l'opzione \texttt{-e} è
possibile indicare un programma che verrà eseguito collegando \textit{standard
  input} e \textit{standard output} alla connessione. Questo significa che
quanto si invierà sulla connessione arriverà in ingresso al programma e si
riotterranno sulla stessa i dati in uscita.  Così si può trasformare
\texttt{nc} (se ad esempio si fa eseguire la shell) in un surrogato temporaneo
del servizio \textit{telnet}.


\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Opzione} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{-e \textsl{cmd}} & esegue il file \texttt{\textsl{cmd}}, collegando
                               il relativo \textit{standard input} e
                               \textit{standard output} alla connessione.\\
    \texttt{-l} & si pone in ascolto sulla porta specificata con \texttt{-p}.\\ 
    \texttt{-p \textit{port}}& indica la porta (o le porte indicando un
                               intervallo separato da un ``\texttt{-}'') su
                               cui mettersi in ascolto; da usare insieme a
                               \texttt{-l}.\\ 
    \texttt{-q \textsl{secs}}& attende \texttt{\texttt{secs}} secondi dopo la
                               chiusura dello \textit{standard input}.\\
    \texttt{-s \textsl{addr}}& specifica l'indirizzo sorgente locale.\\
    \texttt{-u} & esegue le connessioni su UDP.\\
    \texttt{-v} & modalità \textsl{prolissa}, stampa informazioni sullo
                  \textit{standard error}.\\
    \texttt{-w \textsl{secs}}& aspetta \texttt{\textsl{secs}} secondi per il
                               timeout.\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni del comando \texttt{netcat}.}
  \label{tab:net_netcat_option}
\end{table}

In tab.~\ref{tab:net_netcat_option} si sono riportate le principali opzioni
del comando, al solito per l'elenco completo si può fare riferimento alla
pagina di manuale.


\subsection{Il comando \texttt{ftp}}
\label{sec:net_ftp}

Il protocollo FTP è uno dei più vecchi protocolli che consentono lo scambio di
file su Internet. Il protocollo permette di prelevare od immettere file su un
server FTP, previa autenticazione analoga a quella del login o dell'accesso
con telnet. Una sua forma particolare è il cosiddetto \textsl{FTP anonimo} in
cui il servizio viene utilizzato per distribuire i file posti in un server; in
questo caso il servizio non richiede autenticazione, e di norma consente solo
il prelievo dei file.

Dato che il protocollo, come \textit{telnet}, non prevede alcuna cifratura dei
dati, è meglio non usarlo in quanto l'autenticazione verrebbe eseguita in
chiaro; unica eccezione è la modalità anonima in cui non c'è autenticazione
che è ancora una modalità molto usata per distribuire pubblicamente
file.\footnote{anche questo utilizzo è comunque ampiamente discutibile, in
  quanto sarebbe comunque più efficiente distribuire i suddetti dati via web
  usando HTTP, che sovraccarica meno la rete e non presenta tutte le
  problematiche di funzionamento, in particolare quando si devono attraversare
  dei firewall, che ha FTP.} Qualora si necessiti di un meccanismo per lo
scambio di file via rete fra i vari utenti sono disponibili alternative come
\texttt{sftp}, un programma che ha esattamente la stessa sintassi di
\texttt{ftp}, ma consente l'uso di una connessione cifrata attraverso il
protocollo SSH che tratteremo in sez.~\ref{sec:net_ssh}.

Oggi esistono molti client per il protocollo FTP, sia grafici che testuali, ma
il comando originale usato per lanciare il client testuale è semplicemente
\index{comando!\texttt{ftp}} \texttt{ftp}.  Un esempio di uso generico del
comando è il seguente:
\begin{Console}
piccardi@anarres:~$ \textbf{ftp ftp.linux.it}
Connected to vlad-tepes.bofh.it.
220 (vsFTPd 2.0.7)
Name (ftp.linux.it:piccardi): \textbf{anonymous}
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> 
\end{Console}
%$
eventuali opzioni, ed anche la stessa risposta, dipendono in genere dalla
versione del comando che si è installata, e vanno verificate facendo
riferimento alla relativa pagina di manuale. 

Quella illustrata nell'esempio è la risposta data dal comando \texttt{ftp} che
si trova su Debian Squeeze, derivato dalla prima realizzazione del programma
nato con BSD, alternative possono essere client più evoluti come \texttt{lftp}
o \texttt{ncftp} che supportano la storia dei comandi, il completamento dei
nomi, e capacità aggiuntive (come il download ricorsivo dei contenuti di una
directory).

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|l|}
    \hline
    \textbf{Comando} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{ls}       & stampa la lista dei file (sul server).\\
    \texttt{cd}       & cambia directory (sul server).\\
    \texttt{lcd}      & cambia directory (sul client).\\
    \texttt{pwd}      & stampa la directory corrente (sul server).\\
    \texttt{ascii}    & modalità di trasferimento di file di testo.\\
    \texttt{binary}   & modalità di trasferimento di file binari.\\
    \texttt{pasv}     & abilita i trasferimenti in modo passivo.\\
    \texttt{get \textsl{file}}   & scarica il file \texttt{\textsl{file}} dal
                                   server.\\ 
    \texttt{put \textsl{file}}   & invia il file \texttt{\textsl{file}} sul
                                   server.\\ 
    \texttt{mget \textsl{files*}}& scarica i file che corrispondono alla
                                   wildcard \texttt{\textsl{files*}}.\\
    \texttt{mput \textsl{files*}}& invia i file che corrispondono alla wildcard
                                   \texttt{\textsl{files*}}.\\
    \texttt{open \textsl{host}}  & apre una connessione verso il server
                                   \texttt{\textsl{host}}.\\ 
    \texttt{quit}     & chiude la sessione.\\
    \texttt{rmdir}    & cancella directory (deve essere vuota).\\
    \texttt{mkdir}    & crea directory.\\
    \texttt{chmod}    & modifica i permessi del file.\\
%    \texttt{}     & .\\
    \hline
  \end{tabular}
  \caption{Comandi del protocollo FTP.}
  \label{tab:net_FTP_commands}
\end{table}

Si noti come nell'uso generico sia sufficiente indicare la macchina cui ci si
vuole collegare. Nel caso ci viene notificato l'\textit{hostname} effettivo
del server e ci viene richiesto un nome di login che di default corrisponde al
nostro username. Avendo contattato un FTP anonimo l'utente da usare è
\texttt{anonymous}, specificato il quale ci viene richiesta una password, che
nel caso è ininfluente (qualunque cosa si scriva sarà garantito l'accesso).

Fatto questo si viene portati su una riga di comando introdotta dal un prompt
``\texttt{ftp>}'' dalla quale sarà possibile inviare, scrivendoli come si
farebbe con la shell, i vari comandi previsti dal protocollo per operare con
il server. I più importanti sono stati brevemente illustrati in
tab.~\ref{tab:net_FTP_commands}, mentre la lista completa con tutti i dettagli
è al solito disponibile nella pagina di manuale, accessibile con \texttt{man
  ftp}.

Si tenga presente però che non tutti i comandi possono essere supportati dal
server. Ad esempio il comando \texttt{pasv}, che abilita il cosiddetto
\textit{modo passivo},\footnote{il protocollo FTP prevede l'uso di due porte,
  la connessione avviene sempre da parte del client sulla porta 21 del server,
  ma su di essa vengono solo inviati i comandi, quando si richiede l'invio di
  file questo viene effettuato dal server con una seconda connessione che
  contatta il client sulla porta 20; dato che normalmente i firewall bloccano
  le connessioni entranti, il modo passivo fa sì che sia sempre il client a
  creare la nuova connessione anche per i dati.}  è eseguibile solo se il
server supporta questa modalità di operazione, mentre i comandi \texttt{ascii}
e \texttt{binary} non hanno nessun significato su sistemi unix-like, ma
possono averlo per altri sistemi come il VMS o il DOS che introducono una
distinzione fra questi tipi di file.


\subsection{I comandi \texttt{finger} e \texttt{whois}}
\label{sec:net_finger}

Il comando \index{comando!\texttt{finger}} \texttt{finger} viene usato fin
dalle origini di Unix, dove agiva solo sulla macchina locale, per riportare
informazioni relative agli utenti di un sistema. In questo modo si poteva
consentire agli altri utenti di sapere chi era collegato alla macchina.  Il
servizio è stato trasferito sulla rete, ed il client funziona sia in locale
che in remoto (nel qual caso si eseguirà una richiesta con un parametro del
tipo \texttt{nome\@host}).

Un possibile esempio di uso del comando, fatto in locale, è il seguente:
\begin{Console}
piccardi@gont:~$ \textbf{finger franci}
Login: franci                           Name: Francesco Piccardi
Directory: /home/franci                 Shell: /bin/bash
Home Phone: 0XX-XX000XX
Last login Tue Jun 17 21:22 (CEST) on :0
No mail.
No Plan.
\end{Console}
%$
e come si vede il programma mostra una serie di informazioni riguardo l'utente
\texttt{franci}; questi può aggiungervi ulteriori informazioni creando un file
\texttt{.plan} nella sua home directory, che verrà mostrato all'esecuzione del
comando.

Il comando prende come argomento un nome utente che viene confrontato sia con
lo username che con il nome reale dello stesso memorizzato su
\texttt{/etc/passwd}; qualora si voglia eliminare quest'ultimo confronto si
può usare l'opzione \texttt{-m}. Se invocato senza argomenti mostra l'elenco
degli utenti collegati e relativo terminale come:
\begin{Console}
piccardi@gont:~$ \textbf{finger}
Login     Name              Tty      Idle  Login Time   Office     Office Phone
piccardi  Simone Piccardi  *:0             Jul 21 21:55
\end{Console}
%$
altre due opzioni utili sono \texttt{-s} che mostra una lista semplice come
questa e \texttt{-l} che mostra una lista lunga come la precedente, per i
dettagli si può fare riferimento alla pagina di manuale.

Dato che il comando fornisce delle informazioni che potrebbero essere utili
per attività non troppo benevole o per violare la privacy degli utenti (ad
esempio l'uso dell'indirizzo di posta elettronica per inviare dello spam),
oggi si tende sempre di più a non attivare questo servizio sulla rete.
Talvolta però esso viene utilizzato per pubblicare delle informazioni, non
legate alla presenza di specifici utenti sulla macchina, come eventuali
recapiti e contatti, oppure per distribuire le chiavi GPG degli utenti (usando
un file \texttt{.pgpkey} nella home directory degli stessi).

Il comando \index{comando!\texttt{whois}} \texttt{whois} viene usato per
contattare i server che forniscono il servizio \textit{whois}. Questo servizio
permette di accedere alle informazioni presenti nel database dei titolari dei
domini su Internet, che vengono mantenute dagli enti che sono responsabili
della registrazione degli stessi (in Italia il NIC). In genere lo si utilizza
quando si cercano informazioni di natura amministrativa relativa ai domini, ad
esempio per avere un indirizzo di contatto dei relativi proprietari.

Il comando prende come argomento una stringa di ricerca, normalmente un nome a
dominio, e cerca di determinare automaticamente qual'è il server più opportuno
a cui rivolgersi.\footnote{nel caso non riesca a determinarne uno più
  specifico, viene contattato il server di riferimento internazionale, che è
  \texttt{whois.networksolutions.com}.}, il quale restituisce le informazioni
che verranno stampate a video, un esempio di uso del comando è:
\begin{Console}
piccardi@gont:~$ \textbf{whois truelite.it}
*********************************************************************
* Please note that the following result could be a subgroup of      *
* the data contained in the database.                               *
*                                                                   *
* Additional information can be visualized at:                      *
* http://www.nic.it/cgi-bin/Whois/whois.cgi                         *
*********************************************************************

Domain:             truelite.it
Status:             ACTIVE
Created:            2002-08-19 00:00:00
Last Update:        2009-04-09 00:03:35
Expire Date:        2010-03-24

Registrant
  Name:             TRUELITE SRL
  Organization:     TRUELITE SRL
  ContactID:        TRUE12-ITNIC
  Address:          VIA MONFERRATO, 6
                    Firenze
                    50142
                    FI
                    IT
  Created:          2007-03-01 10:50:20
  Last Update:      2007-03-01 10:50:20


...
\end{Console}
%$
e come si può notare si ottengono tutta una serie di informazioni relative a
chi gestisce (come il titolare) un nome a dominio.

Si può richiedere al comando di contattare un server specifico, usando
l'opzione \texttt{-h}, mentre con \texttt{-H} si indica al comando di non
mostrare le note legali che molti server inviano. Per i dettagli sulle altre
opzioni si consulti la pagina di manuale o si invochi il comando senza
argomenti.




% LocalWords:  TCP AppleTalk IPX host local WAN wide metropolitan storage DAN
% LocalWords:  personal bluetooth IRDA topos backbone BNC hub switch locally
% LocalWords:  tree mesh fabric international standards organization systems of
% LocalWords:  interconnection tab application presentation session transport
% LocalWords:  DataLink physical telnet FTP IEEE logical LLC MAC universally
% LocalWords:  address DoD department defense fig socket UDP ICMP IGMP ethernet
% LocalWords:  PPP l'IP client l'UDP IPv sez kernel DECnet EFI unique dynamic
% LocalWords:  BSD stream version ARP RARP l'autoconfigurazione anycast UG Nm
% LocalWords:  l'acknoweledgment router ping ICMPv group OUI identifier hyper
% LocalWords:  multicast multicasting resolution broadcast Token FDDI reverse
% LocalWords:  EGP exterior routing gateway autonomous systems OSPF GRE rule
% LocalWords:  shortest path generic encapsulation authentication header list
% LocalWords:  IPSEC ESP Encapsulating security payload to line over DHCP src
% LocalWords:  DNS dotted decimal netmask IANA assigned INTERNIC main secure
% LocalWords:  authority NCC APNIC dell'IP CIDR l'host all'host loopback route
% LocalWords:  localhost RFC all' l'INFN CERN Frejus peer ephemeral RX simple
% LocalWords:  port ifconfig root inet RUNNING MTU Metric errors dropped bytes
% LocalWords:  overruns packets carrier collisions interrupt NOARP POINTOPOINT
% LocalWords:  ipx Novell aftype pag multihomed aliasing networking options arp
% LocalWords:  type mask addr table add cache netstat datalink forwarding proc
% LocalWords:  sysctl filesystem echo forward destination Genmask flags Ref MSS
% LocalWords:  segment window size wildcard lorbaner gont roke NTP IMAP SNMP
% LocalWords:  oppish hogen dev reject metric mss advertizingrun cap hierarchy
% LocalWords:  level Slackware RedHat SuSE username pppd etherconf dpkg flush
% LocalWords:  debconf reconfigure netcfg netconfig Mandrake ifup ifdown static
% LocalWords:  dhcp shell resolver Domain service like hosts files dns db mtu
% LocalWords:  networks protocols services ethers rpc LDAP ldap search hostname
% LocalWords:  nameserver resolv conf domain order bind nospoof antispoofing is
% LocalWords:  spoofalert log reorder off FQDN Fully Qualified nets uname Sarge
% LocalWords:  dnsdomainname ftp tcp udp ssh SSH smtp unassigned name BOOTP for
% LocalWords:  deprecated tftp gopher Gopher protocol number icmp control igmp
% LocalWords:  message encapsulated officially datagram transmission exterior
% LocalWords:  universal packet monitoring reliable class delivery fragment esp
% LocalWords:  IDRP reservation general Encap pingare request reply from ttl nc
% LocalWords:  statistics transmitted received trip min count backspace wait ls
% LocalWords:  traceroute mtr hop exceeded hops first source firewall Active Di
% LocalWords:  ESTABLISHED connections servers and established Recv Send LISTEN
% LocalWords:  foreign printer news token proxy ether portmapper sunrpc Sun NFS
% LocalWords:  this contains readable names that can used place program numbers
% LocalWords:  portmap rstatd rstat nfs mount rpcinfo netcat Lightweight EUI
% LocalWords:  VAX trying connected escape character Postfix unable connect scp
% LocalWords:  connection refused pipelining error QUIT listen sftp anonymous
% LocalWords:  please specify the successful Have fun system using binary Woody
% LocalWords:  transfer lftp ncftp history lcd pwd ascii get put quit VMS DOS
% LocalWords:  phone last Jun CEST home spam GPG NIC truelite LCP NCP Memory
% LocalWords:  subgroup contained visualised l'incapsulazione l'NCP speed call
% LocalWords:  chat defaultroute demand usepeerdns debug ABORT BUSY VOICE ATZ
% LocalWords:  DIALTONE l'username PAP challenge handshake CHAP hash INBOUND ms
% LocalWords:  UserIDs cannot all your other accounts should not able guest eth
% LocalWords:  support stats OUTBOUND havnor freedom results obtained tech lock
% LocalWords:  postmaster remarks created expire person Surchi Calamandrei
% LocalWords:  device dell'NCP Configuration encap iface l'FDDI rwall shutdown
% LocalWords:  yppasswdd yppasswd etherstatd etherstat rquotad rquotaprog ESMTP
% LocalWords:  rquota cmd secs pasv whois at it org srl admin HWaddr TX GiB ax
% LocalWords:  txqueuelen AX ddp baseT promisc irtt dell'RTT HH addrconf rtt
% LocalWords:  gw mod dyn reinstate pre ifcfg BOOTPROTO IPADDR USERCTL yes
% LocalWords:  ONBOOT IPADRR softwarelibero fsp fspd timserver nicname checking
% LocalWords:  WorldWideWeb HyperText localnet webcache ipp nntp HWtype rusersd
% LocalWords:  HWaddress perfmeter rusers nfsprog ypserv ypprog mountd ypbind
% LocalWords:  showmount walld mget mput franci plan Tty Idle Jul pgpkey any FI
% LocalWords:  objects nserver ITNIC ttyname pppdrc ttyS adsl Printing tacacs
% LocalWords:  crtscts ATDT ppp frijole qualcun'altro ipencap st ST egp pup PUP
% LocalWords:  PARC hmp HMP xns idp Xerox NS rdp RDP iso tp xtp XTP Xpress idpr
% LocalWords:  cmtp ipv frag idrp rsvp RSVP gre skip SKIP seq tproxy svc rup CS
% LocalWords:  vsFTPd rmdir mkdir chmod going mnt nic hdl EDM mtp bootps bootpc
% LocalWords:  rje netrjs ip ggp GGP advertizing run point USB NAT translation
% LocalWords:  pointopoint hw Ubuntu CentOS ck IBM blocking interfaces allow Wi
% LocalWords:  hotplug mapping spoofing fqdn ogin ssword pppN Netware bootp gil
% LocalWords:  unit ethN tracepath tcptraceroute poisoning temp Lenny unicast
% LocalWords:  quest'ultime following result could additional information TRUE
% LocalWords:  visualized update registrant ContactID pathname suid dip ppprc
% LocalWords:  DIAL TONE Hayes GPRS PPPoA PPPoE parts wireless access Fi WLAN
% LocalWords:  AP roaming infrastructure managed hostapd tool manual thr NDP
% LocalWords:  tools iwconfig extension anarres extensions limit QoS local
% LocalWords:  encryption key power quality signal crypt excessive retries misc
% LocalWords:  invalid missed beacon essid repeater secondary restricted freq
% LocalWords:  channel iwlist scanning scan chan mapped compatible scientific
% LocalWords:  SSL netrom AMPR daemon lines desirable capable Squeeze systemd
% LocalWords:  resource location interior reached administered delete valid
%  LocalWords:  forever preferred global label advanced tables blackhole save
%  LocalWords:  unreachable prohibit restore TOS mark netfilter iptables RPDB
%  LocalWords:  policy lookup priority tos keys Organizationally prefix SLAAC
%  LocalWords:  Fujitsu resume neighbour interface subnet Neighbor Discovery
%  LocalWords:  classless stateless autoconfiguration addressing methods ULA
%  LocalWords:  addresses HTTPs IMAPs advertising Mint

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "corso"
%%% End: 
