Protocolli TCP IP

Parte 3

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


5Internet Protocolversion 4 (IPv4)

IntroduzioneIl protocollo IP (Internet Protocol), formalizzato nella RFC 791, nasce per consentire loscambio di dati tra due nodi all’interno di un insieme di reti a commutazione di pac-chetto, interconnesse tra loro tramite dispositivi intermedi chiamati gateway (spessoindicati anche con i termini router o intermediate system). Questo sistema di reti, ini-zialmente chiamato “catenet” (cf. IEN 48, The Catenet Model for Internetworking,Vinton Cerf 1978 e RFC 791 Internet Protocol, Jon Postel 1981), corrisponde all’attualeconcetto di Internet, ovvero un insieme di reti indipendenti e intercomunicanti, cheagiscono come un perfetto sistema olistico, cioè un sistema costituito da un insiemedi componenti interagenti e cooperanti tra loro al fine di costituire ed agire come ununico 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 eVint Cerf). In particolare, quando ci si riferisce alla rete pubblica si utilizza la parolaInternet con la lettera iniziale in maiuscolo mentre con internet si fa riferimento ad uninsieme di reti utilizzate in ambito privato o aziendale. Tuttavia, per semplicità e perevitare confusione, si utilizzano i più diffusi termini intranet o extranet per indicare uninsieme di reti private basate sul protocollo TCP/IP all’interno di una certa organizza-zione o utilizzate per interconnettere varie aziende o organizzazioni consociate.

Come accennato, lo scopo del protocollo IP è quello di fornire i servizi di conse-gna dei dati da un nodo sorgente ad un nodo destinazione. In modo particolare ogni“modulo IP” (ovvero: stack TCP/IP) disponibile in qualsiasi host deve implementare ledue 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 (peresempio: con l’avvento dell’IPv6).

I dati trattati dal protocollo IP prendono il nome di IP datagram. A volte si utiliz-za anche il termine pacchetto o packet. Più precisamente si utilizza il termine data-gramma quando si parla di comunicazione a livello IP diretta tra due host. Viceversasi 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 genereil termine pacchetto viene utilizzato anche per indicare l’unità di informazione o PDUscambiata tra il livello Rete ed il livello inferiore Interfaccia di Rete (livello 1 TCP/IP) odata-link (livello 2 OSI).

IP non fornisce alcun meccanismo per aumentare il grado di affidabilità, per ilcontrollo del flusso o per il controllo della sequenza dei pacchetti. Questi servizi sonodemandati ad un protocollo di livello superiore come ad esempio il protocollo TCP oil 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 siainstradabile, che consenta cioè la separazione in reti diverse, deve prevedere un indi-rizzo logico separato in due parti: una che consenta di identificare univocamente larete di appartenenza tra tutte le reti, e una che identifichi univocamente il nodo all’in-terno della propria rete. Un generico nodo di una rete può essere costituito da com-puter, router, stampanti con interfaccia di rete o, più in generale, da un qualsiasi appa-rato dotato di interfaccia di rete che, normalmente, viene chiamato host.

Origine del termine hostL’utilizzo del termine host deriva dal fatto che, originariamente, le applicazioni ed iservizi venivano ospitati (hosted) su computer centrali, ed il collegamento avvenivatramite l’utilizzo di terminali (TeleTYpe o TTY). I computer host venivano equipag-

Parte 3

62


giati con un sistema operativo con funzionalità Time-Sharing (per esempio: BBNTimesharing System su DEC PDP-1, 1962).Con l’avvento dei personal computer e la diffusione dei nuovi sistemi operativi mul-titasking (cooperative, preemptive, multiuser) con funzionalità di rete integrati e losviluppo di applicazioni di tipo client/server, il termine host può essere utilizzato sialato-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 quindipari opportunità).

Gli indirizzi logici utilizzati dal protocollo IP prendono il nome di IP Address esono 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 ilnome di multi-homed. In alcuni casi con questo termine si identificano anche hostcon più interfacce fisiche che avranno, di conseguenza, più indirizzi IP. Formalmentea questo tipo di apparati si assegna il nome multi-homed fisici in contrapposizione aimulti-homed logici.

Ogni IP Address è costituito da una coppia ordinata di valori, indicati rispettiva-mente come <netID> e <hostID> o <localAddress>, della dimensione complessiva di32-bit, cioè 4 ottetti:

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

oppure

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

dove:

� <netID>: identifica una rete all’interno di un sistema di reti interconnesse.Tutti i nodi appartenenti alla stessa rete logica avranno lo stesso prefisso<netID>. Da notare che non necessariamente deve esistere una relazioneuno-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 talcaso, per l’interazione diretta tra tutti i nodi non è necessario disporre didispositivi di routing. Viceversa, è possibile avere configurazioni di reti, chia-mate multinetting, nelle quali su una stessa rete fisica possono trovarsi diver-se reti logiche, ciascuna identificata da un diverso indirizzo <netID>. In que-st’ultimo caso è necessario predisporre degli appositi meccanismi di inoltroo forwarding, necessari per garantire la visibilità tra i nodi appartenenti allediverse reti logiche attraverso l’utilizzo di sistemi (nodi di rete specializzati)chiamati gateway o router.

� <hostID> o <localAddress>: identifica univocamente ciascun nodo apparte-nente alla stessa rete. Il valore <hostID> deve essere unico all’interno dellaparticolare rete considerata.

Internet Protocol version 4 (IPv4)

63


È necessario sottolineare che la coppia <netID> <hostID> deve essere unica al-l’interno dell’intero insieme di reti interconnesse.

Per esempio, nella figura 5.2, è possibile identificare gli host o mediante una codi-fica binaria o, per semplicità di rappresentazione, mediante una codifica esadecima-le. In questo caso si è scelto di discriminare le due reti attraverso il primo ottetto(netID=0x01 e netID=0x02) e dedicare gli ultimi tre ottetti come identificativo per glihost; 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 l’univocità nell’assegnazione degli indirizzi?� In ambito pubblico (Internet) la gestione degli indirizzi IP venne inizialmente

effettuata da Jon Postel di IANA (Internet Assigned Numbers Authority, www.ia-na.org). A partire dal 1992 con la liberalizzazione di Internet (RFC 1466 Guide-lines for Management of IP Address Space) sono state nominate delle RegionalInternet Registry (RIR), alle quali sono state delegate le funzioni di assegnazionedi indirizzi IP e di nomi di dominio per ciascuna area assegnata. Già in prece-denza con la RFC 1174 (IAB Recommended Policy on Distributing InternetIdentifier Assignment and IAB Recommended Policy Change to Internet “Con-nected” Status), nel 1990 Vint Cerf raccomandava l’utilizzo di una politica perdelegare l’assegnazione dei cosiddetti “Internet Identifier Assignment” a livelloregionale.

� 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 coordinaretutte le RIR del mondo.

� Attualmente esistono cinque RIR operanti in altrettante aree geografiche delmondo:• APNIC (Asia Pacific Network Information Center): www.apnic.net.• ARIN (American Registry for Internet Numbers): www.arin.net.• LACNIC (Latin American and Caribbean Internet Addresses Registry):

www.lacnic.net.• RIPE NCC (Réseaux IP Européens Network Coordination Centre): www.ri-

pe.net.• AFRINIC (African Regional Internet Registry): www.afrinic.org.


Ai RIR fanno capo i Local Internet Registries (LIR) per il rilascio degli indirizzi IP agliutenti finali e/o aziende. Per ulteriori dettagli cf. il capitolo 2 “Introduzione al TCP/IP,alla scoperta di Internet”.

Il formato utilizzato internamente dal software che implementa le funzionalitàTCP/IP all’interno di un sistema operativo, prevede di rappresentare un indirizzo IPmediante la relativa codifica binaria dei quattro ottetti, attraverso una stringa costi-tuita da 32-bit, ad esempio:

11000000101010000000000111001000

NotaI termini byte ed ottetti sono considerati sinonimi all’interno della maggior parte deisistemi operativi attuali, nei quali una “struttura” di tipo byte è implementatamediante 8-bit. Esistono dei casi di sistemi operativi (per esempio: DEC PDP11 ePDP8) nei quali la rappresentazione interna di 8-bit non avviene come singolo bytema come insieme di due nibble (gruppo di 4-bit). In questo tipo di ambienti è neces-sario differenziare espressamente tra i due termini. In relazione a quanto esposto èformalmente più corretto utilizzare il termine ottetto.

A questo punto è necessario definire uno standard per identificare in modo uni-voco il network byte order cioè l’ordine di elaborazione, di trasmissione e di interpre-tazione dei bit all’interno dei singoli ottetti e degli ottetti stessi all’interno di un indi-rizzo IP.

Lo standard TCP/IP prevede di utilizzare la cosiddetta convenzione big endian oleft-to-right sia a livello di intero indirizzo (l’ordine con cui vengono interpretati iquattro ottetti), sia a livello di singolo bit all’interno del generico ottetto. L’ordina-mento di tipo big-endian prevede di considerare, all’interno di una sequenza di piùottetti, l’ottetto di sinistra come il più significativo. Solitamente, quest’ultimo, vieneindicato con il termine MSB (Most Significant Byte) e l’ottetto meno significativo conLSB (Least Significant Byte). Analizzando il contenuto del singolo ottetto si utilizza lostesso tipo di ordinamento: il bit nella posizione di sinistra è considerato più signifi-cativo e chiamato MSb (Most Significant bit). Lo stesso ordinamento è utilizzato anchedurante la trasmissione dei dati. Questo tipo di ordinamento corrisponde all’ordineche viene seguito per leggere lo stesso testo in italiano.

Per motivi di semplicità è prassi codificare gli ottetti con il sistema decimale,separandoli tra loro con un punto al fine di aumentare ulteriormente la leggibilità.Tale convenzione viene indicata come dotted decimal notation (DDN).

Pertanto, nel caso dell’indirizzo IP rappresentato in binario nell’esempio prece-dente, il relativo formato DDN sarà come l’esempio mostrato nella tabella 5.1.

Tabella 5.1: Indirizzo IP rappresentato in binario

MSB (Most Significant Byte) LSB (Least Significant Byte)11000000 10101000 00000001 11001000

192 168 1 200


65


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 esadecimaleAnche 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). Alfine 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 ottalecon 3 cifre (83 ≥ 255) oppure nel caso decimale anteporre davanti al numero espres-so in notazione esadecimale con 2 cifre (162 ≥ 255) il suffisso 0x.

IP DDN IP DON IP DEN192.168.1.200 192.168.1.0310 192.168.1.0xc8192.168.1.254 192.168.1.0x376 192.168.1.0xfe

Attenzione: come è possibile osservare dai precedenti esempi, non è necessario chetutti gli ottetti siano espressi in DON o DEN.

1. Come è possibile osservare dai precedenti esempi, non è necessario che tutti iquattro ottetti siano espressi in DON o DEN.

2. Da notare che l'utilizzo dei suddetti formati DON/DEN non è consentito in fasedi configurazione di un indirizzo IP per una interfaccia di rete (in qualsiasiambiente) ma solamente all’interno di un alcuni comandi (esempio: ping192.168.1.0310 oppure ping 192.168.1.0xc8 oppure telnet 192.168.1.0310). A talproposito non tutti i comandi accettano questi formati ed alcuni accettano soloil formato DON e non DEN (esempio: telnet).

Per ulteriori dettagli sulla conversione dei numeri decimali in binario e viceversafare riferimento all’appendice B “Sistemi di numerazione e conversioni”.

Tipi di indirizzi IPA seconda del numero dei potenziali destinatari identificati da un singolo indirizzo IPe del tipo di comunicazione instaurata tra una entità origine ed una o più entità desti-nazione è possibile distinguere tra:

� Indirizzi IP unicast (“indirizzo al singolare”)

È un indirizzo IP univoco assegnato ad una ben determinata interfaccia logi-ca di un nodo. Questo tipo di indirizzo può comparire, indifferentemente, siacome sorgente sia come destinazione di un datagramma IP. Utilizzando unindirizzo IP di tipo unicast nel campo destinazione la comunicazione tra inodi è di tipo diretta o uno-a-uno. In definitiva si può indicare un indirizzoIP di tipo unicast come un “indirizzo al singolare”, nel senso che identificauna ben determinata interfaccia logica di rete.

Parte 3

66


� Indirizzi IP broadcast (“indirizzo al plurale”)

È un indirizzo IP che serve ad identificare collettivamente tutti i nodi di unarete. 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 indirizzoIP si identificano tutti gli host di una stessa rete. Come vedremo più avantinella sezione “Indirizzi IP speciali e notazioni particolari per la loro rappre-sentazione (RFC 1700, RFC 3232)”, esistono diversi tipi indirizzi di broadcast.

� Indirizzi IP multicast (“indirizzo al plurale circoscritto”)

È un indirizzo IP utilizzato per identificare uno o più nodi (ma non tutti)all’interno di una rete. Questo tipo di indirizzo non può mai apparire comesorgente di un datagramma IP. Utilizzando un indirizzo IP di tipo multicast lacomunicazione è 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, soloun sottoinsieme di tutti gli host di una rete.

Indirizzi IP riservati: network, broadcast, multicast, loopbackAlcuni valori assegnabili alle due componenti <netID> e <hostID> sono da escluderepoiché assumono un significato particolare per il protocollo IP. Nella tabella 5.2 sonoriportati tali valori e il relativo significato attribuito dal protocollo IP.

Tabella 5.2: Indirizzi riservati

Indirizzi riservati per la parte <netID> Significato0 Identifica la rete di appartenenza cioè this

network.

Regola no-tutti-zero: considerando laporzione <netID> espressa in binario, vale laregola generale secondo la quale è daescludere un <netID> composto da tutti zeri oall-zeros.

127 Riservato per uso diagnostico o di loopback.Viene utilizzato per testare la correttainstallazione del software TCP/IP su uncomputer.

224 Indirizzo di multicast, compreso MulticastBackbONE (MBONE) (cf. RFC 2365).

255 Indirizzo di broadcast: identifica tutti gli host(all hosts) presenti all’interno di unadeterminata rete.

Regola no-tutti-uno: considerando la porzione<netID> espressa in binario, vale la regolagenerale 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> Significato0 Identifica un generico nodo su una

determinata rete o this node.

Regola no-tutti-zero: questa regola è validaanche per la componente <hostID>.

255 Indirizzo di broadcast: identifica tutti gli hostpresenti all’interno di una rete o all hosts.

Regola no-tutti-uno: questa regola è validaanche per la componente <hostID>.

Classi di indirizzamento (RFC 791, RFC 1166)Poiché abbiamo a disposizione 32-bit il numero di indirizzi IP disponibili teoricamenteè pari a 232 cioè 4.294.967.296. In realtà, come accennato, viene introdotta una separa-zione tra <netID> e <hostID>. Come conseguenza di questo tipo di organizzazione ge-rarchica il numero di indirizzi IP che si possono utilizzare è inferiore. Inoltre alcuni indi-rizzi, sia per la parte <netID> sia per la parte <hostID>, sono riservati per usi speciali.

Secondo le RFC 791 e RFC 1166, gli indirizzi IP sono organizzati in cinque classi:A, B, C, D, E.

La classe di appartenenza di un indirizzo IP è determinata dai quattro bit più si-gnificativi del primo ottetto (MSB). Essa determina quanti ottetti compongono laparte <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 VIClasse Codifica Binaria nByN / nBiN / nN nByH / nBiH / nH Indirizzi <netID> Indirizzi <hostID>

MSB Validi Validi

IP UnicastA 0xxxxxxx 1 / 7 / 126 3 / 24 / 16.777.214 1.b.c.d ÷126.b.c.d a.0.0.1 ÷

a.255.255.254

B 10xxxxxx 2 / 14 / 16.382 2 / 16 / 65.534 128.0.c.d ÷ a.b.0.1 ÷191.255.c.d a.b.255.254

C 110xxxxx 3 / 21 / 2.097.150 1 / 8 / 254 192.0.0.d ÷ a.b.c.1 ÷223.255.255.d a.b.c.254

D 1110xxxx Classe riservata per applicazioni 224÷239Multicast

E 1111xxxx Classe riservata per uso sperimentale 240÷254

Legenda:

• nByN = Numero Byte componente <netID> • nByH = Numero Byte componente <hostID>

• nBiN = Numero Bit componente <netID> • nBiH = Numero Bit componente <hostID>

• nN = Numero di Network Valide • nH = Numero di Hosts Validi



69

Di seguito viene data una descrizione dettagliata del significato delle varie colonne.

� Colonna I

Indica la classe di appartenenza di un indirizzo IP.

Come si può notare dalla tabella 5.3, le classi D ed E sono riservate per usispeciali: la classe D per applicazioni di tipo multicast e la classe E per finisperimentali da parte di IANA.

Pertanto, le sole classi utilizzabili per l’assegnamento di indirizzi IP di tipounicast sono le rimanenti A, B e C.

� Colonna II

Sono indicati i bit dell’ottetto più significativo (MSB). Come si può notare, aseconda della classe di appartenenza, i primi quattro bit possono avere unvalore diverso, ma comunque prefissato, secondo la seguente convenzione:

• Classe A: 0 è fissato solo il primo bit.

• Classe B: 10 sono fissati solo i primi due bit.

• Classe C: 110 sono fissati solo i primi tre bit.

• Classe D: 1110 sono fissati solo i primi quattro bit.

• Classe E: 1111 sono fissati solo i primi quattro bit.

Viceversa, le “x” rappresentano delle cosiddette condizioni di indifferenza,ovvero variabili che possono assumere sia il valore binario 0 sia 1.

� Colonna III

Il primo numero (nByN) indica quanti ottetti sono riservati per la compo-nente <netID>. Il secondo numero (nBiN) indica quanti sono gli effettivi bitdisponibili per la sezione <netID> all’interno di una classe, escludendo i bitcon valore prefissato (cf. Colonna II). Il terzo, indica il numero di reti onetwork (nN) che si possono identificare all’interno di una determinata clas-se, tenendo conto dei valori da escludere.

Per il calcolo del numero di network (nN) valgono le seguenti relazioni mate-matiche:

• Classe A: nN = 27 – 2 = 126

• Classe B: nN = 214 – 2 = 16.382

• Classe C: nN = 221 – 2 = 2.097.150

nelle quali, le due potenziali reti eliminate dal conteggio relativo al numerodi network (nN) per ciascuna classe, corrispondono alla regola no-tutti-zeroe no-tutti-uno esposta in precedenza.

� Colonna IV

Il primo numero (nByH) indica, riferendosi alla componente <hostID>, ilnumero di ottetti riservati, il secondo numero (nBiH) quanti sono gli effetti-vi bit disponibili e il terzo indica il numero di host (nH) che si possono iden-tificare all’interno di una determinata classe. Questi valori sono calcolatirispettando 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 = 224 – 2 = 16.777.214

• Classe B: nH = 216 – 2 = 65.534

• Classe C: nH = 28 – 2 = 254

nelle quali i due potenziali host sottratti dal conteggio corrispondono allaregola no-tutti-zero e no-tutti-uno esposta in precedenza.

� Colonne V e VI

Indicano qual è l’insieme dei valori ammissibili per le due componenti<netID> e <hostID>, espressi sotto forma decimale (DDN):

• Classe A: 1.0.0.1 ÷ 126.255.255.254

• Classe B: 128.0.0.1 ÷ 191.255.255.254

• Classe C: 192.0.0.1 ÷ 223.255.255.254

È importante notare, che dal punto di vista matematico, gli indirizzi 0.0.0.0 e127.0.0.0 rientrano nella classe A. Essi non sono stati indicati nell’elenco pre-cedente in quanto indirizzi non assegnabili e quindi esclusi.

Osservando il valore decimale del primo ottetto della componente <netID>di ciascun insieme si possono dedurre le seguenti regole per la determina-zione della classe di appartenenza di un indirizzo IP:

1. Ogni indirizzo IP, il cui primo valore decimale è compreso fra 1 e 126appartiene alla classe A.

2. Ogni indirizzo IP, il cui primo valore decimale è compreso fra 128 e 191appartiene alla classe B.

3. Ogni indirizzo IP, il cui primo valore decimale è compreso fra 192 e 223appartiene alla classe C.

Come si può notare la scelta di una classe di indirizzi IP, nella fase progettuale diuna rete, dovrebbe essere condizionata dal numero di nodi e di reti che costituisconola propria infrastruttura di internetworking.

L’idea iniziale della suddivisione in classi dello spazio di indirizzamento IP (IPAddress Space) nasce dalla volontà di ottimizzare l’offerta di indirizzi IP a secondadelle necessità aziendali (tabella 5.4).

Tabella 5.4: Rapporto tra il numero di reti ed il numero di host quando si utilizzano leclassi standard

Elevato numero di host Numero medio di host Basso numero di hostBasso numero di reti Classe A

Numero medio di reti Classe B

Elevato numero di reti Classe C

Come accennato in precedenza, l’assegnazione di un indirizzo viene fatto diret-tamente da IANA (o da una autorità di registrazione delegata). Gli indirizzi di classe Asono 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 tecnicheCIDR/VLSM esposte più avanti in questo capitolo.

Un altro indirizzo IP speciale: la network maskLa network mask è un particolare indirizzo IP che dovrebbe essere specificato unita-mente all’indicazione di qualsiasi indirizzo IP associato ad una rete oppure ad un sin-golo host.

In particolare esso è spesso imposto in fase di configurazione del protocolloTCP/IP su un qualsiasi host con un qualsiasi sistema operativo di rete che implemen-ta il protocollo TCP/IP. In alcuni casi (per esempio: Microsoft Win9x/NT/2K/XP/2003)non è possibile confermare l’inserimento dell’indirizzo IP se non si compila anche ilcampo riservato alla subnet mask. In altri casi (per esempio: UNIX/Linux) è possibileassegnare un indirizzo IP ad una interfaccia logica senza necessariamente specificarela relativa subnet mask. In tal caso viene applicata la subnet mask di default in basealla classe di appartenenza dell’indirizzo IP.

La network mask è una “maschera, o filtro, di bit” utilizzata dal software cheimplementa 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 confinitra le varie network all’interno di un insieme di reti TCP/IP.

Nel caso di indirizzi IP conformi alle RFC 791 e RFC 1166 , detti anche di tipoClassFull, la network mask da applicare ad un qualsiasi indirizzo IP può essere auto-maticamente determinata dalla sua classe di appartenenza, secondo la seguenteregola: una subnet mask è un indirizzo IP costituito da tanti “255” contigui a partiredal MSB (Most Significant Byte), quanti sono gli ottetti della parte <netID>; il resto del-l’indirizzo viene posto a zero:

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

Come si può notare, la network mask identifica il numero di bit, sul totale dei 32potenziali, 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, cheprevede di specificare insieme alla <netID> in formato DDN, anche il numero di bitdella 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 comedeve essere inoltrato un datagramma IP al destinatario:


71

Tabella 5.5: Subnet mask standard

Classe Formato binario Formato decimale Formato esadecimale Network PrefixA 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


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

� Indirettamente attraverso il proprio default gateway se il destinatario nonappartiene 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 sulseguente algoritmo:

1. Confronto bit-a-bit (bit-wise logical AND) tra l’indirizzo destinazione e lanetwork mask locale per mezzo di un’operazione di AND. Il risultato di que-sta operazione prende il nome di RemoteNetID.

2. Confronto bit-a-bit (bit-wise logical AND) tra l’indirizzo sorgente e lanetwork mask locale per mezzo di un’operazione di AND. Il risultato di que-sta operazione prende il nome di LocalNetID.

3. Confronto tra i due risultati precedenti con un’operazione di XNOR (la qualeverifica l’uguaglianza bit a bit).

4. Decisione di inoltro:

a. Se il confronto dà come risultato tutti i 32-bit ad 1 il pacchetto viene con-siderato locale ed inviato direttamente a destinazione (vedi tabella 5.7).

b. Altrimenti il datagramma viene considerato remoto ed inoltrato al de-fault gateway che provvederà alla consegna.

Nella tabella 5.6 sono riportate le tavole della verità delle operazioni logiche ANDe XNOR.

Tabella 5.6: Le tavole della verità delle operazioni logiche AND e XNOR

A B A AND B A B A XNOR B0 0 0 0 0 1

0 1 0 0 1 0

1 0 0 1 0 0

1 1 1 1 1 1

NotaDa una attenta osservazione della tavola della verità dell’operatore logico AND èpossibile esprimere quest’ultima nella forma (più concisa e di più immediata inter-pretazione):

1 AND x = x

dove x viene indicato come condizione di indifferenza e può valere 0 oppure 1.Questa espressione può essere così interpretata: se uno degli argomenti vale 1 il risul-tato dell’operazione di AND coincide sempre con il valore del secondo.Come si può evidenziare dalla tavola di verità dell’operatore XNOR, esso implemen-ta le funzioni di verifica della uguaglianza tra i bit in ingresso (input). Cioè A XNORB 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.2IP 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.1IP 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 dell’organizzazione gerarchica degliindirizzi IP mediante l’introduzione delle classi?� Vantaggi:

• Riduzione delle dimensioni delle tabelle di routing. Infatti, l’utilizzo di unospazio di indirizzi piatto costituito da 232 = 4.294.967.296 avrebbe impostol’inserimento in ciascuna tabella di routing di ogni router degli indirizzi sin-goli per ciascuna potenziale destinazione. Viceversa, l’utilizzo delle classi (esoprattutto delle subnet, come vedremo più avanti) consente il raggruppa-mento (summarize) degli indirizzi.

• Semplificazione nella assegnazione degli indirizzi.• Semplificazione nella gestione degli indirizzi da parte del software dei router

(oltre che di ogni singolo nodo) con evidenti risparmi di tempo di elaborazio-ne e quantità di memoria richiesta. Con l’evoluzione dell’hardware questeultime considerazioni perdono un po’ di importanza.

� Svantaggi:• Riduzione del numero effettivo di indirizzi IP. A tale proposito, come vedremo

più avanti parlando del subnetting VLSM/CIDR, esistono alcune tecniche peralleviare questa perdita di indirizzi.

Indirizzi pubblici e privati (RFC 1918)Come accennato precedentemente, se si necessita di indirizzi pubblici è necessariorivolgersi 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 spaziodi 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, laduplicazione di indirizzi potrebbe causare la mancata consegna dei datagrammi IP.

Al fine di evitare potenziali problemi di questo tipo, nel 1996 è stata promulgatala RFC 1918, Address Allocation for Private Internets. Essa stabilisce alcune fasce diindirizzi 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 aboutprivate networks hall not be propagated on inter-enterprise links, and packetswith private source or destination addresses should not be forwarded across suchlinks. Routers in networks not using private address space, especially those ofInternet service providers, are expected to be configured to reject (filter out) routinginformation about private networks. If such a router receives such information therejection shall not be treated as a routing protocol error…».

È demandato ai router degli ISP il compito di scartare il traffico proveniente da unindirizzo appartenente ad una rete privata.

Le reti definite come private sono:

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

� Classe B: le sedici reti contigue identificate da 172.16.0.0 ÷ 172.31.0.0.

� Classe C: le 256 reti contigue identificate da 192.168.0.0 ÷ 192.168.255.0.

A queste va aggiunta anche la subnet 169.254.0.0/16 (255.255.0.0) utilizzata perimplementare l’assegnazione automatica degli indirizzi per i client DHCP (identifica-to con il termine APIPA (Automatic Private IP Addressing)) come ratificato dalla RFC3330 (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 communicationbetween 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 StandardSubnetting Procedure)Con subnetting si intende il processo di partizionamento di un’unica rete in più sot-toreti o subnet.

La suddivisione di una rete logica in più sottoreti può essere dovuta a varie moti-vazioni, tra cui:

� La necessità di circoscrivere il traffico broadcast.

� La necessità di separare i diversi enti produttivi di un’azienda.

� La dislocazione geografica di un’organizzazione o azienda.

Broadcast e traffico di reteDi 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 (osottorete) ricevono il pacchetto di broadcast. Giunto a livello data-link questo vienepassato al driver della scheda di rete il quale lo passa al modulo di livello networkingcorrispondente al protocollo indicato nel campo “Type”. Se il protocollo indicato non


75


è registrato su un determinato host, il driver scarta la relativa frame. Normalmente irouter 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 disegnoed una corretta configurazione dei dispositivi di rete consentono di limitare gli effet-ti dei broadcast.

In questa sezione verrà presa in considerazione l’implementazione del subnet-ting secondo le direttive della RFC 950, secondo la quale sono da non considerare vali-de le subnet che hanno come valore nel campo <netID> tutti-0 e tutti-1, come indica-to nel seguente estratto della suddetta RFC (pag. 5):

«… In certain contexts, it is useful to have fixed addresses with functionalsignificance rather than as identifiers of specific hosts. When such usage is calledfor, the address zero is to be interpreted as meaning “this”, as in “this network”. Theaddress of all ones are to be interpreted as meaning “all”, as in “all hosts”. Forexample, the address 128.9.255.255 could be interpreted as meaning all hosts onthe network 128.9. Or, the address 0.0.0.37 could be interpreted as meaning host 37on this network».

It is useful to preserve and extend the interpretation of these special addresses insubnetted networks. This means the values of all zeros and all ones in the subnetfield should not be assigned to actual physical) subnets…».

Mediante questa tecnica è possibile suddividere logicamente una rete in un insie-me contiguo di sottoreti di dimensioni ridotte, in modo da ottimizzare l’uso degli indi-rizzi IP.

In pratica l’indirizzo IP di partenza espresso come:

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

assumerà la nuova forma:

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

nella quale la parte <hostId> viene suddivisa in due componenti: <subNetID> e<hostID>. Così facendo il numero dei bit riservati alla sezione rete si espande a disca-pito di quelli dedicati ai singoli nodi.

Analogamente anche la network mask verrà estesa comprendendo la parte disubnet mask:

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

Comunemente, la network mask di un indirizzo derivato da subnetting prende ilnome di subnet mask. Spesso i due termini vengono utilizzati come sinonimi.

Il ripartizionamento dei bit della componente <hostID> obbliga a ricalcolare lasubnet mask da associare agli indirizzi IP delle nuove subnet. A tale proposito è daosservare che, a differenza di quanto visto riguardo agli indirizzi IP di tipo ClassFullper i quali la subnet mask può essere anche non esplicitamente indicata insieme

Parte 3

76


all’indirizzo IP, per un indirizzo ottenuto mediante il procedimento di subnetting l’in-dicazione della subnet mask associata è di fondamentale importanza, al fine di con-ferire ad esso “significato” e “consistenza”. Infatti proprio per evidenziare questoaspetto, gli indirizzi IP derivati da un procedimento di subnetting vengono chiamatianche di tipo ClassLess e per essi non valgono tutte le considerazioni precedentemen-te fatte sulle classi in base alle RFC 791 e RFC 1166.

Per convenzione, per estrapolare la parte <subNetID> dall’originale <hostID> siselezionano i bit strettamente necessari e contigui di ordine superiore cioè a partireda 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 realmentepresenti nella rete di partenza è inferiore al numero massimo dei potenziali nodi con-sentiti dalla classe di appartenenza dell’indirizzo IP.

Per poter determinare con facilità gli indirizzi delle nuove subnet, dei rispettivihost e la nuova subnet mask, è necessario rivedere alcuni concetti relativi all’algebrabinaria e ricavare alcune relazioni formali che vediamo qui di seguito.

Matematica degli indirizzi IPDefinite le seguenti variabili:

• nN = Numero di Network

• nS = Numero di Subnet

• nBiN = Numero di Bit della parte <netID>

• nBiS = Numero di Bit della parte <subNetID>

• nH = Numero di Host

• nBiH = Numero di Bit della parte <hostID>

• nBiSM = Numero di Bit appartenenti alla subnet mask

valgono le seguenti relazioni:

• Numero di Bit rimanenti per la parte <hostID>: nBiH = 32 – (nBiN + nBiS)

• Numero Host Per Subnet: nH = 2nBiH – 2

• Numero di subnet secondo RFC 950: nS = 2nBiS – 2

• Subnet mask in formato Network Prefix: nBiSM = (nBiN + nBiS)

Ricavato il numero di bit da dedicare alla parte subnet (nBiS) e alla parte host(nBiH) è possibile ottenere gli indirizzi delle nS subnet e degli nH host considerandola rappresentazione binaria dei singoli ottetti interessati dal processo di subnetting.

Esempio di subnetting di un indirizzo di classe CNell’esempio della figura 5.5 è assegnata una rete di classe C avente l’indirizzo192.168.1.0/24 nella quale si suppone non siano presenti più di 100 nodi. Volendosuddividere questa rete in due sottoreti, è necessario ricavare gli indirizzi IP delle duenuove 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 direttiveRFC 950.

Ricavare gli indirizzi IP delle nS nuove subnet e la subnet maskEssendo nS = 2 il numero di subnet da creare è possibile dedurre il numero di bitnecessari da riservare alla parte <subNetID>, risolvendo la seguente disequazione:

2nBiS – 2 ≥ nS

dalla quale si deduce il valore minimo da assegnare alla variabile nBiS, cioè 2.Trattandosi di un indirizzo iniziale di classe C, i suddetti 2-bit vengono sottratti

dal quarto ottetto (<hostID>). Inoltre, per quanto detto in precedenza, la separazionedei 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 bitfacenti parte della nuova subnet mask:

nBiSM = nBiN + nBiS = 24 + 2 = 26.

Quindi, nella tabella 5.8 viene mostrata la rappresentazione binaria e decimaledella nuova subnet mask, nella quale viene messo in evidenza l’ottetto interessato dalprocesso di subnetting:

Tabella 5.8: Rappresentazione binaria e decimale della nuova subnet mask

MSB (Most Significant Byte) LSB (Least Significant Byte)11111111 11111111 11111111 11000000

255 255 255 192

A questo punto per ricavare gli indirizzi IP da assegnare alle due nuove subnet, ènecessario ragionare sui 2-bit di subnetting dell’ultimo ottetto evidenziando tutte lepotenziali configurazioni (quattro, 22) che si possono ottenere assegnando ad essi idue 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 dellatabella 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 ottettoPosizione 7 6 5 4 3 2 1 0

Peso =2posizione 128 64 32 16 8 4 2 1

Valore decimale Configurazioni possibili

<subNetID> <hostID>

0 0 0 0 0 0 0 0 0

64 0 1 0 0 0 0 0 0

128 1 0 0 0 0 0 0 0

192 1 1 0 0 0 0 0 0

Determinare il numero nH degli host ed i relativi indirizzi IPPer 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>. Ingenerale questo numero di bit è dato da:

nBiH = 32 – (nBiN + nBiS).

Nel nostro caso sarà:

nBiH = 32 – (24 + 2) = 6.

Per cui il numero di host sarà:

nH = 2nBiH – 2 = 26 – 2 = 62.

A questo punto per dedurre gli indirizzi IP da assegnare ai 62 host di ciascunasubnet, è necessario ragionare sui rimanenti nBiH = 6-bit della parte <hostID> evi-denziando tutte le potenziali 26 – 2 = 62 configurazioni che si possono ottenere asse-gnando ad essi i due valori possibili 0 ed 1, e scartando quelli che identificano un indi-rizzo <hostID> formato da tutti-0 o tutti-1 (tabella 5.10).

Pertanto, per ciascuna delle due subnet la lista degli host è la seguente:

Subnet 192.168.1.64.0: Host: 192.168.1..65 ÷ 192.168.1.126; Broadcast = 192.168.1.127.

Subnet 192.168.1.128: Host: 192.168.1..129 ÷ 192.168.1.190; Broadcast = 192.168.1.191.

Prima di concludere l’argomento del subnettting standard, nel prossimo esempioverrà 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 l’utilizzo di un numero intero di ottettiSi supponga di dover preparare un piano per l’indirizzamento IP ad uso interno, perun’azienda avente 4 sedi sul territorio italiano (per esempio: Milano, Roma, Cagliari,Palermo). In ciascuna sede sono previste inizialmente 3 subnet contenenti al massi-mo 200 nodi.

Al fine di poter implementare un tipo di “indirizzamento gerarchico” che sia fles-sibile, razionale, e che garantisca un certo margine di crescita in futuro, si utilizzerà unindirizzo privato di classe A 10.0.0.0/8.

A questo punto, ragionando sulla struttura di un tipico indirizzo di classe A (1ottetto per la parte <netID> e tre ottetti per la componente <hostID>) è da notare chela parte <hostID> è effettivamente sovradimensionata per questo scenario, dovendogarantire un numero massimo di nodi per ciascuna sede pari a 200. Pertanto, anzichéutilizzare 3 ottetti (24-bit) per l’identificazione dei 200 nodi, si riserverà solamenteuno (8-bit) alla parte <hostID>, tramite il quale si potranno identificare, comunque,fino ad un massimo di 28 – 2 = 254 nodi. I rimanenti due ottetti, e precisamente quel-li immediatamente dopo il MSB (Most Significant Byte), saranno fatti agire come unaestensione ai bit della sezione <netID> utilizzati per evidenziare delle sottoreti o sub-net. In particolare, in questo esempio si darà un significato mnemonico ai suddettidue 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, lereti intermedie avranno subnet mask pari a 16-bit e quella di partenza sarà rimastainvariata.


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/810.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 routingIn questa sezione viene trattato l’aspetto matematico del subnetting e non vengonopresi in conto, volutamente, considerazioni legate al tipo di protocolli di routing daselezionare. A tale proposito, come si vedrà nella sezione dedicata ai protocolli dirouting, è 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 singoliindirizzi estrapolandoli dalla classe di appartenenza standard (A, B, C). Infatti, secosì non fosse, un protocollo di routing in un contesto di subnetting in classe A comequello dell’esempio precedente, valuterebbe tutte gli indirizzi del tipo 10.x.y.0 comeappartenenti alla stessa network di classe A 10.0.0.0/8.I protocolli di rounting che “ragionano” in questo modo vengono definiti di tipoClassFull (per esempio: RIPv1).Viceversa, i protocolli che applicano sempre e comunque la subnet mask al fine distabilire la subnet di appartenenza di un indirizzo IP vengono definiti di tipoClassLess. Alcuni esempi di protocolli di questo tipo sono: RIPv2 e OSPF. In tal caso sidice anche che essi applicano dei meccanismi di “summarization” al fine di sintetiz-zare l’identificazione di gruppi di host in base alla subnet mask specificata. Per con-tro, i protocolli di tipo ClassFull applicano dei criteri di “auto-summarization” ba-sandosi esclusivamente sulla valutazione della classe standard di appartenenza del-l’indirizzo IP.


81


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 costituitedai bit tutti-0 e tutti-1, come riportato brevemente nel seguente estratto dalla RFC1812 (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 impliesthat each of these fields will be at least two bits long.DISCUSSIONPrevious versions of this document also noted that subnet numbers must beneither 0 nor -1, and must be at least two bits in length. In a CIDR world, thesubnet number is clearly an extension of the network prefix and cannot beinterpreted without the remainder of the prefix. This restriction of subnet numbersis therefore meaningless in view of CIDR and may be safely ignored…».

Con l’ormai cronica carenza di indirizzi IP ciò potrebbe costituire un ulterioreproblema. Ecco allora che se i router utilizzati all’interno di una infrastruttura di inter-networking, soddisfano le specifiche RFC 1812, RFC 1878, CIDR (Classless Inter-Domain Routing) e VLSM (Variable Length Subnet Mask), è possibile rivedere le rego-le di subnetting precedentemente definite, riutilizzando anche le due subnet tutti-0 etutti-1.

Pertanto, per quanto esposto nella sezione del subnetting standard (RFC 950), èpossibile rivedere le formule relative alla “Matematica degli indirizzi IP”, nelle quali èpossibile modificare l’equazione per la determinazione del numero nS di subnet chediventerà:

numero di subnet secondo RFC 1812, RFC 1878, CIDR/VLSM: nS = 2nBiS

Per spiegare il funzionamento di questa nuova modalità di subnetting ecco unesempio pratico.

Esempio di subnetting VLSM di un indirizzo in classe CSi dispone della seguente subnet di classe C 192.192.192.0/24 contenente 205 nodi. Sisuppone di avere a disposizione un router dotato di quattro porte LAN che supportaCIDR/VLSM. Si vuole suddividere l’unica rete (fisica e logica) attuale in tre sottoreti: laprima rete (A) composta da 120 computer; la seconda (B) contenente 60 computer, ela terza (C) costituita da 25 computer. Inoltre si prevede di dover aggiungere altricomputer in futuro e, pertanto, si vuole predisporre un’altra rete (D) per eventuali altri25 nodi, in modo da non dover modificare successivamente il piano di indirizzamen-to stabilito.

Per risolvere tale problema è necessario iniziare a determinare il numero di bit(nBiH) da assegnare alla porzione <hostID> e tali da garantire l’implementazionedella subnet più grossa (A con 120 nodi). A tale proposito è sufficiente risolvere laseguente disequazione binaria:

2nBiH – 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 = 2nBiS = 21 = 2

Infine, è possibile ricavare anche la subnet mask in formato network prefix (comenumero di bit) per queste due prime subnet:

nBiSM = nBiN + nBiS = 24 + 1 = 25.

Pertanto, le prime due subnet che si possono dedurre assegnando all’unico bitnBiS 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

Conversione da binario in decimale del quarto ottetto

<subNetID> <hostID>

Posizione 7 6 5 4 3 2 1 0

Peso = 128 64 32 16 8 4 2 12posizione

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 esi prosegue con il ripartizionamento della seconda subnet 192.192.192.128/25 perricavare le altre subnet B, C ed D.

Tenendo conto che la subnet B deve contenere 60 nodi è necessario ricavarecome fatto in precedenza per la subnet A, il numero di bit (nBiH) tale per la nuovaparte <hostID> per cui risulti:

2nBiH – 2 ≥ 60

dalla precedente equazione si ricava il minimo valore di nBiH che soddisfa la dise-quazione. Cioè: nBiH = 6.

Pertanto, il numero di bit (nBiS) da utilizzare per la parte <subNetID> è dato da:

nBiS = 8 – nBiH = 8 – 6 = 2

in tale caso, però, il numero di subnet utilizzabili non è pari a:


83


nS = 2nBiS = 22 = 4

ma coincide con 2, in quanto dei due bit della parte <subNetID> il primo ha un valo-re prefissato (1) trattandosi della subnet iniziale 192.192.192.128 (tabella 5.13).

Tabella 5.13: Deduzione degli indirizzi IP per le due nuove subnet (da notare che il bitin posizione 7 è fisso a 1)


<subNetID> <hostID>

Posizione 7 6 5 4 3 2 1 0

Peso = 128 64 32 16 8 4 2 12posizione

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) comesubnet 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 ilnumero di bit (nBiH) tale per la nuova parte <hostID> per cui risulti:

2nBiH – 2 ≥ 25

dalla quale ricaviamo il minimo valore di nBiH che soddisfa la disequazione. Cioè:nBiH = 5.

Pertanto, il numero di bit (nBiS) da utilizzare per la parte <subNetID> è dato da:

nBiS = 8 – nBiH = 8 – 5 = 3

in tale caso, però, il numero di subnet da considerare non è pari a:

nS = 2nBiS = 23 = 8

ma coincide con 2, in quanto dei tre bit della parte <subNetID> i primi due hanno unvalore 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 iprimi 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 12posizione

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 ÷ 190191 = Broadcast

192.192.192.192/26‡ (C)192.192.192.192/27 30 Host: 193 ÷ 222223 = Broadcast

(D)192.192.192.224/27 30 Host: 225 ÷ 254255 = Broadcast

Perché si chiama VLSM (Variable Length Subnet Mask)?Come si può notare dagli esempi visti finora, l’idea alla base delle tecnicheVLSM/CIDR, che spiega il perché di questo nome, è quella di assegnare a ciascunasubnet 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 alsubnetting; infatti, mentre quest’ultimo permette di suddividere una rete in più sub-net, con il supernetting è possibile raggruppare più subnet IP in una sola, mediantel’applicazione di una nuova subnet mask. Le nuove subnet create con la tecnica CIDRsono 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 iprimi 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 bitCIDR) della parte <netID> a partire dal meno significativo.

Questa strategia è utilizzata soprattutto per:

� Ridurre le dimensioni delle tabelle di routing attraverso l’aggregazione delleentry.

� Gestire in maniera più selettiva l’assegnazione degli indirizzi IP da parte degliISP (Internet Service Provider) agenti come Local Internet Registry.

Indirizzi IP di tipo Provider Indipendent (PI) e Provider Aggregate (PA) (cf. Documento RIPE-127)Generalmente gli indirizzi IP unicast globali assegnabili da un ISP si possono classi-ficare in:� Provider Indipendent (PI): sono in genere rilasciati da un Internet Registry e non

vincolano un utente ad un determinato ISP.� Provider Aggregate (PA): sono rilasciati direttamente da un ISP ed hanno validità

fintanto che l’utente rimane contrattualmente legato ad esso.

Per spiegare il funzionamento del supernetting facciamo un esempio pratico: sisupponga che un’azienda richieda ad un ISP 2000 indirizzi IP. Non avendo a disposi-zione una classe B da assegnare al proprio cliente, l’ISP vuole assegnare un gruppo di8 indirizzi di classe C contigui:

192.192.192.0/24192.192.193.0/24192.192.194.0/24192.192.195.0/24192.192.196.0/24192.192.197.0/24192.192.198.0/24192.192.199.0/24

Notazione network prefix e notazione CIDRA volte la notazione network prefix attraverso la quale è possibile indicare in formaabbreviata 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 l’indirizzo IP della “super-net” da utilizzare per aggregare le 8 subnet.

Per risolvere tale problema è possibile seguire due metodi.

Metodo 1Calcolare 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 è sufficienterisolvere la seguente disequazione binaria:

2nBiC ≥ 8

dalla quale si ricava il minimo valore di nBiC che soddisfa la disequazione. Cioè: nBiC= 3.

Trattandosi di un indirizzo iniziale di classe C gli nBiC bit da utilizzare per ilsupernetting sono da prelevare dall’ultimo ottetto della parte <netID> a partire dal bitmeno significativo. Pertanto, la subnet mask risulta essere:

nBiSM = nBiN - nBiC = 24 - 3 = 21

oppure, in notazione decimale: 255.255.248.0.A questo punto il supernetting prevede di aggregare le 8 subnet specificando l’in-

dirizzo IP della prima subnet del gruppo unitamente alla subnet mask derivata, cioè:

192.192.192.0/21

oppure, in notazione decimale:

192.192.192.0/255.255.248.0.

Così facendo l’ISP risparmia l’inserimento nel proprio router le 8 entry relativealle 8 subnet e può specificare solo l’indirizzo sopra indicato.

Metodo 2Si convertano in binario gli indirizzi delle 8 classi da aggregare:

11000000 11000000 11000000 0000000011000000 11000000 11000001 0000000011000000 11000000 11000010 0000000011000000 11000000 11000011 0000000011000000 11000000 11000100 0000000011000000 11000000 11000101 0000000011000000 11000000 11000110 0000000011000000 11000000 11000111 00000000

A questo punto è sufficiente considerare l’insieme dei bit contigui a partire dalpiù 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 laquale associata all’indirizzo IP della prima subnet del gruppo determina l’indirizzo IPdi supernet di aggregazione: 192.192.192.0/21.

Rappresentazione delle classi di indirizzi IP riservati dalla RFC 1918 in notazioneVSLM/CIDRCome ultimo esempio di utilizzo del subnetting, ecco un riepilogo delle tre fasce diindirizzi IP riservati per uso privato secondo la RFC 1918, utilizzando una notazio-ne VLSM/CIDR:

Classe Notazione nBiH IP Disponibili secondoNetwork (Num. Bit <hostId>) la Notazione ClassFullPrefix VLSM /CIDR

A 10.0.0.0/8 24 (“24-bit-block”) 10.0.0.0 ÷ 10.255.255.255B 172.16.0.0/12 20 (“20-bit-block”) 172.16.0.0 ÷ 172.31.255.255

Attenzione: La notazione 172.16.0.0/12 esprime l’aggregazione CIDR delle 31 subnet di classe B.

C 192.168.0.0/16 16 (“16-bit-block”) 192.168.0.0 ÷ 192.168.255.255Attenzione: La notazione 192.168.0.0/16 esprimel’aggregazione CIDR delle 256 subnet di classe C.

Uno strumento di grande aiuto: la calcolatrice per le Subnet IPFermo restando che la via migliore per imparare bene i procedimenti di subnetting esupernetting è utilizzare i principi esposti nella sezione “Matematica degli indirizziIP”, l’uso della calcolatrice è di grande aiuto come strumento di verifica della corret-tezza dei risultati ottenuti manualmente.Una versione di calcolatrice molto utilizzata è la “IP Subnet Calculator” scaricabilegratuitamente dal sito http://www.wildpackets.com/products/ipsubnetcalculator.

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

Note sulla RFC 1700La RFC 1700 è stata resa obsoleta dalla RFC 3232. In realtà le informazioni primaindicate 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 indicareche il relativo campo è costituito interamente da bit di valore 1.

c) 0

Specificato al posto di <netID> o <subNetID> o <hostID> serve ad indicareche 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ò essereutilizzato 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). Infattiin fase di startup non possedendo ancora un indirizzo, il nodo invierà unarichiesta (per esempio: DHCPRequest) nel cui campo indirizzo IP sorgente cisarà il valore 0.0.0.0, ad indicare un “generico nodo su questa generica rete”.

Alcuni usi speciali dell’indirizzo tutti-0a. In alcuni casi, come ad esempio quelli trattati nei punti seguenti, l’indirizzo IP

tutti-0 viene utilizzato anche come network mask.b. Nel caso di un computer predisposto per ricevere un indirizzo IP dinamico (per

esempio: client DHCP), la configurazione IP iniziale (ottenuta per esempiomediante il comando ipconfig –all in caso di computer Win2K/XP/2003 o ifconfigin caso di computer Linux) prevede: IP Address = 0.0.0.0, Subnet Mask = 0.0.0.0.

c. Può essere utilizzato anche nelle tabelle di routing per identificare l’indirizzo direte 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 laentry 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 computercon sistema operativo Win2K/XP/2003, per inserire la entry relativa al Default


89


Route, per esempio con l’indirizzo di default gateway 192.168.1.254, è necessarioinserire 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 seguentecomando:

ip route 0.0.0.0 0.0.0.0 <Default Gateway>.

e) Indirizzo di una rete o “This” Network: {<netID>, 0}

Come già detto precedentemente il valore 0 per il campo <hostID> non èammesso. Infatti un indirizzo IP in cui il valore della porzione <hostID> è 0(tutti i bit a zero) identifica la rete <netID> nel suo complesso. Non può esse-re utilizzato né come source address né come destination address.

Per esempio, l’indirizzo 192.168.1.0/24 indica la rete 192.168.1 mentre l’indi-rizzo 172.26.0.0/16 indica la rete 172.26.

f) {0, <hostID>}

Identifica il nodo <hostID> su “questa rete” (this network). Può essere utiliz-zato solo come source address.

Per esempio, l’indirizzo 0.0.0.12/24 indica l’host 12 di una generica rete ca-ratterizzata dall'avere 24-bit dedicati alla parte <netID><subNetID> (consi-derando anche l'eventualità di subnetting).

g) Limited o Local Broadcast: {-1, -1}

Indica un indirizzo di broadcast limitato o limited broadcast del tipo255.255.255.255. Spesso viene indicato anche come local broadcast. Puòessere utilizzato solo come destination address in ambito circoscritto (limi-ted) alla rete locale d’origine: infatti non richiede di specificare alcun indiriz-zo di <netID>. Un datagramma IP con questo indirizzo di destinazione nonpuò mai essere reinstradato all’esterno della rete d’origine.

h) Network Broadcast (ClassFull): {<netID>, -1}

Indica un indirizzo di broadcast per una rete con indirizzi IP ClassFull. Puòessere utilizzato solo come destination address.

È ottenuto direttamente dall’indirizzo IP della rete <netID> popolando con 1il campo <hostID>. Per esempio per la rete 172.26.0.0/16 l’indirizzo di broad-cast diretto è 172.26.255.255.

A differenza dell’indirizzo di broadcast limitato richiede di specificare la<netID>.

Un datagramma IP con un indirizzo IP di questo tipo è rivolto a tutti i nodiappartenenti alla rete identificata da <netID>. Pertanto se ricevuto da unrouter 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 directedbroadcast) per una rete con indirizzi di tipo ClassLess. Può essere utilizzatosolo come destination address.

È ottenuto direttamente dall’indirizzo IP indicato nel campo <netID><subNetID>, popolando con 1 il campo <hostID>.

Per esempio per le subnet 192.192.192.0/25:

<netID> <hostID> Broadcast192.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 nodiappartenenti alla rete identificata da “<netID> + <subNetID>”. Pertanto sericevuto da un router lo costringe ad inoltrare lo stesso datagramma IP a tuttii 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> appartenentialla stessa <netID>. Può essere utilizzato solo come destination address.

Per esempio nel caso si utilizzi la rete 10.0.0.0/24 l’indirizzo di All-Subnets-Directed Broadcast è 10.255.255.255 in contrapposizione al DirectedBroadcast che risulterebbe 10.0.0.255.

k) {127, <any>}

Indica un generico indirizzo di loopback. Non viene mai “proiettato” al difuori di un qualsiasi host poiché non viene passato dal livello network al livel-lo fisico, ma restituito direttamente al livello applicativo per mezzo di un’o-perazione di copia dalla coda di trasmissione (transmit buffer) alla coda diricezione (receive buffer).

Normalmente viene utilizzato per scopi diagnostici, in particolare per verifi-care la corretta installazione dello stack TCP/IP su un generico host.

L’indirizzo di loopback può anche essere utilizzato per connettersi ad un ser-vizio TCP/IP installato sullo stesso host da cui si esegue il client, per esempio:http://127.0.0.1 o analogamente http://loopback. Da notare che in alcuniambienti 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 talcaso è da utilizzare il termine localhost, con lo stesso significato.

I potenziali indirizzi che si possono utilizzare per il loopback address sonopari a 224 – 2 = 16.777.214 (classe A), sebbene normalmente sia utilizzato sto-ricamente l’indirizzo 127.0.0.1.


91


Formato del datagramma IPUn datagramma IP è formato da due parti chiamate rispettivamente IP Header e IPPayload ciascuna di lunghezza variabile, in modo da diversificare ed ottimizzare iltraffico 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 campicome indicato nella figura 5.7.

Figura 5.7: PDU IP

TerminologiaIl termine payload viene utilizzato in questo contesto per identificare all’interno diuna stringa di dati scambiati tra due N-entità (dove N identifica un qualsiasi livelloOSI o TCP/IP), la parte corrispondente alle informazioni degli utenti. Di solito nonvengono inclusi nel payload le informazioni di servizio inserite dal sistema, detteanche system overhead, e necessarie per l’implementazione dei protocolli utilizzati aciascun livello. A volte il payload viene anche indicato come mission bit stream (cf.Glossary of Telecommunication Terms-Federal Standard 1037C).


Dove:� IP Header (IH): è costituito da un insieme di blocchi (detti anche parole o

word) di 32-bit in numero variabile da un minimo di 5 (160-bit o 20 ottetti)ad un massimo di 15 (480-bit o 60 ottetti), a seconda dell’aggiunta o meno delcampo “Options e Padding”. Poiché il minimo di un elemento dell’IP Headerha una lunghezza pari a 32-bit o 4 ottetti, l’eventuale espansione dell’IH deveessere eseguita per incrementi di 32-bit. Ciò vale per esempio per l’utilizzodel campo “Options e Padding”: in tal caso l’aggiunta delle opzioni deve esse-re effettuata avendo cura di riempire i bit mancanti per giungere a 32 con deicaratteri “null” (operazione chiamata anche padding-zero), ottenendo così“l’allineamento dell’IH”. Il ruolo dell’IP Header è di fornire tutti gli elementinecessari per discriminare la parte header dalla parte payload, per identifi-care il mittente ed il destinatario di un datagramma oltre ad eventuali altreopzioni necessarie per il loro corretto instradamento.

� IP Payload (IP): come si può osservare dalla figura 5.6, la componente pay-load corrisponde alla PDU (Protocol Data Unit) associata ad un protocollo dilivello superiore ULP, secondo il principio di incapsulamento tipico deimodelli stratificati (ISO/OSI o TCP/IP). Come per il campo precedente ancheil payload ha una lunghezza variabile.

Di seguito viene data una descrizione dettagliata dei vari campi che costituisco-no la parte IP Header di un datagramma:

� Version (VER)

• Dimensione campo: 4-bit

Occupa i primi 4-bit della struttura e contiene il numero di versione che defi-nisce il formato dell’IH. La versione utilizzata correntemente è la 4 indicatacon l’acronimo IPv4. L’aver aggiunto il campo Version nell’IH consente di svi-luppare nuovi protocolli e nuovi formati di header, con la possibilità di inte-grarli in corso d’opera. È questo il caso, per esempio, di alcuni protocolli spe-rimentali (Version 7: IP/IX (RFC 1475, RFC 1707); Version 8: “P” InternetProtocol (RFC 1710); Version 9: Tcp and Udp with Bigger Address (TUBA)(RFC 1347, RFC 1526, RFC 1561) e soprattutto della successiva versione IPv6.IPv6 consente, tra l’altro, l’utilizzo di indirizzi IP a 128-bit.

� Internet Header Length (IHL)

• Dimensione campo = 4-bit

• Unità di misura = 4 gruppi di ottetti (parole o word da 32-bit)

• Range = 5 ÷ 15 (default = 5)

Questo campo non è un contatore di byte ma indica la lunghezza dell’IHespressa in blocchi o parole di 32-bit (4 ottetti). Pertanto il valore contenutoin questo campo deve essere sempre un multiplo di 4. Le sue dimensioni paria 4-bit determinano dei limiti strutturali sulla lunghezza dell’IHL:

a. Dimensioni minime dell’IH: le dimensioni minime si hanno, come per lamaggior 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 dell’IH: la massima estensione indirizzabile dalcampo IHL è di 24 – 1 = 15 (0x0F) parole da 32-bit cioè 480-bit o 60ottetti.

� 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 RFC2474 esso è costituito da cinque sottocampi più un sesto di valore riservato(MBZ: Must Be Zero) (tabella 5.16).

Tabella 5.16: Type Of Service (TOS)

3-bit 1-bit 1-bit 1-bit 1-bit 1-bit

Precedence Delay Throughput Reliability Cost MBZ

000 Routine (R) 0 Normal 0 Normal 0 Normal 0 Normal Must Be

001 Priority (P) 1 Low 1 Low 1 Low 1 Low Zero

010 Immediate (O)

011 Flash (Z)

100 Flash Override (X)

101 Critic/ECP (Critical and Emergency Call Processing)

110 Internetwork Control

111 Network Control

Per default il valore del campo TOS è 0 (0x0) ovvero Normal Service.

� Total Length (TL)


• Unità di misura = Ottetti

Il campo TL è costituito da 16-bit e definisce la lunghezza, espressa in ottetti,dell’intero datagramma considerando sia la parte header sia la parte payload.Da notare che la dimensione massima consentita per un datagramma IP è di216 = 65.535 ottetti. Di fatto essa è limitata dal valore MTU (MaximumTrasmission Unit) imposto dalla rete utilizzata a livello 2 (o livello NetworkInterface TCP/IP). I datagrammi la cui lunghezza supera il valore dell’MTUdella 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 seguenteespressione:

Lunghezza IP Payload = TL – 4 * IHL

� Identification (ID)


Parte 3

94


Rappresenta un numero progressivo unico compreso tra 0 e 65.535 (216)assegnato ad ogni datagramma inviato da ciascun host.

È utilizzato soprattutto in caso di frammentazione per distinguere i fram-menti di un datagramma da quelli di altri datagrammi. Normalmente talevalore viene passato direttamente da un protocollo ULP tramite un appositoparametro (ciò vuol dire che è possibile avere valori duplicati relativamentea datagrammi consecutivamente generati uno da TCP ed uno da UDP; lagestione di questi casi particolari è demandata alle varie implementazioni).In caso contrario viene automaticamente generato dal protocollo IP. Il suovalore deve essere comunque unico per ogni coppia IP Mittente-IPDestinazione e Protocollo per il tempo che sopravvive il datagramma in rete.Ciò potenzialmente potrebbe portare ad una duplicazione di valori delcampo Identification per due datagrammi generati uno dal protocollo TCPed l’altro dal protocollo UDP: queste evenienze sono ammesse e devonoessere gestite dalla particolare implementazione dello stack TCP/IP.

In caso di frammentazione di un datagramma permette di fissare il legametra i singoli frammenti ed il datagramma originario: tutti devono avere lostesso valore del campo Identification. Viceversa, consente all’host destina-zione (o più tipicamente ad un router che interconnette reti con MTU diffe-renti) di ricomporre ciascun frammento associandolo al corrispondentedatagramma distinguendo tra i diversi datagrammi in fase di ricostruzione.Ciò in quanto il protocollo IP è di tipo connection-less e quindi frammentidiversi di datagrammi possono inframmezzarsi. Questo campo viene utiliz-zato, congiuntamente ai campi Flags (DF, MF) e Fragment Offset, per il rias-semblaggio dei frammenti a destinazione.

� Flags


Questo campo contiene 3-bit dei quali il primo (bit 0, più significativo) èriservato ed ha sempre valore 0 (MBZ, Must Be Zero), mentre gli altri duecostituiscono 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 Don’t Fragment (DF) il qualese assume il valore 0 rende possibile la frammentazione del datagramma.Viceversa, un valore 1 del flag DF esclude tale possibilità. In quest’ultimocaso se la dimensione del datagramma originale è superiore al valore MTU


della rete il datagramma viene scartato (per esempio da un router) e vieneriscontrato all’host mittente il seguente messaggio ICMP (Type = 3, Code = 4)Destination Unreachable-Fragmentation Needed And DF Set come specifica-to nella RFC 792.

Il secondo flag viene indicato con il termine More Fragment (MF) ed assumeil valore 1 per indicare al destinatario che sono previsti altri frammenti inarrivo. Viceversa, un valore 0 indica che si tratta dell’ultimo frammento diuna serie oppure che il datagramma è costituito da “un unico pezzo” chia-mato anche “datagramma intero” (in tal caso, però, anche il campo FragmentOffset deve valere 0).

Tips and tricks1. Per ricordarsi mnemonicamente l’ordine dei due flag (DF e MF) fare riferimento

all’ordine alfabetico (prima DF e poi MF).2. Normalmente, utilizzando il comando ping per testare la raggiungibilità di un

host all’interno di una rete, viene inviato un datagramma IP di dimensioni pre-fissate: 32 byte in ambiente Microsoft Windows e 64 byte in ambiente Unix/Linux.Utilizzando apposite opzioni è possibile modificare queste dimensioni e soprat-tutto si può anche imporre di non produrre la deframmentazione dei datagram-mi qualora la loro dimensione ecceda il valore dell’MTU della rete utilizzata. Inquesto modo è possibile scoprire il valore di MTU di una rete. In particolare, aseconda del sistema operativo utilizzato e supponendo di operare su una reteEthernet (con sistema di Encapsulation Ethernet II, valore MTU = 1500), ilcomando 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 nonsi 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 determinatoanche attraverso i comandi ifconfig –a oppure netstat –i.

� Fragment Offset (FO) e il processo di frammentazione


• Unità di misura = 8 gruppi di ottetti (64-bit)

• Range = 0 ÷ 8191 (default = 0)

Parte 3

96


Il campo Fragment Offset (FO) è utilizzato insieme ad altri (per esempio:Identification, Flags, Protocol, Source e Destination Address, Flags, TTL) perimplementare il processo di frammentazione. Esso indica la posizione occu-pata dal singolo frammento relativamente all’inizio del datagramma origina-rio. La dimensione di ogni frammento (tranne l’ultimo) deve essere un mul-tiplo di 8 essendo riferita a gruppi di 8 ottetti. Inoltre, per ciascun frammen-to deve essere ricalcolato il valore del campo Total Length. Nel caso di undatagramma completo (ovvero non ulteriormente frammentato e quindi conil 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 primoframmento di una serie sarà caratterizzato da MF = 1, FO = 0. I successiviavranno: MF = 1, FO ≠ 0. L’ultimo frammento sarà identificato da: MF = 0, FO≠ 0. Da notare che ogni frammento può essere a sua volta sottoposto a fram-mentazione (anche più di una volta), qualora debba attraversare altre reticon un MTU ancora più basso.

Ricordiamo che la frammentazione è uno dei servizi essenziali che ogni moduloIP 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 contosoprattutto della potenziale differenza in termini di dimensione massima (a volteanche minima) dei pacchetti (MTU, Maximum Transmision Unit) supportati da cia-scuna di esse. Infatti, come già anticipato precedentemente, la dimensione massimadi un datagramma è determinata a priori sia in virtù del limite di 16-bit del campoTotal Length che stabilisce il limite massimo di 216 = 65.535 ottetti sia, soprattutto, dalvalore MTU delle singole reti interconnesse (che può oscillare da 48 ottetti di una reteATM fino a 65.535). Naturalmente questo limite risulta essere impraticabile per lamaggior parte delle reti e degli host. Pertanto, tutti gli host di una rete TCP/IP devonoessere preparati per affrontare il problema della frammentazione (host mittente) di undatagramma, qualora la sua dimensione superi il valore MTU della rete utilizzata perl’inoltro, e del relativo riassemblaggio (host destinazione).

Ogni host deve essere comunque in grado di inoltrare un datagramma di almeno68 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 terminologiaSpesso, parlando di frammentazione si utilizzano diversi termini. Di seguito vengo-no descritti alcuni fra quelli più ricorrenti:� Frammentazione locale: la frammentazione locale si verifica al di sotto del livel-

lo IP ed il riassemblaggio avviene prima che i frammenti vengono presentatiall’host o router ricevente.

� Frammentazione non-trasparente: è il classico processo di frammentazione chesi 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 dall’host mittente all’host destinazione.

d) La frammentazione e il riassemblaggio avviene end-to-end.e) La perdita o danneggiamento anche di un solo frammento provoca lo scarto

dell’intero datagramma.� Frammentazione trasparente: processo di frammentazione che si svolge in ma-

niera del tutto trasparente rispetto al modulo IP degli host interagenti e rispettoai protocolli di livello superiore (ULP), scatenato dai router intermedi in caso direti 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 vienechiamata segmentazione. In tal caso la dimensione MTU è pari a 48 ottetti.

� Frammentazione intranet o “Network-Dependent”: si riferisce al processo diframmentazione e relativo riassemblaggio che si verifica all’interno di una reteintranet (tipicamente un insieme di reti locali fisicamente separate (per esempio:distribuite geograficamente), di diversa tipologia (per esempio: Ethernet, TokenRing) e interconnesse mediante reti geografiche; ma anche nel caso più semplicedi una rete singola nel caso di utilizzo di particolari applicazioni (tipicamentebasate su protocollo di trasporto UDP) che utilizzano pacchetti di dimensioniconsistenti anche superiori a 64K) in seguito all’inoltro dei pacchetti tra routerche interconnettono reti di tipo diverso (con MTU potenzialmente diversi). In talcaso ricadendo tutti i dispositivi di internetworking (ovvero: router) sotto unastessa giurisdizione ed in base alla tipologia di reti utilizzate, è possibile determi-nare regole univoche per il trattamento della frammentazione (“private agree-ment”). Si tratta comunque di un processo di frammentazione trasparente.

� Frammentazione intenzionale: come riportato nella RFC 1122 (sezione 3.3.3)ogni host opzionalmente può implementare un meccanismo di frammentazionedei datagrammi in uscita detto intenzionale o provocato. Esso consiste nell’in-viare datagrammi aventi dimensioni molto grandi e tali da innestare sicura-mente il processo di frammentazione. Ciò da un lato permette di ottimizzare leperformance riducendo la quantità di lavoro che un host deve dedicare prima edopo l’invio dei dati. D’altro canto esso può provocare un degrado delle presta-zioni dei router. Pertanto, è da utilizzare solo all’interno di reti private. Per l’im-plementazione di questo meccanismo viene definito un parametro chiamatoEMTU_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 ouguale dell’MTU dell’interfaccia di rete corrispondente all’indirizzo sorgente deldatagramma. Inoltre ogni host deve implementare un meccanismo che consentaal protocollo di trasporto (tipicamente TCP) di dedurre la dimensione massimadi 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 taleparametro 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 didimensione 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 valoreEMTU_S ≤ 576 soprattutto in caso di diverse reti interconnesse.

Considerazioni sull’MTU� Il valore dell’MTU di ogni interfaccia di rete deve essere configurabile.� Ogni implementazione del livello IP deve avere a disposizione un flag “All-

Subnets-MTU” che consenta di specificare l’utilizzo di un MTU per tutte le desti-nazioni appartenenti alle sole subnet derivate dalla stessa rete, ma non ad altrereti (ovvero: lo stesso concetto del Broadcast “All-Subnets-Directed-Broadcast”.Nel caso di host multi-homed questo flag è necessario per ciascuna interfaccia direte. Il suo utilizzo forza l’host ad utilizzare la network mask anziché la subnetmask per la scelta del parametro EMTU_S.

� Alcune implementazioni prevedono la determinazione dell’MTU (sia via UDPsia 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 toReceive) 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 configurableor indefinite, and SHOULD be greater than or equal to the MTU of the connectednetwork(s). DISCUSSION: A fixed EMTU_R limit should not be built into the codebecause some application layer protocols require EMTU_R values larger than576…».

Pertanto, dovendo inviare datagrammi che hanno una dimensione superiore a576 ottetti, è necessario assicurarsi che tutti gli host destinatari siano preparati adaccogliere datagrammi di queste dimensioni.

Il valore 576 è stato scelto in modo tale da garantire l’invio di una ragionevolequantità di informazioni (circa 512 ottetti) oltre agli ottetti obbligatori di overhead (da20 a 60 ottetti per l’header IP e qualche margine per l’header dei protocolli ULP).Infatti, parecchi protocolli di livello superiore soprattutto basati su UDP (per esempio:TFTP, DNS, SNMP, ...) utilizzano come limite proprio 512 ottetti. Viceversa, TCP utiliz-za direttamente un meccanismo per determinare il valore di MTU, chiamato PathMaximum Transmission Unit Discovery (PMTUD), avente l’obiettivo di dedurre il va-lore del parametro Maximum Segment Size (MSS). Come indicato nella RFC 1122 ilvalore della variabile EMTU_R dovrebbe essere maggiore o uguale all’MTU della reteutilizzata.

In definitiva, nel caso di un datagramma IP non contenente alcuna opzione, lalunghezza 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 intraprendereper 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 essereinoltrato il datagramma.

II. Verificare se la dimensione (Total Length) del datagramma non eccede ilvalore 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 contoche occorre riservare almeno 20 ottetti (supponendo che non sia utilizzato ilcampo opzioni) per l’header di ogni frammento, e determinare la dimensio-ne di ciascun frammento (che deve essere multiplo di 8-ottetti, tranne l’ulti-mo frammento). Inoltre ogni frammento deve essere opportunamente nu-merato. Indicando con MOD il resto intero associato ad una divisione interae 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, tranneper l’ultimo frammento deve essere multiplo di 8 ottetti, è data da:

IF ((MTU - 4*IHL) MOD 8) = 0)

/* Cioè, se (MTU – 4*IHL) è multiplo di 8 ? */

THEN LPF = MTU – 4*IHL

ELSE LPF = primo valore inferiore a (MTU – 4*IHL) che sia divisibile per 8.

iii. Il numero di frammenti (NF) è dato da:

NF = (TL – 4*IHL) DIV LPF.

iv. Inoltre, se la divisione precedente ha un resto diverso da 0 (ovvero: lalunghezza del datagramma originale non è un multiplo esatto di LPF equindi [(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 tricksPer gli amanti (ed i “ puristi”) del linguaggio C, il numero di frammenti (NF) lo si puòindicare in maniera molto più sintetica utilizzando l’operatore ternario?:

NF = [(TL – 4*IHL) MOD 8] ? [(TL – 4*IHL) DIV LPF] + 1 : [(TL – 4*IHL) DIV LPF];

Il meccanismo di funzionamento del suddetto operatore può essere spiegato con ilseguente 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 l’espressione Esp1, che diventa il valore dell’intera espres-sione (valore assegnato a x). Viceversa, se Condizione è falsa allora si passa a valuta-re Esp2, che a questo punto determina il valore dell’intera espressione. Essa è equiva-lente alla seguente più classica espressione IF:

IF Condizionex = Esp1

ELSEx = Esp2

IV. Per ogni frammento è necessario riconfigurare i campi seguenti:

a. Identification (uguale per tutti).

b. Il Fragment Offset (FO) sarà dato da:

FO = N*NBF

dove N = 0 (primo frammento), 1, 2, …, NF - 1 (ultimo frammento).

c. DF = 0 per tutti i frammenti.

d. MF = 1 per tutti i frammenti tranne che per l’ultimo.

e. Ricopiare eventuali opzioni.

f. Ricalcolare il checksum.

Da notare che le dimensioni dei frammenti (LPF) si riferiscono alla parte datio payload e non considerano la parte di header. Pertanto, per ottenere ladimensione totale (Total Length) di ciascun nuovo datagramma generatooccorre tenere conto dell’header da aggiungere (almeno 20 ottetti fino ad unmassimo di 60) a seconda delle opzioni utilizzate.

Esempio 1Si supponga di avere le seguenti reti interconnesse A, B e C con MTU rispettivamentedi 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 4482e 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. Ildatagramma 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 valoredell’MTU della rete B, il router AB deve procedere con la sua frammentazione.

Essendo l’MTU della rete B pari a 1500 applicando le relazioni viste in preceden-za si avrà:

I. NBF = (MTU – 4*IHL) DIV 8 = 1480 DIV 8 = 185.

II. LPF = MTU – 4*IHL = 1480 (è un multiplo esatto di 8).

III. NF = (TL – 4*IHL) DIV LPF = 4462 – 1480 = 3 (cioè tre frammenti ciascuno conun 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 quartoframmento 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 frammentigenerati da un datagramma originato nella rete A e destinato alla rete B (cf. figura 5.9)

Esempio 2Consideriamo le reti raffigurate nella figura 5.9 dell’esempio precedente.

Si consideri un datagramma caratterizzato dal campo Identification = 5760 origi-nato da un host della rete B, avente una lunghezza totale (TL = Total Length) di 1500 erivolto 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 deveprocedere con la sua frammentazione, in quanto le sue dimensioni sono superiori aquelle dell’MTU della rete C di destinazione.


Essendo l’MTU della rete B pari a 525 applicando le relazioni viste in precedenzaavremo:

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 ilnumero inferiore più prossimo divisibile per 8. Pertanto sarà LPF = 504.

III. NF = (TL – 4*IHL) DIV LPF = 1480 – 504 = 2 (cioè 2 frammenti ciascuno conun 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 frammentigenerati da un datagramma originato nella rete B e destinato alla rete C (cf. figura 5.9)

Osservazione sugli esempi 1 e 2: frammentazione trasparenteSupponendo che nell’esempio 1 l’host sorgente anziché inviare il datagramma ad unhost della rete B lo invii ad uno della rete C, si verificherà in tal caso una frammen-tazione trasparente nel router BC in quanto ciascun frammento generato dal data-gramma originario deve essere riframmentato prima di essere inoltrato sulla rete C.

Effetti negativi dovuti alla frammentazione e ripercussioni sulla sicurezza� Come si può osservare dagli esempi precedenti, a seguito del processo di fram-

mentazione non solo si impegnano risorse elaborative (CPU, Memoria) degli hosto router coinvolti, ma aumenta anche la quantità di informazioni che devonoessere trasmesse. In particolare la quantità di ottetti che costituiscono l’overhead(cioè l’incremento fisiologico della quantità di dati da inviare) è pari 4*IHL*(NF– 1) dove NF è il numero dei frammenti; in questo calcolo non si tiene conto dieventuali opzioni che, in base al valore del flag (Copy On Fragmentation), devo-no o meno essere copiate in ogni frammento o solamente nel primo. Gli effetti ne-gativi della frammentazione sono ancora più pesanti per l’host destinatario acausa 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 questodeve normalmente svolgere ed i ristrettissimi tempi a disposizione da dedicare aciascun datagramma, si può intuire come la frammentazione sia un processoveramente penalizzante per i router.

� Il mancato recapito o danneggiamento anche di un singolo frammento provocala ritrasmissione dell’intero datagramma, su richiesta di un protocollo di livellosuperiore (tipicamente TCP).

� Datagrammi con valori elevati di TTL possono permanere a lungo nel buffer diricostruzione.

� La deframmentazione potrebbe avere conseguenze negative anche sul correttofunzionamento di alcuni sistemi di networking e di sicurezza come Firewall (peresempio: Non-Initial Fragment Attack), IDS (Intrusion Detection System) e Con-tent Switch Engines) in quanto in quest’ultimo caso, se un pacchetto viene sud-diviso in tanti frammenti, risulta difficile l’analisi del suo effettivo contenuto e larelativa applicazione delle policy.

� Un altro effetto collaterale si può verificare, per esempio, nell’utilizzo di client diposta elettronica che implementano la funzionalità “Message Fragmentationand Reassembly” della RFC 2046 “Multipurpose Internet Mail Extensions (MIME)Part two: Media Types”. È questo il caso di Outlook Express, che opportunamenteconfigurato (Tools → Accounts → “Selezionare un account di e-mail” →Properties → Advanced: nella sezione Sending, selezionare la voce “Break apartmessages larger than” e specificare il valore desiderato (default = 60 KB) consentedi spezzare messaggi lunghi in piccole parti. Così facendo è possibile, spezzandoopportunamente un “messaggio maligno”, per un potenziale attaccante eludere ilcontrollo di eventuali filtri SMTP (SMTP Filtering Engines), Gateway VirusScanner, Content Filters, ecc., qualora questi non eseguano dei controlli più effi-caci (per esempio: includere un “Reassembly Agent” sui server per bloccare l’inol-tro di messaggi frammentati) e non basati unicamente sull’analisi di un deter-minato “pattern” (per esempio: VIRUS SIGNATURE).

In maniera completamente simmetrica ogni host destinazione (e mai un routerintermedio, tranne in casi di frammentazione trasparente) deve procedere con le se-guenti operazioni per poter riassemblare i vari frammenti e ricostruire il datagrammacosì come si presentava all’origine:

I. Predisporre tutte le risorse necessarie per compiere il processo di riassem-blaggio: un buffer per i dati (potenzialmente grande fino a 65.515 ottetti), unbuffer per l’header (potenzialmente grande fino a 60 ottetti), una tabella pertenere traccia dei frammenti elaborati (potenzialmente 8192 bit), una varia-bile che contenga il valore Total Length del datagramma ed un timer (cf. ilriquadro “Alcune note importanti sul dimensionamento del “ReassemblyTimer”” 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 deiquattro campi Identification, Source, Destination, Protocol.

IV. Fino a quando il timer non è scaduto continuare ad assemblare gli altriframmenti 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 deveessere passato al protocollo ULP specificato nel campo Protocol.

Alcune note importanti sulla procedura di riassemblaggio� Come già anticipato precedentemente, ogni host deve essere predisposto per

accettare datagrammi che abbiano una dimensione di almeno 576 ottetti (sia chearrivino in forma intera sia frammentata). Questo limite è identificato medianteil valore EMTU_R (“Effective MTU to Receive”) definito nella RFC 1122. Inoltre,per consentire la ricezione di pacchetti di dimensioni anche più elevate (richiestenormalmente da alcuni protocolli di livello applicazione) è consigliato che talelimite non sia imposto staticamente ma sia configurabile.

� L’algoritmo normalmente utilizzato per effettuare il riassemblaggio dei fram-menti deve prevedere di mantenere l’header del primo frammento in quanto incaso di errore o scadenza del timer esso deve essere restituito nell’eventuale mes-saggio ICMP (Type = 11, Code = 1) “Fragment reassembly time exceeded”.

� Per ottimizzare l’interazione tra gli host e migliorare le performance degli appa-rati di routing è consigliata l’implementazione, su ciascun host, di un meccani-smo che consenta al livello di trasporto di determinare la dimensione massimadi un messaggio in ricezione o “Maximum Message Size that may be Received”(MMS_R). Normalmente il suo valore è deducibile dalla relazione seguente:

MMS_R = EMTU_R – IHL.

Alcune note importanti sul dimensionamento del “Reassembly Timer”� Il timer viene azionato alla ricezione del primo frammento. Il suo valore massi-

mo è di 255 secondi (4,25 minuti). Alla ricezione di ogni frammento dello stessodatagramma il suo valore viene aggiornato, assumendo come valore il massimotra il valore attuale e quello del TTL del frammento.

� Secondo la RFC 791 il valore consigliato è di 15 secondi.� Viceversa secondo la RFC 1122, il valore del timeout dovrebbe essere fisso e non

dipendente dal campo TTL del frammento ricevuto, in quanto tutti i router or-mai trattano il parametro TTL come numero di hop e non come intervallo ditempo ancora a disposizione. Il valore raccomandato è tra 60 e 120 secondi. Incaso di scadenza del timer il datagramma ancora parzialmente assemblato deveessere scartato, ed all’host sorgente deve essere notificato un messaggio ICMP(Type = 11, Code = 1) “Fragment reassembly time exceeded” (se il frammento zeroè stato ricevuto).


105


� Datagrammi con valori elevati di TTL possono permanere a lungo nel buffer diricostruzione e bloccare per tanto tempo le risorse necessarie. Inoltre ciò puòavere una ripercussione negativa sul valore del parametro MSL (MaximumSegment Lifetime) che viene inutilmente settato con un valore elevato dai proto-colli di livello trasporto. MSL controlla la velocità massima con la quale i fram-menti dei datagrammi vengono inviati. Un valore elevato dell’MSL causa unadiminuzione della velocità massima. Le specifiche TCP assumono un valore perMSL pari a 2 minuti, il quale determina un accettabile limite superiore per quan-to riguarda il valore del timer.

� Il messaggio ICMP (Type = 11, Code = 1) “Fragment reassembly time exceeded” (cf.RFC 792) che viene notificato dall’host destinazione in caso di scadenza del timernon è gestito da tutte le implementazioni TCP/IP. Ciò potrebbe causare qualcheproblema o comunque inutile sovraccarico di traffico.

� Time To Live (TTL)


• Unità di misura = secondi

• Range = 0 ÷ 255 (4m15s o 4,25 minuti)

Questo campo può essere utilizzato sia come limite temporale (espresso insecondi) 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 disopravvivenza concesso ad un datagramma. Il decremento del valore del TTLveniva effettuato da ciascun router in base al tempo di permanenza del data-gramma (tempo di forwarding – tempo di arrivo del datagramma). A causadelle difficoltà di tenere traccia dei vari tempi di transito dei datagrammi eper 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 lalibertà di utilizzare questo campo come hop count. In tal caso i router devo-no semplicemente decrementare di una unità il valore originario.

Oltre a limitare il tempo di vita dei datagrammi IP il campo TTL evita l’in-staurarsi dei cosiddetti routing loop.

A proposito della gestione del campo TTL sono state fissate nelle RFC 791,RFC 1122 e RFC 1812, alcune regole comportamentali sia per i router sia pergli 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 propriatabella di routing. Nel caso in cui il campo TTL raggiunge il valore 0 ilrelativo datagramma viene scartato e viene riscontrato al mittente ilmessaggio ICMP (Type = 11, Code = 0) Time To Live Exceeded in Transitcome 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 dirouting.

e. Il valore del campo TTL può essere specificato o in sede di configurazio-ne del sistema operativo oppure direttamente da alcune applicazioni e/outility (applicazioni multicast, ping, traceroute/tracert, …).

f. Il valore raccomandato per il campo TTL è pari al doppio del diametro diuna internetwork. Dove per diametro si intende il numero di link (ovve-ro: di interfacce di rete da attraversare per giungere a destinazione) tra idue nodi più distanti. Da notare che il numero di hop non coincide conil numero di link. Per esempio supponendo che due destinazioni sianoseparate 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 = 4un datagramma non sarebbe in grado di raggiungere la destinazione inquanto arrivato all’ultimo router (il quarto) il valore del TTL avrebbe giàraggiunto 0 e verrebbe scartato. Viceversa, impostando un valore di TTLpari a 5 o superiore può giungere potenzialmente a destinazione.

Il valore minimo consigliato da IANA per il campo TTL è 64 (cf. il sitohttp://www.iana.org/assignments/ip-parameters).

Tips and tricksÈ possibile modificare il valore di default del parametro TTL utilizzato all’internodello stack TCP/IP Per esempio, in ambiente Microsoft WinNT/2K/XP/2003 è possibi-le agire mediante registry aggiungendo o variando la seguente chiave:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TTLDefault:REG_DWORD:1-255:Default=128.

Da notare che applicazioni di tipo WinSockets possono sovrascrivere questo valore.

� Protocol (PROT)


• Range = 0 ÷ 255

Il campo protocollo (PROT) viene utilizzato per identificare a quale proto-collo di livello superiore (ULP) si riferiscono i dati contenuti nel campo pay-load. Attraverso questo campo vengono realizzate operazioni di multiple-xer/demultiplexer in fase di incapsulamento/decapsulamento dei dati scam-biati con i protocolli ULP.

In questo modo ad ogni ULP è assegnato univocamente un valore definito daIANA (per esempio: ICMP = 1, IGMP = 2, TCP = 6, UDP = 17, …). Pertanto, adogni PDU di un protocollo ULP (da notare che si fa riferimento ai protocolliICMP e IGMP come protocolli ULP anche se in effetti sono collocati allo stes-so livello del protocollo IP, in quanto anch’essi vengono incapsulati in PDUIP), in fase di incapsulamento in un datagramma IP, viene associato undeterminato valore PROT. Così facendo quando il datagramma giunge adestinazione, il corrispondente livello IP all’atto del decapsulamento estrae ilpayload 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 Protocollo0 Riservato (IPv6 Hop-by-Hop Option)

1 ICMP

2 IGMP

4 IP in IP (encapsulation)

6 TCP

17 UDP

50 ESP Encap Security Payload for IPv6

51 AH Authentication Header for IPv6

89 OSPF

Essendo definito in ogni sistema operativo nel quale è implementato il pro-tocollo TCP/IP il file protocols (/etc/protocols in ambito Unix/Linux; %Sy-stemRoot%\System32\drivers\etc\protocols in ambiente Microsoft Win*),che contiene la risoluzione tra i valori del campo PROT ed i relativi protocol-li, è possibile riferirsi a questi ultimi anche tramite il nome descrittivo anzi-ché per numero.

� Header Checksum


Questo campo contiene un codice costituito da 16-bit (2 ottetti) utilizzatoper rilevare eventuali errori in fase di trasmissione del datagramma. In casodi rilevazione di errore da parte di un nodo (per esempio: router) il relativodatagramma viene scartato senza l’invio di alcun riscontro al mittente nérichiesta di ritrasmissione. Il Checksum Header copre solamente la parte IPHeader e non prende in considerazione la relativa componente payload.

L’algoritmo di generazione del checksum consiste nell’applicazione delleseguenti operazioni:

a. Inizializzare a 0 il campo Checksum.

b. Per ogni blocco di 16-bit dell’Header IP viene calcolato il complementoad 1 (ovvero: vengono invertiti i bit: gli 1 diventano 0 e viceversa).

c. Vengono sommati i singoli complementi ad 1 di ogni blocco (tenendoconto 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 eventualiriporti) 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 checksumConsideriamo la seguente porzione di cattura di una frame (cf. file \Catture\Esem-pioChecksum.cap, frame numero 10, sul CD-ROM allegato) riferita ad un comandoping, dall’host 10.1.1.1 all’host 192.168.1.201, come si può evidenziare dal campo pro-tocollo (ICMP = 0x01):

IP: ID = 0x14E5; Proto = ICMP; Len: 60IP: Version = 4 (0x4)IP: Header Length = 20 (0x14)IP: Precedence = RoutineIP: Type of Service = Normal ServiceIP: Total Length = 60 (0x3C)IP: Identification = 5349 (0x14E5)IP: Flags Summary = 0 (0x0)IP: .......0 = Last fragment in datagramIP: ......0. = May fragment datagram if necessary

IP: Fragment Offset = 0 (0x0) bytesIP: Time to Live = 127 (0x7F)IP: Protocol = ICMP - Internet Control MessageIP: Checksum = 0x5969IP: Source Address = 10.1.1.1IP: Destination Address = 192.168.1.201IP: Data: Number of data bytes remaining = 40 (0x0028)

Raccogliendo in forma tabellare i valori esadecimali relativi all’header avremoquanto mostrato nella figura 5.12.


109

Figura 5.12: I valori esadecimali relativi all’header in forma tabellare

I valori esadecimali relativi all’header corrispondono ai campi mostrati nella figu-ra 5.13.

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


A questo punto sommiamo tutti i campi dell’header a blocchi di 16-bit a partiredal campo Version (tabella 5.18).

Tabella 5.18: Somma a blocchi di 16-bit a partire dal campo Version

45 00 + Primo blocco di 16 -bit (Version + IHL + TOS)

00 3C = Secondo blocco di 16-bit (Total Length)

45 3C + Risultato intermedio

14 E5 = Terzo blocco di 16-bit (Identification)

5A 21 + Risultato intermedio

00 00 = Quarto blocco di 16-bit (Flags + Fragment Offset)

5A 21 + Risultato intermedio

7F 01 = Quinto blocco di 16-bit (TTL + Protocol)

D9 22 + Risultato intermedio

00 00 = Sesto blocco di 16-bit (Checksum inizializzato a 0)

D9 22 + Risultato intermedio

0A 01 = Settimo blocco di 16-bit (primi due ottetti IP Source)

E3 23 + Risultato Intermedio

01 01 = Ottavo blocco di 16-bit (ultimi due ottetti IP Source)

E4 24 + Risultato intermedio

C0 A8 = Nono blocco di 16-bit (primi due ottetti IP Dest)

(1)A4 CC Essendoci un riporto si elimina la cifra più a sinistra e la si somma al risultato

A4 CD + Risultato intermedio

01 C9 = Decimo blocco di 16-bit (ultimi due ottetti IP Dest)

A6 96 Risultato finale in esadecimale

1010 0110 1001 0110 Trasformazione in binario

0101 1001 0110 1001 Complemento a uno

59 69 Riconversione in esadecimale

� Source Address (SOURCE), Destination Address (DEST)


Essendo il protocollo IP di tipo connection-less per ogni datagramma ènecessario specificare gli indirizzi IP mittente e destinatario al fine di identi-ficare univocamente le due 3-entità (ovvero: entità di livello 3 ISO/OSI) coin-volte nel processo di comunicazione (o IPC, InterProcess Communication). Incaso di utilizzo di sistemi di interconnessione ad Internet di tipo Proxy o NATi suddetti indirizzi saranno riferiti a questi ultimi e non ai nodi estremi. Lostesso vale in caso di utilizzo di meccanismi di loose o strict routing (cf.Options e Padding quindi seguito).

� Options e Padding (OPT)

• Dimensione campo = variabile a blocchi di 4 ottetti (0 ÷ 10)

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 diaggiungere informazioni addizionali anche non previste nella versione origi-naria del protocollo, da utilizzare per fini sperimentali o di test. Ciò evita disovraccaricare l’header di un datagramma con una quantità fissa di bit uti-lizzata solo raramente ed in casi particolari.

Da notare che, come specificato nella RFC 791, ciò che è opzionale non èl’implementazione di questa funzionalità a livello di software o stack TCP/IP,che deve essere obbligatoriamente prevista, ma solamente la sua inclusionee trasmissione in un datagramma IP. Inoltre, affinché si possano utilizzare leinformazioni contenute in questo campo è necessario che tutti i nodi inte-ressati prevedano il loro trattamento.

Come anticipato precedentemente, il “quanto” minimo che costituiscel’Header di un datagramma IP ha una lunghezza pari a 32-bit cioè 4 ottetti.Pertanto, l’eventuale estensione dell’header attraverso l’aggiunta delleopzioni deve essere eseguita per incrementi di 32-bit, prevedendo di inseriredei caratteri “null” (operazione chiamata anche padding-zero) per riempire i“buchi” rimanenti per ottenere “l’allineamento” a 32-bit dell’Header.

IP Options e SecurityI servizi messi a disposizione dal campo Options e Padding sono raramente utilizza-ti. Di conseguenza le relative funzionalità, in generale, possono sfuggire ad una fasedi testing e debugging accurata, lasciando spazio a potenziali buchi utilizzabili perattacchi 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 loronumero dia luogo a multipli di 4 ottetti o 32-bit mediante l’inserimento diopportuni ottetti utilizzati con funzioni di padding. Il primo ottetto è sempredi 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

L’ottetto Option-Type è strutturato in tre campi (figura 5.16).

Figura 5.16: Struttura dell’ottetto Option-Type

I tre campi assumono il significato seguente:

� Copied Flag (CF) (1 bit): è identificato dal bit più significativo (MSB), cioèquello più a sinistra, e serve per indicare ad un router o all’host sorgente sedurante il processo di frammentazione di un datagramma deve copiare ilcontenuto del campo Options su tutti i frammenti (Copied = 1) oppure sola-mente nel primo (Copied = 0). Per tale motivo esso viene anche indicato conil termine Copy on Fragmentation (CF).

� Option-Class (2-bit): è costituito dai successivi due bit e permette di identifi-care 4 classi, delle quali quelle utilizzate sono solamente quelle di ordine pari(0 e 2) come indicato nella tabella 5.19.

Tabella 5.19: Valori del campo Option-Class

Option-Class Descrizione0 00 Network Control

1 01 Riservato per usi futuri

2 10 Debugging e misurazioni

3 11 Riservato per usi futuri

� Option-Number (5-bit): questo campo è costituito da 5-bit e consente di defi-nire fino a 25 = 32 opzioni differenti per ciascuna delle classi precedenti. Nellatabella 5.20 sono indicate alcune delle classi e opzioni più utilizzate (RFC791, 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) Descrizione0 0 0 — (0) End Of Option List (EOOL)

0 0 1 — (1) No Operation

1 0 2 11 (130) US DoD Basic Security (SEC), RFC 1108

1 0 3 Variabile (131) Loose Source Route (LSR) o Loose Source e Record Route (LSRR)

1 0 5 Variabile (133) US DoD Extended Security (E-SEC), RFC 1108

0 0 7 Variabile (7) Record Route (RR)

1 0 8 4 (136) Stream ID (SID)

1 0 9 Variabile (137) Strict Source Route (SSR) o Strict Source e Record Route (SSRR)

0 2 4 Variabile (68) Internet Timestamp (TS)

Analizziamo brevemente l’utilizzo di alcuni dei tipi di Option-Type indicati nellatabella 5.20:

� End Of Option List (EOOL): valore decimale: 0; valore esadecimale: 0x00.

L’opzione EOOL è costituita da un solo ottetto nel quale tutti gli 8-bit hannovalore 0:

0 0 0 0 0 0 0 0

Viene utilizzata, come dice lo stesso nome, per indicare la fine della lista delleopzioni. Non sempre questo ottetto coincide anche con la fine dell’header IP.Infatti nel caso di un eventuale arrotondamento (o padding) a 32-bit (o 4-ottetti), e in accordo alla lunghezza specificata nel campo IHL, possono esse-re aggiunti degli ulteriori ottetti di tipo NOP (No Operation).

� No Operation (NOP): valore decimale: 1; valore esadecimale: 0x01.

L’opzione NOP è costituita da un solo ottetto nel quale tutti gli 8-bit hannovalore 0 tranne quello meno significativo (LSB) che vale 1:

0 0 0 0 0 0 0 1

Essa viene utilizzata per realizzare funzioni di padding allo scopo di allinea-re a 32-bit (o 4 ottetti) le successive opzioni.

� IP Security Option (IPSO)

Queste opzioni sono utilizzate principalmente in ambito militare (US DoD) econsentono di definire livelli di sicurezza per la classificazione dei datagram-mi, per la “compartimentalizzazione”, per la gestione delle restrizioni e l’i-dentificazione dei cosiddetti Closed User Group (CUG) e Transmission Con-trol Code (TCC).


113


Come riportato nella tabella 5.21 esistono due tipi di opzioni di sicurezza oIPSO:

• 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-bit10000010 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 ulteriorispecifiche. 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 Information8-bit 8-bit 8-bit Variabile10000101 000LLLLL AAAAAAAA TCC

Per una descrizione più approfondita sulle IPSO consultare le RFC 791 e RFC1108 ed il sito http://www.iana.org/assignments/protocol-numbers.

� Record Route (RR): valore decimale: 7; valore esadecimale: 0x07.

L’opzione RR è caratterizzata dal valore decimale 7 del campo Option-Type eha 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)8-bit 8-bit 8-bit Variabile

Essa può essere utilizzata da un host mittente per istruire ciascun routerattraversato da un datagramma contenente questa opzione, ad inserire ilproprio indirizzo IP di inoltro in uno spazio apposito (campo variabile RouteData) riservato all’interno dello stesso datagramma e identificato dal campoPointer Offset o Next Slot Pointer. L’indirizzo IP che ogni router inserirà nellalista è quello più lontano rispetto all’host mittente (farthest o outgoing oforwarding). La registrazione degli indirizzi IP da parte dei vari router attra-versati dal datagramma, deve avvenire nel rispetto dei limiti dei 40 ottetti adisposizione per la parte Options e Padding. Questo spazio viene predispostodall’host sorgente ed inizializzato a 0.


Da quanto detto finora ed osservando la struttura dell’opzione RR, si può dedur-re che:

• Essendo CF = 0 questa opzione deve essere copiata solamente sul primoframmento in caso di deframmentazione.

• Essendo: 40 = dimensione massima IP Options; 3 = overhead della opzioneRR; sarà: (40 – 3) / 4 = 9) da notare che si tratta di una divisione intera)” dopoil 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) perallineare l’header IP a 32-bit.

• Il campo Pointer contiene l’indirizzo (chiamato anche Offset o Next Slot Poin-ter) del campo IP Address nel quale ciascun router dovrà inserire il proprioindirizzo. Da notare che l’offset è riferito all’inizio della stessa opzione. Il suovalore iniziale (e comunque minimo) è pari a 4. L’aggiornamento, da parte diogni router, deve avvenire per multipli di 4. Pertanto il suo valore può esserespecificato tramite la seguente espressione:

Pointer = 4 * N, con 1 ≤ N ≤ 9.

• Nel caso in cui il valore iniziale del puntatore è inferiore a 4 viene restituitoun 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 operché il valore contenuto nel campo pointer è superiore a 9) il router inoltrail datagramma senza tracciare la successiva attività o ignorando completa-mente l’opzione (valore iniziale pointer > 9).

IP Record Route e Traceroute� Le stesse informazioni registrate utilizzando l’opzione RR sono ottenibili anche

tramite il comando traceroute.� A differenza del comando traceroute la lista prodotta da RR è limitata a 9 indi-

rizzi.� A differenza del comando traceroute che fornisce una lista asimmetrica della

rotta (ovvero: solo in una direzione), l’opzione RR consente di verificare il path dirouting in entrambe le direzioni.

Utilizzare l’opzione RR mediante il comando pingUtilizzando il comando ping è possibile configurare l’utilizzo dell’opzione RR:� Windows 9x/NT/2K/XP/2003: Ping –r NumeroHop IPDestinatariodove NumeroHop ≤ 9. Così facendo l’host mittente predispone all’interno del data-gramma un numero di slot pari a “NumeroHop” per ospitare gli indirizzi che i varirouter aggiungeranno.


115


Esempio: ping –r 5 192.168.1.199• *nix/Linux:

ping –R IPDestinatarioEsempio:

ping –R 192.168.1.200

� Source Routing (SR)

Normalmente l’inoltro dei datagrammi IP all’interno di una infrastruttura direti interconnesse è determinata dalla configurazione dei router di collega-mento (intermediate system o gateway). Infatti su ciascun router è definitauna tabella o mappa delle rotte che un datagramma deve seguire per giun-gere, nel modo più ottimale possibile, a destinazione.

Attraverso l’utilizzo delle opzioni di SR è possibile predeterminare la rotta(ovvero: Routing) che un datagramma dovrà seguire per giungere a destina-zione, direttamente alla sorgente (ovvero: Source) e ciò indipendentementedalla configurazione delle mappe di routing di ciascun router interessato dalprocesso di SR.

Queste opzioni sono utili in fase di test per verificare delle tratte alternative oper dirottare alcuni datagrammi su dei percorsi “più convenienti” (ovvero:più affidabili, meno costosi) o “fraudolenti” cioè “dirottati” forzatamente daterze persone (ovvero: hacker).

Naturalmente lo svantaggio nell’utilizzo delle opzioni di SR è la conoscenzarichiesta della topologia della rete utilizzata e la lista dei router interessati dalprocesso di inoltro o forwarding.

In particolare esistono due variazioni di SR:

• Loose Source Route (LSR) o Loose Source e Record Route (LSRR): valore de-cimale: 131; valore esadecimale: 0x83.

Nel caso di LSR l’host mittente predispone una lista di indirizzi IP di rou-ter i quali non necessariamente devono essere contigui (neighboringrouter), 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 sianoconsecutivi un router può liberamente scegliere un qualsiasi percorsoper completare la tratta (path) mancante.

Questa opzione viene indicata anche come Loose Source and RecordRoute (LSRR) in quanto consente, alla fine del processo di SR, di ricavarela traccia dei router attraversati dal datagramma come l’opzione RecordRoute.

Il formato dell’opzione 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) valoredecimale: 137; valore esadecimale: 0x89.

Nel caso di SSR l’host mittente predispone la lista esatta degli indirizzi IPdei router che devono essere attraversati dal datagramma. A differenzadell’LSR è obbligatorio che indirizzi consecutivi specificati nella listaappartengano a reti adiacenti cioè direttamente connesse (ovvero: nonpossono risiedere su due subnet separate da più di un router). Viceversa,l’inoltro del datagramma non può essere effettuato e di conseguenzaesso verrà scartato.

Questa opzione viene indicata anche come Strict Source and RecordRoute (SSRR) in quanto consente, alla fine del processo di SR, di ricavarela traccia dei router attraversati dal datagramma come l’opzione RecordRoute.

Il formato dell’opzione SSRR è mostrato nella tabella 5.25.

Tabella 5.25: Opzione Strict Source Route (SSR)


L’host dal quale viene inviato il datagramma con l’opzione LSR o SSRprepara la struttura del datagramma inizializzando il campo DestinationAddress con il primo indirizzo della lista LSR o LSR ed il campo Pointercon il valore 4.

Ciascun router interessato dal processo LSR o SSR prepara il datagram-ma da inviare inserendo come campo Destination Address l’indirizzo IPpuntato dal campo Pointer. Dopodiché registra nella lista degli indirizziLSR o SSR l’indirizzo IP dell’interfaccia verso la quale deve essere reinol-trato il datagramma nel posto indicato da Pointer. Infine viene incre-mentato di 4 unità il valore di Pointer.

Nel caso del processo LSR il campo Destination Address può contenereanche l’indirizzo IP di un router non specificato nell’elenco LSR ma pre-levato direttamente dalla tabella di routing locale dello stesso router.

Continuando in questo modo il datagramma caratterizzato dal processoLSR o SSR raggiungerà la fine del percorso quando il valore del campoPointer conterrà un valore di offset che sarà superiore alla lunghezza del-l’opzione (Option-Length) e l’host destinatario iniziale è stato raggiunto(ovvero: l’ultimo indirizzo indicato nell’header IP coincide con uno degliindirizzi locali). A questo punto, come specificato nella RFC 1122, la listaviene passata così com’è ad un protocollo di livello superiore (ULP) oapplicazione (tramite un protocollo ULP) o per costruire la rispostaall’host mittente tramite il protocollo ICMP nel caso di errore o messag-gio di reply ad un eventuale comando ping. In ogni caso la lista di SR pas-sata dal livello networking viene successivamente invertita e la rispostaverrà quindi inviata al primo indirizzo indicato nella nuova lista. Poiché


117


la lista SR può essere manipolata essa può essere costruita facendo inmodo che il primo indirizzo della lista invertita punti ad un host presele-zionato (scanned host) di una seconda rete raggiungibile tramite router ohost con doppia scheda di rete (per esempio: WinNT/2K/2003 multi-homed configurato come router).

Infine, nel caso in cui all’interno di uno stesso datagramma si trovanodue opzioni SR conflittuali secondo la RFC 1122 il comportamento dellostack può dipendere dalla particolare implementazione.

Utilizzare l’opzione RR mediante il comando pingUtilizzando il comando ping è possibile configurare l’utilizzo delle opzioni LSR eSSR:� LSR: Windows 9x/NT/2K/XP/2003: Ping –j <lista SR> <IPDestinatario>� SSR: Windows 9x/NT/2K/XP/2003: Ping –k <lista SR> <IPDestinatario>

Source Routing e potenziali risvolti sulla sicurezzaLe opzioni di SR sono spesso utilizzate unitamente alle procedure di IP spoofing (let-teralmente truffa dell’indirizzo IP) per ridirigere dei datagrammi verso un host “fan-tasma” transitando magari attraverso un host “sicuro” cioè interno alla rete. Danotare che colui che attacca il sistema può risiedere anche su una rete esterna (peresempio: Internet) rispetto all’host attaccato. Delle due tecniche quelle che risulta piùcritica dal punto di vista della sicurezza è la LSR per la quale è sufficiente inserireall’interno della lista SR l’indirizzo presso il quale si vogliono dirottare i datagram-mi, senza la necessità di conoscere l’intera topologia di routing.Per questo motivo come misura preventiva è consigliato disabilitare il meccanismodi 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 interfacciafisica di rete e “non-local source-routing” nel caso in cui avvenga attraverso unadiversa interfaccia (per esempio: sistemi multi-homed o router). In tal caso mentre ilSR locale deve essere sempre permesso per quello non-locale deve essere consentita ladisabilitazione.

Disabilitare SR su un computer WinNT/2K/XP/2003 multi-homed configuratocome routerAggiungendo la seguente chiave nei registry è possibile disabilitare il processo di SRsu 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.

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

Tabella 5.26: Opzione Timestamp

Option-Type Option-Length Pointer-Offset Overflow Flag(68 / 0x44) (4-bit) (4-bit)8-bit 8-bit 8-bit Variabile

Area Dati IP Address 1 (32-bit)Timestamp 1 (32-bit)

……

Il suo funzionamento è molto simile a quello dell’opzione RR.

Essa può essere utilizzata da un host mittente per istruire ciascun routerattraversato da un datagramma contenente questa opzione, ad inserire ilproprio indirizzo IP di inoltro ed il timestamp (ovvero: il tempo di rice-zione del datagramma espresso in millisecondi rispetto all’ora GMT(Greenwich Meridian Time, o UTC Universal Time Coordinate) e salvatoin una variabile a 32-bit) in uno spazio apposito (nei sotto campi IPAddress e Timestamp del campo variabile Area Dati) riservato all’internodello stesso datagramma e identificato dal campo Pointer Offset o NextSlot Pointer. Questo spazio viene predisposto dall’host sorgente ed ini-zializzato a 0.

La registrazione degli indirizzi IP e del timestamp da parte dei vari rou-ter attraversati dal datagramma, deve avvenire nel rispetto dei limiti dei40 ottetti a disposizione per la parte Options e Padding. Pertanto la di-mensione del campo Area Dati è data da 40 – 4 (ottetti di overhead) = 36ottetti, ovvero 9 parole da 32-bit. La lunghezza dell’opzione TS è conte-nuta nel campo Option-Length.

Il campo Pointer Offset o Next Slot Pointer è un indice, relativo all’iniziodel campo Options, che punta al primo campo libero all’interno dellasezione Area Dati. Il valore minimo che può contenere questo campo èpari a 5; esso viene inizializzato dall’host mittente ed aggiornato da ognirouter.

Il campo Overflow contiene il numero di router (fino ad un massimo di24 – 1 = 15) che non hanno potuto registrare il proprio indirizzo IP ed ilrelativo 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 sonomostrati nella tabella 5.27.


119


Tabella 5.27: Valori possibili del campo Flag dell’opzione Timestamp

Flag Descrizione0 Solo Record Timestamp in parole di 32-bit.

1 Ogni router inserisce prima l’indirizzo IP e poi (nella successiva paroladi 32-bit) il Timestamp.

2 Riservato.

3 L’indirizzo IP è pre-specificato dal mittente. Ogni router inserisce, nel campo relativo associato, il timestamp.

4 ÷ 15 Riservati.

Il valore del Timestamp può essere di due tipi:

• right-justified: espresso in millisecondi rispetto all’ora GMT (Green-wich Meridian Time) o UTC (Universal Time Coordinate) rispetto allamezzanotte, e salvato in una variabile a 32-bit.

• non-standard-time: non necessariamente espresso in millisecondi enon necessariamente aggiornato rispetto all’ora UTC. Per differen-ziarla dall’ora standard viene settato ad uno il bit di ordine superiore.

Nel caso in cui l’area dati risulta essere già piena, il datagramma vienecomunque 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 vienescartato. In entrambi i casi viene inoltrato un messaggio ICMP all’hostsorgente.

Da notare infine che essendo il valore Option-Type pari a 68 ed essendoquindi il primo bit (MSB) uguale a zero, questa opzione non necessita diessere 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 l’assegnazione degli indi-rizzi IP pubblici?

a. A

b. B

c. C

d. D

e. E

f. F

[R2]: a, b, c.

3) Quali sono i valori ammissibili per il primo ottetto per le classi comunemen-te utilizzate?

a. Classe A: 0 ÷ 127

b. Classe A: 1 ÷ 126

c. Classe B: 127 ÷ 192

d. Classe B: 128 ÷ 191

e. Classe C: 191 ÷ 223

f. Classe C: 192 ÷ 223

[R3]: b, d, f.

Da notare che anche se matematicamente gli indirizzi 0 e 127 fanno partedella classe A essi non sono indirizzi validi, bensì riservati per uso speciale: 0= “this network only” e 127 = loopback.

4) Qual è lo scopo della classe D?

a. Disporre indirizzi per host.

b. Disporre indirizzi per network.

c. Disporre indirizzi multicast.

d. Non utilizzata.

[R4]: c.

5) Identificare la classe di appartenenza dell’indirizzo IP 10.255.255.254 con lasubnet mask 255.255.255.240?

a. D

b. B

c. C

d. A

e. E

[R5]

d. La classe di un indirizzo IP non è alterata dal procedimento di subnet-ting. Pertanto, essendo il primo ottetto dell’indirizzo compreso nellafascia 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 l’assegnazione ainodi 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 utilizzabilecome indirizzo da assegnare agli host.

d, e: Ogni indirizzo IP da assegnare ad un nodo non può mai iniziare con 0in quanto esso ha il significato speciale “this network”. Più in generalené la parte <netID> né quella <hostID> possono essere costituite datutti-0.

h, i: Nessuno dei quattro ottetti di qualsiasi indirizzo IP può contenere unvalore decimale superiore a 255. Il valore massimo consentito è pari a28 –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 questaconfigurazione assume il significato di broadcast.

7) Volendo suddividere una rete di classe C in più sottoreti, qual è il numeromassimo 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 inuna subnet costituita da nS bit è dato da: nH = 2nBiS – 2. Dove il “–2” tieneconto del fatto che la parte <hostID> non può mai contenere né tutti-0né tutti-1. Pertanto il numero di bit nBiH da riservare alla parte host nonpuò essere mai inferiore a 2. Quindi 8 –2 = 6 è il massimo numero di bitche si possono prendere in prestito dalla parte <hostID> e dedicare allasezione <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 unaoperazione di AND logico.

e. Per stabilire se un indirizzo IP destinazione è situato sulla stessa retelogica del mittente oppure se appartiene ad una rete remota.

[R8]: b, d, e.

9) Quali sono i principali benefici del CIDR?

a. Consentire l’utilizzo di subnet mask ClassFull.

b. Ridurre le dimensioni delle tabelle di routing tramite l’aggregazionedelle entry (Route Aggregation).

c. Evitare il supernetting.

d. Consentire l’assegnazione di frazioni di indirizzi IP di classe C.

[R9]: b, d.

10) Qual è la lunghezza di un indirizzo IP e dei suoi componenti <netID> e<hostID>?

a. Tutte le risposte seguenti sono corrette in relazione alla classe di appar-tenenza dell’indirizzo IP.

b. 32-bit, 8-bit parte <netID>, 24-bit parte <hostID>.

c. 32-bit, 16-bit parte <netID>, 16-bit parte <hostID>.

d. 32-bit, 24-bit parte <netID>, 8-bit parte <hostID>.

[R10]: a.

11) Rifacendosi alla RFC 1918 indicare quali dei seguenti indirizzi IP sono riser-vati per uso privato?

a. 171.1.2.3

b. 172.16.1.1

c. 169.254.1.2

d. 10.20.30.40

e. 192.168.1.1

f. 192.169.0.1

g. 172.32.1.2

h. 172.15.0.1

[R11]: b, d, e.

12) È corretto l’indirizzo 192.168.0001.0376?

a. Non è un indirizzo valido in quanto non è ammesso che un ottetto siarappresentato da un numero superiore a 255.

b. Si rappresenta un indirizzo espresso in forma DON (Dotted Octal No-tation) e si riferisce all’indirizzo 192.168.1.254 espresso in forma DDN(Dotted Decimal Notation).


123


c. È un indirizzo espresso in esadecimale (Dotted Exadecimal Notation).

[R12]: b.

Appendice 5B: Esercizi1) Dato l’indirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare la

subnet di appartenenza e l’indirizzo di directed broadcast secondo la RFC950.

a. Subnet = 190.190.0.0, Broadcast = 190.190.3.255

b. Subnet = 190.190.0.0, Broadcast = 190.190.7.255

c. Subnet = 190.190.1.0, Broadcast = 190.190.3.255

d. Configurazione non possibile.

[R1]: d.

Per determinare la subnet di appartenenza dell’indirizzo IP assegnato è suf-ficiente trasformare in binario sia l’indirizzo sia la subnet mask e calcolarel’AND logico. Per semplicità è considerato solamente il terzo ottetto dellasubnet mask in quanto essendo i primi due composti da tutti-1 non alteranoil corrispondente valore dell’indirizzo IP (figura 5.17).

Parte 3

124

Figura 5.17: Trasformazione in binario dell'indirizzo IP e della subnet maskdell'esercizio 1 e determinazione della subnet di appartenenza (AND logico)

Pertanto la subnet di cui fa parte l’indirizzo è costituita da: 190.190.0.0/22. Inparticolare osservando la codifica binaria del terzo ottetto si può notare chela parte <subNetID> è costituita da nBiS = 6-bit tutti-0. Quindi in rispettodella RFC 950 questo indirizzo di subnet è da escludere.

2) Dato l’indirizzo 190.190.1.8 con la subnet mask 255.255.252.0 determinare lasubnet di appartenenza e l’indirizzo di directed broadcast secondo la RFC1812 (VLSM/CIDR).




d. Configurazione non possibile.

[R2]: a.

Rifacendosi al conteggio effettuato nell’esercizio precedente ed applicandole regole sul subnetting dettate dalla RFC 1812 ne consegue che l’indirizzo190.190.1.8/22 è “legale” ed appartiene alla subnet 190.190.0.0.


A questo punto per determinare l’indirizzo di broadcast è sufficiente calcola-re le 26 = 64 subnet identificate dalla subnet mask 255.255.252.0 ed i rispetti-vi range di indirizzi IP riservati agli host, assegnando ai 6-bit della parte<subNetID> tutti i possibili valori 0 ed 1 (tabella 5.28).

Tabella 5.28: Valori assunti dal campo <subNetID> ovvero dai 6-bit di ordine superio-re del terzo ottetto per l'indirizzo di rete dell'esercizio 2

Conversione da binario in decimale del terzo ottettoPosizione 7 6 5 4 3 2 1 0

Peso =2posizione 128 64 32 16 8 4 2 1

Valore decimale configurazioni possibili

<subNetID> <hostID>

0 0 0 0 0 0 0 0 0

4 0 0 0 0 0 1 0 0

... X X X X X X 0 0

248 1 1 1 1 1 0 0 0

252 1 1 1 1 1 1 0 0

Pertanto per la subnet identificata, l’indirizzo di directed broadcast corri-sponde a 190.190.3.255, determinato assegnando il valore 1 a tutti i bit dellaparte <hostID>. In sostanza esso corrisponde all’ultimo indirizzo IP del range<hostID> corrispondente: 190.190.0.0 ÷ 190.190.3.255.

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

b) Regola pratica per la determinazione delle subnet nell’ipotesi RFC 950Nel caso della RFC 950 vanno eliminate le subnet corrispondenti ai valori estremidell’intervallo di subnet dedotto secondo la regola a) cioè le subnet tutti-0 e tutti-1.

c) Regola pratica per la determinazione degli indirizzi directed (o subnet) broadcastDopo aver determinato l’insieme delle subnet secondo la regola a) o b), per la deter-minazione dell’indirizzo da considerare come subnet broadcast bisogna considerareper ciascuna subnet il range dei valori di indirizzi da assegnare agli host e identifi-care l’ultimo valore di ciascun range (nell’esempio 190.190.3.255).


125


Parte 3

126

Per facilitare le operazioni di subnetting conviene riferirsi alla tabella mostrata quidi seguito:

Subnet mask Passo nBiS_OS (Ottetto Subnetting)128 128 1192 64 2224 32 3240 16 4248 8 5252 4 6254 2 7255 1 8

Modalità d’uso: di solito nella maggior parte dei problemi di subnetting è assegna-ta la subnet mask o in formato decimale (per esempio: 255.255.252.0) o in formatonetwork prefix o CIDR/VLSM (per esempio: /22). Pertanto è possibile utilizzare latabella precedente per derivare gli indirizzi delle subnet, degli host e di broadcastseguendo i seguenti passi:I. Se il valore della subnet mask è espresso in formato decimale (per esempio:

255.255.252.0) identificare immediatamente la colonna corrispondente al passo,altrimenti identificare il numero di bit di subnetting nBiS dell’ottetto interessatodal subnetting (secondo, terzo o quarto). A tale proposito è necessario verificare laclasse di origine dell’indirizzo IP assegnato ed accertarsi se il numero espresso informato CIDR si riferisce al numero effettivo di bit di subnetting nBiS oppurecomplessivamente al numero di bit della netmask nBiSM:• Considerando l’esercizio 2, per esempio se la subnet mask fosse stata assegna-

ta in formato CIDR con il valore /22 allora trattandosi di un indirizzo di clas-se B si può immediatamente dedurre il numero di bit di dell’ottetto di sub-netting: nBiS_OS = nBiS = nBiSM mod 8 = 22 mod 8 = 6.

• Nel caso di un indirizzo di classe A con subnet mask /30 sarà: nBiS_OS = 30mod 8 = 6.

II. Conoscendo la subnet mask (in qualsiasi formato) identificare la colonna corri-spondente al valore del passo da utilizzare per la determinazione delle subnet(nell’esercizio precedente, 4).

III. Calcolare le subnet ed i rispettivi range di indirizzi IP da assegnare agli hostsecondo le regole a) oppure b).

IV. Identificare il range di indirizzi riservati agli host a cui appartiene l’indirizzoassegnato (nell’esercizio precedente, il range è 190.190.0.0 – 190.190.3.254).

V. Identificare l’indirizzo di broadcast per ogni subnet considerando l’ultimo indi-rizzo IP di ciascun range degli host (nell’esercizio precedente, 190.190.3.255).


d) Regola matematica per la determinazione del “passo” delle subnet nel caso in cui si conosca la subnet mask in formato decimaleConoscendo 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 passoIndicando con D la dimensione delle subnet da determinare (espressa in numero dihost), l’insieme delle subnet avrà come indirizzo iniziale (riferito all’ottetto interes-sato dal subnetting) un valore dato da:

IP Start Subnet = D * N (N = 0, 1, 2, …)

Il cui limite superiore è dato dal valore decimale dell’ultimo ottetto della subnetmask 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 64indirizzi (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 necessariaper ottenere le subnet di dimensioni 64. Cioè essendo 256 – 64 = 192 la subnet masksarà 255.255.255.192 oppure /26 in notazione CIDR.Pertanto le subnet effettive nel caso RFC 1812 saranno: 223.223.223.0/26,223.223.223.64/26, 223.223.223.128/26, 223.223.223.192/26.

3) Dato l’indirizzo 147.148.149.150 con 4-bit di subnet determinare la subnet diappartenenza.

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 subnetmask dalla notazione CIDR a quella decimale. In particolare considerandosolamente l’ottetto della subnet mask interessato dal subnetting (in questocaso il terzo) e trasformandolo in decimale si ricava quanto mostrato nellatabella 5.30.

Tabella 5.30: Deduzione del "passo" delle subnet tramite trasformazione in binario delterzo ottetto interessato dal subnetting

Conversione da binario in decimale del terzo ottettoPosizione 7 6 5 4 3 2 1 0

Peso =2posizione 128 64 32 16 8 4 2 1

nBiS = 4 1 1 1 1 0 0 0 0

Valore decimale 240

Pertanto il “passo” delle subnet prodotte dal subnetting è dato da:

passo = 256 - 240 = 16.

A questo punto le 2nBiS = 16 subnet prodotte dal subnetting saranno: 0, 16, 32,48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240. Quindi l’indirizzo147.148.149.150 sarà compreso nella subnet 147.148.144.0/20.

4) Dato l’indirizzo 212.100.200.62 con la subnet mask 255.255.255.224 determi-nare la subnet di appartenenza ed il relativo indirizzo di directed broadcast.




d. Subnet = 212.100.200.32, Broadcast = 212.100.200.63

[R4]: d.

Essendo la subnet mask espressa in forma decimale si ricava immediata-mente il “passo” delle subnet prodotte dal subnetting:

passo = 256 – 224 = 32.

Parte 3

128


Essendo nBiS = 3 [(224)10 = (111)2] le 2nBiS = 8 subnet derivate saranno: 0, 32,64, 96, 128, 160, 192, 224. Quindi l’indirizzo 212.100.200.62 sarà compresonella subnet 212.100.200.32/27 alla quale corrisponde l’indirizzo di broadca-st 212.100.200.63.

5) Dato il seguente indirizzo di subnetting 143.1.9.61/28 (12-bit di subnet)quale dei seguenti insiemi di indirizzi di host sono validi e quindi fanno partedella stessa subnet dell’indirizzo assegnato?

a. 143.1.0.1 ÷ 143.1.255.254

b. 143.1.0.1 ÷ 143.1.9.62

c. 143.1.9.48 ÷ 143.1.9.62

d. 143.1.9.49 ÷ 143.1.9.62

[R5]: d.

Da notare che l’indirizzo assegnato è di classe B. Inoltre essendo il numerodei bit di subnet (nBiS) pari a 12 ciò vuol dire che il subnetting si estende ai4-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 delquarto ottetto interessato dal subnetting

Conversione da binario in decimale del quarto ottettoPosizione 7 6 5 4 3 2 1 0

Peso =2posizione 128 64 32 16 8 4 2 1

nBiS = 8 (III Ottetto) + 4 (IV Ottetto) = 12 1 1 1 1 0 0 0 0

Valore decimale 240

A questo punto possiamo calcolare il “passo” delle subnet prodotte dal sub-netting:

passo = 256 – 240 = 16.

Pertanto le 2nBiS = 4096 subnet derivate saranno: 143.1.0.0, 143.1.0.16,143.1.0.32, ... 143.1.9.48, ..., 143.1.255.240.

Quindi l’indirizzo 143.1.9.61/28 sarà compreso nella subnet 143.1.9.48/28alla quale corrisponde l’indirizzo di broadcast 143.1.9.63. Mentre il range dihost validi per la stessa subnet sarà: 143.1.9.49 ÷ 143.1.9.62.

6) Determinare l’indirizzo IP di aggregazione (summarization) per le due reti172.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 l’indirizzo di summarization per le due subnet assegnate ènecessario convertirle in binario e calcolare il numero dei bit in comune apartire dal bit più significativo del primo byte più a sinistra (più significativo).Questo numero determina la subnet mask in formato CIDR da specificarecon l’indirizzo della prima subnet del gruppo (tabella 5.32).

Tabella 5.32: Trasformazione in binario dei due indirizzi IP e determinazione dellaparte comune a partire dal bit più significativo del primo ottetto

Subnet in Formato DDN I ottetto II ottetto III ottetto IV ottetto172.26.136.0 10101100 00011010 10001000 00000000

172.26.143.0 10101100 00011010 10001111 00000000

Pertanto l’indirizzo cercato è: 172.26.136.0/21.

7) Quante subnet e quanti host è possibile avere con il seguente indirizzo172.26.42.0/11?

a. 8 Subnet, 2.097.152 Host.

b. 8 Subnet, 2.097.150 Host.

c. 8 Subnet, 8.190 Host.

d. 2046 Subnet con RFC 950 oppure 2048 Subnet con RFC 1812, 30 Host.

[R7]: d.

In questo esercizio occorre prestare attenzione alla convenzione CIDR utiliz-zata. Infatti solitamente con essa viene specificato il numero di bit che costi-tuiscono la network mask, che ricordiamo definita da:

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

A volte, anche se raramente, con la convezione CIDR viene indicato il nume-ro nBiS di bit che costituiscono la subnet mask ovvero la sola parte<subNetID>, come in questo caso.

Pertanto i bit effettivi della network mask sono:

(numero di bit netmask classe B) + nBiS = 16 + 11 = 27.

Per cui risulta:

nS (numero Subnet) secondo RFC 950 = 211 – 2 = 2046

nS (numero Subnet) secondo RFC 1812 = 211 = 2048

nH (numero Host) = 2(32-27) – 2 = 30.

8) Si dispone del seguente indirizzo di rete di classe B 172.26.0.0/16. Volendocreare delle sottoreti ognuna delle quali può ospitare fino a 650 host, qualesubnet 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 ciascunasubnet è necessario riservare un numero minimo di nBiH bit tale per cui siasoddisfatta la seguente disequazione binaria:

nN (numero di Host) = 2nBiH – 2 ≥ 650

dalla quale si ricava: nBiH = 10.

Pertanto la quantità di bit rimanenti per la parte <subNetID> è data da:

nS = 16 – 10 = 6.

Per cui la network mask risulta essere /22 in notazione CIDR oppure255.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 internasecondo quanto indicato nella figura 5.18, nella quale:

Subnet1 (LAN1): richiede 100 indirizzi

Subnet2 (LAN2): richiede 50 indirizzi

Subnet3 (LAN3): richiede 25 indirizzi.

Nell’ipotesi di utilizzare dispositivi di networking (router) che supportanoCIDR/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 routermediante tabelle di routing statiche:


131

Figura 5.18: Esempio per l’esercizio 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 HostLAN1 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.190255.255.255.192 Subnet Broadcast: 223.223.223.191

LAN3 223.223.223.192 /27 30 223.223.223.193 ÷ 223.223.223.222255.255.255.224 Subnet Broadcast: 223.223.223.223

Uso Futuro 223.223.223.224 /27 30 223.223.223.225 ÷ 223.223.223.254255.255.255.224 Subnet Broadcast: 223.223.223.255

Supponendo di assegnare alle interfacce dei router i seguenti indirizzi IP:

• Router1I, LAN1: 223.223.223.1

• Router12, LAN1: 223.223.223.2

• Router13, LAN1: 223.223.223.3

• Router12, LAN2: 223.223.223.129

• Router13, LAN3: 223.223.223.193

e vista la semplicità dell’infrastruttura di rete, in questo caso è possibile im-postare staticamente le seguenti entry statiche, supponendo che i routersiano dei Cisco (tabella 5.34).

Tabella 5.34: Esempio di configurazione statica delle tabelle di routing dei router

Router Descrizione tabella Routing ConfigurazioneRouter1I “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“subnet3 via router13” ip route 223.223.223.192 225.225.225.224 223.223.223.3

Router13 “Internet via router1I” ip route 0.0.0.0 225.225.225.255 223.223.223.1“subnet2 via router12” ip route 223.223.223.128 225.225.225.192 223.223.223.2


E, per finire, affinché i router siano in grado di gestire gli indirizzamenti ditipo CIDR/VLSM ClassLess è necessario dare i seguenti comandi di configu-razione:

• ip classless

• ip subnet-0.

10) Un Internet Service Provider (ISP) europeo ha ottenuto dal RIPE l’indirizzoCIDR 223.223.223.0/20. Quante sono le subnet di classe C aggregate?

a. 24

b. 32

c. 256

d. 16

[R10]: d.

Il numero di subnet di classe C identificate dalla notazione CIDR assegnata èpari a:

2(20 mod 8) = 24 = 16.


133



Documents

Protocolli TCP IP