Protocolli TCP-IP

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

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 allinterno 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 allattuale
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).
61
Figura 5.1: Esempio di reti interconnesse
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 allinterno 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 lavvento dellIPv6).
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 lunit 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 allin-
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
Lutilizzo del termine host deriva dal fatto che, originariamente, le applicazioni ed i
servizi venivano ospitati (hosted) su computer centrali, ed il collegamento avveniva
tramite lutilizzo di terminali (TeleTYpe o TTY). I computer host venivano equipag-
Parte 3
62
giati con un sistema operativo con funzionalit Time-Sharing (per esempio: BBN
Timesharing System su DEC PDP-1, 1962).
Con lavvento 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:
I <netID>: identifica una rete allinterno 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 linterazione 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-
stultimo caso necessario predisporre degli appositi meccanismi di inoltro
o forwarding, necessari per garantire la visibilit tra i nodi appartenenti alle
diverse reti logiche attraverso lutilizzo di sistemi (nodi di rete specializzati)
chiamati gateway o router.
I <hostID> o <localAddress>: identifica univocamente ciascun nodo apparte-
nente alla stessa rete. Il valore <hostID> deve essere unico allinterno della
particolare rete considerata.
Internet Protocol version 4 (IPv4)
63
necessario sottolineare che la coppia <netID> <hostID> deve essere unica al-
linterno dellintero 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:
Parte 3
64
Figura 5.2: Esempio di reti interconnesse con indicazione degli indirizzi
<netID>/<hostID> in esadecimale
Chi garantisce lunivocit nellassegnazione degli indirizzi?
I 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 lutilizzo di una politica per
delegare lassegnazione dei cosiddetti Internet Identifier Assignment a livello
regionale.
I 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.
I 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 (Rseaux IP Europens Network Coordination Centre): www.ri-
pe.net.
AFRINIC (African Regional Internet Registry): www.afrinic.org.
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 allinterno 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 allinterno 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 lordine di elaborazione, di trasmissione e di interpre-
tazione dei bit allinterno dei singoli ottetti e degli ottetti stessi allinterno 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 (lordine con cui vengono interpretati i
quattro ottetti), sia a livello di singolo bit allinterno del generico ottetto. Lordina-
mento di tipo big-endian prevede di considerare, allinterno di una sequenza di pi
ottetti, lottetto di sinistra come il pi significativo. Solitamente, questultimo, viene
indicato con il termine MSB (Most Significant Byte) e lottetto 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 allordine
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 dellindirizzo IP rappresentato in binario nellesempio prece-
dente, il relativo formato DDN sar come lesempio 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
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 (8
3
255) oppure nel caso decimale anteporre davanti al numero espres-
so in notazione esadecimale con 2 cifre (16
2
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 allinterno 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 allappendice 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:
I 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.
Parte 3
66
I 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.
I Indirizzi IP multicast (indirizzo al plurale circoscritto)
un indirizzo IP utilizzato per identificare uno o pi nodi (ma non tutti)
allinterno 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 allinterno 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
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 allinterno 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 2
32
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.
Parte 3
68
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 224239
Multicast
E 1111xxxx Classe riservata per uso sperimentale 240254
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
69
Di seguito viene data una descrizione dettagliata del significato delle varie colonne.
I 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 lassegnamento di indirizzi IP di tipo
unicast sono le rimanenti A, B e C.
I Colonna II
Sono indicati i bit dellottetto 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.
I 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> allinterno 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 allinterno 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 = 2
7
2 = 126
Classe B: nN = 2
14
2 = 16.382
Classe C: nN = 2
21
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.
I 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 allinterno 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:
Classe A: nH = 2
24
2 = 16.777.214
Classe B: nH = 2
16
2 = 65.534
Classe C: nH = 2
8
2 = 254
nelle quali i due potenziali host sottratti dal conteggio corrispondono alla
regola no-tutti-zero e no-tutti-uno esposta in precedenza.
I Colonne V e VI
Indicano qual linsieme 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 nellelenco 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.
Lidea iniziale della suddivisione in classi dello spazio di indirizzamento IP (IP
Address Space) nasce dalla volont di ottimizzare lofferta 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, lassegnazione 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
Parte 3
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 allindicazione 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 linserimento dellindirizzo 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 dellindirizzo 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 allinterno 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-
lindirizzo 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:
71
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
I Direttamente, se il destinatario collocato sulla stessa rete.
I 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 lindirizzo destinazione e la
network mask locale per mezzo di unoperazione di AND. Il risultato di que-
sta operazione prende il nome di RemoteNetID.
2. Confronto bit-a-bit (bit-wise logical AND) tra lindirizzo sorgente e la
network mask locale per mezzo di unoperazione di AND. Il risultato di que-
sta operazione prende il nome di LocalNetID.
3. Confronto tra i due risultati precedenti con unoperazione di XNOR (la quale
verifica luguaglianza 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 delloperatore logico AND
possibile esprimere questultima 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 delloperazione di AND coincide sempre con il valore del secondo.
Come si pu evidenziare dalla tavola di verit delloperatore 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"".
Parte 3
72
73
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)
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)
Parte 3
74
Quali sono i vantaggi e gli svantaggi dellorganizzazione gerarchica degli
indirizzi IP mediante lintroduzione delle classi?
I Vantaggi:
Riduzione delle dimensioni delle tabelle di routing. Infatti, lutilizzo di uno
spazio di indirizzi piatto costituito da 2
32
= 4.294.967.296 avrebbe imposto
linserimento in ciascuna tabella di routing di ogni router degli indirizzi sin-
goli per ciascuna potenziale destinazione. Viceversa, lutilizzo 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 levoluzione dellhardware queste
ultime considerazioni perdono un po di importanza.
I 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:
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:
I Classe A: lintera rete identificata da 10.0.0.0.
I Classe B: le sedici reti contigue identificate da 172.16.0.0 172.31.0.0.
I 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 lassegnazione 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 ununica 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:
I La necessit di circoscrivere il traffico broadcast.
I La necessit di separare i diversi enti produttivi di unazienda.
I La dislocazione geografica di unorganizzazione 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
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 limplementazione 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 luso degli indi-
rizzi IP.
In pratica lindirizzo 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
Parte 3
76
allindirizzo IP, per un indirizzo ottenuto mediante il procedimento di subnetting lin-
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> dalloriginale <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 dellindirizzo IP.
Per poter determinare con facilit gli indirizzi delle nuove subnet, dei rispettivi
host e la nuova subnet mask, necessario rivedere alcuni concetti relativi allalgebra
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 = 2
nBiH
2
Numero di subnet secondo RFC 950: nS = 2
nBiS
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
Nellesempio della figura 5.5 assegnata una rete di classe C avente lindirizzo
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
78
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:
2
nBiS
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 lottetto 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 dellultimo ottetto evidenziando tutte le
potenziali configurazioni (quattro, 2
2
) 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.
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 =
2
posizione
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 = 2
nBiH
2 = 2
6
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 2
6
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 largomento 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
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
Parte 3
80
Esempio di subnetting in classe A con lutilizzo di un numero intero di ottetti
Si supponga di dover preparare un piano per lindirizzamento IP ad uso interno, per
unazienda 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 lidentificazione dei 200 nodi, si riserver solamente
uno (8-bit) alla parte <hostID>, tramite il quale si potranno identificare, comunque,
fino ad un massimo di 2
8
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.
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 laspetto 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 dellesempio 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 lidentificazione 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-
lindirizzo IP.
81
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 lormai cronica carenza di indirizzi IP ci potrebbe costituire un ulteriore
problema. Ecco allora che se i router utilizzati allinterno 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 lequazione per la determinazione del numero nS di subnet che
diventer:
numero di subnet secondo RFC 1812, RFC 1878, CIDR/VLSM: nS = 2
nBiS
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 lunica 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 unaltra 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 limplementazione
della subnet pi grossa (A con 120 nodi). A tale proposito sufficiente risolvere la
seguente disequazione binaria:
2
nBiH
2 120
Parte 3
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 = 2
nBiS
= 2
1
= 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 allunico 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
2
posizione
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:
2
nBiH
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
nS = 2
nBiS
= 2
2
= 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
2
posizione
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:
2
nBiH
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 = 2
nBiS
= 2
3
= 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)
Parte 3
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
2
posizione
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.
85
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, lidea 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-
plificarne il relativo trattamento. Il termine supernetting nasce in contrapposizione al
subnetting; infatti, mentre questultimo permette di suddividere una rete in pi sub-
net, con il supernetting possibile raggruppare pi subnet IP in una sola, mediante
lapplicazione 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:
I Ridurre le dimensioni delle tabelle di routing attraverso laggregazione delle
entry.
I Gestire in maniera pi selettiva lassegnazione 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:
I Provider Indipendent (PI): sono in genere rilasciati da un Internet Registry e non
vincolano un utente ad un determinato ISP.
I Provider Aggregate (PA): sono rilasciati direttamente da un ISP ed hanno validit
fintanto che lutente rimane contrattualmente legato ad esso.
Per spiegare il funzionamento del supernetting facciamo un esempio pratico: si
supponga che unazienda richieda ad un ISP 2000 indirizzi IP. Non avendo a disposi-
zione una classe B da assegnare al proprio cliente, lISP 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.
Parte 3
86
Di seguito si analizzer come sia possibile determinare lindirizzo 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:
2
nBiC
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 dallultimo 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 lin-
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 lISP risparmia linserimento nel proprio router le 8 entry relative
alle 8 subnet e pu specificare solo lindirizzo 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 linsieme dei bit contigui a partire dal
pi significativo condivisi da tutte le subnet appartenenti alla supernet:
11000000 11000000 11000 /21
87
In questo modo stata determinata la subnet mask in formato network prefix la
quale associata allindirizzo IP della prima subnet del gruppo determina lindirizzo 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
laggregazione 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
laggregazione 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, luso 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 lesigenza 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.
Parte 3
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 dellindirizzo tutti-0
a. In alcuni casi, come ad esempio quelli trattati nei punti seguenti, lindirizzo 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 lindirizzo 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
Route, per esempio con lindirizzo 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, lindirizzo 192.168.1.0/24 indica la rete 192.168.1 mentre lindi-
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, lindirizzo 0.0.0.12/24 indica lhost 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 dorigine: infatti non richiede di specificare alcun indiriz-
zo di <netID>. Un datagramma IP con questo indirizzo di destinazione non
pu mai essere reinstradato allesterno della rete dorigine.
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 dallindirizzo IP della rete <netID> popolando con 1
il campo <hostID>. Per esempio per la rete 172.26.0.0/16 lindirizzo di broad-
cast diretto 172.26.255.255.
A differenza dellindirizzo 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.
Parte 3
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 dallindirizzo 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 lindirizzo 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 uno-
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.
Lindirizzo 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 2
24
2 = 16.777.214 (classe A), sebbene normalmente sia utilizzato sto-
ricamente lindirizzo 127.0.0.1.
91
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.
Parte 3
92
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 allinterno 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 limplementazione 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).
Dove:
I 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 dellaggiunta o meno del
campo Options e Padding. Poich il minimo di un elemento dellIP Header
ha una lunghezza pari a 32-bit o 4 ottetti, leventuale espansione dellIH deve
essere eseguita per incrementi di 32-bit. Ci vale per esempio per lutilizzo
del campo Options e Padding: in tal caso laggiunta 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
lallineamento dellIH. Il ruolo dellIP 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.
I 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:
I Version (VER)
Dimensione campo: 4-bit
Occupa i primi 4-bit della struttura e contiene il numero di versione che defi-
nisce il formato dellIH. La versione utilizzata correntemente la 4 indicata
con lacronimo IPv4. Laver aggiunto il campo Version nellIH consente di svi-
luppare nuovi protocolli e nuovi formati di header, con la possibilit di inte-
grarli in corso dopera. 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 laltro, lutilizzo di indirizzi IP a 128-bit.
I 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 dellIH
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 dellIHL:
a. Dimensioni minime dellIH: 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
b. Dimensioni massime dellIH: la massima estensione indirizzabile dal
campo IHL di 2
4
1 = 15 (0x0F) parole da 32-bit cio 480-bit o 60
ottetti.
I 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.
I Total Length (TL)
Unit di misura = Ottetti
Il campo TL costituito da 16-bit e definisce la lunghezza, espressa in ottetti,
dellintero datagramma considerando sia la parte header sia la parte payload.
Da notare che la dimensione massima consentita per un datagramma IP di
2
16
= 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 dellMTU
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
I Identification (ID)
Parte 3
94
Rappresenta un numero progressivo unico compreso tra 0 e 65.535 (2
16
)
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 laltro 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 allhost 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.
I 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).
95
Figura 5.8: Struttura del campo Flags
In particolare il secondo bit implementa il flag Dont 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 questultimo
caso se la dimensione del datagramma originale superiore al valore MTU
della rete il datagramma viene scartato (per esempio da un router) e viene
riscontrato allhost 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 dellultimo 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 lordine dei due flag (DF e MF) fare riferimento
allordine alfabetico (prima DF e poi MF).
2. Normalmente, utilizzando il comando ping per testare la raggiungibilit di un
host allinterno 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 dellMTU 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.
I Fragment Offset (FO) e il processo di frammentazione
Unit di misura = 8 gruppi di ottetti (64-bit)
Range = 0 8191 (default = 0)
Parte 3
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 allinizio del datagramma origina-
rio. La dimensione di ogni frammento (tranne lultimo) 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. Lultimo 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 2
16
= 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
linoltro, 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:
I Frammentazione locale: la frammentazione locale si verifica al di sotto del livel-
lo IP ed il riassemblaggio avviene prima che i frammenti vengono presentati
allhost o router ricevente.
I 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
c) Segue una rotta indipendente da tutti gli altri frammenti, generati dallo stes-
so datagramma, durante il tragitto dallhost mittente allhost destinazione.
d) La frammentazione e il riassemblaggio avviene end-to-end.
e) La perdita o danneggiamento anche di un solo frammento provoca lo scarto
dellintero datagramma.
I 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.
I Frammentazione intranet o Network-Dependent: si riferisce al processo di
frammentazione e relativo riassemblaggio che si verifica allinterno 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 allinoltro 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.
I 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 nellin-
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 linvio dei dati. Daltro canto esso pu provocare un degrado delle presta-
zioni dei router. Pertanto, da utilizzare solo allinterno di reti private. Per lim-
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 dellMTU dellinterfaccia di rete corrispondente allindirizzo 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-
Parte 3
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 sullMTU
I Il valore dellMTU di ogni interfaccia di rete deve essere configurabile.
I Ogni implementazione del livello IP deve avere a disposizione un flag All-
Subnets-MTU che consenta di specificare lutilizzo 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 lhost ad utilizzare la network mask anzich la subnet
mask per la scelta del parametro EMTU_S.
I Alcune implementazioni prevedono la determinazione dellMTU (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 linvio di una ragionevole
quantit di informazioni (circa 512 ottetti) oltre agli ottetti obbligatori di overhead (da
20 a 60 ottetti per lheader IP e qualche margine per lheader 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 lobiettivo 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 allMTU 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
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 lheader di ogni frammento, e determinare la dimensio-
ne di ciascun frammento (che deve essere multiplo di 8-ottetti, tranne lulti-
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 lultimo 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 loperatore 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;
Parte 3
100
Cio, si valuta il valore di condizione. Se Condizione vera (risultato diverso da 0)
allora si passa a valutare lespressione Esp1, che diventa il valore dellintera espres-
sione (valore assegnato a x). Viceversa, se Condizione falsa allora si passa a valuta-
re Esp2, che a questo punto determina il valore dellintera 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 lultimo.
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 dellheader 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
dellMTU della rete B, il router AB deve procedere con la sua frammentazione.
Essendo lMTU 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
102
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 dellesempio 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 dellMTU della rete C di destinazione.
Essendo lMTU 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:
103
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 nellesempio 1 lhost 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
I 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 loverhead
(cio lincremento 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 lhost 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
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.
I Il mancato recapito o danneggiamento anche di un singolo frammento provoca
la ritrasmissione dellintero datagramma, su richiesta di un protocollo di livello
superiore (tipicamente TCP).
I Datagrammi con valori elevati di TTL possono permanere a lungo nel buffer di
ricostruzione.
I 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 questultimo caso, se un pacchetto viene sud-
diviso in tanti frammenti, risulta difficile lanalisi del suo effettivo contenuto e la
relativa applicazione delle policy.
I Un altro effetto collaterale si pu verificare, per esempio, nellutilizzo 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 linol-
tro di messaggi frammentati) e non basati unicamente sullanalisi 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 allorigine:
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 lheader (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.
Parte 3
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
I 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.
I Lalgoritmo normalmente utilizzato per effettuare il riassemblaggio dei fram-
menti deve prevedere di mantenere lheader del primo frammento in quanto in
caso di errore o scadenza del timer esso deve essere restituito nelleventuale mes-
saggio ICMP (Type = 11, Code = 1) Fragment reassembly time exceeded.
I Per ottimizzare linterazione tra gli host e migliorare le performance degli appa-
rati di routing consigliata limplementazione, 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
I 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.
I Secondo la RFC 791 il valore consigliato di 15 secondi.
I 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 allhost sorgente deve essere notificato un messaggio ICMP
(Type = 11, Code = 1) Fragment reassembly time exceeded (se il frammento zero
stato ricevuto).
105
I 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 dellMSL 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.
I Il messaggio ICMP (Type = 11, Code = 1) Fragment reassembly time exceeded (cf.
RFC 792) che viene notificato dallhost 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.
I 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 lin-
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.
Parte 3
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 allultimo 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 allinterno
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.
I 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 anchessi 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 allatto 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
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.
I 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 linvio 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.
Lalgoritmo di generazione del checksum consiste nellapplicazione delle
seguenti operazioni:
a. Inizializzare a 0 il campo Checksum.
b. Per ogni blocco di 16-bit dellHeader 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.
Parte 3
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, dallhost 10.1.1.1 allhost 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 allheader avremo
quanto mostrato nella figura 5.12.
109
Figura 5.12: I valori esadecimali relativi allheader in forma tabellare
I valori esadecimali relativi allheader corrispondono ai campi mostrati nella figu-
ra 5.13.
Figura 5.13: I campi corrispondenti ai valori esadecimali relativi allheader
A questo punto sommiamo tutti i campi dellheader 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 (Checksuminizializzato 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
I 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).
I Options e Padding (OPT)
Dimensione campo = variabile a blocchi di 4 ottetti (0 10)
Parte 3
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 lheader 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
limplementazione 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
lHeader di un datagramma IP ha una lunghezza pari a 32-bit cio 4 ottetti.
Pertanto, leventuale estensione dellheader attraverso laggiunta 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 lallineamento a 32-bit dellHeader.
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).
111
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 linserimento 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).
Parte 3
112
Figura 5.15: Lunghezza specificata dal campo Option-Length si riferisce a tutti
e tre i campi
Lottetto Option-Type strutturato in tre campi (figura 5.16).
Figura 5.16: Struttura dellottetto Option-Type
I tre campi assumono il significato seguente:
I Copied Flag (CF) (1 bit): identificato dal bit pi significativo (MSB), cio
quello pi a sinistra, e serve per indicare ad un router o allhost 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).
I 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
I Option-Number (5-bit): questo campo costituito da 5-bit e consente di defi-
nire fino a 2
5
= 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).
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 lutilizzo di alcuni dei tipi di Option-Type indicati nella
tabella 5.20:
I End Of Option List (EOOL): valore decimale: 0; valore esadecimale: 0x00.
Lopzione 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 dellheader 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).
I No Operation (NOP): valore decimale: 1; valore esadecimale: 0x01.
Lopzione 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.
I 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 li-
dentificazione dei cosiddetti Closed User Group (CUG) e Transmission Con-
trol Code (TCC).
113
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).
Parte 3
114
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.
I Record Route (RR): valore decimale: 7; valore esadecimale: 0x07.
Lopzione 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 allinterno dello stesso datagramma e identificato dal campo
Pointer Offset o Next Slot Pointer. Lindirizzo IP che ogni router inserir nella
lista quello pi lontano rispetto allhost 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
dallhost sorgente ed inizializzato a 0.
Da quanto detto finora ed osservando la struttura dellopzione 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 lheader IP a 32-bit.
Il campo Pointer contiene lindirizzo (chiamato anche Offset o Next Slot Poin-
ter) del campo IP Address nel quale ciascun router dovr inserire il proprio
indirizzo. Da notare che loffset riferito allinizio della stessa opzione. Il suo
valore iniziale (e comunque minimo) pari a 4. Laggiornamento, 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 lopzione (valore iniziale pointer > 9).
IP Record Route e Traceroute
I Le stesse informazioni registrate utilizzando lopzione RR sono ottenibili anche
tramite il comando traceroute.
I A differenza del comando traceroute la lista prodotta da RR limitata a 9 indi-
rizzi.
I A differenza del comando traceroute che fornisce una lista asimmetrica della
rotta (ovvero: solo in una direzione), lopzione RR consente di verificare il path di
routing in entrambe le direzioni.
Utilizzare lopzione RR mediante il comando ping
Utilizzando il comando ping possibile configurare lutilizzo dellopzione RR:
I Windows 9x/NT/2K/XP/2003: Ping r NumeroHop IPDestinatario
dove NumeroHop 9. Cos facendo lhost mittente predispone allinterno del data-
gramma un numero di slot pari a NumeroHop per ospitare gli indirizzi che i vari
router aggiungeranno.
115
Esempio: ping r 5 192.168.1.199
*nix/Linux:
ping R IPDestinatario
Esempio:
ping R 192.168.1.200
I Source Routing (SR)
Normalmente linoltro dei datagrammi IP allinterno 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 lutilizzo 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 nellutilizzo 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 lhost 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 lopzione Record
Route.
Il formato dellopzione LSRR mostrato nella tabella 5.24.
Tabella 5.24: Opzione Loose Source Route (LSR)
Parte 3
116
Strict Source Route (SSR) o Strict Source e Record Route (SSRR) valore
decimale: 137; valore esadecimale: 0x89.
Nel caso di SSR lhost mittente predispone la lista esatta degli indirizzi IP
dei router che devono essere attraversati dal datagramma. A differenza
dellLSR 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,
linoltro 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 lopzione Record
Route.
Il formato dellopzione SSRR mostrato nella tabella 5.25.
Tabella 5.25: Opzione Strict Source Route (SSR)
Lhost dal quale viene inviato il datagramma con lopzione 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 lindirizzo IP
puntato dal campo Pointer. Dopodich registra nella lista degli indirizzi
LSR o SSR lindirizzo IP dellinterfaccia 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 lindirizzo IP di un router non specificato nellelenco 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-
lopzione (Option-Length) e lhost destinatario iniziale stato raggiunto
(ovvero: lultimo indirizzo indicato nellheader 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
allhost 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
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 allinterno di uno stesso datagramma si trovano
due opzioni SR conflittuali secondo la RFC 1122 il comportamento dello
stack pu dipendere dalla particolare implementazione.
Utilizzare lopzione RR mediante il comando ping
Utilizzando il comando ping possibile configurare lutilizzo delle opzioni LSR e
SSR:
I LSR: Windows 9x/NT/2K/XP/2003: Ping j <lista SR> <IPDestinatario>
I 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 dellindirizzo 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 allhost attaccato. Delle due tecniche quelle che risulta pi
critica dal punto di vista della sicurezza la LSR per la quale sufficiente inserire
allinterno della lista SR lindirizzo presso il quale si vogliono dirottare i datagram-
mi, senza la necessit di conoscere lintera 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.
Parte 3
118
Timestamp (TS): valore decimale: 68; valore esadecimale: 0x44.
Lopzione 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 dellopzione 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 allora 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 allinterno
dello stesso datagramma e identificato dal campo Pointer Offset o Next
Slot Pointer. Questo spazio viene predisposto dallhost 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 dellopzione TS conte-
nuta nel campo Option-Length.
Il campo Pointer Offset o Next Slot Pointer un indice, relativo allinizio
del campo Options, che punta al primo campo libero allinterno della
sezione Area Dati. Il valore minimo che pu contenere questo campo
pari a 5; esso viene inizializzato dallhost mittente ed aggiornato da ogni
router.
Il campo Overflow contiene il numero di router (fino ad un massimo di
2
4
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
Tabella 5.27: Valori possibili del campo Flag dellopzione Timestamp
Flag Descrizione
0 Solo Record Timestamp in parole di 32-bit.
1 Ogni router inserisce prima lindirizzo IP e poi (nella successiva parola
di 32-bit) il Timestamp.
2 Riservato.
3 Lindirizzo 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 allora 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 allora UTC. Per differen-
ziarla dallora standard viene settato ad uno il bit di ordine superiore.
Nel caso in cui larea 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 allhost
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.
Parte 3
120
2) Quali sono le classi comunemente utilizzabili per lassegnazione 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 dellindirizzo 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 dellindirizzo compreso nella
fascia 1 126, la classe di appartenenza sar sempre la A indipendente-
mente dalla subnet mask associata.
121
6) Indicare quali dei seguenti indirizzi IP non sono validi per lassegnazione 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
2
8
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 = 2
nBiS
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>.
Parte 3
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 lutilizzo di subnet mask ClassFull.
b. Ridurre le dimensioni delle tabelle di routing tramite laggregazione
delle entry (Route Aggregation).
c. Evitare il supernetting.
d. Consentire lassegnazione 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 dellindirizzo 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 lindirizzo 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 allindirizzo 192.168.1.254 espresso in forma DDN
(Dotted Decimal Notation).
123
c. un indirizzo espresso in esadecimale (Dotted Exadecimal Notation).
[R12]: b.
Appendice 5B: Esercizi
1) Dato lindirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare la
subnet di appartenenza e lindirizzo 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 dellindirizzo IP assegnato suf-
ficiente trasformare in binario sia lindirizzo sia la subnet mask e calcolare
lAND 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 dellindirizzo IP (figura 5.17).
Parte 3
124
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 lindirizzo 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 lindirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare la
subnet di appartenenza e lindirizzo di directed broadcast secondo la RFC
1812 (VLSM/CIDR).
d. Configurazione non possibile.
[R2]: a.
Rifacendosi al conteggio effettuato nellesercizio precedente ed applicando
le regole sul subnetting dettate dalla RFC 1812 ne consegue che lindirizzo
190.190.1.8/22 legale ed appartiene alla subnet 190.190.0.0.
A questo punto per determinare lindirizzo di broadcast sufficiente calcola-
re le 2
6
= 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 =
2
posizione
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, lindirizzo 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 allultimo indirizzo IP del range
<hostID> corrispondente: 190.190.0.0 190.190.3.255.
a) Regola pratica per la determinazione delle subnet nellipotesi RFC 1812
Per ricavare le subnet identificate da una determinata subnet mask sufficiente,
dopo aver espresso in binario lottetto interessato dal procedimento di subnetting
(nellesercizio 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> (nellesempio 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 (nellesempio 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 nellipotesi RFC 950
Nel caso della RFC 950 vanno eliminate le subnet corrispondenti ai valori estremi
dellintervallo 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 linsieme delle subnet secondo la regola a) o b), per la deter-
minazione dellindirizzo da considerare come subnet broadcast bisogna considerare
per ciascuna subnet il range dei valori di indirizzi da assegnare agli host e identifi-
care lultimo valore di ciascun range (nellesempio 190.190.3.255).
125
Parte 3
126
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 duso: 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 dellottetto interessato
dal subnetting (secondo, terzo o quarto). A tale proposito necessario verificare la
classe di origine dellindirizzo 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 lesercizio 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 dellottetto 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
(nellesercizio 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 lindirizzo
assegnato (nellesercizio precedente, il range 190.190.0.0 190.190.3.254).
V. Identificare lindirizzo di broadcast per ogni subnet considerando lultimo indi-
rizzo IP di ciascun range degli host (nellesercizio precedente, 190.190.3.255).
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), linsieme delle subnet avr come indirizzo iniziale (riferito allottetto 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 dellultimo 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 lindirizzo 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
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 lottetto 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 =
2
posizione
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 2
nBiS
= 16 subnet prodotte dal subnetting saranno: 0, 16, 32,
48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240. Quindi lindirizzo
147.148.149.150 sar compreso nella subnet 147.148.144.0/20.
4) Dato lindirizzo 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.
Parte 3
128
Essendo nBiS = 3 [(224)
10
= (111)
2
] le 2
nBiS
= 8 subnet derivate saranno: 0, 32,
64, 96, 128, 160, 192, 224. Quindi lindirizzo 212.100.200.62 sar compreso
nella subnet 212.100.200.32/27 alla quale corrisponde lindirizzo 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 dellindirizzo 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 lindirizzo 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 =
2
posizione
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 2
nBiS
= 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 lindirizzo 143.1.9.61/28 sar compreso nella subnet 143.1.9.48/28
alla quale corrisponde lindirizzo 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 lindirizzo 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
Per determinare lindirizzo 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 lindirizzo 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 lindirizzo 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 = 2
11
2 = 2046
nS (numero Subnet) secondo RFC 1812 = 2
11
= 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
Parte 3
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) = 2
nBiH
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.
Nellipotesi 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:
131
Figura 5.18: Esempio per lesercizio 9
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.
Parte 3
132
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 dellinfrastruttura 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
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 lindirizzo
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)
= 2
4
= 16.
133

Protocolli TCP-IP

Caricato da

Informazioni sul documento

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

Protocolli TCP-IP

Caricato da

Copyright:

Formati disponibili

Parte 3

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

Il suo funzionamento molto simile a quello dellopzione RR.

Potrebbero piacerti anche