IPv 4&subnetting

05 GUIDA TCP/IP XP 28-03-2003 14:07 Pagina 59
Parte 3
5
Internet Protocol
version 4 (IPv4)
Introduzione
Il protocollo IP (Internet Protocol), formalizzato nella RFC 791, nasce per consentire lo
scambio di dati tra due nodi all’interno di un insieme di reti a commutazione di pac-
chetto, interconnesse tra loro tramite dispositivi intermedi chiamati gateway (spesso
indicati anche con i termini router o intermediate system). Questo sistema di reti, ini-
zialmente chiamato “catenet” (cf. IEN 48, The Catenet Model for Internetworking,
Vinton Cerf 1978 e RFC 791 Internet Protocol, Jon Postel 1981), corrisponde all’attuale
concetto di Internet, ovvero un insieme di reti indipendenti e intercomunicanti, che
agiscono come un perfetto sistema olistico, cioè un sistema costituito da un insieme
di componenti interagenti e cooperanti tra loro al fine di costituire ed agire come un
unico sistema organico (figura 5.1).
Figura 5.1: Esempio di reti interconnesse

61
Parte 3
Questo sistema di “rete di reti” viene indicato anche con il termine di internetwor-
king o più comunemente con la contrazione internet (termine coniato da Bob Kahn e
Vint Cerf). In particolare, quando ci si riferisce alla rete pubblica si utilizza la parola
Internet con la lettera iniziale in maiuscolo mentre con internet si fa riferimento ad un
insieme di reti utilizzate in ambito privato o aziendale. Tuttavia, per semplicità e per
evitare confusione, si utilizzano i più diffusi termini intranet o extranet per indicare un
insieme di reti private basate sul protocollo TCP/IP all’interno di una certa organizza-
zione o utilizzate per interconnettere varie aziende o organizzazioni consociate.
Come accennato, lo scopo del protocollo IP è quello di fornire i servizi di conse-
gna dei dati da un nodo sorgente ad un nodo destinazione. In modo particolare ogni
“modulo IP” (ovvero: stack TCP/IP) disponibile in qualsiasi host deve implementare le
due funzioni base di indirizzamento (addressing) e frammentazione (fragmentation)
oltre a fornire alcune funzionalità di diagnostica e segnalazione di errori (cf. RFC 791,
pag. 1; RFC 1122, pag. 26). In futuro tali funzioni possono anche essere estese (per
esempio: con l’avvento dell’IPv6).
I dati trattati dal protocollo IP prendono il nome di IP datagram. A volte si utiliz-
za anche il termine pacchetto o packet. Più precisamente si utilizza il termine data-
gramma quando si parla di comunicazione a livello IP diretta tra due host. Viceversa
si utilizza il termine pacchetto per riferirsi ad un singolo frammento di un datagram-
ma o ad un piccolo datagramma che non necessita di essere frammentato. In genere
il termine pacchetto viene utilizzato anche per indicare l’unità di informazione o PDU
scambiata tra il livello Rete ed il livello inferiore Interfaccia di Rete (livello 1 TCP/IP) o
data-link (livello 2 OSI).
IP non fornisce alcun meccanismo per aumentare il grado di affidabilità, per il
controllo del flusso o per il controllo della sequenza dei pacchetti. Questi servizi sono
demandati ad un protocollo di livello superiore come ad esempio il protocollo TCP o
il protocollo UDP.
Indirizzamento IPv4
Formato decimale e binario (RFC 791, RFC 1166)

Ogni protocollo di rete che opera a livello 3 del modello ISO/OSI, cioè a livello Rete,
necessita di un meccanismo di indirizzamento logico. Affinché un protocollo sia
instradabile, che consenta cioè la separazione in reti diverse, deve prevedere un indi-
rizzo logico separato in due parti: una che consenta di identificare univocamente la
rete di appartenenza tra tutte le reti, e una che identifichi univocamente il nodo all’in-
terno della propria rete. Un generico nodo di una rete può essere costituito da com-
puter, router, stampanti con interfaccia di rete o, più in generale, da un qualsiasi appa-
rato dotato di interfaccia di rete che, normalmente, viene chiamato host.
Origine del termine host

L’utilizzo del termine host deriva dal fatto che, originariamente, le applicazioni ed i
servizi venivano ospitati (hosted) su computer centrali, ed il collegamento avveniva
tramite l’utilizzo di terminali (TeleTYpe o TTY). I computer host venivano equipag-
62
Internet Protocol version 4 (IPv4)
giati con un sistema operativo con funzionalità Time-Sharing (per esempio: BBN
Timesharing System su DEC PDP-1, 1962).
Con l’avvento dei personal computer e la diffusione dei nuovi sistemi operativi mul-
titasking (cooperative, preemptive, multiuser) con funzionalità di rete integrati e lo
sviluppo di applicazioni di tipo client/server, il termine host può essere utilizzato sia
lato-client sia lato-server. Pertanto, in un contesto di reti di computer, il termine host
è utilizzato come sinonimo di computer in un contesto peer-to-peer (ovvero: compu-
ter che potenzialmente possono agire sia come client sia come server ed avere quindi
pari opportunità).
Gli indirizzi logici utilizzati dal protocollo IP prendono il nome di IP Address e

sono espressi in forma gerarchica su due livelli (network, host) o su tre livelli (network,
subnet, host) ed assegnati ad ogni singola interfaccia logica.
Poiché si utilizzano interfacce logiche è possibile assegnare ad una singola inter-
faccia fisica (per esempio: scheda di rete) più indirizzi IP; tale interfaccia prende il
nome di multi-homed. In alcuni casi con questo termine si identificano anche host
con più interfacce fisiche che avranno, di conseguenza, più indirizzi IP. Formalmente
a questo tipo di apparati si assegna il nome multi-homed fisici in contrapposizione ai
multi-homed logici.
Ogni IP Address è costituito da una coppia ordinata di valori, indicati rispettiva-
mente come <netID> e <hostID> o <localAddress>, della dimensione complessiva di
32-bit, cioè 4 ottetti:
<IP Address> ::= <netID> <localAddress>
oppure
<IP Address> ::= <netID> <hostID>
dove:
■ <netID>: identifica una rete all’interno di un sistema di reti interconnesse.

Tutti i nodi appartenenti alla stessa rete logica avranno lo stesso prefisso
<netID>. Da notare che non necessariamente deve esistere una relazione
uno-ad-uno tra rete fisica e rete logica. Infatti è possibile che nei casi più
semplici ad una rete fisica corrisponda un unico indirizzo logico di rete. In tal
caso, per l’interazione diretta tra tutti i nodi non è necessario disporre di
dispositivi di routing. Viceversa, è possibile avere configurazioni di reti, chia-
mate multinetting, nelle quali su una stessa rete fisica possono trovarsi diver-
se reti logiche, ciascuna identificata da un diverso indirizzo <netID>. In que-
st’ultimo caso è necessario predisporre degli appositi meccanismi di inoltro
o forwarding, necessari per garantire la visibilità tra i nodi appartenenti alle
diverse reti logiche attraverso l’utilizzo di sistemi (nodi di rete specializzati)
chiamati gateway o router.
■ <hostID> o <localAddress>: identifica univocamente ciascun nodo apparte-
nente alla stessa rete. Il valore <hostID> deve essere unico all’interno della
particolare rete considerata.
63
Parte 3
È necessario sottolineare che la coppia <netID> <hostID> deve essere unica al-
l’interno dell’intero insieme di reti interconnesse.
Per esempio, nella figura 5.2, è possibile identificare gli host o mediante una codi-
fica binaria o, per semplicità di rappresentazione, mediante una codifica esadecima-
le. In questo caso si è scelto di discriminare le due reti attraverso il primo ottetto
(netID=0x01 e netID=0x02) e dedicare gli ultimi tre ottetti come identificativo per gli
host; inoltre per semplicità grafica si è scelto di assegnare i primi due ottetti della parte
<hostID> al valore 0x0101:
Figura 5.2: Esempio di reti interconnesse con indicazione degli indirizzi

<netID>/<hostID> in esadecimale
Chi garantisce l’univocità nell’assegnazione degli indirizzi?

■ In ambito pubblico (Internet) la gestione degli indirizzi IP venne inizialmente
effettuata da Jon Postel di IANA (Internet Assigned Numbers Authority, www.ia-
na.org). A partire dal 1992 con la liberalizzazione di Internet (RFC 1466 Guide-
lines for Management of IP Address Space) sono state nominate delle Regional
Internet Registry (RIR), alle quali sono state delegate le funzioni di assegnazione
di indirizzi IP e di nomi di dominio per ciascuna area assegnata. Già in prece-
denza con la RFC 1174 (IAB Recommended Policy on Distributing Internet
Identifier Assignment and IAB Recommended Policy Change to Internet “Con-
nected” Status), nel 1990 Vint Cerf raccomandava l’utilizzo di una politica per
delegare l’assegnazione dei cosiddetti “Internet Identifier Assignment” a livello
regionale.
■ A partire dal 1998 è stata fondata una nuova organizzazione no-profit denomi-
nata ICANN (Internet Corporation for Assigned Network and Numbers,
www.icann.org) facente capo al ministero del commercio USA per coordinare
tutte le RIR del mondo.
■ Attualmente esistono cinque RIR operanti in altrettante aree geografiche del
mondo:
• APNIC (Asia Pacific Network Information Center): www.apnic.net.
• ARIN (American Registry for Internet Numbers): www.arin.net.
• LACNIC (Latin American and Caribbean Internet Addresses Registry):
www.lacnic.net.
• RIPE NCC (Réseaux IP Européens Network Coordination Centre): www.ri-
pe.net.
• AFRINIC (African Regional Internet Registry): www.afrinic.org.
64
Ai RIR fanno capo i Local Internet Registries (LIR) per il rilascio degli indirizzi IP agli
utenti finali e/o aziende. Per ulteriori dettagli cf. il capitolo 2 “Introduzione al TCP/IP,
alla scoperta di Internet”.
Il formato utilizzato internamente dal software che implementa le funzionalità

TCP/IP all’interno di un sistema operativo, prevede di rappresentare un indirizzo IP
mediante la relativa codifica binaria dei quattro ottetti, attraverso una stringa costi-
tuita da 32-bit, ad esempio:
11000000101010000000000111001000
Nota
I termini byte ed ottetti sono considerati sinonimi all’interno della maggior parte dei
sistemi operativi attuali, nei quali una “struttura” di tipo byte è implementata
mediante 8-bit. Esistono dei casi di sistemi operativi (per esempio: DEC PDP11 e
PDP8) nei quali la rappresentazione interna di 8-bit non avviene come singolo byte
ma come insieme di due nibble (gruppo di 4-bit). In questo tipo di ambienti è neces-
sario differenziare espressamente tra i due termini. In relazione a quanto esposto è
formalmente più corretto utilizzare il termine ottetto.
A questo punto è necessario definire uno standard per identificare in modo uni-
voco il network byte order cioè l’ordine di elaborazione, di trasmissione e di interpre-
tazione dei bit all’interno dei singoli ottetti e degli ottetti stessi all’interno di un indi-
rizzo IP.
Lo standard TCP/IP prevede di utilizzare la cosiddetta convenzione big endian o
left-to-right sia a livello di intero indirizzo (l’ordine con cui vengono interpretati i
quattro ottetti), sia a livello di singolo bit all’interno del generico ottetto. L’ordina-
mento di tipo big-endian prevede di considerare, all’interno di una sequenza di più
ottetti, l’ottetto di sinistra come il più significativo. Solitamente, quest’ultimo, viene
indicato con il termine MSB (Most Significant Byte) e l’ottetto meno significativo con
LSB (Least Significant Byte). Analizzando il contenuto del singolo ottetto si utilizza lo
stesso tipo di ordinamento: il bit nella posizione di sinistra è considerato più signifi-
cativo e chiamato MSb (Most Significant bit). Lo stesso ordinamento è utilizzato anche
durante la trasmissione dei dati. Questo tipo di ordinamento corrisponde all’ordine
che viene seguito per leggere lo stesso testo in italiano.
Per motivi di semplicità è prassi codificare gli ottetti con il sistema decimale,
separandoli tra loro con un punto al fine di aumentare ulteriormente la leggibilità.
Tale convenzione viene indicata come dotted decimal notation (DDN).
Pertanto, nel caso dell’indirizzo IP rappresentato in binario nell’esempio prece-
dente, il relativo formato DDN sarà come l’esempio mostrato nella tabella 5.1.
Tabella 5.1: Indirizzo IP rappresentato in binario

MSB (Most Significant Byte) LSB (Least Significant Byte)
11000000 10101000 00000001 11001000
192 168 1 200
65
Parte 3
In generale un indirizzo IP in notazione DDN è rappresentato come “a.b.c.d” o

“x.y.w.z”, dove ciascuna lettera rappresenta la codifica decimale di un ottetto.
Esprimere un indirizzo IP in formato ottale ed esadecimale

Anche se non comunemente utilizzata, esiste la convenzione che permette di espri-
mere un indirizzo IP sempre in formato dot notation ma con numeri in ottale
(Dotted Octal Notation, DON) o esadecimale (Dotted Exadecimal Notation, DEN). Al
fine di distinguere gli indirizzi IP nei formati DON o DEN dalla classica DDN è ob-
bligatorio anteporre uno 0 (zero) davanti al numero convertito in notazione ottale
con 3 cifre (83 ≥ 255) oppure nel caso decimale anteporre davanti al numero espres-
so in notazione esadecimale con 2 cifre (162 ≥ 255) il suffisso 0x.
IP DDN IP DON IP DEN

192.168.1.200 192.168.1.0310 192.168.1.0xc8
192.168.1.254 192.168.1.0x376 192.168.1.0xfe
Attenzione: come è possibile osservare dai precedenti esempi, non è necessario che
tutti gli ottetti siano espressi in DON o DEN.
1. Come è possibile osservare dai precedenti esempi, non è necessario che tutti i
quattro ottetti siano espressi in DON o DEN.
2. Da notare che l'utilizzo dei suddetti formati DON/DEN non è consentito in fase
di configurazione di un indirizzo IP per una interfaccia di rete (in qualsiasi
ambiente) ma solamente all’interno di un alcuni comandi (esempio: ping
192.168.1.0310 oppure ping 192.168.1.0xc8 oppure telnet 192.168.1.0310). A tal
proposito non tutti i comandi accettano questi formati ed alcuni accettano solo
il formato DON e non DEN (esempio: telnet).
Per ulteriori dettagli sulla conversione dei numeri decimali in binario e viceversa
fare riferimento all’appendice B “Sistemi di numerazione e conversioni”.
Tipi di indirizzi IP
A seconda del numero dei potenziali destinatari identificati da un singolo indirizzo IP
e del tipo di comunicazione instaurata tra una entità origine ed una o più entità desti-
nazione è possibile distinguere tra:
■ Indirizzi IP unicast (“indirizzo al singolare”)

È un indirizzo IP univoco assegnato ad una ben determinata interfaccia logi-
ca di un nodo. Questo tipo di indirizzo può comparire, indifferentemente, sia
come sorgente sia come destinazione di un datagramma IP. Utilizzando un
indirizzo IP di tipo unicast nel campo destinazione la comunicazione tra i
nodi è di tipo diretta o uno-a-uno. In definitiva si può indicare un indirizzo
IP di tipo unicast come un “indirizzo al singolare”, nel senso che identifica
una ben determinata interfaccia logica di rete.
66
■ Indirizzi IP broadcast (“indirizzo al plurale”)

È un indirizzo IP che serve ad identificare collettivamente tutti i nodi di una
rete. Questo tipo di indirizzo non può mai apparire come sorgente di un data-
gramma IP. Utilizzando un indirizzo IP di tipo broadcast la comunicazione è
di tipo uno-a-tutti. In definitiva, si può indicare un indirizzo IP di tipo broad-
cast come un “indirizzo al plurale” nel senso che mediante un unico indirizzo
IP si identificano tutti gli host di una stessa rete. Come vedremo più avanti
nella sezione “Indirizzi IP speciali e notazioni particolari per la loro rappre-
sentazione (RFC 1700, RFC 3232)”, esistono diversi tipi indirizzi di broadcast.
■ Indirizzi IP multicast (“indirizzo al plurale circoscritto”)
È un indirizzo IP utilizzato per identificare uno o più nodi (ma non tutti)
all’interno di una rete. Questo tipo di indirizzo non può mai apparire come
sorgente di un datagramma IP. Utilizzando un indirizzo IP di tipo multicast la
comunicazione è di tipo uno-a-molti-ma-non-tutti. In definitiva si può indi-
care un indirizzo IP di tipo multicast come un “indirizzo al plurale circoscrit-
to” nel senso che mediante un unico indirizzo IP si identifica, in tal caso, solo
un sottoinsieme di tutti gli host di una rete.
Indirizzi IP riservati: network, broadcast, multicast, loopback

Alcuni valori assegnabili alle due componenti <netID> e <hostID> sono da escludere
poiché assumono un significato particolare per il protocollo IP. Nella tabella 5.2 sono
riportati tali valori e il relativo significato attribuito dal protocollo IP.
Tabella 5.2: Indirizzi riservati

Indirizzi riservati per la parte <netID> Significato
0 Identifica la rete di appartenenza cioè this
network.
Regola no-tutti-zero: considerando la
porzione <netID> espressa in binario, vale la
regola generale secondo la quale è da
escludere un <netID> composto da tutti zeri o
all-zeros.
127 Riservato per uso diagnostico o di loopback.
Viene utilizzato per testare la corretta
installazione del software TCP/IP su un
computer.
224 Indirizzo di multicast, compreso Multicast
BackbONE (MBONE) (cf. RFC 2365).
255 Indirizzo di broadcast: identifica tutti gli host
(all hosts) presenti all’interno di una
determinata rete.
Regola no-tutti-uno: considerando la porzione
<netID> espressa in binario, vale la regola
generale secondo la quale è da escludere un
<netID> composto da tutti uno o all-ones.
67
Parte 3
Tabella 5.2: Continua

Indirizzi riservati per la parte <hostID> Significato
0 Identifica un generico nodo su una
determinata rete o this node.
Regola no-tutti-zero: questa regola è valida
anche per la componente <hostID>.
255 Indirizzo di broadcast: identifica tutti gli host
presenti all’interno di una rete o all hosts.
Regola no-tutti-uno: questa regola è valida
anche per la componente <hostID>.
Classi di indirizzamento (RFC 791, RFC 1166)

Poiché abbiamo a disposizione 32-bit il numero di indirizzi IP disponibili teoricamente
è pari a 232 cioè 4.294.967.296. In realtà, come accennato, viene introdotta una separa-
zione tra <netID> e <hostID>. Come conseguenza di questo tipo di organizzazione ge-
rarchica il numero di indirizzi IP che si possono utilizzare è inferiore. Inoltre alcuni indi-
rizzi, sia per la parte <netID> sia per la parte <hostID>, sono riservati per usi speciali.
Secondo le RFC 791 e RFC 1166, gli indirizzi IP sono organizzati in cinque classi:
A, B, C, D, E.
La classe di appartenenza di un indirizzo IP è determinata dai quattro bit più si-
gnificativi del primo ottetto (MSB). Essa determina quanti ottetti compongono la
parte <netID> e quanti la parte <hostID>, secondo quanto descritto nella tabella 5.3.
Tabella 5.3: Classi di indirizzi IP

I II III IV V VI
Classe Codifica Binaria nByN / nBiN / nN nByH / nBiH / nH Indirizzi <netID> Indirizzi <hostID>
MSB Validi Validi
IP Unicast
A 0xxxxxxx 1 / 7 / 126 3 / 24 / 16.777.214 1.b.c.d ÷126.b.c.d a.0.0.1 ÷
a.255.255.254
B 10xxxxxx 2 / 14 / 16.382 2 / 16 / 65.534 128.0.c.d ÷ a.b.0.1 ÷
191.255.c.d a.b.255.254
C 110xxxxx 3 / 21 / 2.097.150 1 / 8 / 254 192.0.0.d ÷ a.b.c.1 ÷
223.255.255.d a.b.c.254
D 1110xxxx Classe riservata per applicazioni 224÷239
Multicast
E 1111xxxx Classe riservata per uso sperimentale 240÷254
Legenda:
• nByN = Numero Byte componente <netID> • nByH = Numero Byte componente <hostID>
• nBiN = Numero Bit componente <netID> • nBiH = Numero Bit componente <hostID>
• nN = Numero di Network Valide • nH = Numero di Hosts Validi
68
Di seguito viene data una descrizione dettagliata del significato delle varie colonne.
■ Colonna I
Indica la classe di appartenenza di un indirizzo IP.
Come si può notare dalla tabella 5.3, le classi D ed E sono riservate per usi
speciali: la classe D per applicazioni di tipo multicast e la classe E per fini
sperimentali da parte di IANA.
Pertanto, le sole classi utilizzabili per l’assegnamento di indirizzi IP di tipo
unicast sono le rimanenti A, B e C.
■ Colonna II
Sono indicati i bit dell’ottetto più significativo (MSB). Come si può notare, a
seconda della classe di appartenenza, i primi quattro bit possono avere un
valore diverso, ma comunque prefissato, secondo la seguente convenzione:
• Classe A: 0 è fissato solo il primo bit.
• Classe B: 10 sono fissati solo i primi due bit.
• Classe C: 110 sono fissati solo i primi tre bit.
• Classe D: 1110 sono fissati solo i primi quattro bit.
• Classe E: 1111 sono fissati solo i primi quattro bit.
Viceversa, le “x” rappresentano delle cosiddette condizioni di indifferenza,
ovvero variabili che possono assumere sia il valore binario 0 sia 1.
■ Colonna III
Il primo numero (nByN) indica quanti ottetti sono riservati per la compo-
nente <netID>. Il secondo numero (nBiN) indica quanti sono gli effettivi bit
disponibili per la sezione <netID> all’interno di una classe, escludendo i bit
con valore prefissato (cf. Colonna II). Il terzo, indica il numero di reti o
network (nN) che si possono identificare all’interno di una determinata clas-
se, tenendo conto dei valori da escludere.
Per il calcolo del numero di network (nN) valgono le seguenti relazioni mate-
matiche:
• Classe A: nN = 27 – 2 = 126
• Classe B: nN = 214 – 2 = 16.382
• Classe C: nN = 221 – 2 = 2.097.150
nelle quali, le due potenziali reti eliminate dal conteggio relativo al numero
di network (nN) per ciascuna classe, corrispondono alla regola no-tutti-zero
e no-tutti-uno esposta in precedenza.
■ Colonna IV
Il primo numero (nByH) indica, riferendosi alla componente <hostID>, il
numero di ottetti riservati, il secondo numero (nBiH) quanti sono gli effetti-
vi bit disponibili e il terzo indica il numero di host (nH) che si possono iden-
tificare all’interno di una determinata classe. Questi valori sono calcolati
rispettando le regole no-tutti-zero e no-tutti-uno.
Per il calcolo del numero di host (nH) valgono le seguenti relazioni matema-
tiche:
69
Parte 3
• Classe A: nH = 224 – 2 = 16.777.214

• Classe B: nH = 216 – 2 = 65.534
• Classe C: nH = 28 – 2 = 254
nelle quali i due potenziali host sottratti dal conteggio corrispondono alla
regola no-tutti-zero e no-tutti-uno esposta in precedenza.
■ Colonne V e VI
Indicano qual è l’insieme dei valori ammissibili per le due componenti
<netID> e <hostID>, espressi sotto forma decimale (DDN):
• Classe A: 1.0.0.1 ÷ 126.255.255.254
• Classe B: 128.0.0.1 ÷ 191.255.255.254
• Classe C: 192.0.0.1 ÷ 223.255.255.254
È importante notare, che dal punto di vista matematico, gli indirizzi 0.0.0.0 e
127.0.0.0 rientrano nella classe A. Essi non sono stati indicati nell’elenco pre-
cedente in quanto indirizzi non assegnabili e quindi esclusi.
Osservando il valore decimale del primo ottetto della componente <netID>
di ciascun insieme si possono dedurre le seguenti regole per la determina-
zione della classe di appartenenza di un indirizzo IP:
1. Ogni indirizzo IP, il cui primo valore decimale è compreso fra 1 e 126
appartiene alla classe A.
appartiene alla classe B.
appartiene alla classe C.
Come si può notare la scelta di una classe di indirizzi IP, nella fase progettuale di
una rete, dovrebbe essere condizionata dal numero di nodi e di reti che costituiscono
la propria infrastruttura di internetworking.
L’idea iniziale della suddivisione in classi dello spazio di indirizzamento IP (IP
Address Space) nasce dalla volontà di ottimizzare l’offerta di indirizzi IP a seconda
delle necessità aziendali (tabella 5.4).
Tabella 5.4: Rapporto tra il numero di reti ed il numero di host quando si utilizzano le
classi standard
Elevato numero di host Numero medio di host Basso numero di host
Basso numero di reti Classe A
Numero medio di reti Classe B
Elevato numero di reti Classe C
Come accennato in precedenza, l’assegnazione di un indirizzo viene fatto diret-

tamente da IANA (o da una autorità di registrazione delegata). Gli indirizzi di classe A
sono concessi alle grandi organizzazioni o aziende, come ad esempio: General Elec-
tric (3), BBN (4, 8), IBM (9), ATT (12), Xerox (13), HP (15), DEC (16), Apple (17), Ford
(19). Gli indirizzi di classe C sono assegnate a piccole aziende e agli ISP che, a loro
70
volta, provvedono a rivenderli, eventualmente suddividendoli mediante tecniche

CIDR/VLSM esposte più avanti in questo capitolo.
Un altro indirizzo IP speciale: la network mask

La network mask è un particolare indirizzo IP che dovrebbe essere specificato unita-
mente all’indicazione di qualsiasi indirizzo IP associato ad una rete oppure ad un sin-
golo host.
In particolare esso è spesso imposto in fase di configurazione del protocollo
TCP/IP su un qualsiasi host con un qualsiasi sistema operativo di rete che implemen-
ta il protocollo TCP/IP. In alcuni casi (per esempio: Microsoft Win9x/NT/2K/XP/2003)
non è possibile confermare l’inserimento dell’indirizzo IP se non si compila anche il
campo riservato alla subnet mask. In altri casi (per esempio: UNIX/Linux) è possibile
assegnare un indirizzo IP ad una interfaccia logica senza necessariamente specificare
la relativa subnet mask. In tal caso viene applicata la subnet mask di default in base
alla classe di appartenenza dell’indirizzo IP.
La network mask è una “maschera, o filtro, di bit” utilizzata dal software che
implementa le funzionalità dello stack TCP/IP, per determinare la rete di appartenen-
za di un indirizzo IP. In altre parole, la subnet mask permette di identificare i confini
tra le varie network all’interno di un insieme di reti TCP/IP.
Nel caso di indirizzi IP conformi alle RFC 791 e RFC 1166 , detti anche di tipo
ClassFull, la network mask da applicare ad un qualsiasi indirizzo IP può essere auto-
maticamente determinata dalla sua classe di appartenenza, secondo la seguente
regola: una subnet mask è un indirizzo IP costituito da tanti “255” contigui a partire
dal MSB (Most Significant Byte), quanti sono gli ottetti della parte <netID>; il resto del-
l’indirizzo viene posto a zero:
<Network Mask > ::= <netID-Tutti-1> <hostID-Tutti-0>.
Come si può notare, la network mask identifica il numero di bit, sul totale dei 32
potenziali, che sono riservati alla parte <netID>.
Al fine di semplificare la scrittura di un indirizzo IP e della relativa subnet mask,
è possibile indicare entrambi attraverso la cosiddetta notazione Network Prefix, che
prevede di specificare insieme alla <netID> in formato DDN, anche il numero di bit
della maschera di rete separato per mezzo del carattere “/”; ad esempio: 10.0.0.0/8
(equivalente a 10/8) oppure 172.16.0.0/16 (equivalente a 172.16/16) 192.168.1.0/24
(equivalente a 192.168.1/24).
Nella tabella 5.5 sono riportate le network mask delle tre classi standard.
Utilizzando la network mask specificata a livello di configurazione locale, lo stack
TCP/IP (ovvero: il software che implementa le funzioni) è capace di determinare come
deve essere inoltrato un datagramma IP al destinatario:
Tabella 5.5: Subnet mask standard

Classe Formato binario Formato decimale Formato esadecimale Network Prefix
A 11111111.00000000.00000000.00000000 255.0.0.0 FF000000 /8
B 11111111.11111111.00000000.00000000 255.255.0.0 FFFF0000 /16
C 11111111.11111111.11111111.00000000 255.255.255.0 FFFFFF00 /24
71
Parte 3
■ Direttamente, se il destinatario è collocato sulla stessa rete.

■ Indirettamente attraverso il proprio default gateway se il destinatario non
appartiene alla stessa rete.
Come si può osservare ciascun nodo di una rete TCP/IP deve prendere una deci-
sione di forwarding chiamata anche local routing o internal routing. Essa si basa sul
seguente algoritmo:
1. Confronto bit-a-bit (bit-wise logical AND) tra l’indirizzo destinazione e la

network mask locale per mezzo di un’operazione di AND. Il risultato di que-
sta operazione prende il nome di RemoteNetID.
2. Confronto bit-a-bit (bit-wise logical AND) tra l’indirizzo sorgente e la
network mask locale per mezzo di un’operazione di AND. Il risultato di que-
sta operazione prende il nome di LocalNetID.
3. Confronto tra i due risultati precedenti con un’operazione di XNOR (la quale
verifica l’uguaglianza bit a bit).
4. Decisione di inoltro:
a. Se il confronto dà come risultato tutti i 32-bit ad 1 il pacchetto viene con-
siderato locale ed inviato direttamente a destinazione (vedi tabella 5.7).
b. Altrimenti il datagramma viene considerato remoto ed inoltrato al de-
fault gateway che provvederà alla consegna.
Nella tabella 5.6 sono riportate le tavole della verità delle operazioni logiche AND
e XNOR.
Tabella 5.6: Le tavole della verità delle operazioni logiche AND e XNOR
A B A AND B A B A XNOR B
0 0 0 0 0 1
0 1 0 0 1 0
1 0 0 1 0 0
1 1 1 1 1 1
Nota
Da una attenta osservazione della tavola della verità dell’operatore logico AND è
possibile esprimere quest’ultima nella forma (più concisa e di più immediata inter-
pretazione):
1 AND x = x
dove x viene indicato come condizione di indifferenza e può valere 0 oppure 1.
Questa espressione può essere così interpretata: se uno degli argomenti vale 1 il risul-
tato dell’operazione di AND coincide sempre con il valore del secondo.
Come si può evidenziare dalla tavola di verità dell’operatore XNOR, esso implemen-
ta le funzioni di verifica della uguaglianza tra i bit in ingresso (input). Cioè A XNOR
B può anche essere indicato come "A uguale B"".
72
Figura 5.3: Applicazione della subnet mask
Per meglio comprendere questo processo, si supponga di avere due reti intercon-
nesse con indirizzo rispettivamente 192.168.1.0/24 e 172.16.0.0/16 (figura 5.4).
Figura 5.4: Esempio di reti per applicazione network mask
Nella tabella 5.7 è esposto il processo nei due casi di destinazione locale e desti-
nazione remota.
Tabella 5.7: Due casi di destinazione locale e destinazione remota

Caso con destinazione locale: IP Sorgente 192.168.1.1, IP Destinazione 192.168.1.2
IP Sorgente 11000000 10101000 00000001 00000001
Network mask 11111111 11111111 11111111 00000000
LocalNetID 11000000 10101000 00000001 00000000
IP Destinazione 11000000 10101000 00000001 00000010
Network mask 11111111 11111111 11111111 00000000
RemoteNetID 11000000 10101000 00000001 00000000
(LocalNetID) XNOR 11111111 11111111 11111111 11111111
(RemoteNetID)
73
Parte 3
Tabella 5.7: Continua

Caso con destinazione remota: IP Sorgente 192.168.1.1, IP Destinazione 172.16.0.1
IP Sorgente 11000000 10101000 00000001 00000001
Network mask 11111111 11111111 11111111 00000000
LocalNetID 11000000 10101000 00000001 00000000
IP Destinazione 10101100 00010000 00000000 00000001
Network mask 11111111 11111111 00000000 00000000
RemoteNetID 10101100 00010000 00000000 00000000
(LocalNetID) XNOR 10010011 01000111 11111110 11111111
(RemoteNetID)
Quali sono i vantaggi e gli svantaggi dell’organizzazione gerarchica degli

indirizzi IP mediante l’introduzione delle classi?
■ Vantaggi:
• Riduzione delle dimensioni delle tabelle di routing. Infatti, l’utilizzo di uno
spazio di indirizzi piatto costituito da 232 = 4.294.967.296 avrebbe imposto
l’inserimento in ciascuna tabella di routing di ogni router degli indirizzi sin-
goli per ciascuna potenziale destinazione. Viceversa, l’utilizzo delle classi (e
soprattutto delle subnet, come vedremo più avanti) consente il raggruppa-
mento (summarize) degli indirizzi.
• Semplificazione nella assegnazione degli indirizzi.
• Semplificazione nella gestione degli indirizzi da parte del software dei router
(oltre che di ogni singolo nodo) con evidenti risparmi di tempo di elaborazio-
ne e quantità di memoria richiesta. Con l’evoluzione dell’hardware queste
ultime considerazioni perdono un po’ di importanza.
■ Svantaggi:
• Riduzione del numero effettivo di indirizzi IP. A tale proposito, come vedremo
più avanti parlando del subnetting VLSM/CIDR, esistono alcune tecniche per
alleviare questa perdita di indirizzi.
Indirizzi pubblici e privati (RFC 1918)

Come accennato precedentemente, se si necessita di indirizzi pubblici è necessario
rivolgersi ad un Internet Registry o ISP (cf. Capitolo 2, “Introduzione al TCP/IP, alla sco-
perta di Internet”. Al contrario, se si implementa una rete aziendale privata lo spazio
di indirizzi potenzialmente utilizzabili non è limitato o vincolato da alcuna organiz-
zazione o normativa.
Prevedendo tuttavia una futura interconnessione della rete privata alla rete pub-
blica Internet, è necessario garantire che non vi siano conflitti di indirizzi IP. Infatti, la
duplicazione di indirizzi potrebbe causare la mancata consegna dei datagrammi IP.
Al fine di evitare potenziali problemi di questo tipo, nel 1996 è stata promulgata
la RFC 1918, Address Allocation for Private Internets. Essa stabilisce alcune fasce di
indirizzi IP riservati per un utilizzo su rete privata e garantisce il confinamento a livel-
lo locale del traffico da esse generato. Ecco come recita questa RFC:
74
«… Because private addresses have no global meaning, routing information about

private networks hall not be propagated on inter-enterprise links, and packets
with private source or destination addresses should not be forwarded across such
links. Routers in networks not using private address space, especially those of
Internet service providers, are expected to be configured to reject (filter out) routing
information about private networks. If such a router receives such information the
rejection shall not be treated as a routing protocol error…».
È demandato ai router degli ISP il compito di scartare il traffico proveniente da un

indirizzo appartenente ad una rete privata.
Le reti definite come private sono:
■ Classe A: l’intera rete identificata da 10.0.0.0.

■ Classe B: le sedici reti contigue identificate da 172.16.0.0 ÷ 172.31.0.0.
■ Classe C: le 256 reti contigue identificate da 192.168.0.0 ÷ 192.168.255.0.
A queste va aggiunta anche la subnet 169.254.0.0/16 (255.255.0.0) utilizzata per

implementare l’assegnazione automatica degli indirizzi per i client DHCP (identifica-
to con il termine APIPA (Automatic Private IP Addressing)) come ratificato dalla RFC
3330 (Special-Use IPv4 Addresse”, settembre 2002) ed indicato dal seguente estratto
(pag. 2):
«… 169.254.0.0/16 – This is the “link local” block. It is allocated for communication

between hosts on a single link. Hosts obtain these addresses by auto-configuration,
such as when a DHCP server may not be found…».
Subnetting standard secondo la RFC 950 (Internet Standard

Subnetting Procedure)
Con subnetting si intende il processo di partizionamento di un’unica rete in più sot-
toreti o subnet.
La suddivisione di una rete logica in più sottoreti può essere dovuta a varie moti-
vazioni, tra cui:
■ La necessità di circoscrivere il traffico broadcast.

■ La necessità di separare i diversi enti produttivi di un’azienda.
■ La dislocazione geografica di un’organizzazione o azienda.
Broadcast e traffico di rete

Di per sé i broadcast non determinano un aumento del traffico di rete, ma provoca-
no un incremento di lavoro di elaborazione sia nei dispositivi di networking (bridge,
router, switch, schede di rete) sia sugli host. Infatti tutti gli host di una stessa rete (o
sottorete) ricevono il pacchetto di broadcast. Giunto a livello data-link questo viene
passato al driver della scheda di rete il quale lo passa al modulo di livello networking
corrispondente al protocollo indicato nel campo “Type”. Se il protocollo indicato non
75
Parte 3
è registrato su un determinato host, il driver scarta la relativa frame. Normalmente i

router vengono configurati per non inoltrare il traffico di broadcast mentre i bridge,
operando a livello data-link (livello 2 OSI), lo permettono. Pertanto, un buon disegno
ed una corretta configurazione dei dispositivi di rete consentono di limitare gli effet-
ti dei broadcast.
In questa sezione verrà presa in considerazione l’implementazione del subnet-

ting secondo le direttive della RFC 950, secondo la quale sono da non considerare vali-
de le subnet che hanno come valore nel campo <netID> tutti-0 e tutti-1, come indica-
to nel seguente estratto della suddetta RFC (pag. 5):
«… In certain contexts, it is useful to have fixed addresses with functional

significance rather than as identifiers of specific hosts. When such usage is called
for, the address zero is to be interpreted as meaning “this”, as in “this network”. The
address of all ones are to be interpreted as meaning “all”, as in “all hosts”. For
example, the address 128.9.255.255 could be interpreted as meaning all hosts on
the network 128.9. Or, the address 0.0.0.37 could be interpreted as meaning host 37
on this network».
It is useful to preserve and extend the interpretation of these special addresses in

subnetted networks. This means the values of all zeros and all ones in the subnet
field should not be assigned to actual physical) subnets…».
Mediante questa tecnica è possibile suddividere logicamente una rete in un insie-

me contiguo di sottoreti di dimensioni ridotte, in modo da ottimizzare l’uso degli indi-
rizzi IP.
In pratica l’indirizzo IP di partenza espresso come:
<IP Address> ::= <netID> <hostID>
assumerà la nuova forma:
<IP Address> ::= <netID> <subNetID> <hostId>
nella quale la parte <hostId> viene suddivisa in due componenti: <subNetID> e

<hostID>. Così facendo il numero dei bit riservati alla sezione rete si espande a disca-
pito di quelli dedicati ai singoli nodi.
Analogamente anche la network mask verrà estesa comprendendo la parte di
subnet mask:
<Network Mask > ::= <netID-Tutti-1> <subNetID-Tutti-1> <hostID-Tutti-0>.
Comunemente, la network mask di un indirizzo derivato da subnetting prende il

nome di subnet mask. Spesso i due termini vengono utilizzati come sinonimi.
Il ripartizionamento dei bit della componente <hostID> obbliga a ricalcolare la
subnet mask da associare agli indirizzi IP delle nuove subnet. A tale proposito è da
osservare che, a differenza di quanto visto riguardo agli indirizzi IP di tipo ClassFull
per i quali la subnet mask può essere anche non esplicitamente indicata insieme
76
all’indirizzo IP, per un indirizzo ottenuto mediante il procedimento di subnetting l’in-

dicazione della subnet mask associata è di fondamentale importanza, al fine di con-
ferire ad esso “significato” e “consistenza”. Infatti proprio per evidenziare questo
aspetto, gli indirizzi IP derivati da un procedimento di subnetting vengono chiamati
anche di tipo ClassLess e per essi non valgono tutte le considerazioni precedentemen-
te fatte sulle classi in base alle RFC 791 e RFC 1166.
Per convenzione, per estrapolare la parte <subNetID> dall’originale <hostID> si
selezionano i bit strettamente necessari e contigui di ordine superiore cioè a partire
da quello più significativo.
Questo tipo di operazione è fattibile solamente se non tutti i bit della parte
<hostID> sono strettamente necessari, ovvero solo se il numero dei nodi realmente
presenti nella rete di partenza è inferiore al numero massimo dei potenziali nodi con-
sentiti dalla classe di appartenenza dell’indirizzo IP.
Per poter determinare con facilità gli indirizzi delle nuove subnet, dei rispettivi
host e la nuova subnet mask, è necessario rivedere alcuni concetti relativi all’algebra
binaria e ricavare alcune relazioni formali che vediamo qui di seguito.
Matematica degli indirizzi IP

Definite le seguenti variabili:
• nN = Numero di Network
• nS = Numero di Subnet
• nBiN = Numero di Bit della parte <netID>
• nBiS = Numero di Bit della parte <subNetID>
• nH = Numero di Host
• nBiH = Numero di Bit della parte <hostID>
• nBiSM = Numero di Bit appartenenti alla subnet mask
valgono le seguenti relazioni:
• Numero di Bit rimanenti per la parte <hostID>: nBiH = 32 – (nBiN + nBiS)

• Numero Host Per Subnet: nH = 2nBiH – 2
• Numero di subnet secondo RFC 950: nS = 2nBiS – 2
• Subnet mask in formato Network Prefix: nBiSM = (nBiN + nBiS)
Ricavato il numero di bit da dedicare alla parte subnet (nBiS) e alla parte host
(nBiH) è possibile ottenere gli indirizzi delle nS subnet e degli nH host considerando
la rappresentazione binaria dei singoli ottetti interessati dal processo di subnetting.
Esempio di subnetting di un indirizzo di classe C

Nell’esempio della figura 5.5 è assegnata una rete di classe C avente l’indirizzo
192.168.1.0/24 nella quale si suppone non siano presenti più di 100 nodi. Volendo
suddividere questa rete in due sottoreti, è necessario ricavare gli indirizzi IP delle due
nuove subnet dei rispettivi host, nonché la nuova subnet mask.
77
Parte 3
Figura 5.5: Subnetting di una rete di classe C, in due sottoreti secondo le direttive
RFC 950.
Ricavare gli indirizzi IP delle nS nuove subnet e la subnet mask

Essendo nS = 2 il numero di subnet da creare è possibile dedurre il numero di bit
necessari da riservare alla parte <subNetID>, risolvendo la seguente disequazione:
2nBiS – 2 ≥ nS
dalla quale si deduce il valore minimo da assegnare alla variabile nBiS, cioè 2.
Trattandosi di un indirizzo iniziale di classe C, i suddetti 2-bit vengono sottratti
dal quarto ottetto (<hostID>). Inoltre, per quanto detto in precedenza, la separazione
dei bit avviene sempre a partire dal bit di ordine superiore e in modo contiguo.
A questo punto, applicando la relazione seguente, ricaviamo il numero di bit
facenti parte della nuova subnet mask:
nBiSM = nBiN + nBiS = 24 + 2 = 26.
Quindi, nella tabella 5.8 viene mostrata la rappresentazione binaria e decimale

della nuova subnet mask, nella quale viene messo in evidenza l’ottetto interessato dal
processo di subnetting:
Tabella 5.8: Rappresentazione binaria e decimale della nuova subnet mask

MSB (Most Significant Byte) LSB (Least Significant Byte)
11111111 11111111 11111111 11000000
255 255 255 192
A questo punto per ricavare gli indirizzi IP da assegnare alle due nuove subnet, è
necessario ragionare sui 2-bit di subnetting dell’ultimo ottetto evidenziando tutte le
potenziali configurazioni (quattro, 22) che si possono ottenere assegnando ad essi i
due valori possibili 0 ed 1 (tabella 5.9).
Da ciò, scartando le due configurazioni tutti-0 (valore decimale 0) e tutti-1 (valo-
re decimale 192), si ottengono le due subnet 192.168.1.64/26 e 192.168.1.128/26 della
tabella 5.9.
78
Tabella 5.9: Processo di derivazione dell'indirizzo IP delle due subnet per l'esempio
di figura 5.5
Conversione da binario in decimale del quarto ottetto
Posizione 7 6 5 4 3 2 1 0
Peso =
2posizione 128 64 32 16 8 4 2 1
Valore decimale Configurazioni possibili
<subNetID> <hostID>
0 0 0 0 0 0 0 0 0
64 0 1 0 0 0 0 0 0
128 1 0 0 0 0 0 0 0
192 1 1 0 0 0 0 0 0
Determinare il numero nH degli host ed i relativi indirizzi IP

Per calcolare il numero nH di host di ciascuna nuova subnet ed i relativi indirizzi IP, è
necessario considerare la parte rimanente di bit relativa alla sezione <hostID>. In
generale questo numero di bit è dato da:
nBiH = 32 – (nBiN + nBiS).
Nel nostro caso sarà:
nBiH = 32 – (24 + 2) = 6.
Per cui il numero di host sarà:
nH = 2nBiH – 2 = 26 – 2 = 62.
A questo punto per dedurre gli indirizzi IP da assegnare ai 62 host di ciascuna

subnet, è necessario ragionare sui rimanenti nBiH = 6-bit della parte <hostID> evi-
denziando tutte le potenziali 26 – 2 = 62 configurazioni che si possono ottenere asse-
gnando ad essi i due valori possibili 0 ed 1, e scartando quelli che identificano un indi-
rizzo <hostID> formato da tutti-0 o tutti-1 (tabella 5.10).
Pertanto, per ciascuna delle due subnet la lista degli host è la seguente:
Subnet 192.168.1.64.0: Host: 192.168.1..65 ÷ 192.168.1.126; Broadcast = 192.168.1.127.

Subnet 192.168.1.128: Host: 192.168.1..129 ÷ 192.168.1.190; Broadcast = 192.168.1.191.
Prima di concludere l’argomento del subnettting standard, nel prossimo esempio

verrà presa in considerazione una rete di classe A; si utilizzeranno, inoltre, degli inte-
ri ottetti per produrre le subnet.
79
Parte 3
Tabella 5.10: Processo di derivazione degli indirizzi IP degli host per le due subnet dell'esempio di figura 5.5
Valore decimale Configurazioni possibili
<subNetID> <hostID>
Prima subnet 64=tutti-0 ‡ hostID 0 1 0 0 0 0 0 0
65 0 1 0 0 0 0 0 1
… 0 1 X X X X X X
126 0 1 1 1 1 1 1 0
127=tutti-1 ‡ hostID 0 1 1 1 1 1 1 1
Seconda subnet 128=tutti-0 ‡ hostID 1 0 0 0 0 0 0 0
129 1 0 0 0 0 0 0 1
… 1 0 X X X X X X
190 1 0 1 1 1 1 1 0
191=tutti-1 ‡ hostID 1 0 1 1 1 1 1 1
Esempio di subnetting in classe A con l’utilizzo di un numero intero di ottetti

Si supponga di dover preparare un piano per l’indirizzamento IP ad uso interno, per
un’azienda avente 4 sedi sul territorio italiano (per esempio: Milano, Roma, Cagliari,
Palermo). In ciascuna sede sono previste inizialmente 3 subnet contenenti al massi-
mo 200 nodi.
Al fine di poter implementare un tipo di “indirizzamento gerarchico” che sia fles-
sibile, razionale, e che garantisca un certo margine di crescita in futuro, si utilizzerà un
indirizzo privato di classe A 10.0.0.0/8.
A questo punto, ragionando sulla struttura di un tipico indirizzo di classe A (1
ottetto per la parte <netID> e tre ottetti per la componente <hostID>) è da notare che
la parte <hostID> è effettivamente sovradimensionata per questo scenario, dovendo
garantire un numero massimo di nodi per ciascuna sede pari a 200. Pertanto, anziché
utilizzare 3 ottetti (24-bit) per l’identificazione dei 200 nodi, si riserverà solamente
uno (8-bit) alla parte <hostID>, tramite il quale si potranno identificare, comunque,
fino ad un massimo di 28 – 2 = 254 nodi. I rimanenti due ottetti, e precisamente quel-
li immediatamente dopo il MSB (Most Significant Byte), saranno fatti agire come una
estensione ai bit della sezione <netID> utilizzati per evidenziare delle sottoreti o sub-
net. In particolare, in questo esempio si darà un significato mnemonico ai suddetti
due ottetti, nel seguente modo:
• Secondo ottetto: verrà utilizzato per indicare la subnet di una generica sede,
secondo la seguente convenzione: 1=Milano, 2=Roma, 3=Cagliari, 4=Pa-
lermo.
• Terzo ottetto: verrà utilizzato per indicare una generica subnet di una gene-
rica sede.
Avendo utilizzato i primi tre ottetti per identificare la parte “<netID> +

<subNetID>” la subnet mask per i singoli host sarà costituita da 24-bit. Viceversa, le
reti intermedie avranno subnet mask pari a 16-bit e quella di partenza sarà rimasta
invariata.
80
Riepilogando, lo schema degli indirizzi IP appena ricavato, può essere rappresen-

to nella forma descritta nella tabella 5.11.
Tabella 5.11: Schema degli indirizzi IP

Spazio di indirizzamento iniziale: 10.0.0.0/8
10.1.0.0/16 10.1.1.0/24 Subnet 1 Milano
10.1.2.0/24 Subnet 2 Milano
10.1.3.0/24 Subnet 3 Milano
10.2.0.0/16 10.2.1.0/24 Subnet 1 Roma
10.2.2.0/24 Subnet 2 Roma
10.2.3.0/24 Subnet 3 Roma
10.3.0.0/16 10.3.1.0/24 Subnet 1 Cagliari
10.3.2.0/24 Subnet 2 Cagliari
10.3.3.0/24 Subnet 3 Cagliari
10.4.0.0/16 10.4.1.0/24 Subnet 1 Palermo
10.4.2.0/24 Subnet 2 Palermo
10.4.3.0/24 Subnet 3 Palermo
Subnetting e protocolli di routing

In questa sezione viene trattato l’aspetto matematico del subnetting e non vengono
presi in conto, volutamente, considerazioni legate al tipo di protocolli di routing da
selezionare. A tale proposito, come si vedrà nella sezione dedicata ai protocolli di
routing, è necessario valutare attentamente quale protocollo implementare sui rou-
ter in caso di subnetting soprattutto di tipo VLSM/CIDR, laddove la subnet mask è
per definizione variabile e quindi il protocollo di routing deve interpretare i singoli
indirizzi estrapolandoli dalla classe di appartenenza standard (A, B, C). Infatti, se
così non fosse, un protocollo di routing in un contesto di subnetting in classe A come
quello dell’esempio precedente, valuterebbe tutte gli indirizzi del tipo 10.x.y.0 come
appartenenti alla stessa network di classe A 10.0.0.0/8.
I protocolli di rounting che “ragionano” in questo modo vengono definiti di tipo
ClassFull (per esempio: RIPv1).
Viceversa, i protocolli che applicano sempre e comunque la subnet mask al fine di
stabilire la subnet di appartenenza di un indirizzo IP vengono definiti di tipo
ClassLess. Alcuni esempi di protocolli di questo tipo sono: RIPv2 e OSPF. In tal caso si
dice anche che essi applicano dei meccanismi di “summarization” al fine di sintetiz-
zare l’identificazione di gruppi di host in base alla subnet mask specificata. Per con-
tro, i protocolli di tipo ClassFull applicano dei criteri di “auto-summarization” ba-
sandosi esclusivamente sulla valutazione della classe standard di appartenenza del-
l’indirizzo IP.
81
Parte 3
Subnetting VLSM e CIDR (RFC 1518, RFC 1519,

RFC 1520, RFC 1812, RFC 1878, RFC 2644)
La procedura di subnetting vista nella sezione precedente obbliga a creare delle sub-
net aventi tutte le stesse dimensioni e, soprattutto, a scartare le due subnet costituite
dai bit tutti-0 e tutti-1, come riportato brevemente nel seguente estratto dalla RFC
1812 (pag. 48):
«… IP addresses are not permitted to have the value 0 or –1 for the <Host-number>
or <Network-prefix> fields except in the special cases listed above. This implies
that each of these fields will be at least two bits long.
DISCUSSION
Previous versions of this document also noted that subnet numbers must be
neither 0 nor -1, and must be at least two bits in length. In a CIDR world, the
subnet number is clearly an extension of the network prefix and cannot be
interpreted without the remainder of the prefix. This restriction of subnet numbers
is therefore meaningless in view of CIDR and may be safely ignored…».
Con l’ormai cronica carenza di indirizzi IP ciò potrebbe costituire un ulteriore

problema. Ecco allora che se i router utilizzati all’interno di una infrastruttura di inter-
networking, soddisfano le specifiche RFC 1812, RFC 1878, CIDR (Classless Inter-
Domain Routing) e VLSM (Variable Length Subnet Mask), è possibile rivedere le rego-
le di subnetting precedentemente definite, riutilizzando anche le due subnet tutti-0 e
tutti-1.
Pertanto, per quanto esposto nella sezione del subnetting standard (RFC 950), è
possibile rivedere le formule relative alla “Matematica degli indirizzi IP”, nelle quali è
possibile modificare l’equazione per la determinazione del numero nS di subnet che
diventerà:
numero di subnet secondo RFC 1812, RFC 1878, CIDR/VLSM: nS = 2nBiS
Per spiegare il funzionamento di questa nuova modalità di subnetting ecco un

esempio pratico.
Esempio di subnetting VLSM di un indirizzo in classe C

Si dispone della seguente subnet di classe C 192.192.192.0/24 contenente 205 nodi. Si
suppone di avere a disposizione un router dotato di quattro porte LAN che supporta
CIDR/VLSM. Si vuole suddividere l’unica rete (fisica e logica) attuale in tre sottoreti: la
prima rete (A) composta da 120 computer; la seconda (B) contenente 60 computer, e
la terza (C) costituita da 25 computer. Inoltre si prevede di dover aggiungere altri
computer in futuro e, pertanto, si vuole predisporre un’altra rete (D) per eventuali altri
25 nodi, in modo da non dover modificare successivamente il piano di indirizzamen-
to stabilito.
Per risolvere tale problema è necessario iniziare a determinare il numero di bit
(nBiH) da assegnare alla porzione <hostID> e tali da garantire l’implementazione
della subnet più grossa (A con 120 nodi). A tale proposito è sufficiente risolvere la
seguente disequazione binaria:
2nBiH – 2 ≥ 120
82
dalla quale si ricava il minimo valore di nBiH che soddisfa la disequazione. Cioè: nBiH
= 7.
Trattandosi di un indirizzo di classe C i bit (nBiS) da utilizzare per la parte
<subNetID> sono da estrarre dal quarto ottetto (<hostID>). In particolare si ottiene:
nBiS = 8 – nBiH = 8 – 7 = 1
e di conseguenza, il numero di subnet possibili è dato da:
nS = 2nBiS = 21 = 2
Infine, è possibile ricavare anche la subnet mask in formato network prefix (come
numero di bit) per queste due prime subnet:
nBiSM = nBiN + nBiS = 24 + 1 = 25.
Pertanto, le prime due subnet che si possono dedurre assegnando all’unico bit
nBiS i due valori possibili, sono: 192.192.192.0/25 e 192.192.192.128/25, come indica-
to nella tabella 5.12.
Tabella 5.12: Deduzione degli indirizzi IP per le due subnet iniziali

<subNetID> <hostID>
Posizione 7 6 5 4 3 2 1 0
Peso = 128 64 32 16 8 4 2 1
2posizione
0 0 0 0 0 0 0 0 0
128 1 0 0 0 0 0 0 0
A questo punto, si sceglie la prima delle due subnet (192.192.192.0/25) come A e

si prosegue con il ripartizionamento della seconda subnet 192.192.192.128/25 per
ricavare le altre subnet B, C ed D.
Tenendo conto che la subnet B deve contenere 60 nodi è necessario ricavare
come fatto in precedenza per la subnet A, il numero di bit (nBiH) tale per la nuova
parte <hostID> per cui risulti:
2nBiH – 2 ≥ 60
dalla precedente equazione si ricava il minimo valore di nBiH che soddisfa la dise-
quazione. Cioè: nBiH = 6.
Pertanto, il numero di bit (nBiS) da utilizzare per la parte <subNetID> è dato da:
nBiS = 8 – nBiH = 8 – 6 = 2
in tale caso, però, il numero di subnet utilizzabili non è pari a:
83
Parte 3
nS = 2nBiS = 22 = 4
ma coincide con 2, in quanto dei due bit della parte <subNetID> il primo ha un valo-
re prefissato (1) trattandosi della subnet iniziale 192.192.192.128 (tabella 5.13).
Tabella 5.13: Deduzione degli indirizzi IP per le due nuove subnet (da notare che il bit
in posizione 7 è fisso a 1)
<subNetID> <hostID>
Posizione 7 6 5 4 3 2 1 0
Peso = 128 64 32 16 8 4 2 1
2posizione
128 1 0 0 0 0 0 0 0
192 1 1 0 0 0 0 0 0
Per quanto riguarda la nuova subnet mask vale la seguente relazione:
nBiSM = nBiN + nBiS = 24 + 2 = 26.
Pertanto, le subnet ricavate in questa seconda fase di subnetting sono le seguen-

ti: 192.192.192.128/26 e 192.192.192.192/26.
A questo punto si sceglie la prima delle due subnet (192.192.192.128/26) come
subnet B e si prosegue con il ripartizionamento della seconda subnet 192.192.192.
192/26 per ricavare le altre subnet D ed E.
Tenendo conto che la subnet D deve contenere 25 nodi è necessario ricavare il
numero di bit (nBiH) tale per la nuova parte <hostID> per cui risulti:
2nBiH – 2 ≥ 25
dalla quale ricaviamo il minimo valore di nBiH che soddisfa la disequazione. Cioè:
nBiH = 5.
Pertanto, il numero di bit (nBiS) da utilizzare per la parte <subNetID> è dato da:
nBiS = 8 – nBiH = 8 – 5 = 3
in tale caso, però, il numero di subnet da considerare non è pari a:
nS = 2nBiS = 23 = 8
ma coincide con 2, in quanto dei tre bit della parte <subNetID> i primi due hanno un
valore prefissato (11) trattandosi della subnet iniziale 192.192.192.192 (tabella 5.14)
84
Tabella 5.14: Deduzione degli indirizzi IP per le due nuove subnet (da notare che i
primi due bit più significativi hanno valore fisso a 1).
<subNetID> <hostID>
Posizione 7 6 5 4 3 2 1 0
Peso = 128 64 32 16 8 4 2 1
2posizione
192 1 1 0 0 0 0 0 0
224 1 1 1 0 0 0 0 0
Per quanto riguarda la nuova subnet mask vale la seguente relazione:
nBiSM = nBiN + nBiS = 24 + 3 = 27.
Pertanto, le subnet ricavate in questa terza fase di subnetting sono le seguenti:

192.192.192.192/27 e 192.192.192.224/27.
Lo schema degli indirizzi IP appena ricavato può essere rappresentato nella for-
ma descritta nella tabella 5.15.
Tabella 5.15: Processo di derivazione degli indirizzi IP delle quattro subnet (A. B, C e D), degli host
e di broadcast per ciascuna delle subnet.
Spazio di indirizzamento iniziale: 192.192.192.0/24
(A)192.192.192.0/25 126 Host: 1 ÷ 126
127 = Broadcast
192.192.192.128/25→ (B)192.192.192.128/26 62 Host: 129 ÷ 190
191 = Broadcast
192.192.192.192/26‡ (C)192.192.192.192/27 30 Host: 193 ÷ 222
223 = Broadcast
(D)192.192.192.224/27 30 Host: 225 ÷ 254
255 = Broadcast
Perché si chiama VLSM (Variable Length Subnet Mask)?

Come si può notare dagli esempi visti finora, l’idea alla base delle tecniche
VLSM/CIDR, che spiega il perché di questo nome, è quella di assegnare a ciascuna
subnet il numero più adatto di bit evitando inutili sprechi; in altre parole, consenti-
re di creare subnet di dimensioni variabili.
Supernetting o CIDR/VLSM (RFC 1518, RFC 1519,

RFC 1520, RFC 1812, RFC 1878, RFC 2644)
La tecnica di supernetting o CIDR/VLSM definisce una convenzione per aggregare
(summarize) un insieme di indirizzi IP contigui in un singolo indirizzo al fine di sem-
85
Parte 3
plificarne il relativo trattamento. Il termine supernetting nasce in contrapposizione al

subnetting; infatti, mentre quest’ultimo permette di suddividere una rete in più sub-
net, con il supernetting è possibile raggruppare più subnet IP in una sola, mediante
l’applicazione di una nuova subnet mask. Le nuove subnet create con la tecnica CIDR
sono definite “supernet” in quanto permettono di ospitare più indirizzi IP di una nor-
male subnet standard di classe C (254) o B (65.534).
A differenza del subnetting, che sottrae dei bit dalla parte <hostID>, il supernet-
ting “ne prende in prestito” dalla parte <netID>. Inoltre, mentre il subnetting utilizza i
primi nBiS (numero di bit della parte subnet) bit contigui della parte <hostID> a par-
tire dal più significativo, il supernetting utilizza gli ultimi nBiC bit (numero di bit
CIDR) della parte <netID> a partire dal meno significativo.
Questa strategia è utilizzata soprattutto per:
■ Ridurre le dimensioni delle tabelle di routing attraverso l’aggregazione delle

entry.
■ Gestire in maniera più selettiva l’assegnazione degli indirizzi IP da parte degli
ISP (Internet Service Provider) agenti come Local Internet Registry.
Indirizzi IP di tipo Provider Indipendent (PI) e Provider Aggregate (PA)

(cf. Documento RIPE-127)
Generalmente gli indirizzi IP unicast globali assegnabili da un ISP si possono classi-
ficare in:
■ Provider Indipendent (PI): sono in genere rilasciati da un Internet Registry e non
vincolano un utente ad un determinato ISP.
■ Provider Aggregate (PA): sono rilasciati direttamente da un ISP ed hanno validità
fintanto che l’utente rimane contrattualmente legato ad esso.
Per spiegare il funzionamento del supernetting facciamo un esempio pratico: si

supponga che un’azienda richieda ad un ISP 2000 indirizzi IP. Non avendo a disposi-
zione una classe B da assegnare al proprio cliente, l’ISP vuole assegnare un gruppo di
8 indirizzi di classe C contigui:
192.192.192.0/24
192.192.193.0/24
192.192.194.0/24
192.192.195.0/24
192.192.196.0/24
192.192.197.0/24
192.192.198.0/24
192.192.199.0/24
Notazione network prefix e notazione CIDR

A volte la notazione network prefix attraverso la quale è possibile indicare in forma
abbreviata un indirizzo IP e la relativa subnet mask (per esempio: 192.192.192.0/24)
viene anche indicata come notazione CIDR.
86
Di seguito si analizzerà come sia possibile determinare l’indirizzo IP della “super-

net” da utilizzare per aggregare le 8 subnet.
Per risolvere tale problema è possibile seguire due metodi.
Metodo 1
Calcolare il numero di bit da riservare al CIDR (nBiC) da estrapolare dalla parte
<NetID> e tali da consentire di identificare le 8 subnet. A tale proposito è sufficiente
risolvere la seguente disequazione binaria:
2nBiC ≥ 8
dalla quale si ricava il minimo valore di nBiC che soddisfa la disequazione. Cioè: nBiC
= 3.
Trattandosi di un indirizzo iniziale di classe C gli nBiC bit da utilizzare per il
supernetting sono da prelevare dall’ultimo ottetto della parte <netID> a partire dal bit
meno significativo. Pertanto, la subnet mask risulta essere:
nBiSM = nBiN - nBiC = 24 - 3 = 21
oppure, in notazione decimale: 255.255.248.0.

A questo punto il supernetting prevede di aggregare le 8 subnet specificando l’in-
dirizzo IP della prima subnet del gruppo unitamente alla subnet mask derivata, cioè:
192.192.192.0/21
oppure, in notazione decimale:
192.192.192.0/255.255.248.0.
Così facendo l’ISP risparmia l’inserimento nel proprio router le 8 entry relative
alle 8 subnet e può specificare solo l’indirizzo sopra indicato.
Metodo 2
Si convertano in binario gli indirizzi delle 8 classi da aggregare:
11000000 11000000 11000000 00000000

11000000 11000000 11000001 00000000
11000000 11000000 11000010 00000000
11000000 11000000 11000011 00000000
11000000 11000000 11000100 00000000
11000000 11000000 11000101 00000000
11000000 11000000 11000110 00000000
11000000 11000000 11000111 00000000
A questo punto è sufficiente considerare l’insieme dei bit contigui a partire dal
più significativo condivisi da tutte le subnet appartenenti alla “supernet”:
11000000 11000000 11000 → /21
87
Parte 3
In questo modo è stata determinata la subnet mask in formato network prefix la

quale associata all’indirizzo IP della prima subnet del gruppo determina l’indirizzo IP
di supernet di aggregazione: 192.192.192.0/21.
Rappresentazione delle classi di indirizzi IP riservati dalla RFC 1918 in notazione

VSLM/CIDR
Come ultimo esempio di utilizzo del subnetting, ecco un riepilogo delle tre fasce di
indirizzi IP riservati per uso privato secondo la RFC 1918, utilizzando una notazio-
ne VLSM/CIDR:
Classe Notazione nBiH IP Disponibili secondo

Network (Num. Bit <hostId>) la Notazione ClassFull
Prefix VLSM
/CIDR
A 10.0.0.0/8 24 (“24-bit-block”) 10.0.0.0 ÷ 10.255.255.255
B 172.16.0.0/12 20 (“20-bit-block”) 172.16.0.0 ÷ 172.31.255.255
Attenzione: La notazione
172.16.0.0/12 esprime
l’aggregazione CIDR delle
31 subnet di classe B.
C 192.168.0.0/16 16 (“16-bit-block”) 192.168.0.0 ÷ 192.168.255.255
Attenzione: La notazione
192.168.0.0/16 esprime
l’aggregazione CIDR delle 256
subnet di classe C.
Uno strumento di grande aiuto: la calcolatrice per le Subnet IP

Fermo restando che la via migliore per imparare bene i procedimenti di subnetting e
supernetting è utilizzare i principi esposti nella sezione “Matematica degli indirizzi
IP”, l’uso della calcolatrice è di grande aiuto come strumento di verifica della corret-
tezza dei risultati ottenuti manualmente.
Una versione di calcolatrice molto utilizzata è la “IP Subnet Calculator” scaricabile
gratuitamente dal sito http://www.wildpackets.com/products/ipsubnetcalculator.
Indirizzi IP speciali e notazioni particolari

per la loro rappresentazione (RFC 1700, RFC 3232)
Con la diffusione delle tecniche di subnetting VLSM e CIDR, sorge l’esigenza di avere
a disposizione una modalità più concisa per riassumere alcuni indirizzi IP speciali.
Note sulla RFC 1700

La RFC 1700 è stata resa obsoleta dalla RFC 3232. In realtà le informazioni prima
indicate nella RFC 1700 adesso sono contenute direttamente sul sito www.iana.org.
88
A tale proposito, con la RFC 1700 resa obsoleta dalla RFC 3232, sono state defini-
te le seguenti convenzioni:
a) Un indirizzo IP può assumere una delle due seguenti forme:

IP Address ClassFull ::= {<netID> <hostID>}
IP Address ClassLess ::= {<netID> <subnetID> <hostID>}
b) -1
Specificato al posto di <netID> o <subNetID> o <hostID> serve ad indicare
che il relativo campo è costituito interamente da bit di valore 1.
c) 0
Specificato al posto di <netID> o <subNetID> o <hostID> serve ad indicare
che il campo è costituito interamente da bit di valore 0.
d) Indirizzo IP tutti-0: {0, 0}
Identifica “questo nodo”(this host) su “questa rete” (this network). Può essere
utilizzato solamente nel campo source address di un datagramma IP.
Questo indirizzo speciale è tipicamente utilizzato nel caso di un host confi-
gurato per ottenere un indirizzo IP dinamicamente (DHCP, BOOTP). Infatti
in fase di startup non possedendo ancora un indirizzo, il nodo invierà una
richiesta (per esempio: DHCPRequest) nel cui campo indirizzo IP sorgente ci
sarà il valore 0.0.0.0, ad indicare un “generico nodo su questa generica rete”.
Alcuni usi speciali dell’indirizzo tutti-0

a. In alcuni casi, come ad esempio quelli trattati nei punti seguenti, l’indirizzo IP
tutti-0 viene utilizzato anche come network mask.
b. Nel caso di un computer predisposto per ricevere un indirizzo IP dinamico (per
esempio: client DHCP), la configurazione IP iniziale (ottenuta per esempio
mediante il comando ipconfig –all in caso di computer Win2K/XP/2003 o ifconfig
in caso di computer Linux) prevede: IP Address = 0.0.0.0, Subnet Mask = 0.0.0.0.
c. Può essere utilizzato anche nelle tabelle di routing per identificare l’indirizzo di
rete di destinazione (network entry) per il Default Route, utilizzato come “percor-
so” di default verso una destinazione da raggiungere in assenza di altre “percor-
si” più specifiche. Infatti, inserendo i comandi netstat –r o route print su un com-
puter con sistema operativo Win2K/XP/2003 o netstat –r o route –n su un com-
puter con sistema operativo Linux si ottiene:
Network Destination Netmask/Genmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.200 20
Da cui si evince che 192.168.1.254 è proprio il default gateway. Da notare che la

entry 0.0.0.0 non appare se non è stato specificato alcun default gateway.
d. Sempre a proposito di gestione delle tabelle di routing nel caso di un computer
con sistema operativo Win2K/XP/2003, per inserire la entry relativa al Default
89
Parte 3
Route, per esempio con l’indirizzo di default gateway 192.168.1.254, è necessario

inserire il seguente comando:
route add 0.0.0.0 mask 0.0.0.0 192.168.1.200
nel quale viene specificata la network mask come 0.0.0.0.
e. In ambito Cisco il Default Route viene spesso indicato anche con il nome “Gate-
way of Last Resort” per la configurazione del quale viene utilizzato il seguente
comando:
ip route 0.0.0.0 0.0.0.0 <Default Gateway>.
e) Indirizzo di una rete o “This” Network: {<netID>, 0}

Come già detto precedentemente il valore 0 per il campo <hostID> non è
ammesso. Infatti un indirizzo IP in cui il valore della porzione <hostID> è 0
(tutti i bit a zero) identifica la rete <netID> nel suo complesso. Non può esse-
re utilizzato né come source address né come destination address.
Per esempio, l’indirizzo 192.168.1.0/24 indica la rete 192.168.1 mentre l’indi-
rizzo 172.26.0.0/16 indica la rete 172.26.
f) {0, <hostID>}
Identifica il nodo <hostID> su “questa rete” (this network). Può essere utiliz-
zato solo come source address.
Per esempio, l’indirizzo 0.0.0.12/24 indica l’host 12 di una generica rete ca-
ratterizzata dall'avere 24-bit dedicati alla parte <netID><subNetID> (consi-
derando anche l'eventualità di subnetting).
g) Limited o Local Broadcast: {-1, -1}
Indica un indirizzo di broadcast limitato o limited broadcast del tipo
255.255.255.255. Spesso viene indicato anche come local broadcast. Può
essere utilizzato solo come destination address in ambito circoscritto (limi-
ted) alla rete locale d’origine: infatti non richiede di specificare alcun indiriz-
zo di <netID>. Un datagramma IP con questo indirizzo di destinazione non
può mai essere reinstradato all’esterno della rete d’origine.
h) Network Broadcast (ClassFull): {<netID>, -1}
Indica un indirizzo di broadcast per una rete con indirizzi IP ClassFull. Può
essere utilizzato solo come destination address.
È ottenuto direttamente dall’indirizzo IP della rete <netID> popolando con 1
il campo <hostID>. Per esempio per la rete 172.26.0.0/16 l’indirizzo di broad-
cast diretto è 172.26.255.255.
A differenza dell’indirizzo di broadcast limitato richiede di specificare la
<netID>.
Un datagramma IP con un indirizzo IP di questo tipo è rivolto a tutti i nodi
appartenenti alla rete identificata da <netID>. Pertanto se ricevuto da un
router lo costringe ad inoltrare il datagramma stesso a tutti i nodi della rete
<netID>.
I router possono essere configurati per non reinstradare questo tipo di data-
grammi in modo da limitare il relativo traffico di broadcast.
90
i) Subnet o Directed Broadcast (ClassLess): {<netID>, <subnetID>, -1}

Indica un indirizzo di broadcast diretto per una subnet (subnet o directed
broadcast) per una rete con indirizzi di tipo ClassLess. Può essere utilizzato
solo come destination address.
È ottenuto direttamente dall’indirizzo IP indicato nel campo <netID>
<subNetID>, popolando con 1 il campo <hostID>.
Per esempio per le subnet 192.192.192.0/25:
<netID> <hostID> Broadcast
192.192.192.0 192.192.192.1 ÷192.192.192.126 192.192.192.127
192.192.192.128 192.192.192.129 ÷ 192.192.192.254 192.192.192.255
Un datagramma con un indirizzo IP di questo tipo è rivolto a tutti i nodi
appartenenti alla rete identificata da “<netID> + <subNetID>”. Pertanto se
ricevuto da un router lo costringe ad inoltrare lo stesso datagramma IP a tutti
i nodi della rete <netID> <subNetID>.
I router possono essere configurati per non reinstradare questo tipo di data-
grammi per circoscrivere il relativo traffico di broadcast.
j) All-Subnets-Directed Broadcast: {netID>, -1, -1}
Indica un indirizzo di broadcast diretto a tutte le <subNetID> appartenenti
alla stessa <netID>. Può essere utilizzato solo come destination address.
Per esempio nel caso si utilizzi la rete 10.0.0.0/24 l’indirizzo di All-Subnets-
Directed Broadcast è 10.255.255.255 in contrapposizione al Directed
Broadcast che risulterebbe 10.0.0.255.
k) {127, <any>}
Indica un generico indirizzo di loopback. Non viene mai “proiettato” al di
fuori di un qualsiasi host poiché non viene passato dal livello network al livel-
lo fisico, ma restituito direttamente al livello applicativo per mezzo di un’o-
perazione di copia dalla coda di trasmissione (transmit buffer) alla coda di
ricezione (receive buffer).
Normalmente viene utilizzato per scopi diagnostici, in particolare per verifi-
care la corretta installazione dello stack TCP/IP su un generico host.
L’indirizzo di loopback può anche essere utilizzato per connettersi ad un ser-
vizio TCP/IP installato sullo stesso host da cui si esegue il client, per esempio:
http://127.0.0.1 o analogamente http://loopback. Da notare che in alcuni
ambienti la parola loopback. Da notare che in alcuni ambienti la parola loop-
back non è risolta (cioè non viene riconosciuta) nell'indirizzo 127.0.0.1. In tal
caso è da utilizzare il termine localhost, con lo stesso significato.
I potenziali indirizzi che si possono utilizzare per il loopback address sono
pari a 224 – 2 = 16.777.214 (classe A), sebbene normalmente sia utilizzato sto-
ricamente l’indirizzo 127.0.0.1.
91
Parte 3
Formato del datagramma IP

Un datagramma IP è formato da due parti chiamate rispettivamente IP Header e IP
Payload ciascuna di lunghezza variabile, in modo da diversificare ed ottimizzare il
traffico di rete in base alla tipologia dei pacchetti da inviare:
<IP Datagramm> ::= <IP Header> <IP Payload>
rappresentabili come mostrato nella figura 5.6.
Figura 5.6: Incapsulamento di un protocollo di livello 4 in un datagramma IP
Dove ULP o Upper Layer Protocol identifica un generico protocollo di livello supe-
riore, cioè TCP o UDP.
In particolare, dettagliando la sezione IP Header, si possono evidenziare i campi
come indicato nella figura 5.7.
Figura 5.7: PDU IP
Terminologia
Il termine payload viene utilizzato in questo contesto per identificare all’interno di
una stringa di dati scambiati tra due N-entità (dove N identifica un qualsiasi livello
OSI o TCP/IP), la parte corrispondente alle informazioni degli utenti. Di solito non
vengono inclusi nel payload le informazioni di servizio inserite dal sistema, dette
anche system overhead, e necessarie per l’implementazione dei protocolli utilizzati a
ciascun livello. A volte il payload viene anche indicato come mission bit stream (cf.
Glossary of Telecommunication Terms-Federal Standard 1037C).
92
Dove:
■ IP Header (IH): è costituito da un insieme di blocchi (detti anche parole o
word) di 32-bit in numero variabile da un minimo di 5 (160-bit o 20 ottetti)
ad un massimo di 15 (480-bit o 60 ottetti), a seconda dell’aggiunta o meno del
campo “Options e Padding”. Poiché il minimo di un elemento dell’IP Header
ha una lunghezza pari a 32-bit o 4 ottetti, l’eventuale espansione dell’IH deve
essere eseguita per incrementi di 32-bit. Ciò vale per esempio per l’utilizzo
del campo “Options e Padding”: in tal caso l’aggiunta delle opzioni deve esse-
re effettuata avendo cura di riempire i bit mancanti per giungere a 32 con dei
caratteri “null” (operazione chiamata anche padding-zero), ottenendo così
“l’allineamento dell’IH”. Il ruolo dell’IP Header è di fornire tutti gli elementi
necessari per discriminare la parte header dalla parte payload, per identifi-
care il mittente ed il destinatario di un datagramma oltre ad eventuali altre
opzioni necessarie per il loro corretto instradamento.
■ IP Payload (IP): come si può osservare dalla figura 5.6, la componente pay-
load corrisponde alla PDU (Protocol Data Unit) associata ad un protocollo di
livello superiore ULP, secondo il principio di incapsulamento tipico dei
modelli stratificati (ISO/OSI o TCP/IP). Come per il campo precedente anche
il payload ha una lunghezza variabile.
Di seguito viene data una descrizione dettagliata dei vari campi che costituisco-
no la parte IP Header di un datagramma:
■ Version (VER)
• Dimensione campo: 4-bit
Occupa i primi 4-bit della struttura e contiene il numero di versione che defi-
nisce il formato dell’IH. La versione utilizzata correntemente è la 4 indicata
con l’acronimo IPv4. L’aver aggiunto il campo Version nell’IH consente di svi-
luppare nuovi protocolli e nuovi formati di header, con la possibilità di inte-
grarli in corso d’opera. È questo il caso, per esempio, di alcuni protocolli spe-
rimentali (Version 7: IP/IX (RFC 1475, RFC 1707); Version 8: “P” Internet
Protocol (RFC 1710); Version 9: Tcp and Udp with Bigger Address (TUBA)
(RFC 1347, RFC 1526, RFC 1561) e soprattutto della successiva versione IPv6.
IPv6 consente, tra l’altro, l’utilizzo di indirizzi IP a 128-bit.
■ Internet Header Length (IHL)
• Dimensione campo = 4-bit
• Unità di misura = 4 gruppi di ottetti (parole o word da 32-bit)
• Range = 5 ÷ 15 (default = 5)
Questo campo non è un contatore di byte ma indica la lunghezza dell’IH
espressa in blocchi o parole di 32-bit (4 ottetti). Pertanto il valore contenuto
in questo campo deve essere sempre un multiplo di 4. Le sue dimensioni pari
a 4-bit determinano dei limiti strutturali sulla lunghezza dell’IHL:
a. Dimensioni minime dell’IH: le dimensioni minime si hanno, come per la
maggior parte dei datagrammi IP, quando il campo Options non è utiliz-
zato. In tal caso la lunghezza corrispondente è di 5 (0x05) parole da 32-
bit ovvero 160-bit o 20 ottetti.
93
Parte 3
b. Dimensioni massime dell’IH: la massima estensione indirizzabile dal

campo IHL è di 24 – 1 = 15 (0x0F) parole da 32-bit cioè 480-bit o 60
ottetti.
■ Type Of Service (TOS)
Il campo TOS è costituito da 8-bit e consente di specificare il grado di qualità
del servizio o Quality Of Service (QOS) con il quale si desidera che i data-
grammi siano reinstradati dai router. Come specificato nelle RFC 1349 e RFC
2474 esso è costituito da cinque sottocampi più un sesto di valore riservato
(MBZ: Must Be Zero) (tabella 5.16).
Tabella 5.16: Type Of Service (TOS)

3-bit 1-bit 1-bit 1-bit 1-bit 1-bit
Precedence Delay Throughput Reliability Cost MBZ
000 Routine (R) 0 Normal 0 Normal 0 Normal 0 Normal Must Be
001 Priority (P) 1 Low 1 Low 1 Low 1 Low Zero
010 Immediate (O)
011 Flash (Z)
100 Flash Override (X)
101 Critic/ECP (Critical
and Emergency Call Processing)
110 Internetwork Control
111 Network Control
Per default il valore del campo TOS è 0 (0x0) ovvero Normal Service.
■ Total Length (TL)
• Unità di misura = Ottetti
Il campo TL è costituito da 16-bit e definisce la lunghezza, espressa in ottetti,
dell’intero datagramma considerando sia la parte header sia la parte payload.
Da notare che la dimensione massima consentita per un datagramma IP è di
216 = 65.535 ottetti. Di fatto essa è limitata dal valore MTU (Maximum
Trasmission Unit) imposto dalla rete utilizzata a livello 2 (o livello Network
Interface TCP/IP). I datagrammi la cui lunghezza supera il valore dell’MTU
della rete utilizzata vengono frammentati, numerati ed inviati singolarmente.
Conoscendo i valori dei campi IHL (IP Header Length) e TL è possibile dedur-
re la lunghezza della parte payload di un datagramma tramite la seguente
espressione:
Lunghezza IP Payload = TL – 4 * IHL
■ Identification (ID)
94
Rappresenta un numero progressivo unico compreso tra 0 e 65.535 (216)

assegnato ad ogni datagramma inviato da ciascun host.
È utilizzato soprattutto in caso di frammentazione per distinguere i fram-
menti di un datagramma da quelli di altri datagrammi. Normalmente tale
valore viene passato direttamente da un protocollo ULP tramite un apposito
parametro (ciò vuol dire che è possibile avere valori duplicati relativamente
a datagrammi consecutivamente generati uno da TCP ed uno da UDP; la
gestione di questi casi particolari è demandata alle varie implementazioni).
In caso contrario viene automaticamente generato dal protocollo IP. Il suo
valore deve essere comunque unico per ogni coppia IP Mittente-IP
Destinazione e Protocollo per il tempo che sopravvive il datagramma in rete.
Ciò potenzialmente potrebbe portare ad una duplicazione di valori del
campo Identification per due datagrammi generati uno dal protocollo TCP
ed l’altro dal protocollo UDP: queste evenienze sono ammesse e devono
essere gestite dalla particolare implementazione dello stack TCP/IP.
In caso di frammentazione di un datagramma permette di fissare il legame
tra i singoli frammenti ed il datagramma originario: tutti devono avere lo
stesso valore del campo Identification. Viceversa, consente all’host destina-
zione (o più tipicamente ad un router che interconnette reti con MTU diffe-
renti) di ricomporre ciascun frammento associandolo al corrispondente
datagramma distinguendo tra i diversi datagrammi in fase di ricostruzione.
Ciò in quanto il protocollo IP è di tipo connection-less e quindi frammenti
diversi di datagrammi possono inframmezzarsi. Questo campo viene utiliz-
zato, congiuntamente ai campi Flags (DF, MF) e Fragment Offset, per il rias-
semblaggio dei frammenti a destinazione.
■ Flags
Questo campo contiene 3-bit dei quali il primo (bit 0, più significativo) è
riservato ed ha sempre valore 0 (MBZ, Must Be Zero), mentre gli altri due
costituiscono dei flag di controllo per il processo di frammentazione e ricom-
posizione dei frammenti di un datagramma IP (figura 5.8).
Figura 5.8: Struttura del campo Flags
In particolare il secondo bit implementa il flag Don’t Fragment (DF) il quale

se assume il valore 0 rende possibile la frammentazione del datagramma.
Viceversa, un valore 1 del flag DF esclude tale possibilità. In quest’ultimo
caso se la dimensione del datagramma originale è superiore al valore MTU
95
Parte 3
della rete il datagramma viene scartato (per esempio da un router) e viene

riscontrato all’host mittente il seguente messaggio ICMP (Type = 3, Code = 4)
Destination Unreachable-Fragmentation Needed And DF Set come specifica-
to nella RFC 792.
Il secondo flag viene indicato con il termine More Fragment (MF) ed assume
il valore 1 per indicare al destinatario che sono previsti altri frammenti in
arrivo. Viceversa, un valore 0 indica che si tratta dell’ultimo frammento di
una serie oppure che il datagramma è costituito da “un unico pezzo” chia-
mato anche “datagramma intero” (in tal caso, però, anche il campo Fragment
Offset deve valere 0).
Tips and tricks

1. Per ricordarsi mnemonicamente l’ordine dei due flag (DF e MF) fare riferimento
all’ordine alfabetico (prima DF e poi MF).
2. Normalmente, utilizzando il comando ping per testare la raggiungibilità di un
host all’interno di una rete, viene inviato un datagramma IP di dimensioni pre-
fissate: 32 byte in ambiente Microsoft Windows e 64 byte in ambiente Unix/Linux.
Utilizzando apposite opzioni è possibile modificare queste dimensioni e soprat-
tutto si può anche imporre di non produrre la deframmentazione dei datagram-
mi qualora la loro dimensione ecceda il valore dell’MTU della rete utilizzata. In
questo modo è possibile scoprire il valore di MTU di una rete. In particolare, a
seconda del sistema operativo utilizzato e supponendo di operare su una rete
Ethernet (con sistema di Encapsulation Ethernet II, valore MTU = 1500), il
comando da utilizzare per provocare la frammentazione è il seguente:
• WinNT/2K/XP/2003:
ping –f –l 1473 192.168.1.200.
• Unix/Linux:
ping –M do –s 1473 192.168.1.200.
Viceversa, specificando una dimensione del buffer di trasmissione pari a 1472 non
si produce alcun errore in quanto il datagramma viene inviato interamente.
Attenzione: la dimensione indicata in bit corrisponde alla lunghezza della com-
ponente payload. Viceversa, per determinare la reale dimensione del datagram-
ma inviato dal comando ping è necessario aggiungere i bit di overhead del pro-
tocollo IP (20 ottetti) più quelli del protocollo ICMP (8 ottetti). Pertanto, in defi-
nitiva, la dimensione del pacchetto inviato (MTU) è pari a:
MTU Ethernet II = 1472 + 20 + 8 = 1500.
3. Nel caso di sistemi operativi *NIX/Linux il valore MTU può essere determinato
anche attraverso i comandi ifconfig –a oppure netstat –i.
■ Fragment Offset (FO) e il processo di frammentazione

• Unità di misura = 8 gruppi di ottetti (64-bit)
• Range = 0 ÷ 8191 (default = 0)
96
Il campo Fragment Offset (FO) è utilizzato insieme ad altri (per esempio:

Identification, Flags, Protocol, Source e Destination Address, Flags, TTL) per
implementare il processo di frammentazione. Esso indica la posizione occu-
pata dal singolo frammento relativamente all’inizio del datagramma origina-
rio. La dimensione di ogni frammento (tranne l’ultimo) deve essere un mul-
tiplo di 8 essendo riferita a gruppi di 8 ottetti. Inoltre, per ciascun frammen-
to deve essere ricalcolato il valore del campo Total Length. Nel caso di un
datagramma completo (ovvero non ulteriormente frammentato e quindi con
il flag MF = 0) o per il primo frammento prodotto da un datagramma, il valo-
re del campo Fragment Offset deve essere sempre 0. In particolare il primo
frammento di una serie sarà caratterizzato da MF = 1, FO = 0. I successivi
avranno: MF = 1, FO ≠ 0. L’ultimo frammento sarà identificato da: MF = 0, FO
≠ 0. Da notare che ogni frammento può essere a sua volta sottoposto a fram-
mentazione (anche più di una volta), qualora debba attraversare altre reti
con un MTU ancora più basso.
Ricordiamo che la frammentazione è uno dei servizi essenziali che ogni modulo
IP deve fornire.
Il processo di frammentazione permette ad un datagramma di giungere a desti-
nazione (oltre che grazie alle capacità di indirizzamento e di routing del protocollo IP)
in modo indipendente dalla tipologia fisica delle reti attraversate tenendo conto
soprattutto della potenziale differenza in termini di dimensione massima (a volte
anche minima) dei pacchetti (MTU, Maximum Transmision Unit) supportati da cia-
scuna di esse. Infatti, come già anticipato precedentemente, la dimensione massima
di un datagramma è determinata a priori sia in virtù del limite di 16-bit del campo
Total Length che stabilisce il limite massimo di 216 = 65.535 ottetti sia, soprattutto, dal
valore MTU delle singole reti interconnesse (che può oscillare da 48 ottetti di una rete
ATM fino a 65.535). Naturalmente questo limite risulta essere impraticabile per la
maggior parte delle reti e degli host. Pertanto, tutti gli host di una rete TCP/IP devono
essere preparati per affrontare il problema della frammentazione (host mittente) di un
datagramma, qualora la sua dimensione superi il valore MTU della rete utilizzata per
l’inoltro, e del relativo riassemblaggio (host destinazione).
Ogni host deve essere comunque in grado di inoltrare un datagramma di almeno
68 ottetti senza necessità di frammentazione. Ciò in quanto un datagramma IP può
contenere un header di dimensioni massime pari a 60 ottetti ed il minimo frammen-
to deve essere di 8 ottetti (cf. RFC 791, pag. 24).
Vari tipi di frammentazione: chiarimenti sulla terminologia

Spesso, parlando di frammentazione si utilizzano diversi termini. Di seguito vengo-
no descritti alcuni fra quelli più ricorrenti:
■ Frammentazione locale: la frammentazione locale si verifica al di sotto del livel-
lo IP ed il riassemblaggio avviene prima che i frammenti vengono presentati
all’host o router ricevente.
■ Frammentazione non-trasparente: è il classico processo di frammentazione che
si svolge host-to-host:
a) Ogni frammento agisce come un qualsiasi datagramma.
b) È dotato di un proprio header (overhead).
97
Parte 3
c) Segue una rotta indipendente da tutti gli altri frammenti, generati dallo stes-
so datagramma, durante il tragitto dall’host mittente all’host destinazione.
d) La frammentazione e il riassemblaggio avviene end-to-end.
e) La perdita o danneggiamento anche di un solo frammento provoca lo scarto
dell’intero datagramma.
■ Frammentazione trasparente: processo di frammentazione che si svolge in ma-
niera del tutto trasparente rispetto al modulo IP degli host interagenti e rispetto
ai protocolli di livello superiore (ULP), scatenato dai router intermedi in caso di
reti interconnesse con diversi valori di MTU (cf. gli esempi 1 e 2 trattati alla pagg.
95-96). Nel caso di reti ATM tale tipo di frammentazione è di default e viene
chiamata segmentazione. In tal caso la dimensione MTU è pari a 48 ottetti.
■ Frammentazione intranet o “Network-Dependent”: si riferisce al processo di
frammentazione e relativo riassemblaggio che si verifica all’interno di una rete
intranet (tipicamente un insieme di reti locali fisicamente separate (per esempio:
distribuite geograficamente), di diversa tipologia (per esempio: Ethernet, Token
Ring) e interconnesse mediante reti geografiche; ma anche nel caso più semplice
di una rete singola nel caso di utilizzo di particolari applicazioni (tipicamente
basate su protocollo di trasporto UDP) che utilizzano pacchetti di dimensioni
consistenti anche superiori a 64K) in seguito all’inoltro dei pacchetti tra router
che interconnettono reti di tipo diverso (con MTU potenzialmente diversi). In tal
caso ricadendo tutti i dispositivi di internetworking (ovvero: router) sotto una
stessa giurisdizione ed in base alla tipologia di reti utilizzate, è possibile determi-
nare regole univoche per il trattamento della frammentazione (“private agree-
ment”). Si tratta comunque di un processo di frammentazione trasparente.
■ Frammentazione intenzionale: come riportato nella RFC 1122 (sezione 3.3.3)
ogni host opzionalmente può implementare un meccanismo di frammentazione
dei datagrammi in uscita detto intenzionale o provocato. Esso consiste nell’in-
viare datagrammi aventi dimensioni molto grandi e tali da innestare sicura-
mente il processo di frammentazione. Ciò da un lato permette di ottimizzare le
performance riducendo la quantità di lavoro che un host deve dedicare prima e
dopo l’invio dei dati. D’altro canto esso può provocare un degrado delle presta-
zioni dei router. Pertanto, è da utilizzare solo all’interno di reti private. Per l’im-
plementazione di questo meccanismo viene definito un parametro chiamato
EMTU_S (“Effective MTU for Sending”) come dimensione massima di un data-
gramma da inviare per una particolare combinazione della tripletta (IP destina-
zione, IP Mittente, TOS). Normalmente il valore EMTU_S deve essere minore o
uguale dell’MTU dell’interfaccia di rete corrispondente all’indirizzo sorgente del
datagramma. Inoltre ogni host deve implementare un meccanismo che consenta
al protocollo di trasporto (tipicamente TCP) di dedurre la dimensione massima
di un messaggio in spedizione o “Maximum Message Size that may be Sent”
(MMS_S). In caso di non utilizzo di frammentazione intenzionale il valore di tale
parametro sarà derivato dalla relazione seguente: MMS_S = EMTU_S – IHL.
Pertanto, ogni host che non utilizza frammentazione intenzionale deve assicu-
rarsi che il protocollo TCP o un applicazione che utilizza il protocollo UDP rice-
vano dal livello IP il valore MMS_S e non possano mai inviare datagrammi di
dimensione superiore a MMS_S. Al fine di evitare frammentazione intenzionale
è consigliato utilizzare un valore EMTU_S sufficientemente basso da non scate-
98
nare frammentazione in ciascun router attraversato il datagramma. In mancan-

za di una conoscenza diretta di tale parametro è consigliato utilizzare un valore
EMTU_S ≤ 576 soprattutto in caso di diverse reti interconnesse.
Considerazioni sull’MTU
■ Il valore dell’MTU di ogni interfaccia di rete deve essere configurabile.
■ Ogni implementazione del livello IP deve avere a disposizione un flag “All-
Subnets-MTU” che consenta di specificare l’utilizzo di un MTU per tutte le desti-
nazioni appartenenti alle sole subnet derivate dalla stessa rete, ma non ad altre
reti (ovvero: lo stesso concetto del Broadcast “All-Subnets-Directed-Broadcast”.
Nel caso di host multi-homed questo flag è necessario per ciascuna interfaccia di
rete. Il suo utilizzo forza l’host ad utilizzare la network mask anziché la subnet
mask per la scelta del parametro EMTU_S.
■ Alcune implementazioni prevedono la determinazione dell’MTU (sia via UDP
sia via TCP) al fine di ottimizzare il processo di frammentazione.
Inoltre tutti gli host devono essere preparati per accettare datagrammi che abbia-
no una dimensione di almeno 576 ottetti (sia che arrivino in forma intera sia fram-
mentata). Questo limite è identificato mediante il valore EMTU_R (Effective MTU to
Receive) definito nella RFC 1122 di cui riportiamo un estratto:
«… we designate the largest datagram size that can be reassembled by EMTU_R

(“Effective MTU to receive”); this is sometimes called the “reassembly buffer size”.
EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable
or indefinite, and SHOULD be greater than or equal to the MTU of the connected
network(s). DISCUSSION: A fixed EMTU_R limit should not be built into the code
because some application layer protocols require EMTU_R values larger than
576…».
Pertanto, dovendo inviare datagrammi che hanno una dimensione superiore a

576 ottetti, è necessario assicurarsi che tutti gli host destinatari siano preparati ad
accogliere datagrammi di queste dimensioni.
Il valore 576 è stato scelto in modo tale da garantire l’invio di una ragionevole
quantità di informazioni (circa 512 ottetti) oltre agli ottetti obbligatori di overhead (da
20 a 60 ottetti per l’header IP e qualche margine per l’header dei protocolli ULP).
Infatti, parecchi protocolli di livello superiore soprattutto basati su UDP (per esempio:
TFTP, DNS, SNMP, ...) utilizzano come limite proprio 512 ottetti. Viceversa, TCP utiliz-
za direttamente un meccanismo per determinare il valore di MTU, chiamato Path
Maximum Transmission Unit Discovery (PMTUD), avente l’obiettivo di dedurre il va-
lore del parametro Maximum Segment Size (MSS). Come indicato nella RFC 1122 il
valore della variabile EMTU_R dovrebbe essere maggiore o uguale all’MTU della rete
utilizzata.
In definitiva, nel caso di un datagramma IP non contenente alcuna opzione, la
lunghezza effettiva del payload deve essere compresa tra 576 e 65.515 [= 65.535 – 20
(IHL)].
99
Parte 3
Le operazioni che un host sorgente (o un router intermedio) deve intraprendere

per implementare il processo di frammentazione possono essere sinteticamente rias-
sunte nel modo seguente:
I. Ricavare il valore MTU della interfaccia di rete verso la quale deve essere
inoltrato il datagramma.
II. Verificare se la dimensione (Total Length) del datagramma non eccede il
valore di MTU: in tal caso non si necessita di frammentazione. Viceversa,
procedere dal passo III.
III. Stabilire il numero e le dimensioni dei frammenti necessari tenendo conto
che occorre riservare almeno 20 ottetti (supponendo che non sia utilizzato il
campo opzioni) per l’header di ogni frammento, e determinare la dimensio-
ne di ciascun frammento (che deve essere multiplo di 8-ottetti, tranne l’ulti-
mo frammento). Inoltre ogni frammento deve essere opportunamente nu-
merato. Indicando con MOD il resto intero associato ad una divisione intera
e con DIV il relativo quoziente intero, ne segue che:
i. Il numero di blocchi da 8 ottetti per ogni frammento (NBF) è dato da:
NBF = (MTU – 4*IHL) DIV 8.
ii. La lunghezza del payload di ciascun frammento (LPF) la quale, tranne
per l’ultimo frammento deve essere multiplo di 8 ottetti, è data da:
IF ((MTU - 4*IHL) MOD 8) = 0)
/* Cioè, se (MTU – 4*IHL) è multiplo di 8 ? */
THEN LPF = MTU – 4*IHL
ELSE LPF = primo valore inferiore a (MTU – 4*IHL) che sia divisibile
per 8.
iii. Il numero di frammenti (NF) è dato da:
NF = (TL – 4*IHL) DIV LPF.
iv. Inoltre, se la divisione precedente ha un resto diverso da 0 (ovvero: la
lunghezza del datagramma originale non è un multiplo esatto di LPF e
quindi [(TL – 4*IHL) MOD LPF) ≠ 0] allora esisterà un ulteriore fram-
mento la cui dimensione è data proprio dal resto intero della stessa divi-
sione, cioè:
lunghezza_ultimo_frammentto = (TL - 4*IHL) MOD LPF
In tal caso il numero dei frammenti sarà aggiornato a NF = NF + 1.
Tips and tricks

Per gli amanti (ed i “ puristi”) del linguaggio C, il numero di frammenti (NF) lo si può
indicare in maniera molto più sintetica utilizzando l’operatore ternario?:
NF = [(TL – 4*IHL) MOD 8] ? [(TL – 4*IHL) DIV LPF] + 1 : [(TL – 4*IHL) DIV LPF];
Il meccanismo di funzionamento del suddetto operatore può essere spiegato con il

seguente esempio:
x = Condizione? Esp1 : Esp2;
100
Cioè, si valuta il valore di condizione. Se Condizione è vera (risultato diverso da 0)

allora si passa a valutare l’espressione Esp1, che diventa il valore dell’intera espres-
sione (valore assegnato a x). Viceversa, se Condizione è falsa allora si passa a valuta-
re Esp2, che a questo punto determina il valore dell’intera espressione. Essa è equiva-
lente alla seguente più classica espressione IF:
IF Condizione
x = Esp1
ELSE
x = Esp2
IV. Per ogni frammento è necessario riconfigurare i campi seguenti:

a. Identification (uguale per tutti).
b. Il Fragment Offset (FO) sarà dato da:
FO = N*NBF
dove N = 0 (primo frammento), 1, 2, …, NF - 1 (ultimo frammento).
c. DF = 0 per tutti i frammenti.
d. MF = 1 per tutti i frammenti tranne che per l’ultimo.
e. Ricopiare eventuali opzioni.
f. Ricalcolare il checksum.
Da notare che le dimensioni dei frammenti (LPF) si riferiscono alla parte dati
o payload e non considerano la parte di header. Pertanto, per ottenere la
dimensione totale (Total Length) di ciascun nuovo datagramma generato
occorre tenere conto dell’header da aggiungere (almeno 20 ottetti fino ad un
massimo di 60) a seconda delle opzioni utilizzate.
Esempio 1
Si supponga di avere le seguenti reti interconnesse A, B e C con MTU rispettivamente
di 4482, 1500 e 525 (figura 5.9).
Si consideri un datagramma caratterizzato dal campo Identification = 14361 ori-
ginato da un host della rete A, avente una lunghezza totale (TL = Total Length) di 4482
e diretto ad un host della rete B. Supponendo che non siano state utilizzate opzioni IP
(cioè risulta IHL = 5), le dimensioni del payload IP saranno pari a 4482 – 20 = 4462. Il
datagramma per giungere a destinazione viene inoltrato al router AB il quale lo inol-
tra sulla rete B. Essendo le sue dimensioni effettive (payload) inferiori al valore
dell’MTU della rete B, il router AB deve procedere con la sua frammentazione.
Essendo l’MTU della rete B pari a 1500 applicando le relazioni viste in preceden-
za si avrà:
I. NBF = (MTU – 4*IHL) DIV 8 = 1480 DIV 8 = 185.

II. LPF = MTU – 4*IHL = 1480 (è un multiplo esatto di 8).
III. NF = (TL – 4*IHL) DIV LPF = 4462 – 1480 = 3 (cioè tre frammenti ciascuno con
un payload di 1480 ottetti).
101
Parte 3
Figura 5.9: Esempio di frammentazione con reti caratterizzate da diversi valori

di MTU
IV. Non essendo 4462 (TL – 4*IHL) un multiplo di 1480 (LPF) esisterà un quarto
frammento avente dimensioni pari a: lunghezza_ultimo_frammentto = (TL -
4*IHL) MOD LPF = 4462 MOD 1480 = 22.
V. Infine: FO = N*NBF = N*185, con N = 0, 1, 2, 3.
Nella figura 5.10 è mostrato un riepilogo di quanto esposto:
Figura 5.10: Determinazione dei parametri di frammentazione dei frammenti

generati da un datagramma originato nella rete A e destinato alla rete B (cf. figura 5.9)
Esempio 2
Consideriamo le reti raffigurate nella figura 5.9 dell’esempio precedente.
Si consideri un datagramma caratterizzato dal campo Identification = 5760 origi-
nato da un host della rete B, avente una lunghezza totale (TL = Total Length) di 1500 e
rivolto ad un host della rete C. Supponendo che non siano state utilizzate opzioni IP
(cioè risulta IHL = 5), le dimensioni del payload IP saranno pari a 1500 – 20 = 1480.
Quando il datagramma giunge al router BC che deve inoltrarlo sulla rete C esso deve
procedere con la sua frammentazione, in quanto le sue dimensioni sono superiori a
quelle dell’MTU della rete C di destinazione.
102
Essendo l’MTU della rete B pari a 525 applicando le relazioni viste in precedenza
avremo:
I. NBF = (MTU – 4*IHL) DIV 8 = 505 DIV 8 = 63.

II. LPF = MTU – 4*IHL = 505. Non essendo un multiplo esatto di 8 si seleziona il
numero inferiore più prossimo divisibile per 8. Pertanto sarà LPF = 504.
III. NF = (TL – 4*IHL) DIV LPF = 1480 – 504 = 2 (cioè 2 frammenti ciascuno con
un payload di 504 ottetti).
IV. Un terzo frammento avente dimensioni pari a: lunghezza_ultimo_fram-
mentto = (TL - 4*IHL) MOD LPF = 1480 MOD 504 = 472.
V. FO = N*NBF = N*63, con N = 0, 1, 2.
Nella figura 5.11 è mostrato un riepilogo di quanto appena esposto:
Figura 5.11: Determinazione dei parametri di frammentazione dei frammenti

generati da un datagramma originato nella rete B e destinato alla rete C (cf. figura 5.9)
Osservazione sugli esempi 1 e 2: frammentazione trasparente

Supponendo che nell’esempio 1 l’host sorgente anziché inviare il datagramma ad un
host della rete B lo invii ad uno della rete C, si verificherà in tal caso una frammen-
tazione trasparente nel router BC in quanto ciascun frammento generato dal data-
gramma originario deve essere riframmentato prima di essere inoltrato sulla rete C.
Effetti negativi dovuti alla frammentazione e ripercussioni sulla sicurezza

■ Come si può osservare dagli esempi precedenti, a seguito del processo di fram-
mentazione non solo si impegnano risorse elaborative (CPU, Memoria) degli host
o router coinvolti, ma aumenta anche la quantità di informazioni che devono
essere trasmesse. In particolare la quantità di ottetti che costituiscono l’overhead
(cioè l’incremento fisiologico della quantità di dati da inviare) è pari 4*IHL*(NF
– 1) dove NF è il numero dei frammenti; in questo calcolo non si tiene conto di
eventuali opzioni che, in base al valore del flag (Copy On Fragmentation), devo-
no o meno essere copiate in ogni frammento o solamente nel primo. Gli effetti ne-
gativi della frammentazione sono ancora più pesanti per l’host destinatario a
causa delle risorse e del tempo (TTL, Timer) necessario da dedicare al riassem-
blaggio dei frammenti. Comunque questi effetti negativi influiscono in maniera
103
Parte 3
diversa su un host, che possiede le risorse ed il tempo necessario da dedicare,

rispetto ad un router. Infatti, considerando il notevole carico di lavoro che questo
deve normalmente svolgere ed i ristrettissimi tempi a disposizione da dedicare a
ciascun datagramma, si può intuire come la frammentazione sia un processo
veramente penalizzante per i router.
■ Il mancato recapito o danneggiamento anche di un singolo frammento provoca
la ritrasmissione dell’intero datagramma, su richiesta di un protocollo di livello
superiore (tipicamente TCP).
■ Datagrammi con valori elevati di TTL possono permanere a lungo nel buffer di
ricostruzione.
■ La deframmentazione potrebbe avere conseguenze negative anche sul corretto
funzionamento di alcuni sistemi di networking e di sicurezza come Firewall (per
esempio: Non-Initial Fragment Attack), IDS (Intrusion Detection System) e Con-
tent Switch Engines) in quanto in quest’ultimo caso, se un pacchetto viene sud-
diviso in tanti frammenti, risulta difficile l’analisi del suo effettivo contenuto e la
relativa applicazione delle policy.
■ Un altro effetto collaterale si può verificare, per esempio, nell’utilizzo di client di
posta elettronica che implementano la funzionalità “Message Fragmentation
and Reassembly” della RFC 2046 “Multipurpose Internet Mail Extensions (MIME)
Part two: Media Types”. È questo il caso di Outlook Express, che opportunamente
configurato (Tools → Accounts → “Selezionare un account di e-mail” →
Properties → Advanced: nella sezione Sending, selezionare la voce “Break apart
messages larger than” e specificare il valore desiderato (default = 60 KB) consente
di spezzare messaggi lunghi in piccole parti. Così facendo è possibile, spezzando
opportunamente un “messaggio maligno”, per un potenziale attaccante eludere il
controllo di eventuali filtri SMTP (SMTP Filtering Engines), Gateway Virus
Scanner, Content Filters, ecc., qualora questi non eseguano dei controlli più effi-
caci (per esempio: includere un “Reassembly Agent” sui server per bloccare l’inol-
tro di messaggi frammentati) e non basati unicamente sull’analisi di un deter-
minato “pattern” (per esempio: VIRUS SIGNATURE).
In maniera completamente simmetrica ogni host destinazione (e mai un router

intermedio, tranne in casi di frammentazione trasparente) deve procedere con le se-
guenti operazioni per poter riassemblare i vari frammenti e ricostruire il datagramma
così come si presentava all’origine:
I. Predisporre tutte le risorse necessarie per compiere il processo di riassem-

blaggio: un buffer per i dati (potenzialmente grande fino a 65.515 ottetti), un
buffer per l’header (potenzialmente grande fino a 60 ottetti), una tabella per
tenere traccia dei frammenti elaborati (potenzialmente 8192 bit), una varia-
bile che contenga il valore Total Length del datagramma ed un timer (cf. il
riquadro “Alcune note importanti sul dimensionamento del “Reassembly
Timer”” alla pagina successiva).
II. Alla ricezione del primo frammento (caratterizzato da: MF = 1, FO = 0) copia-
re il relativo header nel buffer di ricostruzione e far partire il timer.
104
III. Identificare tutti i frammenti che condividono gli stessi valori per ognuno dei
quattro campi Identification, Source, Destination, Protocol.
IV. Fino a quando il timer non è scaduto continuare ad assemblare gli altri
frammenti ciascuno nella posizione relativa indicata dal campo FO. Altri-
menti rilasciare tutte le risorse allocate, scartare i restanti frammenti ed inol-
trare al mittente il messaggio ICMP (Type = 11, Code = 1) Fragment reassem-
bly time exceeded come specificato nella RFC 792, indicando il primo fram-
mento ricevuto (64 byte o meno).
V. Se tutta la procedura è eseguita correttamente il payload IP ricostruito deve
essere passato al protocollo ULP specificato nel campo Protocol.
Alcune note importanti sulla procedura di riassemblaggio

■ Come già anticipato precedentemente, ogni host deve essere predisposto per
accettare datagrammi che abbiano una dimensione di almeno 576 ottetti (sia che
arrivino in forma intera sia frammentata). Questo limite è identificato mediante
il valore EMTU_R (“Effective MTU to Receive”) definito nella RFC 1122. Inoltre,
per consentire la ricezione di pacchetti di dimensioni anche più elevate (richieste
normalmente da alcuni protocolli di livello applicazione) è consigliato che tale
limite non sia imposto staticamente ma sia configurabile.
■ L’algoritmo normalmente utilizzato per effettuare il riassemblaggio dei fram-
menti deve prevedere di mantenere l’header del primo frammento in quanto in
caso di errore o scadenza del timer esso deve essere restituito nell’eventuale mes-
saggio ICMP (Type = 11, Code = 1) “Fragment reassembly time exceeded”.
■ Per ottimizzare l’interazione tra gli host e migliorare le performance degli appa-
rati di routing è consigliata l’implementazione, su ciascun host, di un meccani-
smo che consenta al livello di trasporto di determinare la dimensione massima
di un messaggio in ricezione o “Maximum Message Size that may be Received”
(MMS_R). Normalmente il suo valore è deducibile dalla relazione seguente:
MMS_R = EMTU_R – IHL.
Alcune note importanti sul dimensionamento del “Reassembly Timer”

■ Il timer viene azionato alla ricezione del primo frammento. Il suo valore massi-
mo è di 255 secondi (4,25 minuti). Alla ricezione di ogni frammento dello stesso
datagramma il suo valore viene aggiornato, assumendo come valore il massimo
tra il valore attuale e quello del TTL del frammento.
■ Secondo la RFC 791 il valore consigliato è di 15 secondi.
■ Viceversa secondo la RFC 1122, il valore del timeout dovrebbe essere fisso e non
dipendente dal campo TTL del frammento ricevuto, in quanto tutti i router or-
mai trattano il parametro TTL come numero di hop e non come intervallo di
tempo ancora a disposizione. Il valore raccomandato è tra 60 e 120 secondi. In
caso di scadenza del timer il datagramma ancora parzialmente assemblato deve
essere scartato, ed all’host sorgente deve essere notificato un messaggio ICMP
(Type = 11, Code = 1) “Fragment reassembly time exceeded” (se il frammento zero
è stato ricevuto).
105
Parte 3
■ Datagrammi con valori elevati di TTL possono permanere a lungo nel buffer di
ricostruzione e bloccare per tanto tempo le risorse necessarie. Inoltre ciò può
avere una ripercussione negativa sul valore del parametro MSL (Maximum
Segment Lifetime) che viene inutilmente settato con un valore elevato dai proto-
colli di livello trasporto. MSL controlla la velocità massima con la quale i fram-
menti dei datagrammi vengono inviati. Un valore elevato dell’MSL causa una
diminuzione della velocità massima. Le specifiche TCP assumono un valore per
MSL pari a 2 minuti, il quale determina un accettabile limite superiore per quan-
to riguarda il valore del timer.
■ Il messaggio ICMP (Type = 11, Code = 1) “Fragment reassembly time exceeded” (cf.
RFC 792) che viene notificato dall’host destinazione in caso di scadenza del timer
non è gestito da tutte le implementazioni TCP/IP. Ciò potrebbe causare qualche
problema o comunque inutile sovraccarico di traffico.
■ Time To Live (TTL)

• Unità di misura = secondi
• Range = 0 ÷ 255 (4m15s o 4,25 minuti)
Questo campo può essere utilizzato sia come limite temporale (espresso in
secondi) sia come numero di hop ovvero di attraversamenti di router con-
cessi ad un datagramma prima di essere definitivamente rimosso da una rete
(Internet/intranet/extranet) quando il suo valore raggiunge 0. Originaria-
mente il ruolo del campo TTL era di svolgere le funzioni di intervallo di
sopravvivenza concesso ad un datagramma. Il decremento del valore del TTL
veniva effettuato da ciascun router in base al tempo di permanenza del data-
gramma (tempo di forwarding – tempo di arrivo del datagramma). A causa
delle difficoltà di tenere traccia dei vari tempi di transito dei datagrammi e
per non incidere ulteriormente sul carico di lavoro dei router, è stato stabili-
to (dietro la spinta dei costruttori di router) tramite la RFC 1812 di lasciare la
libertà di utilizzare questo campo come hop count. In tal caso i router devo-
no semplicemente decrementare di una unità il valore originario.
Oltre a limitare il tempo di vita dei datagrammi IP il campo TTL evita l’in-
staurarsi dei cosiddetti routing loop.
A proposito della gestione del campo TTL sono state fissate nelle RFC 791,
RFC 1122 e RFC 1812, alcune regole comportamentali sia per i router sia per
gli host:
a. Un router non può mai dare origine o reinstradare un datagramma aven-
te un valore TTL = 0.
b. Un router decrementa il valore del TTL prima di analizzare la propria
tabella di routing. Nel caso in cui il campo TTL raggiunge il valore 0 il
relativo datagramma viene scartato e viene riscontrato al mittente il
messaggio ICMP (Type = 11, Code = 0) Time To Live Exceeded in Transit
come specificato nella RFC 792.
c. Qualsiasi host destinatario di un datagramma non ha necessità di verifi-
care il valore del campo TTL.
106
d. Il valore del campo TTL è indipendente dalla metrica dei protocolli di

routing.
e. Il valore del campo TTL può essere specificato o in sede di configurazio-
ne del sistema operativo oppure direttamente da alcune applicazioni e/o
utility (applicazioni multicast, ping, traceroute/tracert, …).
f. Il valore raccomandato per il campo TTL è pari al doppio del diametro di
una internetwork. Dove per diametro si intende il numero di link (ovve-
ro: di interfacce di rete da attraversare per giungere a destinazione) tra i
due nodi più distanti. Da notare che il numero di hop non coincide con
il numero di link. Per esempio supponendo che due destinazioni siano
separate da 4 router, in tal caso il numero di hop è 4, ma il numero di link
è pari a 5 (numero di hop + 1). Infatti, impostando il parametro TTL = 4
un datagramma non sarebbe in grado di raggiungere la destinazione in
quanto arrivato all’ultimo router (il quarto) il valore del TTL avrebbe già
raggiunto 0 e verrebbe scartato. Viceversa, impostando un valore di TTL
pari a 5 o superiore può giungere potenzialmente a destinazione.
Il valore minimo consigliato da IANA per il campo TTL è 64 (cf. il sito
http://www.iana.org/assignments/ip-parameters).
Tips and tricks

È possibile modificare il valore di default del parametro TTL utilizzato all’interno
dello stack TCP/IP Per esempio, in ambiente Microsoft WinNT/2K/XP/2003 è possibi-
le agire mediante registry aggiungendo o variando la seguente chiave:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\
Parameters\TTLDefault:REG_DWORD:1-255:Default=128.
Da notare che applicazioni di tipo WinSockets possono sovrascrivere questo valore.
■ Protocol (PROT)
• Range = 0 ÷ 255
Il campo protocollo (PROT) viene utilizzato per identificare a quale proto-
collo di livello superiore (ULP) si riferiscono i dati contenuti nel campo pay-
load. Attraverso questo campo vengono realizzate operazioni di multiple-
xer/demultiplexer in fase di incapsulamento/decapsulamento dei dati scam-
biati con i protocolli ULP.
In questo modo ad ogni ULP è assegnato univocamente un valore definito da
IANA (per esempio: ICMP = 1, IGMP = 2, TCP = 6, UDP = 17, …). Pertanto, ad
ogni PDU di un protocollo ULP (da notare che si fa riferimento ai protocolli
ICMP e IGMP come protocolli ULP anche se in effetti sono collocati allo stes-
so livello del protocollo IP, in quanto anch’essi vengono incapsulati in PDU
IP), in fase di incapsulamento in un datagramma IP, viene associato un
determinato valore PROT. Così facendo quando il datagramma giunge a
destinazione, il corrispondente livello IP all’atto del decapsulamento estrae il
payload e lo consegna al protocollo identificato dal campo PROT.
Per avere la lista completa dei valori possibili consultare il sito http://www.
iana.org/assignments/protocol-numbers.
107
Parte 3
Alcuni dei valori per i protocolli più comuni descritti nella tabella 5.17.
Tabella 5.17: I protocolli più comuni

Valore Campo PROT Protocollo
0 Riservato (IPv6 Hop-by-Hop Option)
1 ICMP
2 IGMP
4 IP in IP (encapsulation)
6 TCP
17 UDP
50 ESP Encap Security Payload for IPv6
51 AH Authentication Header for IPv6
89 OSPF
Essendo definito in ogni sistema operativo nel quale è implementato il pro-

tocollo TCP/IP il file protocols (/etc/protocols in ambito Unix/Linux; %Sy-
stemRoot%\System32\drivers\etc\protocols in ambiente Microsoft Win*),
che contiene la risoluzione tra i valori del campo PROT ed i relativi protocol-
li, è possibile riferirsi a questi ultimi anche tramite il nome descrittivo anzi-
ché per numero.
■ Header Checksum
Questo campo contiene un codice costituito da 16-bit (2 ottetti) utilizzato
per rilevare eventuali errori in fase di trasmissione del datagramma. In caso
di rilevazione di errore da parte di un nodo (per esempio: router) il relativo
datagramma viene scartato senza l’invio di alcun riscontro al mittente né
richiesta di ritrasmissione. Il Checksum Header copre solamente la parte IP
Header e non prende in considerazione la relativa componente payload.
L’algoritmo di generazione del checksum consiste nell’applicazione delle
seguenti operazioni:
a. Inizializzare a 0 il campo Checksum.
b. Per ogni blocco di 16-bit dell’Header IP viene calcolato il complemento
ad 1 (ovvero: vengono invertiti i bit: gli 1 diventano 0 e viceversa).
c. Vengono sommati i singoli complementi ad 1 di ogni blocco (tenendo
conto di eventuali riporti che devono essere risommati).
d. Viene ricavato il complemento ad 1 della somma precedente.
e. Il risultato viene copiato nel campo Checksum Header.
Oppure si sommano i singoli blocchi da 16-bit (tenendo conto di eventuali
riporti) e poi si calcola il complemento a 1 del risultato.
Da notare che questo campo deve essere rigenerato ogni volta che il data-
gramma subisce delle variazioni, ad esempio in conseguenza del suo rein-
stradamento da parte di un router conseguente alla modifica del campo TTL.
108
Esempio di calcolo del checksum

Consideriamo la seguente porzione di cattura di una frame (cf. file \Catture\Esem-
pioChecksum.cap, frame numero 10, sul CD-ROM allegato) riferita ad un comando
ping, dall’host 10.1.1.1 all’host 192.168.1.201, come si può evidenziare dal campo pro-
tocollo (ICMP = 0x01):
IP: ID = 0x14E5; Proto = ICMP; Len: 60

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Precedence = Routine
IP: Type of Service = Normal Service
IP: Total Length = 60 (0x3C)
IP: Identification = 5349 (0x14E5)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 127 (0x7F)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0x5969
IP: Source Address = 10.1.1.1
IP: Destination Address = 192.168.1.201
IP: Data: Number of data bytes remaining = 40 (0x0028)
Raccogliendo in forma tabellare i valori esadecimali relativi all’header avremo

quanto mostrato nella figura 5.12.
Figura 5.12: I valori esadecimali relativi all’header in forma tabellare
I valori esadecimali relativi all’header corrispondono ai campi mostrati nella figu-

ra 5.13.
Figura 5.13: I campi corrispondenti ai valori esadecimali relativi all’header

109
Parte 3
A questo punto sommiamo tutti i campi dell’header a blocchi di 16-bit a partire

dal campo Version (tabella 5.18).
Tabella 5.18: Somma a blocchi di 16-bit a partire dal campo Version

45 00 + Primo blocco di 16 -bit (Version + IHL + TOS)
00 3C = Secondo blocco di 16-bit (Total Length)
45 3C + Risultato intermedio
14 E5 = Terzo blocco di 16-bit (Identification)
5A 21 + Risultato intermedio
00 00 = Quarto blocco di 16-bit (Flags + Fragment Offset)
5A 21 + Risultato intermedio
7F 01 = Quinto blocco di 16-bit (TTL + Protocol)
D9 22 + Risultato intermedio
00 00 = Sesto blocco di 16-bit (Checksum inizializzato a 0)
D9 22 + Risultato intermedio
0A 01 = Settimo blocco di 16-bit (primi due ottetti IP Source)
E3 23 + Risultato Intermedio
01 01 = Ottavo blocco di 16-bit (ultimi due ottetti IP Source)
E4 24 + Risultato intermedio
C0 A8 = Nono blocco di 16-bit (primi due ottetti IP Dest)
(1)A4 CC Essendoci un riporto si elimina la cifra più a sinistra
e la si somma al risultato
A4 CD + Risultato intermedio
01 C9 = Decimo blocco di 16-bit (ultimi due ottetti IP Dest)
A6 96 Risultato finale in esadecimale
1010 0110 1001 0110 Trasformazione in binario
0101 1001 0110 1001 Complemento a uno
59 69 Riconversione in esadecimale
■ Source Address (SOURCE), Destination Address (DEST)

Essendo il protocollo IP di tipo connection-less per ogni datagramma è
necessario specificare gli indirizzi IP mittente e destinatario al fine di identi-
ficare univocamente le due 3-entità (ovvero: entità di livello 3 ISO/OSI) coin-
volte nel processo di comunicazione (o IPC, InterProcess Communication). In
caso di utilizzo di sistemi di interconnessione ad Internet di tipo Proxy o NAT
i suddetti indirizzi saranno riferiti a questi ultimi e non ai nodi estremi. Lo
stesso vale in caso di utilizzo di meccanismi di loose o strict routing (cf.
Options e Padding quindi seguito).
■ Options e Padding (OPT)
• Dimensione campo = variabile a blocchi di 4 ottetti (0 ÷ 10)
110
La predisposizione di questo campo speciale, opzionale e di lunghezza varia-

bile da 0 a 10 blocchi (dette anche parole o word) di 32-bit, consente di
aggiungere informazioni addizionali anche non previste nella versione origi-
naria del protocollo, da utilizzare per fini sperimentali o di test. Ciò evita di
sovraccaricare l’header di un datagramma con una quantità fissa di bit uti-
lizzata solo raramente ed in casi particolari.
Da notare che, come specificato nella RFC 791, ciò che è opzionale non è
l’implementazione di questa funzionalità a livello di software o stack TCP/IP,
che deve essere obbligatoriamente prevista, ma solamente la sua inclusione
e trasmissione in un datagramma IP. Inoltre, affinché si possano utilizzare le
informazioni contenute in questo campo è necessario che tutti i nodi inte-
ressati prevedano il loro trattamento.
Come anticipato precedentemente, il “quanto” minimo che costituisce
l’Header di un datagramma IP ha una lunghezza pari a 32-bit cioè 4 ottetti.
Pertanto, l’eventuale estensione dell’header attraverso l’aggiunta delle
opzioni deve essere eseguita per incrementi di 32-bit, prevedendo di inserire
dei caratteri “null” (operazione chiamata anche padding-zero) per riempire i
“buchi” rimanenti per ottenere “l’allineamento” a 32-bit dell’Header.
IP Options e Security
I servizi messi a disposizione dal campo Options e Padding sono raramente utilizza-
ti. Di conseguenza le relative funzionalità, in generale, possono sfuggire ad una fase
di testing e debugging accurata, lasciando spazio a potenziali buchi utilizzabili per
attacchi di tipo Denial Of Service o di violazione della security del sistema.
Esistono due formati per il campo Options:
• Formato 1: contiene un singolo ottetto di tipo Option-Type (figura 5.14).
Figura 5.14: Un singolo ottetto di tipo Option-Type
• Formato 2: contiene un numero variabile di ottetti in modo tale che il loro

numero dia luogo a multipli di 4 ottetti o 32-bit mediante l’inserimento di
opportuni ottetti utilizzati con funzioni di padding. Il primo ottetto è sempre
di tipo Option-Type, il secondo ottetto è di tipo Option-Length ed i successi-
vi sono di tipo Option-Data. La lunghezza specificata dal campo Option-
Length si riferisce a tutti e tre i campi (figura 5.15).
111
Parte 3
Figura 5.15: Lunghezza specificata dal campo Option-Length si riferisce a tutti

e tre i campi
L’ottetto Option-Type è strutturato in tre campi (figura 5.16).
Figura 5.16: Struttura dell’ottetto Option-Type
I tre campi assumono il significato seguente:
■ Copied Flag (CF) (1 bit): è identificato dal bit più significativo (MSB), cioè
quello più a sinistra, e serve per indicare ad un router o all’host sorgente se
durante il processo di frammentazione di un datagramma deve copiare il
contenuto del campo Options su tutti i frammenti (Copied = 1) oppure sola-
mente nel primo (Copied = 0). Per tale motivo esso viene anche indicato con
il termine Copy on Fragmentation (CF).
■ Option-Class (2-bit): è costituito dai successivi due bit e permette di identifi-
care 4 classi, delle quali quelle utilizzate sono solamente quelle di ordine pari
(0 e 2) come indicato nella tabella 5.19.
Tabella 5.19: Valori del campo Option-Class

Option-Class Descrizione
0 00 Network Control
1 01 Riservato per usi futuri
2 10 Debugging e misurazioni
3 11 Riservato per usi futuri
■ Option-Number (5-bit): questo campo è costituito da 5-bit e consente di defi-

nire fino a 25 = 32 opzioni differenti per ciascuna delle classi precedenti. Nella
tabella 5.20 sono indicate alcune delle classi e opzioni più utilizzate (RFC
791, RFC 1108) (per una lista completa consultare il sito http://www.iana.
org/assignments/ip-parameters).
112
Tabella 5.20: Classi e opzioni maggiormente utilizzate

CF Option-Class Option-Number Option-Length (Valore decimale ottetto Option-Type)
(1-bit) (2-bit) (5-bit) Descrizione
0 0 0 — (0) End Of Option List (EOOL)
0 0 1 — (1) No Operation
1 0 2 11 (130) US DoD Basic Security
(SEC), RFC 1108
1 0 3 Variabile (131) Loose Source Route (LSR)
o Loose Source e Record Route
(LSRR)
1 0 5 Variabile (133) US DoD Extended Security
(E-SEC), RFC 1108
0 0 7 Variabile (7) Record Route (RR)
1 0 8 4 (136) Stream ID (SID)
1 0 9 Variabile (137) Strict Source Route (SSR)
o Strict Source e Record Route
(SSRR)
0 2 4 Variabile (68) Internet Timestamp (TS)
Analizziamo brevemente l’utilizzo di alcuni dei tipi di Option-Type indicati nella

tabella 5.20:
■ End Of Option List (EOOL): valore decimale: 0; valore esadecimale: 0x00.

L’opzione EOOL è costituita da un solo ottetto nel quale tutti gli 8-bit hanno
valore 0:
0 0 0 0 0 0 0 0
Viene utilizzata, come dice lo stesso nome, per indicare la fine della lista delle
opzioni. Non sempre questo ottetto coincide anche con la fine dell’header IP.
Infatti nel caso di un eventuale arrotondamento (o padding) a 32-bit (o 4-
ottetti), e in accordo alla lunghezza specificata nel campo IHL, possono esse-
re aggiunti degli ulteriori ottetti di tipo NOP (No Operation).
■ No Operation (NOP): valore decimale: 1; valore esadecimale: 0x01.
L’opzione NOP è costituita da un solo ottetto nel quale tutti gli 8-bit hanno
valore 0 tranne quello meno significativo (LSB) che vale 1:
0 0 0 0 0 0 0 1
Essa viene utilizzata per realizzare funzioni di padding allo scopo di allinea-
re a 32-bit (o 4 ottetti) le successive opzioni.
■ IP Security Option (IPSO)
Queste opzioni sono utilizzate principalmente in ambito militare (US DoD) e
consentono di definire livelli di sicurezza per la classificazione dei datagram-
mi, per la “compartimentalizzazione”, per la gestione delle restrizioni e l’i-
dentificazione dei cosiddetti Closed User Group (CUG) e Transmission Con-
trol Code (TCC).
113
Parte 3
Come riportato nella tabella 5.21 esistono due tipi di opzioni di sicurezza o
IPSO:
• US DoD Basic Security Option (SEC), RFC 1108: valore decimale: 130;
valore esadecimale: 0x82 (tabella 5.21).
Tabella 5.21: Opzioni Basic Security (SEC)

Option-Type Option-Length IPSO Compartments Handling Restrictions Transmission Control Code
(130) (11) (min. 3)
8-bit 8-bit 16-bit 16-bit 16-bit 24-bit
10000010 00001011 SSS...SSS CCC...CCC HHH...HHH TCC
• US DoD Extended Security (E-SEC), RFC 1108: valore decimale: 133; valo-
re esadecimale: 0x85.
Le opzioni di sicurezza estese consentono di aggiungere delle ulteriori
specifiche. Il loro formato è mostrato nella tabella 5.22.
Tabella 5.22: Opzioni Extended Security (E-SEC)

Option-Type Option-Length Additional Security Additional Security
(133 / 0x82) (min. 3) Info Format Code Information
8-bit 8-bit 8-bit Variabile
10000101 000LLLLL AAAAAAAA TCC
Per una descrizione più approfondita sulle IPSO consultare le RFC 791 e RFC
1108 ed il sito http://www.iana.org/assignments/protocol-numbers.
■ Record Route (RR): valore decimale: 7; valore esadecimale: 0x07.
L’opzione RR è caratterizzata dal valore decimale 7 del campo Option-Type e
ha la struttura mostrata nella tabella 5.23.
Tabella 5.23: Opzione Record Route (RR)

Option-Type Option-Length Pointer-Offset Route Data
(7 / 0x07) (max. 9 Indirizzi IP = 9 blocchi da 32-bit)
Essa può essere utilizzata da un host mittente per istruire ciascun router
attraversato da un datagramma contenente questa opzione, ad inserire il
proprio indirizzo IP di inoltro in uno spazio apposito (campo variabile Route
Data) riservato all’interno dello stesso datagramma e identificato dal campo
Pointer Offset o Next Slot Pointer. L’indirizzo IP che ogni router inserirà nella
lista è quello più lontano rispetto all’host mittente (farthest o outgoing o
forwarding). La registrazione degli indirizzi IP da parte dei vari router attra-
versati dal datagramma, deve avvenire nel rispetto dei limiti dei 40 ottetti a
disposizione per la parte Options e Padding. Questo spazio viene predisposto
dall’host sorgente ed inizializzato a 0.
114
Da quanto detto finora ed osservando la struttura dell’opzione RR, si può dedur-

re che:
• Essendo CF = 0 questa opzione deve essere copiata solamente sul primo

frammento in caso di deframmentazione.
• Essendo: 40 = dimensione massima IP Options; 3 = overhead della opzione
RR; sarà: (40 – 3) / 4 = 9) da notare che si tratta di una divisione intera)” dopo
il numero 9 e prima del punto. Ciò vuol dire il campo Route Data può conte-
nere fino ad un massimo di 9 indirizzi IP di router.
• Non essendo la dimensione complessiva della opzione RR un multiplo di 4 è
necessario aggiungere o una opzione EOOL (se non esistono altre opzioni)
oppure una opzione NOP (nel caso in cui siano presenti altre opzioni) per
allineare l’header IP a 32-bit.
• Il campo Pointer contiene l’indirizzo (chiamato anche Offset o Next Slot Poin-
ter) del campo IP Address nel quale ciascun router dovrà inserire il proprio
indirizzo. Da notare che l’offset è riferito all’inizio della stessa opzione. Il suo
valore iniziale (e comunque minimo) è pari a 4. L’aggiornamento, da parte di
ogni router, deve avvenire per multipli di 4. Pertanto il suo valore può essere
specificato tramite la seguente espressione:
Pointer = 4 * N, con 1 ≤ N ≤ 9.
• Nel caso in cui il valore iniziale del puntatore è inferiore a 4 viene restituito
un messaggio di errore tramite ICMP.
• Nel caso in cui non esista più alcuno slot disponibile per registrare un ulte-
riore indirizzo IP (o perché sono stati utilizzati tutti i 9 spazi a disposizione o
perché il valore contenuto nel campo pointer è superiore a 9) il router inoltra
il datagramma senza tracciare la successiva attività o ignorando completa-
mente l’opzione (valore iniziale pointer > 9).
IP Record Route e Traceroute

■ Le stesse informazioni registrate utilizzando l’opzione RR sono ottenibili anche
tramite il comando traceroute.
■ A differenza del comando traceroute la lista prodotta da RR è limitata a 9 indi-
rizzi.
■ A differenza del comando traceroute che fornisce una lista asimmetrica della
rotta (ovvero: solo in una direzione), l’opzione RR consente di verificare il path di
routing in entrambe le direzioni.
Utilizzare l’opzione RR mediante il comando ping

Utilizzando il comando ping è possibile configurare l’utilizzo dell’opzione RR:
■ Windows 9x/NT/2K/XP/2003: Ping –r NumeroHop IPDestinatario
dove NumeroHop ≤ 9. Così facendo l’host mittente predispone all’interno del data-
gramma un numero di slot pari a “NumeroHop” per ospitare gli indirizzi che i vari
router aggiungeranno.
115
Parte 3
Esempio: ping –r 5 192.168.1.199

• *nix/Linux:
ping –R IPDestinatario
Esempio:
ping –R 192.168.1.200
■ Source Routing (SR)

Normalmente l’inoltro dei datagrammi IP all’interno di una infrastruttura di
reti interconnesse è determinata dalla configurazione dei router di collega-
mento (intermediate system o gateway). Infatti su ciascun router è definita
una tabella o mappa delle rotte che un datagramma deve seguire per giun-
gere, nel modo più ottimale possibile, a destinazione.
Attraverso l’utilizzo delle opzioni di SR è possibile predeterminare la rotta
(ovvero: Routing) che un datagramma dovrà seguire per giungere a destina-
zione, direttamente alla sorgente (ovvero: Source) e ciò indipendentemente
dalla configurazione delle mappe di routing di ciascun router interessato dal
processo di SR.
Queste opzioni sono utili in fase di test per verificare delle tratte alternative o
per dirottare alcuni datagrammi su dei percorsi “più convenienti” (ovvero:
più affidabili, meno costosi) o “fraudolenti” cioè “dirottati” forzatamente da
terze persone (ovvero: hacker).
Naturalmente lo svantaggio nell’utilizzo delle opzioni di SR è la conoscenza
richiesta della topologia della rete utilizzata e la lista dei router interessati dal
processo di inoltro o forwarding.
In particolare esistono due variazioni di SR:
• Loose Source Route (LSR) o Loose Source e Record Route (LSRR): valore de-
cimale: 131; valore esadecimale: 0x83.
Nel caso di LSR l’host mittente predispone una lista di indirizzi IP di rou-
ter i quali non necessariamente devono essere contigui (neighboring
router), ma possono trovarsi anche su reti non adiacenti e quindi sepa-
rati da più di un salto (hop). Nel caso in cui due indirizzi IP non siano
consecutivi un router può liberamente scegliere un qualsiasi percorso
per completare la tratta (path) mancante.
Questa opzione viene indicata anche come Loose Source and Record
Route (LSRR) in quanto consente, alla fine del processo di SR, di ricavare
la traccia dei router attraversati dal datagramma come l’opzione Record
Route.
Il formato dell’opzione LSRR è mostrato nella tabella 5.24.
Tabella 5.24: Opzione Loose Source Route (LSR)

116
• Strict Source Route (SSR) o Strict Source e Record Route (SSRR) valore
decimale: 137; valore esadecimale: 0x89.
Nel caso di SSR l’host mittente predispone la lista esatta degli indirizzi IP
dei router che devono essere attraversati dal datagramma. A differenza
dell’LSR è obbligatorio che indirizzi consecutivi specificati nella lista
appartengano a reti adiacenti cioè direttamente connesse (ovvero: non
possono risiedere su due subnet separate da più di un router). Viceversa,
l’inoltro del datagramma non può essere effettuato e di conseguenza
esso verrà scartato.
Questa opzione viene indicata anche come Strict Source and Record
Route (SSRR) in quanto consente, alla fine del processo di SR, di ricavare
la traccia dei router attraversati dal datagramma come l’opzione Record
Route.
Il formato dell’opzione SSRR è mostrato nella tabella 5.25.
Tabella 5.25: Opzione Strict Source Route (SSR)

L’host dal quale viene inviato il datagramma con l’opzione LSR o SSR
prepara la struttura del datagramma inizializzando il campo Destination
Address con il primo indirizzo della lista LSR o LSR ed il campo Pointer
con il valore 4.
Ciascun router interessato dal processo LSR o SSR prepara il datagram-
ma da inviare inserendo come campo Destination Address l’indirizzo IP
puntato dal campo Pointer. Dopodiché registra nella lista degli indirizzi
LSR o SSR l’indirizzo IP dell’interfaccia verso la quale deve essere reinol-
trato il datagramma nel posto indicato da Pointer. Infine viene incre-
mentato di 4 unità il valore di Pointer.
Nel caso del processo LSR il campo Destination Address può contenere
anche l’indirizzo IP di un router non specificato nell’elenco LSR ma pre-
levato direttamente dalla tabella di routing locale dello stesso router.
Continuando in questo modo il datagramma caratterizzato dal processo
LSR o SSR raggiungerà la fine del percorso quando il valore del campo
Pointer conterrà un valore di offset che sarà superiore alla lunghezza del-
l’opzione (Option-Length) e l’host destinatario iniziale è stato raggiunto
(ovvero: l’ultimo indirizzo indicato nell’header IP coincide con uno degli
indirizzi locali). A questo punto, come specificato nella RFC 1122, la lista
viene passata così com’è ad un protocollo di livello superiore (ULP) o
applicazione (tramite un protocollo ULP) o per costruire la risposta
all’host mittente tramite il protocollo ICMP nel caso di errore o messag-
gio di reply ad un eventuale comando ping. In ogni caso la lista di SR pas-
sata dal livello networking viene successivamente invertita e la risposta
verrà quindi inviata al primo indirizzo indicato nella nuova lista. Poiché
117
Parte 3
la lista SR può essere manipolata essa può essere costruita facendo in

modo che il primo indirizzo della lista invertita punti ad un host presele-
zionato (scanned host) di una seconda rete raggiungibile tramite router o
host con doppia scheda di rete (per esempio: WinNT/2K/2003 multi-
homed configurato come router).
Infine, nel caso in cui all’interno di uno stesso datagramma si trovano
due opzioni SR conflittuali secondo la RFC 1122 il comportamento dello
stack può dipendere dalla particolare implementazione.
Utilizzare l’opzione RR mediante il comando ping

Utilizzando il comando ping è possibile configurare l’utilizzo delle opzioni LSR e
SSR:
■ LSR: Windows 9x/NT/2K/XP/2003: Ping –j <lista SR> <IPDestinatario>
■ SSR: Windows 9x/NT/2K/XP/2003: Ping –k <lista SR> <IPDestinatario>
Source Routing e potenziali risvolti sulla sicurezza

Le opzioni di SR sono spesso utilizzate unitamente alle procedure di IP spoofing (let-
teralmente truffa dell’indirizzo IP) per ridirigere dei datagrammi verso un host “fan-
tasma” transitando magari attraverso un host “sicuro” cioè interno alla rete. Da
notare che colui che attacca il sistema può risiedere anche su una rete esterna (per
esempio: Internet) rispetto all’host attaccato. Delle due tecniche quelle che risulta più
critica dal punto di vista della sicurezza è la LSR per la quale è sufficiente inserire
all’interno della lista SR l’indirizzo presso il quale si vogliono dirottare i datagram-
mi, senza la necessità di conoscere l’intera topologia di routing.
Per questo motivo come misura preventiva è consigliato disabilitare il meccanismo
di SR direttamente tramite firewall, router (per esempio, nel caso di router Cisco,
inserendo il comando no ip source-route) e server NAT.
A tale proposito secondo la RFC 1122 occorre distinguere tra “local source-routing”
nel caso in cui il reinoltro del datagramma avviene attraverso la stessa interfaccia
fisica di rete e “non-local source-routing” nel caso in cui avvenga attraverso una
diversa interfaccia (per esempio: sistemi multi-homed o router). In tal caso mentre il
SR locale deve essere sempre permesso per quello non-locale deve essere consentita la
disabilitazione.
Disabilitare SR su un computer WinNT/2K/XP/2003 multi-homed configurato

come router
Aggiungendo la seguente chiave nei registry è possibile disabilitare il processo di SR
su computer WinNT/2K/XP/2003 multi-homed e configurati come router:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\
Parameters\DisableIPSourceRouting.
118
• Timestamp (TS): valore decimale: 68; valore esadecimale: 0x44.

L’opzione TS è caratterizzata dal valore decimale 68 del campo Option-
Type e presenta la struttura mostrata in tabella 5.26.
Tabella 5.26: Opzione Timestamp

Option-Type Option-Length Pointer-Offset Overflow Flag
(68 / 0x44) (4-bit) (4-bit)
Area Dati IP Address 1 (32-bit)
Timestamp 1 (32-bit)
…
…
Il suo funzionamento è molto simile a quello dell’opzione RR.

Essa può essere utilizzata da un host mittente per istruire ciascun router
attraversato da un datagramma contenente questa opzione, ad inserire il
proprio indirizzo IP di inoltro ed il timestamp (ovvero: il tempo di rice-
zione del datagramma espresso in millisecondi rispetto all’ora GMT
(Greenwich Meridian Time, o UTC Universal Time Coordinate) e salvato
in una variabile a 32-bit) in uno spazio apposito (nei sotto campi IP
Address e Timestamp del campo variabile Area Dati) riservato all’interno
dello stesso datagramma e identificato dal campo Pointer Offset o Next
Slot Pointer. Questo spazio viene predisposto dall’host sorgente ed ini-
zializzato a 0.
La registrazione degli indirizzi IP e del timestamp da parte dei vari rou-
ter attraversati dal datagramma, deve avvenire nel rispetto dei limiti dei
40 ottetti a disposizione per la parte Options e Padding. Pertanto la di-
mensione del campo Area Dati è data da 40 – 4 (ottetti di overhead) = 36
ottetti, ovvero 9 parole da 32-bit. La lunghezza dell’opzione TS è conte-
nuta nel campo Option-Length.
Il campo Pointer Offset o Next Slot Pointer è un indice, relativo all’inizio
del campo Options, che punta al primo campo libero all’interno della
sezione Area Dati. Il valore minimo che può contenere questo campo è
pari a 5; esso viene inizializzato dall’host mittente ed aggiornato da ogni
router.
Il campo Overflow contiene il numero di router (fino ad un massimo di
24 – 1 = 15) che non hanno potuto registrare il proprio indirizzo IP ed il
relativo timestamp, per mancanza di spazio nel settore Area Dati.
Il campo Flag serve per controllare la tipologia di informazioni che cia-
scun router può inserire nel campo Area Dati. I valori possibili sono
mostrati nella tabella 5.27.
119
Parte 3
Tabella 5.27: Valori possibili del campo Flag dell’opzione Timestamp

Flag Descrizione
0 Solo Record Timestamp in parole di 32-bit.
1 Ogni router inserisce prima l’indirizzo IP e poi (nella successiva parola
di 32-bit) il Timestamp.
2 Riservato.
3 L’indirizzo IP è pre-specificato dal mittente. Ogni router inserisce, nel campo
relativo associato, il timestamp.
4 ÷ 15 Riservati.
Il valore del Timestamp può essere di due tipi:

• right-justified: espresso in millisecondi rispetto all’ora GMT (Green-
wich Meridian Time) o UTC (Universal Time Coordinate) rispetto alla
mezzanotte, e salvato in una variabile a 32-bit.
• non-standard-time: non necessariamente espresso in millisecondi e
non necessariamente aggiornato rispetto all’ora UTC. Per differen-
ziarla dall’ora standard viene settato ad uno il bit di ordine superiore.
Nel caso in cui l’area dati risulta essere già piena, il datagramma viene
comunque inoltrato senza inserire il relativo timestamp ed incremen-
tando di una unità il campo overflow.
Viceversa, se lo spazio a disposizione è insufficiente per inserire un Full-
Timestamp oppure se il campo overflow è già arrivato al valore limite (15)
il relativo datagramma viene considerato in uno stato di errore e viene
scartato. In entrambi i casi viene inoltrato un messaggio ICMP all’host
sorgente.
Da notare infine che essendo il valore Option-Type pari a 68 ed essendo
quindi il primo bit (MSB) uguale a zero, questa opzione non necessita di
essere ricopiata in ogni frammento ma solamente nel primo.
Appendice 5A:
Domande - FAQ (Frequently Asked Questions)
1) Utilizzando la regola del “valore decimale del primo ottetto” quale dei se-
guenti indirizzi IP sono di classe B?
a. 1.2.3.4
b. 127.255.255.254
c. 128.0.0.1
d. 191.1.0.1
e. 192.168.1.200
f. 224.0.0.1
[R1]; c, d.
120
2) Quali sono le classi comunemente utilizzabili per l’assegnazione degli indi-

rizzi IP pubblici?
a. A
b. B
c. C
d. D
e. E
f. F
[R2]: a, b, c.
3) Quali sono i valori ammissibili per il primo ottetto per le classi comunemen-
te utilizzate?
a. Classe A: 0 ÷ 127
b. Classe A: 1 ÷ 126
c. Classe B: 127 ÷ 192
d. Classe B: 128 ÷ 191
e. Classe C: 191 ÷ 223
f. Classe C: 192 ÷ 223
[R3]: b, d, f.
Da notare che anche se matematicamente gli indirizzi 0 e 127 fanno parte
della classe A essi non sono indirizzi validi, bensì riservati per uso speciale: 0
= “this network only” e 127 = loopback.
4) Qual è lo scopo della classe D?
a. Disporre indirizzi per host.
b. Disporre indirizzi per network.
c. Disporre indirizzi multicast.
d. Non utilizzata.
[R4]: c.
5) Identificare la classe di appartenenza dell’indirizzo IP 10.255.255.254 con la
subnet mask 255.255.255.240?
a. D
b. B
c. C
d. A
e. E
[R5]
d. La classe di un indirizzo IP non è alterata dal procedimento di subnet-
ting. Pertanto, essendo il primo ottetto dell’indirizzo compreso nella
fascia 1 ÷ 126, la classe di appartenenza sarà sempre la A indipendente-
mente dalla subnet mask associata.
121
Parte 3
6) Indicare quali dei seguenti indirizzi IP non sono validi per l’assegnazione ai
nodi di una rete?
a. 127.255.255.255
b. 1.2.3.4
c. 225.0.0.1
d. 0.0.0.1
e. 1.0.0.0
f. 1.0..0.1
g. 192.168.1.255
h. 192.168.1.256
i. 256.255.255.254
j. 255.255.255.255
[R6]
a: Riservato per fini diagnostici (loopback).
c: Riservato per applicazioni multicast (Classe D) e non utilizzabile
come indirizzo da assegnare agli host.
d, e: Ogni indirizzo IP da assegnare ad un nodo non può mai iniziare con 0
in quanto esso ha il significato speciale “this network”. Più in generale
né la parte <netID> né quella <hostID> possono essere costituite da
tutti-0.
h, i: Nessuno dei quattro ottetti di qualsiasi indirizzo IP può contenere un
valore decimale superiore a 255. Il valore massimo consentito è pari a
28 –1.
g, j: Né la parte <netID> né la parte <hostID> di un indirizzo IP da asse-
gnare ad un nodo possono mai contenere tutti-1 in quanto questa
configurazione assume il significato di broadcast.
7) Volendo suddividere una rete di classe C in più sottoreti, qual è il numero
massimo di bit della parte <hostID> (quarto ottetto) che si possono prende-
re in prestito?
a. 7
b. 5
c. 6
d. 8
[R7]
c: Ricordiamo che il numero di host (nH) che possono essere compresi in
una subnet costituita da nS bit è dato da: nH = 2nBiS – 2. Dove il “–2” tiene
conto del fatto che la parte <hostID> non può mai contenere né tutti-0
né tutti-1. Pertanto il numero di bit nBiH da riservare alla parte host non
può essere mai inferiore a 2. Quindi 8 –2 = 6 è il massimo numero di bit
che si possono prendere in prestito dalla parte <hostID> e dedicare alla
sezione <subNetID>.
122
8) A che cosa serve la network (o subnet) mask?

a. Per determinare la parte <hostID>.
b. Per determinare la parte <netID>.
c. Per identificare il default route.
d. Per ricavare la subnet di appartenenza di un indirizzo IP attraverso una
operazione di AND logico.
e. Per stabilire se un indirizzo IP destinazione è situato sulla stessa rete
logica del mittente oppure se appartiene ad una rete remota.
[R8]: b, d, e.
9) Quali sono i principali benefici del CIDR?
a. Consentire l’utilizzo di subnet mask ClassFull.
b. Ridurre le dimensioni delle tabelle di routing tramite l’aggregazione
delle entry (Route Aggregation).
c. Evitare il supernetting.
d. Consentire l’assegnazione di frazioni di indirizzi IP di classe C.
[R9]: b, d.
10) Qual è la lunghezza di un indirizzo IP e dei suoi componenti <netID> e
<hostID>?
a. Tutte le risposte seguenti sono corrette in relazione alla classe di appar-
tenenza dell’indirizzo IP.
b. 32-bit, 8-bit parte <netID>, 24-bit parte <hostID>.
c. 32-bit, 16-bit parte <netID>, 16-bit parte <hostID>.
d. 32-bit, 24-bit parte <netID>, 8-bit parte <hostID>.
[R10]: a.
11) Rifacendosi alla RFC 1918 indicare quali dei seguenti indirizzi IP sono riser-
vati per uso privato?
a. 171.1.2.3
b. 172.16.1.1
c. 169.254.1.2
d. 10.20.30.40
e. 192.168.1.1
f. 192.169.0.1
g. 172.32.1.2
h. 172.15.0.1
[R11]: b, d, e.
12) È corretto l’indirizzo 192.168.0001.0376?
a. Non è un indirizzo valido in quanto non è ammesso che un ottetto sia
rappresentato da un numero superiore a 255.
b. Si rappresenta un indirizzo espresso in forma DON (Dotted Octal No-
tation) e si riferisce all’indirizzo 192.168.1.254 espresso in forma DDN
(Dotted Decimal Notation).
123
Parte 3
c. È un indirizzo espresso in esadecimale (Dotted Exadecimal Notation).

[R12]: b.
Appendice 5B: Esercizi

1) Dato l’indirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare la
subnet di appartenenza e l’indirizzo di directed broadcast secondo la RFC
950.
a. Subnet = 190.190.0.0, Broadcast = 190.190.3.255
b. Subnet = 190.190.0.0, Broadcast = 190.190.7.255
c. Subnet = 190.190.1.0, Broadcast = 190.190.3.255
d. Configurazione non possibile.
[R1]: d.
Per determinare la subnet di appartenenza dell’indirizzo IP assegnato è suf-
ficiente trasformare in binario sia l’indirizzo sia la subnet mask e calcolare
l’AND logico. Per semplicità è considerato solamente il terzo ottetto della
subnet mask in quanto essendo i primi due composti da tutti-1 non alterano
il corrispondente valore dell’indirizzo IP (figura 5.17).
Figura 5.17: Trasformazione in binario dell'indirizzo IP e della subnet mask

dell'esercizio 1 e determinazione della subnet di appartenenza (AND logico)
Pertanto la subnet di cui fa parte l’indirizzo è costituita da: 190.190.0.0/22. In

particolare osservando la codifica binaria del terzo ottetto si può notare che
la parte <subNetID> è costituita da nBiS = 6-bit tutti-0. Quindi in rispetto
della RFC 950 questo indirizzo di subnet è da escludere.
2) Dato l’indirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare la
subnet di appartenenza e l’indirizzo di directed broadcast secondo la RFC
1812 (VLSM/CIDR).
d. Configurazione non possibile.
[R2]: a.
Rifacendosi al conteggio effettuato nell’esercizio precedente ed applicando
le regole sul subnetting dettate dalla RFC 1812 ne consegue che l’indirizzo
124 190.190.1.8/22 è “legale” ed appartiene alla subnet 190.190.0.0.
A questo punto per determinare l’indirizzo di broadcast è sufficiente calcola-

re le 26 = 64 subnet identificate dalla subnet mask 255.255.252.0 ed i rispetti-
vi range di indirizzi IP riservati agli host, assegnando ai 6-bit della parte
<subNetID> tutti i possibili valori 0 ed 1 (tabella 5.28).
Tabella 5.28: Valori assunti dal campo <subNetID> ovvero dai 6-bit di ordine superio-
re del terzo ottetto per l'indirizzo di rete dell'esercizio 2
Conversione da binario in decimale del terzo ottetto
Posizione 7 6 5 4 3 2 1 0
Peso =
2posizione 128 64 32 16 8 4 2 1
Valore decimale configurazioni possibili
<subNetID> <hostID>
0 0 0 0 0 0 0 0 0
4 0 0 0 0 0 1 0 0
... X X X X X X 0 0
248 1 1 1 1 1 0 0 0
252 1 1 1 1 1 1 0 0
Pertanto per la subnet identificata, l’indirizzo di directed broadcast corri-

sponde a 190.190.3.255, determinato assegnando il valore 1 a tutti i bit della
parte <hostID>. In sostanza esso corrisponde all’ultimo indirizzo IP del range
<hostID> corrispondente: 190.190.0.0 ÷ 190.190.3.255.
a) Regola pratica per la determinazione delle subnet nell’ipotesi RFC 1812

Per ricavare le subnet identificate da una determinata subnet mask è sufficiente,
dopo aver espresso in binario l’ottetto interessato dal procedimento di subnetting
(nell’esercizio precedente è il terzo), iniziare dalla subnet tutti-0 (decimale 0) e prose-
guire con il primo valore corrispondente al peso del bit di ordine inferiore della parte
<subNetID> (nell’esempio 4). Questo valore assumerà le funzioni di “passo” nella
determinazione delle successive subnet, per le quali si prosegue sommando ripetuta-
mente questo peso fino al raggiungimento del valore identificato dalla cifra decima-
le del relativo ottetto della subnet mask (nell’esempio si tratta del terzo ottetto di
valore 252) corrispondente alla configurazione tutti-uno per la parte <subNetID>.
b) Regola pratica per la determinazione delle subnet nell’ipotesi RFC 950

Nel caso della RFC 950 vanno eliminate le subnet corrispondenti ai valori estremi
dell’intervallo di subnet dedotto secondo la regola a) cioè le subnet tutti-0 e tutti-1.
c) Regola pratica per la determinazione degli indirizzi directed (o subnet)

broadcast
Dopo aver determinato l’insieme delle subnet secondo la regola a) o b), per la deter-
minazione dell’indirizzo da considerare come subnet broadcast bisogna considerare
per ciascuna subnet il range dei valori di indirizzi da assegnare agli host e identifi-
care l’ultimo valore di ciascun range (nell’esempio 190.190.3.255).
125
Parte 3
Per facilitare le operazioni di subnetting conviene riferirsi alla tabella mostrata qui
di seguito:
Subnet mask Passo nBiS_OS (Ottetto Subnetting)

128 128 1
192 64 2
224 32 3
240 16 4
248 8 5
252 4 6
254 2 7
255 1 8
Modalità d’uso: di solito nella maggior parte dei problemi di subnetting è assegna-
ta la subnet mask o in formato decimale (per esempio: 255.255.252.0) o in formato
network prefix o CIDR/VLSM (per esempio: /22). Pertanto è possibile utilizzare la
tabella precedente per derivare gli indirizzi delle subnet, degli host e di broadcast
seguendo i seguenti passi:
I. Se il valore della subnet mask è espresso in formato decimale (per esempio:
255.255.252.0) identificare immediatamente la colonna corrispondente al passo,
altrimenti identificare il numero di bit di subnetting nBiS dell’ottetto interessato
dal subnetting (secondo, terzo o quarto). A tale proposito è necessario verificare la
classe di origine dell’indirizzo IP assegnato ed accertarsi se il numero espresso in
formato CIDR si riferisce al numero effettivo di bit di subnetting nBiS oppure
complessivamente al numero di bit della netmask nBiSM:
• Considerando l’esercizio 2, per esempio se la subnet mask fosse stata assegna-
ta in formato CIDR con il valore /22 allora trattandosi di un indirizzo di clas-
se B si può immediatamente dedurre il numero di bit di dell’ottetto di sub-
netting: nBiS_OS = nBiS = nBiSM mod 8 = 22 mod 8 = 6.
• Nel caso di un indirizzo di classe A con subnet mask /30 sarà: nBiS_OS = 30
mod 8 = 6.
II. Conoscendo la subnet mask (in qualsiasi formato) identificare la colonna corri-
spondente al valore del passo da utilizzare per la determinazione delle subnet
(nell’esercizio precedente, 4).
III. Calcolare le subnet ed i rispettivi range di indirizzi IP da assegnare agli host
secondo le regole a) oppure b).
IV. Identificare il range di indirizzi riservati agli host a cui appartiene l’indirizzo
assegnato (nell’esercizio precedente, il range è 190.190.0.0 – 190.190.3.254).
V. Identificare l’indirizzo di broadcast per ogni subnet considerando l’ultimo indi-
rizzo IP di ciascun range degli host (nell’esercizio precedente, 190.190.3.255).
126
d) Regola matematica per la determinazione del “passo” delle subnet nel caso
in cui si conosca la subnet mask in formato decimale
Conoscendo la subnet mask in formato decimale è possibile ricavare il valore del
“passo” delle subnet dalla seguente relazione:
passo = 256 – <Valore Decimale Ottetto Subnetting>
Per esempio nel caso 255.255.252.0 sarà: passo = 256 – 252 = 4.
e) Regola matematica per la determinazione delle subnet VLSM data

la loro dimensione D (numero di host) o passo
Indicando con D la dimensione delle subnet da determinare (espressa in numero di
host), l’insieme delle subnet avrà come indirizzo iniziale (riferito all’ottetto interes-
sato dal subnetting) un valore dato da:
IP Start Subnet = D * N (N = 0, 1, 2, …)
Il cui limite superiore è dato dal valore decimale dell’ultimo ottetto della subnet
mask interessato dal subnetting.
Esempio: avendo assegnato il seguente indirizzo di classe C 223.223.223.0/24, si sup-

ponga di voler costruire delle subnet aventi ciascuna una capacità complessiva di 64
indirizzi (compreso tutti-0 e tutti-1). In tal caso le subnet avranno come ultimo ottet-
to un valore compreso nella seguente serie:
IP Start Subnet = 64 * N (N = 0, 1, 2, 3,...)
Per determinare il limite massimo è sufficiente dedurre la subnet mask necessaria
per ottenere le subnet di dimensioni 64. Cioè essendo 256 – 64 = 192 la subnet mask
sarà 255.255.255.192 oppure /26 in notazione CIDR.
Pertanto le subnet effettive nel caso RFC 1812 saranno: 223.223.223.0/26,
223.223.223.64/26, 223.223.223.128/26, 223.223.223.192/26.
3) Dato l’indirizzo 147.148.149.150 con 4-bit di subnet determinare la subnet di

appartenenza.
a. 147.148.0.0
b. 147.148.128.0
c. 147.148.144.0
d. 147.148.149.0
[R3]: c.
Facendo riferimento alla tabella 5.29, si può dedurre che il passo da utilizza-
re per la determinazione delle subnet è 16.
127
Parte 3
Tabella 5.29: Tabella per la determinazione del “passo” delle subnet

Subnet Mask 128 192 224 240 248 252 254 255
Passo 128 64 32 16 8 4 2 1
nBiS 1 2 3 4 5 6 7 8
Lo stesso risultato poteva essere conseguito anche trasformando la subnet

mask dalla notazione CIDR a quella decimale. In particolare considerando
solamente l’ottetto della subnet mask interessato dal subnetting (in questo
caso il terzo) e trasformandolo in decimale si ricava quanto mostrato nella
tabella 5.30.
Tabella 5.30: Deduzione del "passo" delle subnet tramite trasformazione in binario del
terzo ottetto interessato dal subnetting
Conversione da binario in decimale del terzo ottetto
Posizione 7 6 5 4 3 2 1 0
Peso =
2posizione 128 64 32 16 8 4 2 1
nBiS = 4 1 1 1 1 0 0 0 0
Valore decimale 240
Pertanto il “passo” delle subnet prodotte dal subnetting è dato da:

passo = 256 - 240 = 16.
A questo punto le 2nBiS = 16 subnet prodotte dal subnetting saranno: 0, 16, 32,
48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240. Quindi l’indirizzo
147.148.149.150 sarà compreso nella subnet 147.148.144.0/20.
4) Dato l’indirizzo 212.100.200.62 con la subnet mask 255.255.255.224 determi-
nare la subnet di appartenenza ed il relativo indirizzo di directed broadcast.
d. Subnet = 212.100.200.32, Broadcast = 212.100.200.63
[R4]: d.
Essendo la subnet mask espressa in forma decimale si ricava immediata-
mente il “passo” delle subnet prodotte dal subnetting:
passo = 256 – 224 = 32.
128
Essendo nBiS = 3 [(224)10 = (111)2] le 2nBiS = 8 subnet derivate saranno: 0, 32,

64, 96, 128, 160, 192, 224. Quindi l’indirizzo 212.100.200.62 sarà compreso
nella subnet 212.100.200.32/27 alla quale corrisponde l’indirizzo di broadca-
st 212.100.200.63.
5) Dato il seguente indirizzo di subnetting 143.1.9.61/28 (12-bit di subnet)
quale dei seguenti insiemi di indirizzi di host sono validi e quindi fanno parte
della stessa subnet dell’indirizzo assegnato?
a. 143.1.0.1 ÷ 143.1.255.254
b. 143.1.0.1 ÷ 143.1.9.62
c. 143.1.9.48 ÷ 143.1.9.62
d. 143.1.9.49 ÷ 143.1.9.62
[R5]: d.
Da notare che l’indirizzo assegnato è di classe B. Inoltre essendo il numero
dei bit di subnet (nBiS) pari a 12 ciò vuol dire che il subnetting si estende ai
4-bit del quarto ottetto.
Pertanto trasformando il quarto ottetto della subnet mask in formato deci-
male si ricava quanto mostrato nella tabella 5.31.
Tabella 5.31: Deduzione del "passo" delle subnet tramite trasformazione in binario del
quarto ottetto interessato dal subnetting
Posizione 7 6 5 4 3 2 1 0
Peso =
2posizione 128 64 32 16 8 4 2 1
nBiS = 8 (III Ottetto)
+ 4 (IV Ottetto) = 12 1 1 1 1 0 0 0 0
Valore decimale 240
A questo punto possiamo calcolare il “passo” delle subnet prodotte dal sub-
netting:
passo = 256 – 240 = 16.
Pertanto le 2nBiS = 4096 subnet derivate saranno: 143.1.0.0, 143.1.0.16,
143.1.0.32, ... 143.1.9.48, ..., 143.1.255.240.
Quindi l’indirizzo 143.1.9.61/28 sarà compreso nella subnet 143.1.9.48/28
alla quale corrisponde l’indirizzo di broadcast 143.1.9.63. Mentre il range di
host validi per la stessa subnet sarà: 143.1.9.49 ÷ 143.1.9.62.
6) Determinare l’indirizzo IP di aggregazione (summarization) per le due reti
172.26.136.0/24 e 172.26.143.0/24.
a. 172.26.128.0/20
b. 172.26.136.0/20
c. 172.26.136.0/21
d. 172.26.136.0/22
[R6]: c. 129
Parte 3
Per determinare l’indirizzo di summarization per le due subnet assegnate è

necessario convertirle in binario e calcolare il numero dei bit in comune a
partire dal bit più significativo del primo byte più a sinistra (più significativo).
Questo numero determina la subnet mask in formato CIDR da specificare
con l’indirizzo della prima subnet del gruppo (tabella 5.32).
Tabella 5.32: Trasformazione in binario dei due indirizzi IP e determinazione della

parte comune a partire dal bit più significativo del primo ottetto
Subnet in Formato DDN I ottetto II ottetto III ottetto IV ottetto
172.26.136.0 10101100 00011010 10001000 00000000
172.26.143.0 10101100 00011010 10001111 00000000
Pertanto l’indirizzo cercato è: 172.26.136.0/21.

7) Quante subnet e quanti host è possibile avere con il seguente indirizzo
172.26.42.0/11?
a. 8 Subnet, 2.097.152 Host.
b. 8 Subnet, 2.097.150 Host.
c. 8 Subnet, 8.190 Host.
d. 2046 Subnet con RFC 950 oppure 2048 Subnet con RFC 1812, 30 Host.
[R7]: d.
In questo esercizio occorre prestare attenzione alla convenzione CIDR utiliz-
zata. Infatti solitamente con essa viene specificato il numero di bit che costi-
tuiscono la network mask, che ricordiamo definita da:
<Network Mask > ::= <netID-Tutti-1> <subNetID-Tutti-1> <hostID-
Tutti-0>.
A volte, anche se raramente, con la convezione CIDR viene indicato il nume-

ro nBiS di bit che costituiscono la subnet mask ovvero la sola parte
<subNetID>, come in questo caso.
Pertanto i bit effettivi della network mask sono:
(numero di bit netmask classe B) + nBiS = 16 + 11 = 27.
Per cui risulta:
nS (numero Subnet) secondo RFC 950 = 211 – 2 = 2046
nS (numero Subnet) secondo RFC 1812 = 211 = 2048
nH (numero Host) = 2(32-27) – 2 = 30.
8) Si dispone del seguente indirizzo di rete di classe B 172.26.0.0/16. Volendo
creare delle sottoreti ognuna delle quali può ospitare fino a 650 host, quale
subnet mask è necessario utilizzare?
a. 255.255.255.0
b. 255.255.248.0
c. 255.255.254.0
d. 255.255.252.0
130
[R8]: d.
Trattandosi di un indirizzo di classe B risulta: nBiN = 16, nBiH = 16.
Dovendo creare delle subnet è necessario prendere in prestito alcuni dei 16-
bit della parte <hostID>. Dovendo comunque disporre di 650 per ciascuna
subnet è necessario riservare un numero minimo di nBiH bit tale per cui sia
soddisfatta la seguente disequazione binaria:
nN (numero di Host) = 2nBiH – 2 ≥ 650
dalla quale si ricava: nBiH = 10.
Pertanto la quantità di bit rimanenti per la parte <subNetID> è data da:
nS = 16 – 10 = 6.
Per cui la network mask risulta essere /22 in notazione CIDR oppure
255.255.252.0 in notazione decimale.
9) Un cliente ha ottenuto dal suo Internet Service Provider (ISP) la seguente sub-
net di classe C: 223.223.223.0/24. Volendo organizzare la propria rete interna
secondo quanto indicato nella figura 5.18, nella quale:
Subnet1 (LAN1): richiede 100 indirizzi
Subnet2 (LAN2): richiede 50 indirizzi
Subnet3 (LAN3): richiede 25 indirizzi.
Nell’ipotesi di utilizzare dispositivi di networking (router) che supportano
CIDR/VLSM definire gli indirizzi IP da associare alle tre subnet IP e le relati-
ve subnet mask e formulare inoltre un'ipotesi di configurazione dei router
mediante tabelle di routing statiche:
Figura 5.18: Esempio per l’esercizio 9
131
Parte 3
a. Subnet1: 223.223.223.0/25; Subnet2: 223.223.223.128/26; Subnet3:

223.223.223.192/27
b. Subnet1: 223.223.223.0/26; Subnet2: 223.223.223.16/26; Subnet3:
223.223.223.32/26
c. Subnet1: 223.223.223.0/24; Subnet2: 223.223.223.128/25; Subnet3:
223.223.223.192/26
d. Impossibile.
[R9]: a.
Tabella 5.33: Processo di suddivisione della rete iniziale in 4 sottoreti

LAN Subnet IP Subnet mask nH Range IP Host
LAN1 223.223.223.0 /25 126 223.223.223.1 ÷ 223.223.223.126
255.255.255.128 Subnet Broadcast: 223.223.223.127
LAN2 223.223.223.128 /26 62 223.223.223.129 ÷ 223.223.223.190
LAN3 223.223.223.192 /27 30 223.223.223.193 ÷ 223.223.223.222
Uso Futuro 223.223.223.224 /27 30 223.223.223.225 ÷ 223.223.223.254
Supponendo di assegnare alle interfacce dei router i seguenti indirizzi IP:

• Router1I, LAN1: 223.223.223.1
• Router12, LAN1: 223.223.223.2
• Router13, LAN1: 223.223.223.3
• Router12, LAN2: 223.223.223.129
• Router13, LAN3: 223.223.223.193
e vista la semplicità dell’infrastruttura di rete, in questo caso è possibile im-
postare staticamente le seguenti entry statiche, supponendo che i router
siano dei Cisco (tabella 5.34).
Tabella 5.34: Esempio di configurazione statica delle tabelle di routing dei router
Router Descrizione tabella Routing Configurazione
Router1I “subnet2 via router12” ip route 223.223.223.128 225.225.225.192 223.223.223.2
“subnet3 via router13” ip route 223.223.223.192 225.225.225.224 223.223.223.3
Router12 “Internet via router1I” ip route 0.0.0.0 225.225.225.255 223.223.223.1
Router13 “Internet via router1I” ip route 0.0.0.0 225.225.225.255 223.223.223.1
132
E, per finire, affinché i router siano in grado di gestire gli indirizzamenti di

tipo CIDR/VLSM ClassLess è necessario dare i seguenti comandi di configu-
razione:
• ip classless
• ip subnet-0.
10) Un Internet Service Provider (ISP) europeo ha ottenuto dal RIPE l’indirizzo
CIDR 223.223.223.0/20. Quante sono le subnet di classe C aggregate?
a. 24
b. 32
c. 256
d. 16
[R10]: d.
Il numero di subnet di classe C identificate dalla notazione CIDR assegnata è
pari a:
2(20 mod 8) = 24 = 16.
133

IPv 4&subnetting

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IPv 4&subnetting

Caricato da

Copyright:

Formati disponibili

05 GUIDA TCP/IP XP 28-03-2003 14:07 Pagina 59

Figura 5.1: Esempio di reti interconnesse

Formato decimale e binario (RFC 791, RFC 1166)

Origine del termine host

Internet Protocol version 4 (IPv4)

Gli indirizzi logici utilizzati dal protocollo IP prendono il nome di IP Address e

<IP Address> ::= <netID> <localAddress>

<IP Address> ::= <netID> <hostID>

■ <netID>: identifica una rete all’interno di un sistema di reti interconnesse.

Figura 5.2: Esempio di reti interconnesse con indicazione degli indirizzi

Chi garantisce l’univocità nell’assegnazione degli indirizzi?

Internet Protocol version 4 (IPv4)

Il formato utilizzato internamente dal software che implementa le funzionalità

Tabella 5.1: Indirizzo IP rappresentato in binario

In generale un indirizzo IP in notazione DDN è rappresentato come “a.b.c.d” o

Esprimere un indirizzo IP in formato ottale ed esadecimale

IP DDN IP DON IP DEN

■ Indirizzi IP unicast (“indirizzo al singolare”)

Internet Protocol version 4 (IPv4)

■ Indirizzi IP broadcast (“indirizzo al plurale”)

Indirizzi IP riservati: network, broadcast, multicast, loopback

Tabella 5.2: Indirizzi riservati

Tabella 5.2: Continua

Classi di indirizzamento (RFC 791, RFC 1166)

Tabella 5.3: Classi di indirizzi IP

Internet Protocol version 4 (IPv4)

• Classe A: nH = 224 – 2 = 16.777.214

Come accennato in precedenza, l’assegnazione di un indirizzo viene fatto diret-

Internet Protocol version 4 (IPv4)

volta, provvedono a rivenderli, eventualmente suddividendoli mediante tecniche

Un altro indirizzo IP speciale: la network mask

<Network Mask > ::= <netID-Tutti-1> <hostID-Tutti-0>.

Tabella 5.5: Subnet mask standard

■ Direttamente, se il destinatario è collocato sulla stessa rete.

1. Confronto bit-a-bit (bit-wise logical AND) tra l’indirizzo destinazione e la

Internet Protocol version 4 (IPv4)

Figura 5.3: Applicazione della subnet mask

Figura 5.4: Esempio di reti per applicazione network mask

Tabella 5.7: Due casi di destinazione locale e destinazione remota

Tabella 5.7: Continua

Quali sono i vantaggi e gli svantaggi dell’organizzazione gerarchica degli

Indirizzi pubblici e privati (RFC 1918)

Internet Protocol version 4 (IPv4)

«… Because private addresses have no global meaning, routing information about

È demandato ai router degli ISP il compito di scartare il traffico proveniente da un

■ Classe A: l’intera rete identificata da 10.0.0.0.

A queste va aggiunta anche la subnet 169.254.0.0/16 (255.255.0.0) utilizzata per

«… 169.254.0.0/16 – This is the “link local” block. It is allocated for communication

Subnetting standard secondo la RFC 950 (Internet Standard

■ La necessità di circoscrivere il traffico broadcast.

Broadcast e traffico di rete

è registrato su un determinato host, il driver scarta la relativa frame. Normalmente i

In questa sezione verrà presa in considerazione l’implementazione del subnet-

«… In certain contexts, it is useful to have fixed addresses with functional

It is useful to preserve and extend the interpretation of these special addresses in

Mediante questa tecnica è possibile suddividere logicamente una rete in un insie-

<IP Address> ::= <netID> <hostID>

assumerà la nuova forma:

<IP Address> ::= <netID> <subNetID> <hostId>

nella quale la parte <hostId> viene suddivisa in due componenti: <subNetID> e

<Network Mask > ::= <netID-Tutti-1> <subNetID-Tutti-1> <hostID-Tutti-0>.

Comunemente, la network mask di un indirizzo derivato da subnetting prende il

Internet Protocol version 4 (IPv4)