Indirizzamento IP Avanzato

Modulo 2 - Indirizzamento IP Avanzato
Introduzione
Una rete scalabile, richiede uno schema di indirizzamento che gli consenta di espandersi.
Tuttavia la crescita incontrollata dell'infrastruttura di rete può avere forti ripercussioni sulla
sua funzionalità e affidabilità. Man mano che nuovi nodi vengono aggiunti all'infrastruttura
esistente, può essere necessario riassegnare gli indirizzi esistenti. Tabelle di
instradamento eccessivamente ampie, possono rallentare il funzionamento dei router,
soprattutto di quelli più datati. Può, più semplicemente capitare che gli indirizzi disponibili
si esauriscano. Tutte questi problemi possono essere evitati pianificando e sviluppando
attentamente uno schema di indirizzamento efficiente e scalabile
Mentre in passato per l'implementazione di una rete era possibile scegliere tra differenti
protocolli e schemi di indirizzamento, oggi tutte queste tecnologie sono praticamente
scomparse per via dell'adozione universale dei protocolli non-proprietari TCP/IP che
stanno alla base del funzionamento di Internet. Ciò significa che praticamente in ogni rete
è necessario sviluppare uno schema di indirizzamento IP. Sebbene sia rarissimo, è ancora
possibile che in alcune infrastrutture di rete molto datate possano essere utilizzati
protocolli e rispettivi schemi di indirizzamento proprietari come quelli sviluppati da Novel e
Apple, anche se recentemente tali compagnie hanno deciso di adottare quelli TCP/IP
abbandonando lo sviluppo dei rispettivi protocolli proprietari.
Possiamo dunque affermare che la stragrande maggioranza delle organizzazioni utilizza

come unico protocollo di livello rete il protocollo IP.
Sfortunatamente, quando i protocolli TCP/IP furono sviluppati, i progettisti non avevano

previsto un tale successo. I protocolli TCP/IP oggigiorno sostengono l'intero traffico dati
del globo dal commercio all'intrattenimento. Fino a 10-15 anni fa il protocollo IP versione 4
(IPv4) offriva una strategia di indirizzamento che, sebbene scalabile è risultata inefficiente
con il passare del tempo e ha causato uno spreco enorme di indirizzi IP. Nelle ultime due
decadi, ricercatori e progettisti hanno apportato con successo modifiche al protocollo IPv4
cosicché potesse sopravvivere alla crescita esponenziale di Internet. Nel frattempo è stata
sviluppata una nuova versione del protcollo IP, ancora più flessibile e scalabile, IP
versione 6 o IPv6. Grazie all'ottimo lavoro di revisione fatto con IPv4, IPv6 viene
implmentato con estrema lentezza nella rete, e ancora oggi non si è in grado di stabilire
con precisione quando sostituirà definitivamente il vecchio IP, se mai succederà.
2.1 Indirizzamento IPv4

2.1.1 L'architettura degli indirizzi Internet
I protocolli TCP/IP vennero introdotti nel 1980. In particolare il protocollo IP utilizzava uno
schema di indirizzamento gerarchico a due livelli, all'epoca tale schema offriva un livello
adeguato di scalabilità. L'intera lunghezza dell'indirizzo, 32 bit, veniva divisa in due parti, la
prima identificava la rete il secondo l'host di quella rete.
L'indirizzo IP completo identifica univocamente tutti gli host collegati alla rete Internet, e
consente a questi di comunicare tra di loro. I dispositivi come i router utilizzano la porzione
dell'indirizzo IP che identifica la rete per decidere dove instradare il pacchetto e facilitare la
comunicazione tra gli host che si trovano su reti differenti.
Dal punto di vista umano è molto scomodo gestire numeri binari, proprio per questo, viene
adottata la notazione decimale puntata per rappresentare i 32 bit degli indirizzi IP.
Praticamente i 32 bit vengono divisi in quattro gruppi composti da otto bit ciascuno , tali
gruppi vengono chiamati ottetti. Ogni ottetto viene quindi rappresentato in decimale e
diviso dagli altri utilizzando un punto.
Rappresentazione in notazione decimale puntata (dotted-decimal notation)

Un indirizzo IP è un numero binario formato da 32 cifre – 32 bit
10101100000111101000000000010001
I bit possono essere raccolti in ottetti, cioè gruppi di otto bit
10101100 00011110 10000000 00010001
Ogni ottetto o byte viene convertito nel corrispettivo decimale:
172 030 128 017
I quattro numeri decimali ottenuti vengono infine separati con un punto, scritti cioè in notazione
decimale puntata:
172.30.128.17
Ma come fare a stabilire quale di questi quattro gruppi rappresenta l'indirizzo della rete e
quale l'indirizzo dell'host? Per esempio nell'indirizzo 172.30.128.17, qual'è l'indirizzo di rete
e quale quello dell'host? La risposta a questa domanda non semplice utilizzando la
rappresentazione decimale puntata.
La prima implementazione dell'indirizzamento IP, per definire ciò che doveva essere
l'indirizzo di rete e ciò che invece doveva essere l'indirizzo dell'host ,utilizzava un sistema
detto a classi. Gli indirizzi IP venivano in pratica suddivisi in cinque classi distinte, in base
al valore dei primi bit dell'indirizzo stesso. Sebbene tale sistema possa essere ancora
applicato, in generale i dispositivi di rete odierni vengono configurati in modo da non
considerare la suddivisione in classi, e utilizzare uno schema di indirizzamento senza
classi (classless).
2.1.2 Indirizzi di classe A e B

Il sistema di suddivisione in classi prevede che gli indirizzi IP vengano raggruppati in 5
differenti categorie che vengono indicate usando le prime 5 lettere maiuscole dell'alfabeto:
A B C D E
Classe A Rete (Network) Host
Ottetto 1 2 3 4
Classe B Rete (Network) Host

Ottetto 1 2 3 4
Classe C Rete (Network) Host

Ottetto 1 2 3 4
Classe D Host
Ottetto 1 2 3 4
L'appartenenza di ad una classe o a un'altra, determina in un indirizzo IP quali ottetti

formano l'indirizzo di rete e quali l'indirizzo dell'host.
Per l'indirizzamento degli host attualmente vengono utilizzati solo gli indirizzi IP
appartenenti alle prime tra classi. Gli indirizzi di classe D vengono utilizzati per
l'indirizzamento multicast, cioè gruppi di host. Gli indirizzi di classe E invece sono riservati
per la sperimentazione.
Indirizzi di classe A
Fanno parte di questa classe tutti gli indirizzi il cui primo bit del primo ottetto è 0 (zero).
Con il primo bit a 0 (zero), il primo ottetto di tali indirizzi può essere un valore compreso tra
(000)10 o (00000000)2 e (127)10 o (01111111)2. Praticamente qualsiasi indirizzo IP, il cui
primo ottetto è compreso tra (000)10 e (127)10 è un indirizzo di classe A. Gli estremi (000)10
e (127)10 sono indirizzi riservati e non possono essere utilizzati per l'indirizzamento delle
reti.
I progettisti, con gli indirizzi di Classe A intendevano servire reti estremamente grandi
formate da milioni di host, pertanto l'indicazione della rete viene fornita dal valore del
primo ottetto, i restanti tre, cioè 24 bit vengono usati per rappresentare gli host. Con 24 bit
sono possibili 224 combinazioni, cioè 16.777.216. La prima e l'ultima di queste
combinazioni (cioè tutti i 24 bit a zero e tutti i 24 bit a 1) sono riservate e non possono
essere utilizzati per l'indirizzamento. Di conseguenza ogni indirizzo di classe A supporta
fino a un massimo di16.777.214 host.
La prima combinazione cioè quella con tutti i bit dell'indirizzo host a 0 (zero) è riservata
perché con essa viene identificata la rete stessa. Ogni rete necessita di un identificativo
che rappresenti tutti gli host ad essa appartenenti; quando i bit degli indirizzi degli host
sono tutti a zero, ciò che rimane sono i bit che rappresentano la rete. Ad esempio
l'indirizzo di classe A 46.0.0.0 è un indirizzo di rete, a nessun host è permesso avere
questo indirizzo.
Per un motivo simile è riservata anche l'ultima combinazione di indirizzi host, cioè quella
con tutti i bit a 1, in questo caso infatti, tale cobinazione, rappresenta l'indirizzo di
broadcast della rete, cioè quell'indirizzo utilizzato per mandare per mandare un messaggio
a tutti gli host della rete.
Con quasi 17 milioni di indirizzi disponibili le reti di classe A, vanno ben al di la delle
richieste di indirizzamento della media delle organizzazione e società. Sebbene sia
semplice immaginare una enorme rete formata da milioni di computer, in realtà per
semplificare l'amministrazione e la gestione delle risorse, tali reti vengono generalmente
suddivise in gruppi logici, di dimensioni inferiori. Tale suddivisione è resa possibile con
l'uso della maschere di sottorete. Tutte le reti di classe A sono partizionate in sottoreti di
dimensione inferiore, se tale operazione non venisse fatta si avrebbe un enorme spreco di
risorse e inefficienza.
Considerato che le reti di classe A vengono identificare solo dal primo ottetto e il primo bit
è sempre a zero è ovvio che possono esistere un massimo di 126 reti di classe A (la rete 0
e la rete 127 sono riservate), ognuna delle quali può avere quasi 17 milioni di host. Il
numero di indirizzi IP dedicati alle reti di Classe A rappresenta circa la metà dello spazio di
indirizzamento totale possibile con indirizzi IPv4.
In pratica un numero limitato di organizzazioni controllano quasi la metà degli indirizzi

disponibili su Internet.
Indirizzi di classe B
La classe B, comprende tutti quegli indirizzi il cui primo ottetto ha i primi due bit pari a
(10)2. Con tale configurazione si ottiene che il valore più piccolo del primo ottetto di un
indirizzo di classe B è pari a (10000000)2 cioè (128)10, mentre quello massimo è
(10111111)2 cioè (191)10. Quindi qualunque indirizzo IP il cui primo ottetto è compreso tra
128 e 191 inclusi è da considerare un indirizzo di classe B.
Con gli indirizzi di classe B i progettisti di Internet pensarono di servire le società e le

organizzazioni di medie dimensioni. Pertanto per identificare le reti di classe B furono
utilizzati i primi due ottetti (16 bit), divisero quindi in parti uguali i 32 bit dell'indirizzo IP,
lasciando 16bit per identificare gli host. Con 16 bit sono possibili 2 16 combinazioni, cioè
65.536 indirizzi. Anche per la classe B vale la considerazione dei due indirizzi riservati,
pertanto ogni rete di classe B può avere fino a 65.534 host. Sebbene tale numero sia
significativamente inferiore ai 17 milioni di host possibili per reti di classe A, è ancora un
valore molto elevato, e un gruppo di 65.000 host rimane ancora difficoltoso da
amministrare e nei fatti impraticabile. Pertanto come per gli indirizzi di Classe A anche
quelli di Classe B vengono partizionati in gruppi logici utilizzando le maschere di sottorete,
per migliorare l'efficienza.
Considerato che le reti di classe B vengono identificate dai primi due ottetti, ma di questi
solo 14 contribuiscono realmente a generare il numero di reti possibili, perché ricordiamo
che i primi due sono sempre posti a (10) 2, otteniamo che possono esistere 2 14 reti di
classe B e cioè 16.384. Il numero degli indirizzi IP occupato da tutte le reti di classe B,
rappresenta circa il 25% dell'indirizzamento IPv4. total IP space. L'enorme espansione di
Internet ha causato l'esaurimento di praticamente tutti gli indirizzi di classe B. Questo
essenzialmente significa che la crescita di internet è rimasta legata esclusivamente alla
disponibilità di indirizzi IP appartenenti alla classe C.
2.1.3 Indirizzi di classe C, D ed E
indirizzi di Classe C
La classe C, comprende tutti quegli indirizzi il cui primo ottetto ha i primi tre bit pari a
(110)2. Con tale configurazione il valore più piccolo che il primo ottetto può assumere è
pari a (11000000)2 pari a (192)10, il valore più alto è invece (11011111) 2 pari a (223)10.
Pertanto tutti gli indirizzi il cui primo ottetto è compreso tra (192) 10 e (223)10 inclusi sono di
classe C.
Originariamente la classe C era stata prevista per servire tutte organizzazioni di piccole e
medie dimensioni. Dato il numero elevato di tali entità il numero di reti doveva essere
molto elevato, pertanto i progettisti hanno deciso di identificare le reti classe C utilizzando i
primi tre ottetti dell'indirizzo, lasciando l'ultimo per indirizzare gli host. Essendo 28 pari a
256, eliminando la combinazione pari a 0 e quella pari a 255, ecco che il numero di host
che possono esserci in una rete di classe C è pari a 254. Mentre la gestione efficiente di
reti di classe A e B impone il partizionamento utilizzando le maschere di sottorete, le reti di
Classe C invece impongono un limite troppo restrittivo al numero di host.
Come detto, le reti di classe C vengono rappresentate dai primi tre ottetti dell'indirizzo,
cioè 24bit, di questi, 21 contribuiscono a generare il numero di reti, poiché i primi tre sono
sempre a configurazione fissa; da questo si ricava che il numero totale di reti di classe C è
pari a 2.097.152, ognuna delle quali contiene come detto 254 host. Il numero totale di
indirizzi di classe C è pari al 12.5% dell'indirizzamento totale IP. Giacché ormai gli indirizzi
di Classe A e B sono praticamente esauriti, possono essere rilasciati esclusivamente
indirizzi di classe C.
Classe dell'indirizzo Intervallo 1° ottetto Numero di reti supportate Numero di host per
rete supportati
Classe A Da 0 a 127 128 (di cui 2 riservate) 16.777.214
Classe B Da 128 a 191 16.348 65.534
Classe C Da 192 223 2.097.152 254
Indirizzi di Classe D
Gli indirizzi di classe D hanno i primi quattro bit del primo ottetto pari a (1110) 2. Pertanto
l'intervallo di valori possibili per il primo ottetto di un indirizzo di classe D varia da
(11100000)2 pari a (224)10 fino a (11101111)10 pari a (239)10. Gli indirizzi di Classe D non
vengono utilizzati per identificare i singoli host, piuttosto ognuno degli indirizzi di questa
classe può essere utilizzato per rappresentare gruppi di host, chiamati anche gruppi
multicast.
Per esempio, un router configurato con il protocollo di instradamento dinamico EIGRP,

Enhanced Interior Gateway Routing Protocol fa parte di un gruppo che include altri nodi
che utilizzano anch'essi EIGRP. Singolarmente, ognuno dei membri di questo gruppo
riceve i messaggi diretti al proprio indirizzo IP, tuttavia si pone anche in ascolto dei
messaggi diretti verso l'indirizzo di classe D 224.0.0.10. Pertanto un messaggio indirizzato
verso 224.0.0.10 viene ricevuto da tutti i router che utilizzano il protocollo EIGRP. Quando
un singolo messaggio viene ricevuto da diversi destinatari prende il nome di multicast. Gli
indirizzi di Classe D sono anche detti indirizzi Multicast.
Un messaggio multicast è differente da un messaggio broadcast. Mentre questi ultimi

devono essere processati da tutti i dispositivi della rete, i primi sono ricevuti solo dai
dispositivi appartenenti a quel determinato gruppo che può essere formato anche da un
solo dispositivo.
Indirizzi di Classe E
Il primo ottetto degli indirizzi di Classe E ha la seguente configurazione dei primi quattro
bit (1111)2, pertanto l'intervallo di valori possibili per tale ottetto va da (11110000) 2, pari a
(240)2, fino a (11111111)2, pari a (255)2. Cli indirizzi di classe E sono riservati per
sperimentazione e non dovrebbero essere utilizzati per indirizzare gli host su Internet o i
gruppi multicast.
2.1.4 Maschere di sottorete (subnet-mask)
Il mascheramento o subnetting, viene utilizzato per partizionare una rete di grandi

dimensioni in sottoreti. Queste possono essere distribuite per tutta l'organizzazione. Tale
operazione consente di ridurre notevolmente lo spreco di indirizzi IP, e migliorare
l'organizzazione logica della rete. Il mascheramento è stato formalizzato nel 1985 in RFC
950. Praticamente il mascheramento ha introdotto un terzo livello di gerarchia nella
struttura degli indirizzi IP. Il numero di bit disponibili per l'identificazione di rete, sottorete e
host in un dato indirizzo, varia in base alla dimensione della maschera di sottorete.
La maschera di sottorete è un numero a 32 bit, che agisce come controparte dell'indirizzo

IP. Ad ogni bit della maschera corrisponde un bit dell'indirizzo IP. Applicando tra la
maschera e l'indirizzo IP l'operazione di AND logico si ottiene il valore che rappresenta la
rete. In pratica tutti i bit nell'indirizzo IP che hanno corrispondenti bit a 1 nella maschera di
sottorete, formano il numero della rete. Tutti i restanti bit dell'indirizzo IP che invece hanno
come controparte bit a 0 nella maschera rappresentano il numero dell'host.
Quando la maschera di sottorete è definita, ha la precedenza sulla classe di appartenenza

dell'indirizzo IP e quindi sulla determinazione di quale sia l'identificativo della rete e
dell'host. Questa tecnica consente ai router di gestire gli indirizzi in maniera differente da
quella imposta con l'indirizzamento a classi. Usando la maschera di sottorete si può
stabilire che la rete di un determinato host è rappresentata dai primi tre ottetti, sebbene
l'indirizzo assegnatogli sia di classe B, questa assunzione è valida all'interno
dell'organizzazione in cui la maschera è configurata.
La maschera di sottorete applicata all'indirizzo determina senza ambiguità numero di rete

e host dell'IP. Tali valori variano in base al valore della maschera; per esempio se a
all'indirizzo IP 172.24.100.45 viene applicata una maschera di 16 bit, cioè 255.255.0.0, i
primi 16 bit dell'indirizzo individuano la rete,i restanti 16 individuano l'host; nel caso
dell'esempio, la rete sarà 172.24.0.0, come viene indicato nell'immagine seguente:
Indirizzo IP 172.24.100.45
Decimale 172 24 100 45
Binario 10101100 00011000 01100100 00101101
Maschera di sottorete 255.255.0.0

Decimale 255 255 0 0
Binario 11111111 11111111 00000000 00000000
Le regole dell'indirizzamento a classi prevedono che i primi due ottetti di un indirizzo di

Classe B rappresentino la rete, pertanto la maschera di16 bit utilizzata nell'esempio, non
crea alcuna sottorete nella rete 172.24.0.0.
Per creare una sottorete su un indirizzo di classe B, è necessario utilizzare una maschera
che identifichi bit fino al terzo o quarto ottetto dell'indirizzo IP.
Supponendo di usare una maschera a 24 bit cioè 255.255.255.0, allora i primi 24 bit
dell'indirizzo IP vengono identificati come numero di rete. La rete nell'indirizzo IP utilizzato
in precedenza diventa 172.24.100.0, come indicato nell'immagine successiva:
Indirizzo IP 172.24.100.45 Sottorete

Decimale 172 24 100 45
Binario 10101100 00011000 01100100 00101101
Maschera di sottorete 255.255.0.0

Decimale 255 255 255 0
Binario 11111111 11111111 11111111 00000000
Router e host configurati con tale maschera considerano anche il terzo ottetto come
facente parte del numero della rete. Questi ulteriori bit costituiscono il campo della
sottorete, questi vengono aggiunti ai due ottetti previsti nell'indirizzamento a classi.
All'interno di una rete come la precedente, in cui i dispositivi vengono configurati con
maschera a 24 bit, gli otto bit del terzo ottetto vengono usati per stabilire a qual'è la
sottorete di appartenenza dell'host. Infine l'host stesso viene identificato utilizzando
l'ottetto finale. Da ciò si deduce che per ogni sottorete possono esistere al massimo 254
host. Gli host di una stessa rete ma di una sottorete differente possono comunicare tra di
loro solo ricorrendo all'aiuto di un dispositivo come un router.
Per indirizzi di Classe B, una maschera di sottorete di 8 bit crea potenzialmente 2 8 cioè
256 sottoreti. Poiché 8 bit rimangono per il campo host, ogni sottorete può essere popolata
con 254 host. Due indirizzi host sono riservati perchè rappresentano il numero di sottorete
e l'indirizzo di broadcast. L'amministrabilità, efficienza e scalabilità di una rete di classe B
migliorano notevolmente se si utilizza il mascheramento per suddividerla in gruppi logici di
piccole dimensioni.
Si osservi che la maschera di sottorete non viene inviata nell'intestazione del pacchetto IP.
Questo significa che nessun router al di fuori della rete conosce come il mascheramento è
stato utilizzato dentro la rete. Un router esterno continuerà a trattare un indirizzo come
172.24.100.45 come uno dei 65-mila host all'interno della rete di classe B 172.24.0.0. In
pratica la suddivisione logica effettuate con il mascheramento è completamente invisibile
al di fuori della rete.
2.2 La crisi degli indirizzi IP e le soluzioni adottate
2.2.1 La crisi degli indirizzi IP
Gli indirizzi di Classe A e B costituiscono insieme circa il 75% dello spazio di

indirizzamento totale di IPv4. Tuttavia tali indirizzi possono essere assegnati ad un gruppo
relativamente piccolo, circa 17.000, tra organizzazioni e società. Il numero di reti utilizzabili
con indirizzi di classe C è molto maggiore, tuttavia il totale degli indirizzi di classe C
costituisce solo 12.5% dei possibili 4 miliardi (232) di indirizzi IP disponibili.
Inoltre gli indirizzi di Classe C consentono un numero limitato di host, 254 per l'appunto.
Questo valore è troppo piccolo per soddisfare le esigenze di società e organizzazioni di
grandi dimensioni. Gli indirizzi di Classe A e B sono virtualmente esauriti e non possono
essere più acquistati.
Inoltre se anche fossero disponibili ulteriori indirizzi di Classe A, B e C la gestione di così

tanti indirizzi di rete, causerebbe il collasso dei router Internet che verrebbero
letteralmente schiacciati dalle enormi dimensioni delle loro tabelle di instradamento.
Infine il sistema originario di suddivisione a classi si è dimostrato poco scalabile e anche

con l'introduzione del mascheramento, non è stato in grado di gestire efficacemente
l'enorme richiesta di connettività Internet.
All'inizio del 1992, L'IETF Internet Engineering Task Force identificò due specifici problemi:
Esaurimento degli indirizzi IPv4 rimanenti. All'epoca gli indirizzi di Classe B

erano già al limite dell'esaurimento.
Rapida e sostanziale crescita della dimensione delle tabelle di instradamento

a causa dell'enorme sviluppo di Internet. Man mano che le reti di Classe C
venivano assegnate e messe on-line, l'effettiva capacità dei router di funzionare
correttamente veniva messa a dura prova dalla valanga di dati dovuti allo scambio
di informazioni di instradamento sulle nuove reti.
Per affrontare questi problemi l'IETF decise:

Nel breve periodo di modificare IPv4;
Nel lungo periodo la progettazione e lo sviluppo di un nuovo protocollo Internet.
Il nuovo protocollo, IPv6, nasce per risolvere definitivamente la crisi degli indirizzi IP grazie
ad uno spazio di indirizzamento di 128 bit. Dopo anni di progettazione e sviluppo, IPv6 è
finalmente pronto per essere implementato su larga scala. Tuttavia tale implementazione è
ancor oggi ben lungi dall'essere completata.
Una delle ragioni per cui IPv6 non è stato ancora adottato è che le modifiche a IPv4 decise
per il breve periodo, si sono rivelate così efficaci da non rendere così urgente il passaggio
al nuovo. Possiamo affermare che IPv4, eliminate le regole limitanti delle classi, è tornato
a nuova vita.
2.2.2 CIDR Classess Interdomain Routing – Instradamento interdomini senza classi
I problemi identificati da IETF

1. Esaurimento degli indirizzi IPv4;
2. Aumento della dimensione delle tabelle di instradamento;
I router utilizzano una forma di indirizzamento IPv4 chiamanta CIDR Classless

Interdomain Routing cioè instradamento inter-dominio senza classi. Che appunto elimina
l'utilizzo delle classi negli indirizzi IP.
CIDR viene pronunciato cider. In un sistema in cui viene utilizzato ancora l'indirizzamento
a classi, i router determina la classe dell'indirizzo IP, e in base a quest'informazione
stabilisce il numero di ottetti che rappresentano la rete e quelli che rappresentano l'host.
Quando invece un router utilizza il CIDR, la determinazione del numero di rete e del
numero di host avviene in base alla lunghezza della maschera di sottorete; l'utilizzo del
mascheramento consente tra l'altro di non limitare all'intero ottetto tali informazioni.
Caratteristiche del CIDR

Elimina l'indirizzamento con Classi;
Migliore efficacia nell'aggregazione delle rotte;
Super-rete
Il CIDR fu introdotto nel 1993 e formalizzato nei documenti RFC 1517, 1518, 1519 e 1520.
Fu impiegato su Internet a partire dal 1994. Questa tecnica ha migliorato enormemente la
scalabilità e l'efficienza dell'indirizzamento IPv4, consentendo di ottenere i seguenti
vantaggi:
Fortemente diminuito lo spreco di indirizzi IP – grazie all'uso di uno schema di

indirizzamento senza classi, che ha sostituito l'indirizzamento originario che
prevedeva l'uso di classi;
Gestione più efficiente dell'aggregazione delle rotte – chiamata anche con i

termini di super-rete (supernetting o summarization);
Aggregazione delle reti – consente di raggruppare differenti reti contigue

utilizzando un unico indirizzo di rete definito da una maschera di sottorete.
2.2.3 Aggregazione delle rotte e super-rete (supernetting)
Il CIDR consente ai router di aggregare o riassumere, le informazioni di instradamento.
Piuttosto che suddividere in classi gli indirizzi IP, viene utilizzata una maschera di bit, che
consente di stabilire quale porzione dell'indirizzo IP si riferisce alla rete e quale all'host.
Questo consente di ridurre la dimensione delle tabelle di instradamento. In altre parole è
possibile utilizzare un unico indirizzo IP e la rispettiva maschera per rappresentare sul
router differenti reti.
Senza il CIDR e l'aggregazione, ogni router è costretto memorizzare nella propria tabella
ognuna delle reti.
Indirizzo di Rete Primo ottetto Secondo Ottetto Terzo Ottetto Quarto Ottetto
172.024.0.0/16 10101100 00011000 00000000 00000000
172.025.0.0/16 10101100 00011001 00000000 00000000
172.026.0.0/16 10101100 00011010 00000000 00000000
172.027.0.0/16 10101100 00011011 00000000 00000000
172.028.0.0/16 10101100 00011100 00000000 00000000
172.029.0.0/16 10101100 00011101 00000000 00000000
172.030.0.0/16 10101100 00011110 00000000 00000000
172.031.0.0/16 10101100 00011111 00000000 00000000
L'immagine precedente elenca una serie di reti di Classe B. Seguendo le regole

dell'indirizzamento a classi il numero che rappresenta la rete è contenuto nei primi due
ottetti, cioè 16 bit. I router che utilizzassero un tale schema di indirizzamento, si
soffermerebbero ad analizzare i primi 16 bit e poiché il loro contenuto è univoco per
ognuna delle 8 reti, sarebbero costretti a creare nella propria tabella di instradamento una
voce per ognuna della reti.
Indirizzo di Rete Primo ottetto Secondo Ottetto Terzo Ottetto Quarto Ottetto
172.024.0.0/16 10101100 00011 000 00000000 00000000
172.025.0.0/16 10101100 00011 001 00000000 00000000
172.026.0.0/16 10101100 00011 010 00000000 00000000
172.027.0.0/16 10101100 00011 011 00000000 00000000
172.028.0.0/16 10101100 00011 100 00000000 00000000
172.029.0.0/16 10101100 00011 101 00000000 00000000
172.030.0.0/16 10101100 00011 110 00000000 00000000
172.031.0.0/16 10101100 00011 111 00000000 00000000
Come dimostra l'immagine precedente le 8 reti, pur risultando differenti al 16 bit, risultano
uguali considerando fino al 13 bit. Un router in grado di utilizzare il CIDR, può quindi
essere in grado di aggregare (o riassumere) tutte e 8 le reti in una sola utilizzando un
maschera con lunghezza pari a 13 bit. Per dimostrare quanto detto, si consideri che
ognuna delle otto reti condivide i primi 13 bit e cioé:
10101100 00011
Questi 13 bit vengono indicati spesso con il termine prefisso. Aggiungendo i 19 zeri
necessari per completare i 32 bit e utilizzando una maschera lunga 13 bit si ottiene:
10101100 00011000 00000000 00000000 = 172.024.000.000

11111111 11111000 00000000 00000000 = 255.248.000.000
Pertanto utilizzando 172.024.0.0/13 cioè un singolo indirizzo di rete e la rispettiva

maschera, siamo stati in grado di riassumete 8 reti.
Questa tecnica è consentendo di aggregare le rotte permette di contenere le dimensioni

delle tabelle di instradamento e ottenere i seguenti benefici:
Processo di instradamento più efficiente;

Minor impiego di tempo CPU per le operazioni di calcolo e di ricerca nelle tabelle di
instradamento;
Minori richieste di spazio in memoria;
L'aggregazione o supernetting è dunque una pratica che consente, utilizzando una

maschera di bit, di raggruppare differenti reti in unico indirizzo IP. I termini supernetting
(super-rete) e route aggregation (aggregazione) indicano lo stesso processo, tuttavia il
primo termine è in genere utilizzato quando si tratta di aggregare reti controllate dalla
stessa amministrazione. E' necessario inoltre evitare di confondere il processo di
supernetting con quello di subnettig, con il primo vengono utilizzati bit appartenenti alla
porzione dell'indirizzo IP che identifica la rete; con il secondo vengono invece utilizzati bit
appartenenti alla porzione di indirizzo IP che appartengono agli host. Praticamente
supernetting e aggregazione delle rotte sono l'operazione inversa del subnetting.
E' necessario ribadire che gli indirizzi di Classe A e Classe B sono ormai praticamente
esauriti, l'unica scelta per le grandi società è quella di acquistare differenti blocchi contigui
di indirizzi di Classe C e aggregarli così da essere visti come una singola grande rete o
super-rete.
2.2.4 Aggregazione e distribuzione degli indirizzi IP
Si consideri una società fittizia XYZ che necessiti di indirizzare 400 host. Utilizzando lo
schema di indirizzamento a classi si avrebbero due alternative: la prima è quella di
richiedere un'intera rete di classe B con conseguente spreco di decine di migliaia di
indirizzi. L'altra opzione è invece quella di richiedere due blocchi di indirizzi di classe C, in
questo modo sarebbe possibile indirizzare 2 x 254 = 508 host. L'aspetto negativo di
una tale scelta è che sarebbe necessario dover instradare entrambe le reti ed inoltre i
router Internet sarebbero costretti a mantenere due voci differenti nelle loro tabelle di
instradamento, piuttosto che una.
Utilizzando lo schema di indirizzamento senza classi, la società XYZ può procedere alla
richiesta di due blocchi di indirizzi di Classe C, che gli garantirebbero lo spazio di
indirizzamento sufficiente alle esigenze e aggregarli senza ulteriori sprechi. Usando il
CIDR tra l'altro la società XYZ potrebbe far richiesta dei blocchi di indirizzi direttamente
all'ISP di fiducia, senza necessariamente ricorrere ad un'autorità centrale come InterNIC
(o ICANN). L'ISP infatti potrebbe riservare gli indirizzi necessaria allla società XYZ
direttamente dal suo spazio di indirizzamento. Il fornitore stesso si assumerebbe l'aggravio
della gestione degli indirizzi. Questo sistema consente a livello di router Internet di
utilizzare un'unica rete aggregate, o supernet, del fornitore di servizi. Sarà cura del
fornitore organizzare le rotte più specifiche verso gli indirizzi dei clienti. Questo metodo
riduce drasticamente la dimensione delle tabelle di instradamento.
Numero Rete Primo Ottetto Secondo Ottetto Terzo Ottetto Quarto Ottetto
207.21.54.0 11001111 00010101 00110110 00000000
207.21.55.0 11001111 00010101 00110111 00000000
Nell'esempio la società XYZ richide all'ISP due blocchi contigui di indirizzi di Classe C,
207.21.54.0/24 e 207.21.55.0/24. Esaminando l'immagine precedente si nota,
che tali blocchi di indirizzi hanno un prefisso di 23 bit in comune:
11001111 00010101 0011011
Aggregando tali reti, con l'utilizzo di una maschera a 23 bit, si ottiene la super-rete
207.21.54.0/23, che consente di indirizzare oltre 400 host, per essere più precisi la
società XYZ ha a disposizione 2 9 – 2 = 510 indirizzi IP, senza comunque incorrere
nell'enorme spreco in caso di utilizzo di una rete di Classe B. L'ISP in questo caso funge
da autorità di registrazione di nomi e indirizzi per i suoi clienti. Le reti dei clienti inclusa
quella della società XYZ, vengono annunciate dai router Internet tramite la super-rete
dell'ISP. Nell'esempio l'ISP amministra 256 blocchi di indirizzi IP di classe C che vengono
annunciate utilizzando un prefisso di 16 bit, come: 207.21.0.0/16
Grazie al CIDR gli indirizzi IP possono essere distribuiti in maniera gerarchica e

amministrati in blocchi contigui, ottenendo i seguenti benefici:
Distribuzione efficiente degli indirizzi;

Numero di voci nelle tabelle di instradamento estremamente contenuto;
2.3 VLSM – Variable Length Subnet Mask (Maschere di sottorete a
lunghezza variabile)
2.3.1 VLSM - Maschere di sottorete a lunghezza variabile
Le maschere di sottorete a lunghezza variabile o VLSM Variable-Length Subnet Mask

consento l'utilizzo in una rete di maschere di sottorete differenti all'interno dello stesso
spazio di indirizzamento. L'implementazione delle VLSM consente di massimizzare
l'efficienza nell'assegnazione degli indirizzi, ci si riferisce spesso a questa tecnica con
l'espressione subnetting a subnet. Consideriamo ad esempio la sottorete creata
prendendo tre bit, dalla porzione host dell'indirizzo IP di Classe C 207.21.24.0.
Num. Sottorete Indirizzo di sottorete

Sottorete 0 207.21.24.000/27
Sottorete 1 207.21.24.032/27
Sottorete 2 207.21.24.064/27
Sottorete 3 207.21.24.096/27
Sottorete 4 207.21.24.128/27
Sottorete 5 207.21.24.160/27
Sottorete 6 207.21.24.192/27
Sottorete 7 207.21.24.224/27
Applicando una maschera di sottorete di 27 bit

a un indirizzo di classe C si ottengono 8 sottoreti
Se sul router viene utilizzato il comando ip subnet-zero, è possibile usate tutte e otto
le sottoreti, altrimenti usando no ip subnet-zero la sottorete 0 non sarà disponibile1.
Ogni sottorete contiene fino a 30 host e possono essere utilizzate indipendentemente l'una
dall'altra. Nell'esempio che segue non verrà utilizzata la sottorete 0 e le prime quattro
sottoreti utili verranno utilizzate per indirizzare gli host appartenenti agli uffici di una
società:
Sfortunatamente rimangono soltanto tre sottoreti disponibili per eventuali espansioni
1 Su quanto qui affermato è necessario un chiarimento. Nei moduli CCNA viene esplicitamente dichiarato
che il numero di sottoreti utilizzabili prendendo x bit dal campo host di un indirizzo IPv4 è pari a 2x - 2,
questo perché la sottorete zero e la sottorete di broadcast non possono essere utilizzate. In realtà i motivi
di tale affermazione derivavano più da problemi di ordine pratico, piuttosto che tecnico, quindi sarebbe
meglio parlare di ”sottoreti sconsigliate“ piuttosto che di “sottoreti non utilizzabili”. La maggior parte dei
router consente infatti di utilizzare, quanto meno, la sottorete di boradcast. Discorso a parte merita il
calcolo del numero di host, in questo caso il primo e l'ultimo indirizzo non sono effettivamente utilizzabili
in quanto rappresentano rispettivamente numero e indirizzo di broadcast della sottorete. Nelle domande
di certificazione Cisco, quando non esplicitamente dichiarato, la risposta corretta sul numero di sottoreti
utilizzabili, si ottiene sempre togliendo dal risultato le due sottoreti sconsigliate.
future, inoltre è necessario ancora assegnare gli indirizzi IP per i collegamenti WAN
punto-punto tra i siti rimanenti. Si potrebbe pensare di assegnare le rimanenti tre sottoreti
per indirizzare questi collegamenti WAN, ma in questo caso tutti gli indirizzi IP si
esaurirebbero, con lo spreco tra l'altro di oltre il 30% degli indirizzi. Per evitare questi tipi di
sprechi di indirizzi IP, circa 20 anni fa vennero sviluppate tre tecniche che consentono tra
l'altro di indirizzare in maniera efficiente i collegamenti WAN di tipo punto-punto:
Utilizzo della tecnica VLSM

Utilizzo di indirizzi privati (RFC 1918)
Utilizzo di IP non numerati (unnumbered)
Discuteremo indirizzi privati e IP non numerati più avanti in questo modulo. In questa
sezione affronteremo la tecnica VLSM.
Quando viene utilizzata la tecnica VLSM per l'indirizzamento di una rete è possibile creare
gruppi o sottoreti di differenti dimensioni. Le sottoreti più grandi saranno utilizzate per
indirizzare gli host delle LAN, mentre le sottoreti piccole vengono utilizzate per indirizzare i
collegamenti WAN o per altri casi particolari. Utilizzando una maschera di 30 bit è
possibile creare una sottorete contenente al massimo due host validi. Questo per
l'appunto è il numero esatto di indirizzi necessari per collegamenti WAN di tipo
punto-punto. L'immagine seguente mostra ciò che avviene quando una delle tre rimanenti
sottoreti dell'esempio precedente, viene ulteriormente partizionata utilizzando una
maschera di 30 bit:
Partizionare subnetting ulteriormente la sottorete 207.21.24.192/27 consente di

ottenere altre otto sottoreti, queste possono essere utilizzate per i collegamenti WAN
punto-punto. Per esempio la rete 207.21.24.192/30 può essere utilizzata per
indirizzare il collegamento seriale punto-punto tra il router del sito A e quello del sito B.
Di seguito i comandi necessari per configurare il router del sito A, chiamato RTA, con una
maschera di 27 bit sull'interfaccia ethernet e una di 30 bit sull'interfaccia seriale:
Riassumendo:
Le maschere di sottorete a lunghezza variabile o VLSM forniscono un meccanismo

per evitare lo spreco di indirizzi IP
Utilizzando VLSM è possibile utilizzare maschere di differente lunghezza per ogni

segmento di rete;
La lunghezza della maschera di sottorete può essere scelta in base alle esigenze di
indirizzamento del segmento di rete; per esempio un collegamento di rete
punto-punto richiede solo due indirizzi e pertanto è possibile utilizzare una
maschera a 30 bit;
2.3.2 Protocolli di Instradamento con classi e senza classi

Quando in una rete vengono utilizzate maschere a lunghezza variabile, affinché i router si
possano aggiornare correttamente gli uni con gli altri, devono includere nei messaggi che
annunciano le rotte anche la maschera di sottorete. Senza tale informazioni, per i router,
l'unico modo di ricavare da un indirizzo la porzione che rappresenta la rete e quella che
rappresenta l'host è quella di utilizzare la classe dell'indirizzo. Solo i router che ignorano le
regole dell'indirizzamento a classi e utilizzano invece le regole senza classi gestendo
correttamente i prefissi posono funzionare correttamente in una rete dove vengono
utilizzate le VLSM:
Protocolli di instradamento a Classi Protocolli di instradamento senza classi

RIPv1 Routing Information Protocol versione 1 RIPv2 Routing Information Protocol versione 2
IGRP Interior Gateway Routing Protocol EIGRP Enhanced Interior Gateway Routing Protocol
EGP Exterior Gateway Protocol OSPF Open Short Path First
BGPv3 Border Gateway Protocol versione 3 IS-IS Intermediate system to Intermediate system
BGPv4 Border Gateway Protocol versione 4
RIPv1 Routing Information Protocol e IGRP Interior Gatway Routing Protocol, sono i più
comuni protocolli di instradamento interni IGP (Interior Gateway Protocols), ma non
supportano le VLSM poiché non inviano le informazioni sulle sottoreti negli aggiornamenti.
Per determinare il prefisso di rete di un indirizzo i protocolli di instradamento a classi

usano uno dei seguenti sistemi:
Se il router riceve informazioni su una rete il cui indirizzo appartiene alla stessa rete
dell'interfaccia sulla quale l'aggiornamento è stato ricevuto, viene applicata la
maschera di sottorete che è stata configurata su tale interfaccia;
Se il router riceve informazioni si una rete il cui indirizzo non appartiene alla stessa
rete dell'interfaccia sulla quale l'aggiornamento è stato ricevuto, allora su tale
indirizzo viene applicata la maschera predefinita prevista per l'indirizzamento a
classi;
Nonostante queste limitazioni, il protocollo RIP è ancora molto utilizzato anche perché è
supportato praticamente da qualsiasi router; La popolarità del protocollo RIP deriva quindi
dalla semplicità di implementazione e configurazione e dalla sua compatibilità. La prima
versione di tale protocollo RIPv1 non è esenta da problemi:
Gli aggiornamenti inviati non comprendono le informazioni sulle maschere di

sottorete, pertanto VLSM e CIDR non sono supportati;
Gli aggiornamenti vengono inviati utilizzando indirizzi di broadcast con conseguente

aumento del traffico di rete;
Non è previsto nessun meccanismo di autenticazione;
Nel 1998 con il documento RCF 1058, venne introdotto una versione migliorata di RIP cioè
RIPv2, che consente di superare le limitazione del suo predecessore:
Gli aggiornamenti RIPv2 prevedono l'invio delle informazioni sulle maschere di

sottorete, pertanto CIDR e VLSM sono pienamente supportati;
Gli aggiornamenti RIPv2 vengono inviati verso l'indirizzo multicast di Classe D

224.0.0.9, che garantisce una migliore efficienza;
RIPv2 prevede un meccanismo di autenticazione;
Queste caratteristiche rendono RIPv2 preferibile a RIPv1, a meno che alcuni vecchi
dispositivi di rete non lo supportino;
Quando viene abilitato il protocollo RIP sui router Cisco, per impostazione predefinita,
questi sono in grado di ricevere (in gergo ascoltano) sia aggiornamenti invitati da router
che utilizzano RIPv1, sia quelli inviati da router che utilizzano RIPv2 ma inviano
esclusivamente aggiornamenti RIPv1. Per poter utilizzare i vantaggi introdotti con RIPv2, è
necessario abilitare tale protocollo esplicitamente con i seguenti comandi:
Router(config)# router rip

Router(router-config)# version 2
La semplicità nello stesso tempo la bontà del progetto RIP, gli consentirà di continuare a
sopravvivere anche in futuro; tanto è vero che una nuova versione è stata sviluppata per
supportare le caratteristiche del protocollo IPv6.
2.4 Aggregazione delle rotte (Route summarization)

2.4.1 Introduzione all'aggregazione delle rotte
CIDR e VLSM non sono stati introdotti solo per evitare lo spreco di indirizzi, ma anche per
favorire l'aggregazione delle rotte o summarization. Senza l'aggregazione delle rotte le
dorsali Internet sarebbero collassate già dal 1997.
L'immagine precedente illustra come l'aggregazione riduce il carico sui router di confine.
Questa complessa gerarchia di reti e sottoreti di dimensioni variabili, viene via via
aggregata man mano che ci si sposta verso il nodo radice, usando alla fine un prefisso,
grazie al quale tutte le reti e sottoreti sottostanti vengono annunciate come una singola
rotta aggregata, nell'esempio 192.168.48.0/20.
E' bene ricordare che l'aggregazione delle rotte è possibile esclusivamente se i router
utilizzano un protocollo di instradamento senza classi, come ad esempio OSPF o EIGRP.
Tali protocolli prevedono infatti l'invio nei messaggi di aggiornamento sia del prefisso della
rete che della rispettiva maschera utilizzata, entrambi di 32 bit. Osservando l'immagine
dell'esempio precedente, la rotta aggregata finale è rappresentata da un prefisso di 20 bit
che tutte le rotte all'interno dell'organizzazione hanno in comune, che è nel caso specifico:
192.168.48.0 in forma decimale puntata.
11000000.10101000.00110000.00000000 in binario
con la rispettiva maschera di sottorete pari a:
255.255.240.0 in forma decimale puntata.

11111111.11111111.11110000.00000000 in binario.
Tuttavia per poter aggregare correttamente le rotte è necessario che gli indirizzi IP
vengano assegnati in maniera gerarchica, in modo tale che via via che si risale fino al
nodo principale gli indirizzi aggregati condividano un maggior numero di bit più significativi
degli indirizzi.
2.4.2 Instabilità delle rotte - Route Flapping (rotte intermittenti)
Il termine route flapping viene utilizzato per descrivere quella situazione in cui l'interfaccia
di un router non raggiunge mai una situazione di stabilità, passando continuamente da
attiva (up) a disattiva (down). Trovare la causa di questo problema non è sempre facile
poiché può essere causato da diversi fattori, come un'interfaccia difettosa o un cavo non
terminato.
Utilizzando l'aggregazione, i router ai livelli più alti possono essere efficacemente isolati da
problemi di instabilità delle rotte. Osservando l'immagine precedente si consideri il router
RTC, se l'interfaccia di tale router connessa alla sottorete 200.199.56.0 per qualsiasi
motivo dovesse disattivarsi, la rotta verso tale sottorete sarebbe rimossa dalla tabella di
instradamento. Se RTC non fosse configurato per aggregare le sue rotte sull'interfaccia
verso RTZ, allora invierebbe un messaggio (triggered update) verso RTZ per comunicare
l'indisponibilità della rotta. Ogni volta che i router rilevano una variazione della topologia di
rete, sono costretti a ricalcolare le tabelle di instradamento, e soprattutto sui i router in cui
vengono utilizzati protocolli di instradamento basati su algoritmi a stato del collegamento,
come OSPF (Open Shortest Path First), il processo di ricalcolo può essere abbastanza
oneroso tanto da riperquotersi sulle prestazioni generali del router. Supponendo adesso
che l'interfaccia di RTC verso la rete 200.199.56.0, abbia qualche problema e sia molto
instabile, attivandosi e disattivandosi frequentemente. Tutti i router all'interno del dominio
amministrativo sarebbero costretti a riaggiornare frequentemente le loro tabelle con un
impatto negativo sul funzionamento delle rete.
Grazie all'aggregazione invece anche se il router RTC soffrisse di problemi di route

flapping questi resterebbero confinati all'interno del router stesso, senza essere propagati
agli altri router, infatti anche se la super-rete che 200.199.56.0/21, che RTC annuncia
a RTZ include otto sottoreti da 200.199.56.0 a 200.199.63.0, il fatto che una di
queste sia attiva o meno, non invalida la rotta verso la super-rete. Ovviamente a causa
delle instabilità delle sue sottoreti le prestazioni del router RTC potrebbero pesantemente
influenzate in negativo, ma tuttavia questo non si ripercuoterebbe su RTZ e gli altri router
di livello superiore. Quindi l'aggregazione isola efficacemente i router di livello superiore da
problemi di instabilità delle rotte.
2.5 Indirizzi privati e Traslazione degli indirizzi NAT Network

Address Translation
2.5.1 Indirizzi privati (RFC 1918)
L'utilizzo dei protocolli TCP/IP è ormai predominante nel mondo, tanto che la stragrande
maggioranza delle applicazioni di rete e dei sistemi operativi li supportano direttamente. La
diffusione di tali protocolli è così ampia che, anche se una rete non richiede un
collegamento a Internet, viene comunque progettata basandosi su essi. Mentre gli host
collegati a Internet richiedono un indirizzo IP globalmente univoco, in generale gli host
appartenenti a reti private possono utilizzare qualsiasi indirizzo IP valido, con il solo
requisito di essere unico all'interno della rete privata.
Poiché insieme a molte reti private vengono affiancate reti pubbliche, il semplice utilizzo di
un indirizzo qualsiasi è una pratica fortemente scoraggiata. Con il documento RFC 1918
sono stati riservati tre blocchi di indirizzi IP con le seguenti modalità e motivazioni:
:
Utilizzo privato o interno;
Un intervallo di indirizzi di Classe A;
Un intervallo di indirizzi di Classe B;
Un intervallo di indirizzi di Classe B;
Questi indirizzi riservati nono possono essere instradati sulle dorsali Internet. I router
Internet dovranno scartare immediatamente tali indirizzi.
Classe Intervallo di indirizzi privati RCF 1918 Prefisso CIDR

A Da 10.0.0.0 a 10.255.255.255 10.0.0.0/8
B Da 172.16.0.0 a 172.31.0.0 172.16.0.0/12
C Da 192.168.0.0 a 192.168.255.255 192.168.0.0/16
L'utilizzo degli indirizzi privati è consentitito al posto degli indirizzi pubblici, in tutti questi
casi:
Reti intranet non pubbliche;

Laboratori di sperimentazione e ricerca;
Reti domestiche;
In caso di necessità gli indirizzi pubblici globali dovranno essere richiesti dietro pagamento
di una quota, in genere annuale, da un Fornitore di servizi Internet o a un'Autorità di
Registrazione.
Gli indirizzi RCF 1918 possono essere utilizzati sia in reti casalinghe che in reti di
produzione. Nei moduli precedenti abbiamo visto come utilizzare la tecnica VLSM per non
sprecare indirizzi nei collegamenti punto-punto, partizionando ulteriormente una sottorete
usando una maschera di 30 bit. Sebbene questa soluzione è di gran lunga migliore che
sprecare ad esempio un intero blocco di indirizzi di Classe C, è necessario impiegare
comunque una sottorete esclusivamente per collegamenti WAN. Una soluzione migliore
potrebbe essere quella di utilizzare gli indirizzi privati per indirizzare i collegamenti WAN.
L'esempio in figura mostra come i collegamenti WAN di una rete sono stati indirizzati
utilizzando una sottorete 10.0.0.0/8 i cui indirizzi fanno parte dello spazio di
indirizzamento privato.
I router possono usare indirizzi privati anche se gli utenti delle LAN ai siti A, B, C hanno
accesso a internet, perchè gli host di ognuno di questi siti utilizza indirizzi globali unici, o
pubblici, presi partizionando la rete 207.21.24.0. I router da parte loro usano le
interfacce seriali con gli indirizzi privati, esclusivamente per inoltrare il traffico e scambiarsi
le informazioni sull'instradamento. Il router centrale posto al sito C e quello dell'ISP
“vedono” esclusivamente l'indirizzo IP del mittente e del destinatario. In pratica ai router
del fornitore, posti gerarchicamente a un livello superiore, non importa come i pacchetti
hanno attraversato la rete attraverso i collegamenti con gli indirizzi privati. Nei fatti diversi
ISP utilizzano gli indirizzi RFC 1918 per indirizzare i collegamenti tra i loro router a livello
core, così da evitare di utilizzare parte dei loro indirizzi globali univoci.
Esiste tuttavia un aspetto negativo nell'utilizzare indirizzi privati per i collegamenti WAN, e
cioè che le interfacce WAN dei router non possono essere sorgenti dirette del traffico
destinato su Internet, o viceversa destinatari del traffico proveniente da Internet. I router
non sono dispositivi utilizzati per navigare su Internet, tuttavia una tale limitazione può
divenire un problema quando è previsto che alcune operazioni come l'amministrazione o il
troubleshooting (ricerca ed individuazione dei problemi) possa essere effettuato anche da
Internet; per esempio tramite l'uso del comando ping (quindi messaggi ICMP Internet
Control Message Protocol) o usando strumenti che si basano sul protocollo SMTP (Simple
Network Management Protocol) o infine collegandosi in remoto tramite telnet. In questi
casi è necessario assegnare anche alle interfacce WAN indirizzi globalmente univoci.
2.5.2 Sottoreti discontinue
L'utilizzo di indirizzi privati e pubblici crea spesso sottoreti discontinue; praticamente si

tratta di sottoreti appartenenti alla stessa rete o super-rete che si trovano separati da una
rete o una sottorete completamente differente.
L'esempio in figura mostra due siti A e B; entrambe le LAN di questi siti sono indirizzate
con indirizzi pubblici appartenenti alla super-rete 207.21.24.0. Tali LAN sono
discontinue perché separate dalla rete 10.0.0.4/30 utilizzata per i collegamenti WAN. I
protocolli di instradamento a classi come, RIPv1 o IGRP, non possono essere utilizzati in
sottoreti discontinue perché non prevedono l'uso della maschera di sottorete. Supponendo
infatti di utilizzare il protocollo RIPv1, il router al sito A, riceverebbe dal router al sito B, un
aggiornamento riguardante la rete 207.21.24.0/24 e non la rete 207.21.24.32/27,
proprio per il fatto che la maschera di sottorete non viene inviata negli aggiornamenti;
poiché il sito A possiede un interfaccia direttamente collegata alla rete che gli viene
annunciata, nella fattispecie l'interfaccia e0 l'informazione ricevuta viene scartata.
Per risolvere il problema delle sottoreti discontinue l'unica via praticabile è dunque quella
di utilizzare protocolli di instradamento senza classi; tuttavia anche con alcuni di questi è
necessario effettuare delle configurazioni aggiuntive. Nella fattispecie i protocolli RIP v2 e
EIGRP senza un esplicita configurazione che lo vieti, eseguono automaticamente
l'aggregazione delle rotte, secondo quanto previsto dall'indirizzamento a classi. Nella
maggior parte dei casi questo comportamento è auspicabile, perché riduce la dimensione
delle tabelle di instradamento. Tuttavia in casi come il precedente, è necessario procedere
alla disabilitazione dell'aggregazione automatica. Per fare tale operazione è necessario
utilizzare il comando:
Router(config-router)# no auto-summary
Un'altra importante operazione da effettuare quando vengono utilizzati indirizzi IP privati in

reti collegate a Internet è quella di filtrarli in modo tale che non possano essere utilizzati su
Internet. Questa operazione si effettua bloccando tutti gli indirizzi specificati in RFC 1918
evitando che si propaghino tra Sistemi autonomi.
2.5.3 NAT Network Address Traslation (Traslazione indirizzi di rete)
Il NAT venne formalmente introdotto con il documento RFC 1631. Identifica il processo di
scambiare un indirizzo IP contenuto nell'intestazione del pacchetto con un altro indirizzo.
Praticamente il NAT viene utilizzato per consentire agli host che utilizzano indirizzi privati,
come definito da RFC 1918, di accedere a Internet.
Un dispositivo di rete in cui è stato abilitato il NAT, come un computer con UNIX o un
router Cisco, opera come dispositivo di confine di un troncone di rete o stub domain2,
come ad esempio una LAN o intranet aziendale con una singola connessione verso il
2 Il termine Stub domain identifica un dominio (o un troncone di rete), in cui tutto il traffico è generato e
destinato dai membri del dominio stesso. Inoltre il percorso che connette due membri passa solo
attraverso quel dominio.
mondo esterno. Quando un host all'interno dello stub domain vuole trasmettere verso un
host che si trova all'esterno, inoltra il pacchetto verso il dispositivo NAT, il quale attiva il
processo NAT, che controlla l'intestazione del pacchetto IP, e se necessario sostitusce
l'indirizzo IP interno (inside) con un indirizzo IP globalmente unico. Quando
successivamente l'host esterno invia una risposta, il processo NAT esegue le seguenti
operazioni:
Riceve il pacchetto;
Ricerca l'indirizzo di destinazione all'interno della tabella delle traslazioni;
Sosituisce l'indirizzo di destinazione con quello originale trovato nella tabella;
Indirizzo IP Locale Interno Indirizzo IP Globale

(Local Inside IP address) (Global IP Address)
10.4.4.5 2.2.2.3
10.4.1.1 2.2.2.2
.
La traslazione degli indirizzi NAT può avvenire dinamicamente o staticamente, e può
essere usata per svariati scopi.
Tra le caratteristiche più potenti dei dispositivi NAT, c'è la possibilità di utilizzare la
funzionalità di PAT Port Address Traslation, traslation degli indirizzi in base alla porta.
Questa consente a differenti indirizzi interni di essere associati allo stesso indirizzo
globale. Questa finzione è anche chiamata NAT molti-a-uno (many-to-one NAT). Grazie al
PAT o address overloading (letteralmente sovraccarico di indirizzi), centinai di indirizzi
privati possono accedete a Internet utilizzando un unico indirizzo globale. I router che
hanno tali finzionalità tengono traccia delle differenti comunicazioni utilizzando oltre che gli
indirizzi del mittente e del destinatario anche i numeri di porta dei protocolli TCP e UDP.
2.6 IP Unnumbered – Indirizzi IP non numerati

2.6.1 Utilizzo di IP Unnunbered
Abbiamo visto nei precedenti paragrafi differenti modi per massimizzare l'efficienza
dell'indirizzamento IP. Come ad esempio evitare di sprecare un'intera sottorete per
indirizzare i collegamenti punto-punto con l'utilizzo delle VLSM o di indirizzi privati.
Nessuna delle due tecniche tuttavia è correttamente supportata dai protocolli di
instradamento a classi come RIP v1 o IGRP. Fortunatamente il sistema operativo IOS di
Cisco, offre una terza opzione per indirizzare efficacemente i collegamenti seriali
punto-punto. Questa opzione prende il nome di IP unnumbered o IP non numerati.
Quando un'interfaccia seriale viene configurata utilizzando IP unnumbered, non necessita

di un proprio indirizzo ip. Infatti può prenderlo per così dire in ”prestito“ da un'altra
interfaccia, come quella della LAN, oppure dell'interfaccia di loopback. L'utilizzo di IP
unnumbered evita non solo lo spreco di indirizzi IP per i collegamento punto-punto, ma
può essere utilizzato insieme ai protocolli di instradamento a classi, a differenza delle
VLSM oppure delle sottoreti discontinue. Se si è obbligati ad utilizzare protocolli come
RIPv1 o IGRP, l'uso di IP unnumbered può essere l'unica soluzione per massimiffare
l'efficienza dell'indirizzamento.
Osservando l'esempio in figura, si nota come il router RTA la cui interfaccia e0 ha IP

168.71.5.1, e il router RTB la cui interfaccia e0, ha invece IP 168.71.8.1, possono
comunicare usando i protocolli TCP/IP sul collegamento seriale. Questo anche se le reti
su cui si trovano le interfacce ethernet fossero diverse. La comunicazione è possibile
perchè il collegamento seriale è di tipo punto-punto, pertanto non è può essere fatta
confusione tra il dispositivo dal quale il pacchetto si è originato e il dispositivo al quale il
pacchetto è diretto e viceversa. In questi casi il comando ip unnumbered e0 deve
essere impartito sul router in modalità configurazione interfaccia s1 sia su RTA che su
RTB. Le due regole fondamentali da tenere a mente quando si configura IP unnumbered
sono:
Le due interfacce devono essere entrambe seriali e connesse tramite un

collegamento punto-punto;
Le due interfacce LAN dei rispettivi router che condividono i loro indirizzi con le
seriali devono appartenenenre alla stessa rete principale. Quando invece si
utilizzano le maschere di sottorete predefinite in base alla classe dell'indirizzo, è
possibile assegnare alla interfacce LAN anche indirizzi appartenenti a reti differenti.
Ci sono anche degli aspetti negativi nell'utilizzo di IP unnumbered:

L'utilizzo del comando ping non è in grado di determinare se l'interfaccia è attiva
poiché l'interfaccia non ha indirizzo IP.
Non può essere eseguito il boot dell'immaggine del sistema operativo di rete IOS su
un'interfaccia unnumbered.
Le opzioni di sicurezza del protocollo IP non possono essere utilizzate su
un'interfaccia unnumbered.
2.7 Protocollo DHCP Dynamic Host Configuration Protocol ed Easy
IP
2.7.1 Introduzione al protocollo DHCP
Lo sviluppo di uno schema di indirizzamento efficiente è una parte fondamentale della

progettazione logica di una rete. Terminata tale fase si è pronti all'implementazione.
Dispositivi fondamentali per il funzionamento della rete quali routers, server, switch ecc.,
richiedono la massima attenzione. Generalmente i PC degli utenti e altri dispositivi di rete
secondari, vengono configurati in modo tale da aquisire automaticamente il proprio
indirizzo IP, usando il protocollo DHCP (Dynamic Host Configuration Protocol). Poiché i
PC utente generalmente costituisco la gran parte dei dispositivi di rete, la possibilità di
utilizzare ul protocollo DHCP semplifica il compito di amministrazione. Anche in piccoli
uffici e installazioni casalinghe, si può trarre vantaggio dalle caratteristiche del procollo
DHCP, associato magari a Easy IP, una funzionalità dell'IOS Cisco che consente di
combinare i vantaggi di DHCP con quelli del NAT.
Il procollo DHCP funziona utilizzano un server che distrbuisce ai client che ne fanno
richiesta, le informazioni di configurazione del protocollo IP. I client a loro volta utilizzano
queste informazioni per un periodo di tempo prestabilito chiamato lease time. Quando tale
periodo termina, il client deve richiedere un'altro indirizzo, generalmente comunque il
server rinnova al client l'indirizzo precedente.
Generalmente gli amministratori di rete preferiscono utilizzare un computer dedicato che
funga da server DHCP, dotato di sistema operativo come Microsoft NT Server o UNIX.
Questa soluzione è infatti notevolmente scalabile e relativamente semplice da
amministrare. Tuttavia l'IOS Cisco incorpora tutte le funzionalità di un server DHCP che
possono essere utilizzare all'occorrenza, l'impostazione predefinita per il temp di lease
degli indirizzi rilasciati da tale server è di 24 ore.
L'amministratore può configurare il server DHCP per assegnare indirizzi appartenenti ad

un determinato intervallo o pool. Il protcollo DHCP prevede, oltre il rilascio dell'indirizzo IP,
la possibilità di comunicare al client altri parametri:
Indirizzo del server o dei server DNS;

Indirizzo del server o dei server WINS;
Il nome di Dominio;
Alcuni Server DHCP hanno caratteristiche aggiuntive che consentono ad esempio di

assegnare un indirizzo IP in base all'indirizzo MAC del client,.
Il protocolo BootP fu originariamente formalizzato nel 1985 con il documento RFC 951.
Tale protocollo è il predecessore di DHCP e condivide con esso alcune caratteristiche
operazionali. Entrambi i protocolli utilizzano il protocollo UDP e le porte 67 e 68; queste
vengono spesso descritte come porte well known (riconosciute o ben note) assegnate al
protocollo BootP proprio perchè tale protocollo è il predecessore di DHCP.
2.7.2 Funzionamente del protocollo DHCP
Per poter utilizzare il servizio DHCP, e quindi ottenere automaticamente la sua

configurazione IP, un computer deve essere impostato per funzionare come client DHCP.
Il processo assegnazione dei parametri IP a un client DHCP consta di cinque fasi:
1. Generalmente durante la fase di avvio o di boot, un client che necessiti della
configurazione IP, ed è impostato per farlo, cerca di contattare almeno un server
DHCP; per eseguire tale operazione invia un messaggio di broadcast chiamato
DHCPDISCOVER.
2. Quando il server DHCP riceve il messaggio DHCPDISCOVER dal client verifica
prima di poter servire la richiesta controllando nella sua base di dati se gli indirizzi a
sua disposizione non siano già stati tutti assegnati. Nel caso in cui il server non
possa servire la richiesta, in base alla com'è configurato, può o inoltrare la richiesta
ricevuta dal client verso un'altro server DHCP o semplicemente non rispondere.
Quando invece il server è in grado di servire la richiesta, invia al client un
messaggio unicast chiamato DHCPOFFER. Questo contiene una proposta di
configurazione, e può includere l'indirizzo IP, l'indirizzo dei server DNS e la validità
della configurazione il lease time.
3. Quando il client riceve il messaggio DHCPOFFER dai server, sceglie tra tutti, quello
contenente i parametri che ritiene accettabili, nella pratica tale scelta ricade sul
primo messaggio ricevuto. A questo punto il client invia un messaggio broadcast
chiamato DHCPREQUEST. Questo ha lo scopo di richiedere ai server una
particolare configurazione, ma nei fatti, contiene le impostazioni ricevute dal server,
che il client ha ritenuto accettabili. Il fatto che il client a questo punto, piuttosto che
inviare un messaggio unicast direttamente al server DHCP scelto, invii un ulteriore
messaggio di boradcast, potrebbe sembrare strano, ma così facendo il client, non
solo conferma al server DHCP che ha scelto la sua configurazione, ma
indirettamente informa tutti gli altri, qualora c'è ne fossero, che ha rifiutato la loro
proposta.
4. A questo punto il server indicato nel messaggio DHCPOFFER, ufficializza la
configurazione inviando al client un messggio unicast chiamato DHCPACK.
Potrebbe anche essere possibile, anche se altamente improbabile, che il server
DHCP, non invii al client il messaggio DHCPACK, questo perchè nel frattempo,
potrebbe avere rilasciato la stessa configurazione ad un altro client.
5. Quando il client riceve il messaggio DHCPACK può immediatamente utilizzare la
configurazione assegnatagli.
In base alla politiche dell'organizzazione, potrebbe essere possibile, per l'utente o per
l'amministratore, assegnare staticamente a un host uno degli indirizzi IP che appartengono
all'intervallo configurato nel server DHCP. In questi casi, per evitare possibili conflitti di
indirizzi IP, la stragrande maggioranza dei server DHCP, incluso quello dell'IOS Cisco, si
asscurano, prima di inviare al client il messaggio DHCPOFFER, che l'indirizzo da rilasciare
non sia già in uso. Per farlo inviano all'indirizzo prescelto un messaggio ICMP echo
requests, cioè un ping. In particolare, il server DHCP presente nell'IOS Cisco, come
impostazione predefinita, per accertarsi che non ci siano conflitti, invia due ping, verso
l'indirizzo in questione. Ovviamente più è alto il numero di ping più si è certi che l'indirizzo
che verrà rilasciato non è in uso, ma ovviamente cosi facendo il tempo impiegato dal
processo di configurazione DHCP aumenta.
2.7.3 Configurazione del Server DHCP dell'IOS Cisco
Il processo DHCP server su tutte le versioni di Cisco IOS che lo supportano è abilitato
come impostazione predefinita. Se per qualche ragione tale processo dovesse risultare
disabilitato, può essere riabilitato usando il comando service dhcp in modalità
configurazione globale. La versione negata del comando precedente, cioè il comando
no service dhcp disabilita il processo.
Come avviene con la funzionalità di NAT, anche per quella del server DHCP è richiesto
che venga definito almeno un intervallo o pool di indirizzi IP che il server rilascerà di volta
in volta. Il comando ip dhcp pool definisce appunto tale intervallo di indirizzi:
RTA(config)# ip dhcp pool ufficio1

RTA(dhcp-config)# network 172.16.1.0 255.255.255.0
RTA(dhcp-config)# exit
RTA(config)# ip dhcp excluded address 172.16.1.1 172.16.1.10
Il primo comando ip dhcp pool ufficio1, crea un pool chiamato ufficio1, da questo
momento il router entra in modalità configurazione DCHP, specializzata appunto per
configurare i parametri DHCP. Il comando successivo network definisce l'intervallo
indirizzi che dovrà essere rilasciato ai client che ne faranno richiesta. Se per un motivo
qualunque si vogliono escludere degli indirizzi IP dall'essere assegnati dal server DHCP, è
necessario utilizzare in modalità configurazione globale il comando:
ip dhcp excluded-address
che nel caso in oggetto esclude tutti gli indirizzi da 172.16.1.1 a 172.16.1.10. Il comando
ip dhcp excluded-address può essere utilizzato ad esempio per riservare alcuni
indirizzi che dovranno essere assegnati staticamente ad alcuni host.
Un server DHCP è in grado di inviare al client anche altre informazioni oltre che l'indirizzo
IP. Il contenuto di tali configurazione deve essere specificato in modalità configurazione
DHCP:
RTA(config)# ip dhcp pool ufficio1
RTA(dhcp-config)# dns-server 172.16.1.2
RTA(dhcp-config)# net-bios-name-server 172.16.1.2
RTA(dhcp-config)# default-router 172.16.1.1
Senza un gateway predefinito i client non potranno andare molto lontano, questo
parametro viene configurato con il comando default-router. Anche gli indirizzi DNS
sono essenziali per poter navigare su Internet, vanno configurati con il comando
dns-server, quindi per i sistemi windows è possibile rialsciare automaticamente anche
un server WINS con netbios-name-server. Sono moltissimi i parametri che il server
DHCP dell'IOS è in grado di rilasciare.
Comando in modalità router(config-dhcp)#

network network-number [mask Specifica l'indirizzo della sottorete e la rispettiva
| /prefix-length] maschera del pool di indirizzi DHCP. Con il
parametro prefix-length può essere specificato
il numero di bit da comprendere nell'indirizzo del
prefisso, questo è un metodo alternativo di
specificare la maschera di sottorete; va preceduto
da uno slash (/).
default-router address [address2 ... Specifica l'indirizzo del router predefinito per il client
address8] DHCP. Dovrebbe essere specificato un solo un
indirizzo, sebbene sia possibile specificarne un
massimo di 8.
dns-server address [address2 ... Specifica l'indirizzo IP del sever DNS per il client
address8] DHCP. In genere vengono configurati due server
DNS, tuttavia è possibile specificarne un masimo di
8.
netbios-name-server address Specifica l'indirizzo IP del sever WINS NETBIOS per
[address2 ... address8] i per il client DHCP con sistemi operativi Microsoft.
Non è fondamentale configurare tale impostazione.
E' possibile specificare un masimo di 8 server
WINS.
domain-name domain Specifica il nome di dominio per il client DHCP
lease {days [hours][minutes] | Specifica il tempo di validità della configurazione,
infinite} prima che il client debba fare di nuovo richiesta
.
La tabella precedente mostra i comandi principali per la configurazione del server DHCP
dell'IOS. Tali comandi dovranno essere impartiti in modalità condfigurazione DHCP,
identificata con il prompt router(dhcp-config)#.
Comando in modalità router> Descrizione

show ip dhcp binding [address] Visualizza l'elenco di tutte le connessioni create su uno
specifico server DHCP
show ip dhcp conflict [address] Visualizza l'elenco di tutti i conflitti di indirizzi registrati da uno
specifico server DHCP.
show ip dhcp database [url] Visualizza le recenti attività sulla base di dati del DHCP (tale
comando vautilizzato in modalità privilegiata.
show ip dhcp server statistics Visualizza alcune statistiche sul sever e sui messaggi inviati e
ricevuti.
La tabella precedente mostra invece i comandi show della modalità utente per analizzare il
funzionamento del server DHCP.
2.7.4 Easy IP
Easy IP è una funzionalità del sistema operativo IOS Cisco che consente ai router di
negoziare il proprio indirizzo IP e di attivare il NAT su questo indirizzo. Le funzionalità di
easy PC generalmente vengono utilizzate in piccoli uffici o nelle abitazioni, ambianti che
vengono genraralmente indicati con la sigla SOHO Small Office, home office. Questo
perchè in tali ambienti, generalmente il collegamento a Internet avviene tramite un ISP,
che assegna dinamicamente un indirizzo IP.
Un router SOHO con Easy PC utilizza inoltre DHCP per assegnare automaticamente gli
indirizzi IP ai client locali usando indirizzi privati come specificato in RFC 1918. Quando il
router riceve sulla sua interfaccia WAN l'indirizzo IP tramite il protocollo PPP Point to
Point, viene utilizzato il NAT con overload per la traslazione degli indirizzi locali interni
verso un singolo indirizzo globale. In questo modo sia la parte WAN che quella LAN,
vengono configurate dinamicamente senza alcun tipo di internvento. Ci si riferisce alla
funzionalità Easy PC come routing plug-and-play.
2.8 Helper Address

2.8.1 Utilizzo di Helper Address
DHCP non è l'unico protocollo che utilizza messaggi di broadcast, esistono infatti altri
protocolli e servizi altrettano importanti che ne fanno uso. Per esempio i router Cisco
utilizzano messaggi broadcast per localizzare nella rete i server TFTP alcunu client li
utilizano per i servizi di sicurezza AAA come per la localizzazione dei server TACACS.
Inoltre in una rete di notevoli dimesioni, a struttura gerarchica, in alcuni casi, i client
potrebbero non essere collegati sulla stessa sottorete dei server sui quali accedono per
richiedere i servizi. Per localizzare tali server la maggioranza dei protocolli prevede l'invio
di messaggi broadcast. Tuttavia tutti i router per impostazione predefinita, non inoltrano i
messaggi di broadcast. In queste condizioni alcuni client non sono in grado ad esempio di
contattare il server DHCP per l'assegnazione dell'indirizzo. Per questa ragione in genere si
fa in modo che per ogni sottorete sia presente un server che esegua tutti i servizi
essenziali come DHCP o DNS. Tale pratica tuttavia non è sempre possibile per problemi
logistici, economici e non ultimo il problema di sovraccaricare un unico server con più
servizi. In tutti questi casi è possibile ricorrere alla funzionalità dell'IOS di Cisco chiamata
helper address.
L'implementazione di tale funzione si effettua utilizzando il comando

ip helper-address, che consente ai router di ritrasmettere le richieseste broadcast
inviate dai client, per accedere a tutti quei servizi che utilizzano il protocollo UDP User
Datagram Protocol, verso o uno specifico indirizzo IP unicast, oppure verso una specifica
rete o sottorete.
2.8.2 Configurazione di Helper Address
Prima di procedere alla configurazione vera e propria della funzionalità di helper address,
è necessario identificare le interfacce del router che ricevono i broadcast per i servizi UDP.
Fatto questo in modalità configurazione interfaccia utilizzare il comando
ip helper-address per definire gli indirizzi sui quali i messaggi UDP di broadcast
saranno rediretti.
L'impostazione predefinita di del comando ip helper-address è quella di inoltrare i

seguenti otto servizi UDP:
Servizio Porta
Time 37
TACACS 49
DNS 53
BootP / DHCP Server 67
BootP / DHCP Client 68
TFTP 69
NetBIOS name service 137
NetBIOS datagram service 138
.
Nel caso in cui si utilizzasse un servizio che non sia tra quelli nella lista precedente, l'IOS
Cisco consente di specificare la porta UDP di tale servizio in modo tale da poterne
inoltrare i messaggi di broadcast; il comando da utilizzare è ip forward-protocol da
inseriere in modalità configurazione globale. Per esempio, per poter inoltrare i broadcast
per un servizio che utilizza la porta UDP 517, utilizzare il comando:
ip forward-protocol udp 517
Questo comando può essere utilizzato non solo per aggiungere un'altra porta a quelle
specificate precedentemente in tabella, ma anche di eliminare una porta corrispondente a
quella di un servizio che magari non è utilizzato nella rete. Ad esempio se in una rete è
necessario inoltrare i broadcast per i servizi DHCP, TFTP e DNS, ma non quelli dei servizi:
Time, TACACS e NetBIOS, è necessario inserire i seguenti comandi:
RTA(config-if)# ip helper-address 192.168.1.254

RTA(config-if)# exit
RTA(config)# ip forward-protocol udp 517
RTA(config)# no ip forward-protocol udp 37
2.8.3 Esempio di utilizzo di Helper Address
Per capire meglio come funziona e come configurare la funzionalità helper-address

dell'IOS Cisco, facciamo un esempio abbastanza complesso.
L'immagine precedente raffigura una rete suddivisa in tre sottoreti. La sottorete

10.1.1.0/24 serve gli host della LAN; la sottorete 172.24.1.0/24 è dedicata alla
server farm; infine la rete 172.16.1.0/24 dove risiede un server TACAS per
l'autenticazione degli utenti. Ovviamente è necessario che gli host della LAN riescano ad
accedere ai servizi della server farm e al server TACACS. Nel caso in questione tutti
questi servizi utilizzano messaggi di broadcast su pacchetti UDP. Supponiamo che l'host
A debba utilizzare il server DHCP, il cui indirizzo IP è 172.24.1.9, per ottenere la
corretta configurazione Internet. Poiché la configurazione predefinita per il router RTA è
quella di non inoltrare i messaggi di broadcast, ne consegue che i messaggi
DHCPDISCOVER inviati dall'host A, verranno tutti scartati. E' necessario pertanto
configurare il router RTA in modo tale da aiutare l'host A.
Dall'immagine si rileva che il router RTA riceve i messaggi di broadcast sull'interfaccia e0

pertanto i comandi da imparitire sono i seguenti:
RTA(config)# interface e0
Questa semplice configurazione consente al router di inoltrare verso l'indirizzo IP del

server 172.24.1.9, i messaggi di broadcast UDP che utilizzino una delle otto porte
predefinite, provenienti dagli host della rete collegata all'interfaccia e0. Tuttavia se un
host piuttosto che il servizio DHCP, volesse accedere al servizio NetBIOS, che si trova sul
server con IP 172.24.1.5, verrebbe comunque instradato dal router verso il server DHCP.
Stessa cosa se qualche host cercasse di inviare un messaggio TFTP di broadcast, e così
via. In questo caso ciò che realmente serve, è che il router inoltri i pacchetti riguardanti i
UDP broadcast, ricevuti sull'interfaccia e0, verso la sottorete collegata all'interfaccia e3, e
cioè verso l'indirizzo di broadcast 172.24.1.255. Pertanto la configurazione corretta
diventa:
Sebbene sia possibile utilizzare più volte il comando ip helper-address specificando

di volta in volta gli indirizzi dei vari server, questo modo di procedere è alquanto
inefficiente; infatti per ogni messaggio di broadcast che il router riceve sull'interfaccia e0
dovrebbe inoltrare tanti messaggi unicast sull'interfaccia e2, per quanti sono gli indirizzi
helper-address specificati. Il sistema di specificare l'indirizzo di broadcast della rete è
sicuramente molto più efficiente.
Infine, affinché gli host della LAN, riescano ad accedere al server TACACS, che risiede su
una sottorete separata, è necessario configurare l'interfaccia e0 del router RTA
aggiungendo anche il comando: ip helper-address 172.16.1.2.
La verifica della corretta configurazione helper-address si effettua utilizzando i comandi

show ip interface.
Nell'immagine successiva si può osservare come l'interfaccia e3 del router, a cui è

connessa la server farm, non è configurata con gli helper address.
Si nota inoltre che su tale interfaccia è disabilitato l'inoltro diretto dei messaggi di
broadcast (directed broadcast forwarding is disabled), ciò significa che il router non
convertirà i messaggi di broadcast di livello 3 o broadcast logici come 172.24.1.255 in
broadcast di livello 2 come FF-FF-FF-FF-FF-FF. Affinché il router esegua tale
conversione è necessario configurarlo utilizzado il comando ip directed-broadcast.
Nell'esempio in oggetto tutti i nodi della server farm devono ricevere i broadcasts a livello
2, pertanto l'interfaccia e3 deve essere configurata per inoltrarli:
RTA(config-if)# ip directed-broadcast
2.9 IPv6 – Internet Protcol version 6

2.9.1 La soluzione all'esaurimento degli indirizzi IP
In questo modulo abbiamo parlato più volte dei due principali problemi legati
all'indirizzamento IPv4:
Esaurimento degli indirizzi, in particolare quelli di classe B;

Crescita esponenziale delle tabelle di instradamento dei router Internet;
Agli inizi del 1990, grazie all'introduzione del CIDR, instradamento senza classi, costruito
sul concetto di mascheramento, IETF è riuscita nell'intento di arginare, temporaneamente,
i due problemi citati in precedenza. La natura fortemente gerarchica del CIDR ha
consentito di migliorare enormemente la scalabilità dell'indirizzamento IPv4, provando
ancora una volta, qualora c'è ne fosse stato bisogno, che le strutture gerarchiche sono, tra
tutte, quelle più scalabili.
Le varie tecniche via via introdotte, mascheramento (subnetting) nel 1985, VLSM nel 1987
e per l'appunto il CIDR nel 1993, hanno aumentato notevolmente la longevità del
protocollo IPv4, estremizzandone la natura gerarchica. Tuttavia tutte queste tecniche non
riusciranno a salvare ancora per molto tempo IPv4 dal suo destino. La questione è
semplice, non ci sono abbastanza indirizzi IPv4 per rispondere alle esigenze future. IPv4
consta di oltre 4 miliardi di indirizzi, che tuttavia non sono sufficienti nel mondo
globalizzato di domani, in cui miliardi di persone, dispositivi e apparati di vario genere,
avranno accesso Internet.
Oltre quelle già citate, sono state introdotte altre soluzioni a breve termine, per affrontare il
problema dell'esaurimento degli indirizzi IPv4. Queste includono l'utilizzo di indirizzi privati
RFC1918, e il NAT, che consente a centinaia di host di accedere a internet utilizzando un
numero limitato di indirizzi IP.
Tuttavia la soluzione definitiva al problema è sicuramente la sostituzione di IPv4 con IPv6
che, con il suo spazio di indirizzamento a 128 bit 3, potrà sicuramente far fronte a qualsiasi
richiesta di indirizzi. IPv6 comunque non differisce da IPv4 solo per il numero più elevato
di indirizzi, ma anche per altre caratteristiche, tra le quali una struttura gerarchica su tre
livelli.
Nel 1994, L'IETF Internet Engineering Task Force propose formalmente IPv6 in RFC
1752; in risposta a tale proposta vennero formati dei gruppi di lavoro. Il protocollo IPv6 è
stato sviluppato per risolvere i seguenti problemi:
Esaurimento degli indirizzi;

Qualità del servizio;
Auto-configurazione degli indirizzi;
Autenticazione;
Sicurezza;
Non è semplice per un'organizzazione che ha fortemente investito in un'infrastruttura di

rete basata su IPv4 migrare verso un'architettura totalmente nuova. Finché IPv4, grazie al
CIDR e alle altre tecniche introdotte per migliorarne la scalabilità, rimarrà un'alternativa
praticabile, nessun amministratore di rete penserà mai di passare a IPv6. Una tale scelta
comporterebbe tra l'altro la necessità di: nuovo software, nuovo hardware e nuovi metodi
di amministrazione. E' quindi altamente probabile che i protocolli IPv4 e IPv6
coesisteranno, soprattutto all'interno dei sistemi autonomi, per molti anni a venire. Il 20
luglio 2004 l'ICANN ha annunciato che i server DNS primari, sono stati modificati per
supportare sia il protocollo IPv6 che IPv4. Si pensa che il protocollo IPv4 verrà utilizzato
fino al 2025 circa, per dare il tempo necessario a correggere gli eventuali errori in IPv6.
2.9.2 Tipi di Indrizzi IPv6
Come definito nel documento RFC 1884 successivamente revisionato da RFC 2373 4, la
dimensione degli indirizzi o identificatori IPv6 è fissata a 128 bit, per interfacce ed insiemi
di interfacce, non per i nodi5.Vengono definiti tre tipi generali di indirizzi:
3 E' utile osservare che i 128 bit di IPv6 garantiscono 2 128 indirizzi un numero pari a
340.282.366.920.938.463.463.374.607.431.768.211.456 circa 340 trilioni di biliardi. Invece i 32 bit di
IPv4, garantiscono 232 indirizzi e cioè 4.294.967.296 circa di 4 miliardi.
4 Al momento della stesura RFC 2373 è stato reso obsoleto da RCF 3513, che a sua volta è stato reso
obsoleto da RFC 4291. Nel caso particolare dei tipo di indirizzi IPv6, tali documenti non introducono nulla
di nuovo.
5 Con il termine nodo vengono identificati tutti quei dispositivi che tramite interfacce sono collegati alla rete
Unicast – un identificatore assegnato a una singola interfaccia. Un pacchetto
inviato verso un indirizzo unicast, viene consegnato all'interfaccia identificata con
quell'indirizzo. Gli indirizzi IPv6 unicast sono aggregabili utilizzando un prefisso di
dimensione albitraria; in maniera del tutto simile agli indirizzi IPv4 quando associati
al CIDR Classless Inter-Domain Routing. Sono stati definiti diversi tipi di indirizzi
unicast, in particolare:
Indirizzi unicast globali (Global Unicast);

Indirizzi locali al sito (Site-Local)6
Indirizzi unicast locali al collegamento (Link-Local Unicast)
Sono inoltre stati introdotti, per essere utilizzati in casi particolari, alcuni sottotipi di
indirizzi unicast globali (Global Unicast), come ad esempio gli Indirizzi IPv6
contenenti indirizzi IPv4 (IPv6 Addresses with Embedded IPv4 Addresses). E'
possibile che in futuro vengano aggiunti altri tipi o sottotipi di indirizzi.
Anycast – un identificatore assegnato a un gruppo di interfacce, tipicamente

appartenenti a nodi differenti. Un pacchetto inviato verso un indirizzo anycast, viene
consegnato alla più vicina, o la prima, interfaccia del gruppo anycast.
l'indirizzamento anycast, consente ad esempio a un computer in rete di raggiungere
automaticamente il più vicino server disponibile per un certo servizio (come DNS)
anche senza conoscerne a priori l'indirizzo;
Multicast – un identificatore per un insieme di interfacce, tipicamente appartenenti

a nodi differenti. Un pacchetto inviato verso un indirizzo multicast viene ricevuto da
tutte le interfacce appartenenti al gruppo multicast.
Tra quelli citati in precedenza, si nota l'assenza di indirizzi di broadcast; questo perché in
IPv6, la funzione svolta da tali indirizzi è stato sostituita dagli indirizzi multicast.
2.9.3 Rappresentazione di un indirizzo IPv6
A causa del numero eccessivo di cifre che servirebbero per rappresentare un l'indirizzo
IPv6, la notazione decimale puntata è stata abbandonata in favore della notazione
esadecimale. Gli indirizzi IPv6, vengono scritti utilizzando 32 cifre esadecimali, disposte in
otto gruppi di quattro cifre; ogni gruppo è separato dal simbolo di due punti (:).
Rappresentazione degli indirizzi IPv6

Il seguente è un indirizzo IPv6 valido: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344. Se uno dei
gruppi è composto da una sequenza di 4 zeri, come il seguente:
2001:0db8:85a3:0000:1319:8a2e:0370:7344
I 4 zeri possono essere rappresentati da un solo zero: 2001:0db8:85a3:0:1319:8a2e:0370:7344.

Soprattutto nelle prime fasi di implementazione, gli indirizzi IPv6 potranno essere formati da lunghe
sequenze di zeri consecutivi; ad esempio l'indirizzo: 1080:0000:0000:0000:0008:0800:200C:417A
può essere ridotto in: 1080:0:0:0:0008:0800:200C:417A. Quindi gli zeri iniziali di ogni gruppo
possono essere eliminati: 1080:0:0:0:8:800:200C:417A. Infine, un gruppo contiguo, ed uno solo,
formato da soli zeri può essere rappresentato da una sequenza di (::): 1080::8:800:200C:417A.
Questa forma non è soggetta ad ambiguità; nell'indirizo precedente è chiaro che mancano 3 gruppi di zeri.
Tuttavia la seguente forma non è valida: 2001::25de::cade. Poiché non è possibile stabilire da quante
sequenze è composta ogni singola lacuna. Esistono anche altre due notazioni speciali ibride, che
Internet, ogni nodo può possedere più interfacce.

6 Sebbene ancora citati in RFC 2373, tali indirizzi sono stati deprecati.
Rappresentazione degli indirizzi IPv6
consentono di rappresentare indirizzi IPv6 che contengono indirizzi IPv4:
::ffff:192.168.0.200 notazione IPv4 Mapped Address;

::192.168.0.200 notazione IPv4 Compatible Address;
2.9.4 Rappresentazione dell'indirizzo di rete o sottorete IPv6
Come gli indirizzi IPv4, anche quelli IPv6 vengono scritti utilizzando la notazione CIDR,
cioè priva di classi. Una rete o sottorete IPv6 è corrisponde ad un gruppo contiguo di
indirizzi IPv6; il numero di elementi di tale gruppo deve essere una potenza del 2. I bit
iniziali degli indirizzi del gruppo di indrizzi IPv6, che sono identici per ogni interfaccia
presente nella rete o sottorete, prende il nome di prefisso. La rete o sottorete, viene quindi
identificata dal prefisso e dalla sua lunghezza (in decimale), separati dal simbolo di barra
(/). Per esempio, 2001:0db8:1234::/48 identifica una rete contenente gli indirizzi
da: 2001:0db8:1234:0000:0000:0000:0000:0000
a: 2001:0db8:1234:FFFF:FFFF:FFFF:FFFF:FFFF
poiché una singola interfaccia può essere vista come una rete con prefisso di lunghezza
pari a 128 bit, quindi non sono rare le notazioni che vendono l'indirizzo di un'interfaccia
seguito da /128.
2.9.5 Scopo e ambito di validità degli indirizzi IPv6
Come avviene per IPv4, anche con IPv6 alcuni indirizzi sono stati destinati per usi
particolari. L'ambito di validità di un indirizzo IPv6 può spaziare dai seguenti livelli:
Validità a livello del Nodo (Node-Local scope): questi indirizzi sono validi
esclusivamente sul nodo (PC, server e altri dispositivi di rete) a cui è applicato;
Validità a livello di collegamento (Link-Local Scope): questi indirizzi sono validi
all'interno di un segmento di rete a cui sono applicati, un esempio può essere quello
di un dominio di broadcast nel caso di reti ethernet;
Validità a livello di sito (Site-local scope): gli indirizzi in questo caso sono validi
all'interno di un sito di un'organizzazione, per esempio la LAN della filiale di una
società;
Validità a livello dell'organizzazione (Organization-Local scope): l'ambito in
questo caso si estende per tutte le sedi dell'organizzazione;
Validità Globale (Global scope): l'indirizzo è valido a livello globale, cioè tutta la
rete internet;
2.9.6 Allocazione dello spazio di indirizzamento IPv6
Dopo aver trattato per anni con il numero sempre più esiguo di indirizzi IPv4 rimanenti, gli
ingegneri di IETF, grazie a IPv6 avevano finalmente uno spazio di indirizzamento a dir
poco illimitato da poter gestire.
Tuttavia amministrare un numero così enorme di indirizzi richiedeva un'attenta

pianificazione. Oltre al fatto che è impensabile poter rendere direttamente disponibili tutti
gli indirizzi IPv6, è necessario implementare un sistema consenta ai router di poter
instradare i pacchetti utilizzando il numero minore di bit dell'indirizzo stesso. Quindi, come
nel caso di IPv4, la scelta principale era quella di stabilire come organizzare l'indirizzo per
consentire sia l'identificazione degli host che l'instradamento. La decisione fu quella di
identificare ogni indirizzo IPv6 da una sequenza di bit all'inizio dell'indirizzo stesso, tale
sequenza è chiamata FP prefisso di formattazione (format prefix), che venne introdotta
con RFC 2373.
E' ironico che i creatori di IPv6 abbiano deciso di utilizzare un tale sistema, nonostante il
fatto che fu proprio una tale scelta a causare il precoce esaurimento degli IPv4 . Utilizzare
un prefisso da 3 a 10 bit, che consenta di identificare gli indirizzi IPv6, è concettualmente
identico a quello di usare i bit dall'1 al 4, per distinguere le classi in IPv4.
Successivamente alla pubblicazione di RFC 2373, nacquero molte discussioni in merito al

metodo di classificazione adottato per IPv6. E, se è vero che per i motivi sopra esposti,
non si può prescindere da una suddivisione degli indirizzi, è anche vero che l'uso del
prefisso di formattazione era in tutto e per tutto equivalente al vecchio sistema a classi di
IPv4.
Da RFC 3513 e successive, fino a RFC 4291, furono introdotte alcune modifiche,
soprattutto nella terminologia utilizzata, e in particolare venne eliminato il termine “format
prefix”. Questo, sebbene ancora oggi, il sistema di allocazione dell'indirizzamento IPv6, si
basi sulla particolare configurazione dei bit iniziali, è stato uno stimolo per tenerlo in
considerazione il meno possibile. La tabella seguente mostra, in base all'RFC 4291,
l'ultimo al momento della compilazione del presente, come IETF ha strutturato lo spazio di
indirizzamento IPv6:
Tipo di indirizzo Prefisso in binario Notazione IPv6

Non specificato 00...0 (128 bit) ::/128
Tipo di indirizzo Prefisso in binario Notazione IPv6
Loopback 00...1 (128 bit) ::1/128
Multicast 11111111 FF00::/8
Unicast per Collegamento-Locale (Link-Local unicast) 1111111010 FE80::/10
Unicast globali (Global Unicast) Tutto i restanti ----
Tuttavia degli indirizzi Unicast globali (Global Unicast), che sono quelli effettivamente utili
per l'indirizzamento, IETF ne ha resi effettivamente disponibili a IANA 7 circa il 30% e cioè
quelli del blocco 2000::/3. Nella tabella seguente, che mostra com'è attualmente
organizzato lo spazio di indirizzamento IPv6, si può notare come il 70% degli indirizzi non
è ancora stato reso disponibile:
Prefisso Allocazione Note

Sebbene tale blocco contenga fisicamente i seguenti
indirizzi IPv6:
“indirizzo non specificato” (unspecified address);

0000::/8 Riservato IETF “Indrizzo di loopbak” ("loopback address")
Indrizzi IPv6 contenenti indirizzi IPv4 (Addresses
with Embedded IPv4 Addresses)
questi sono da considerarsi concettualmente al di fuori.
0100::/8 Tale blocco era stato precedentemente definito come OSI

Riservato IETF
NSAP-mapped. Tale definizione è ora deprecata.
0200::/7 Riservato IETF
2000::/3 Questo è blocco di indirizzi unicast attualmente registrati da

Unicast Globali (Global Unicast)
IANA per l'indirizzamento
A000::/3 Riservato IETF
C000::/3 Riservato IETF
E000::/4 Riservato IETF
F000::/5 Riservato IETF
F800::/6 Riservato IETF
FC00::/7 Unique Local Unicast
FE00::/9 Riservato IETF
FE80::/10 Link Local Unicast
Questo blocco inizialmente era stato riservato per gli
FEC0::/10 Riservato IETF indirizzi di tipo locali al sito “Site-Local”. Tale definizione è
ora deprecata.
FF00::/8 Multicast
7 IANA Internet Assigned Numbers Authority, è l'autorità formalmente delegata in RFC1881 del dicembre
1995 per l'amministrazione e il rilascio degli indirizzi IPv6.
2.9.7 Gli indirizzi Unicast Globali (Global Unicast Addresses)
Secondo gli attuali piani di sviluppo, i nodi IPv6 che si connetteranno a Internet useranno
gli indirizzi unicast globali aggregabili aggregatable global unicast address. Il termine è
simile a quello della controparte IPv4, per definire l'aggregazione quando viene utilizzato il
CIDR. E come nella controparte gli indirizzi globali si basano su un sistema gerarchico per
mantenere le tabelle di instradamento dei router su dimensioni accettabili. In particolare la
struttura generale degli indirizzi globali unicast IPv6 è suddivisa su tre livelli di gerarchia:
Prefisso di instradamento globale (global routing prefix): E' il livello più alto della
gerarchia di un indirizzo IPv6 (in origine chiamata Topologia pubblica - Public
topology), in genere viene assegnato da IANA o dalle autorità locali (come ICANN
ecc.) direttamente ai fornitori di servizi Internet, cioè gli ISP. Viene utilizzato per
l'instradamento sulle dorsali pubbliche Internet. Può a sua volta essere strutturato
aggiungendo altri livelli di gerarchia;
L'identificativo di sottorete (subnet ID): è il livello intermedio della gerarchia di un
indirizzo IPv6 (in origine chiamato Topologia Locale - Site topology), cioè il livello
assegnato localmente a un'organizzazione. Il suo utilizzo è limitato
all'instradamento interno all'organizzazione a cui è stato assegnato, non fornisce
connettività a nodi esterni;
l'identificativo dell'interfaccia (Interface ID) viene utilizzato per identificare

l'interfaccia sul collegamento, all'interno della sottorete deve essere unico 8. Anche
se è possibile che sia univoco in un ambito più ampio.
2.9.8 L'identificativo d'interfaccia (Interface ID)
Questo campo dell'indirizzo IPv6 può essere paragonato alla porzione host degli indirizzi
IPv4. Tuttavia grazie alle dimensioni maggiori, è stato possibile ampliare le modalità di
applicazione. In particolare, è possibile, in alcuni casi, derivare l'identificativo
dell'interfaccia (Interface ID) direttamente dall'indirizzo di livello collegamento (data-link),
quindi dall'indirizzo MAC, della scheda di rete. In pratica un host può essere in grado di
auto determinare il proprio indirizzo IPv6, con la certezza di essere globalmente univoco.
Prima di poter implementare tali meccanismi era necessario risolvere i seguenti problemi:
Alcuni indirizzi unicast IPv6 erano già comunemente utilizzati per varie applicazioni,
era quindi necessario strutturare l'identificativo dell'interfaccia (Interface ID) senza
dover riassegnare i vecchi indirizzi;
Esistono due formati per rappresentare gli indirizzi MAC delle schede rete, il
classico IEEE 802 o EUI-48, che ha una lunghezza di 48 bit, e il nuovo IEEE
EUI-64 che invece ha una lunghezza di 64 bit;
Per superare questi inconvenienti, IETF ha deciso che tutti gli indirizzi unicast globali
(Global Unicast), devono avere l'identificativo d'interfaccia (Interface ID) costituito da 64
bit, e deve essere calcolato utilizzando il formato EUI-64 modificato. Il nuovo formato
8 Come vedremo, un eccezione a questa regola è costituita dagli indirizzi anycast.
diventa quindi: nm=64  128=nm64
poiché come detto in precedenza alcuni indirizzi IPv6, come gli IPv6 contenenti indirizzi
IPv4 (IPv6 Addresses with Embedded IPv4), erano già stati utilizzati, questa
configurazione diviene non obbligatoria negli indirizzi unicast globali (Global Unicast) i cui
tre bit più significativi sono impostati a 000,
2.9.9 Identificatori di interfaccia basati su indirizzi EUI-64 Modificati
Come abbiamo visto nel precedente paragrafo, l'identificatore d'interfaccia di un indirizzo

IPv6 deve essere di 64 bit e basato sul formato EUI-64 modificato. In pratica tale formato
è ottenuto a partire da quello EUI-64. E' anche possibile passare dal vecchio formato
EUI-48 a EUI-64.
EUI-48 (o IEEE 802) e EUI-64, come anticipato in precedenza sono due standard introdotti
da IEEE per rappresentare gli indirizzi fisici delle schede di rete:
IEEE 802 o EUI-48
Sono gli identificatori di interfaccia tradizionali delle schede di rete: un indirizzo a 48

bit denominato anche indirizzo fisico o indirizzo MAC (Media Access Control). E'
composto da due campi, l'identificativo del produttore di 24 bit, assegnato a livello
globale a ogni azienda, e da un'estensione di 24 bit, che viene invece assegnata
univocamente a livello locale per ogni singola scheda direttamente dal produttore:
Nell'identificativo del produttore, i bit 7° e 8° più significativi, hanno un significato

particolare:
il 7° bit o bit Universale/locale (U/L, Universal/Local): consente determinare

se l'indirizzo è amministrato universalmente o localmente. Se il bit U/L è
impostato su 0, significa IEEE ha designato univocamente l'identificativo di
azienda, generando pertanto un indirizzo univoco a livello globale; se invece il
bit U/L è impostato a 1, l'indirizzo è amministrato localmente. Ciò avviene ad
esempio quando, l'amministratore di rete, ignora l'indirizzo originale della
scheda e ne specifica uno differente.
L'8° bit o bit Individuale/di Gruppo (I/G, Individual/Group): consente di
determinare se l'indirizzo è individuale (unicast) o di gruppo (multicast). Se il bit
è impostato a 0, l'indirizzo è unicast altrimenti è multicast;
Tutte le schede di rete ethernet 802.x hanno indirizzi MAC con entrambi i bit U/L e
I/G impostati a 0, indicando così che l'indirizzo in oggetto è unicast e universale.
IEEE EUI-64
Poiché, il campo estensione, sotto il controllo dei produttori, negli ultimi anni era
andato via via esaurendosi, L'IEEE (Institute of Electrical and Electronic Engineers)
ha standardizzato un nuovo formato EUI-64, che ne aumenta le dimensioni
portandole a 40 bit. La dimensione del campo Identificativo del produttore rimane
come invariata:
In maniera del tutto analoga a EUI-48, EUI-64 prevede l'utilizzo dei bit U/L e I/G,
con stesse modalità e significati, anche le posizioni dei bit all'interno
dall'identificativo del produttore rimangono invariate.
L'identificativo dell'interfaccia (Interface ID) basato sul formato EUI-64 modificato può
essere globalmente univoco quando deriva da un indirizzo Universale e Individuale (bit
U/L e I/G entrambi a 0), quindi ad esempio nel caso di conversione diretta da indirizzi
MAC IEEE 802 a 48 bit o a 64 bit. Oppure avere significato locale quando, o non è
possibile derivarlo da identificatori univoci, per esempio nel caso di collegamenti seriali o
nodi terminali di un tunnel, o tale globalità non è desiderabile, come nel caso di indirizzi
temporanei o per questioni di privacy.
2.9.10 Conversione dal formato EUI-64 al formato EUI-64-Modificato
Il formato EUI-64 modificato, si ottiene a partire dal formato EUI-64 negando (o

invertendo) il bit U/L.
In pratica il bit U/L va posto a 1 quando l'indirizzo EUI-64 è universale (bit U/L a 0), va
invece posto a 0 quando l'indirizzo EUI-64 è locale (bit U/L impostato a 1).
A prima vista, sembra che tale scelta sia stata presa esclusivamente per complicare le
cose. Ma approfondendo l'analisi ha l'effetto opposto. Quando si usano identificatori
univoci globalmente la precedente procedura non costituisce un problema perché viene
eseguita automaticamente dagli host nel momento in cui ricavano il loro indirizzo IPv6
dall'ìndirizzo MAC della propria interfaccia. Quando invece è l'amministratore a dover
configurare manualmente l'identificatore ovviamente perchè non è globale, come nel caso
di un collegamento seriale punto-punto, se non fosse utilizzata l'inversione gli identificatori
IPv6 sarebbero nella forma 0200:0:0:1, 0200:0:0:2, ecc., piuttosto che nella forma
0:0:0:1, 0:0:0:2, che è molto più semplice.
Quando a un nodo IPv6 viene assegnato un identificatore d'interfaccia (Interface ID)

creato a partire da un indirizzo EUI-64 universale (bit U/L a 0), non è necessario che
questo venga verificato, poiché tali indirizzi sono già unici.
2.9.11 Conversione dal formato EUI-48 al formato EUI-64
Nel precedente paragrafo ci siamo occupati della conversione di un indirizzo EUI-64 al

formato EUI-64-Modificato, pronto per essere utilizzato come identificativo dell'interfaccia
in IPv6. Per quanto riguarda tutte le schede di rete meno recenti che utilizzano ancora un
indirizzio EUI-48, è prevista una semplice procedura che ne consente la trasformazione in
EUI-64. Praticamente, è necessario aggiungere inserire 16 bit impostati come segue:
(11111111 11111110)2 in esadecimale (0xFFFE)16
tra l'identificativo dell'azienda e l'estensione:
2.9.12 Il vecchio formato degli indirizzi Unicast Globali (Global Unicast Addresses)
Come anticipato all'inizio di questo capitolo, i primi tempi di vita di IPv6 furono abbastanza
travagliati. Da un formato puramente a classi si è passati oggi a un formato (quasi)
completamente privo di vincoli. Tuttavia è molto facile imbattersi in pubblicazioni e articoli
che utilizzano ancora i vecchi schemi e la vecchia terminologia. Con questo paragrafo si
intende riesaminare brevemente l'originale struttura degli indirizzi IPv6, nella speranza di
fare un po' di luce nel caos generato nelle varie transizioni
Gli indirizzi unicast IPv6 erano stati pensati per essere strutturati in modo tale da poter
somigliare a qualcosa come un codice autodescrittivo, cioè, che dall'indirizzo stesso si
potessero ricavare i dati necessari a stabilire informazioni del tipo: “quale autorità aveva
rilasciato l'indirizzo”, “quale fornitore di servizi lo gestisce”, “a quale organizzazione è stato
assegnato”, “in quale posizione geografica si trova l'host”. Per ottenere quanto detto la
struttura dell'indirizzo stesso doveva essere rigidamente definita secondo questo schema:
Topologia pubblica (Public Topology): Questo costituiva il primo livello di
gerarchia dell'indirizzo IPv6 e rappresentava “l'insieme dei fornitori di servizi che
consente l'accesso ad Internet”, in particolare veniva suddiviso in:
FP (prefix format) – prefisso di formattazione: un campo di 3 bit che serviva

(e serve ancor oggi, anche se con modalità differenti) a individuare il tipo di
indirizzo IPv6. La configurazione 001 identifica gli indirizzi unicast globali.
TLA ID (Top-Level Aggregation identifier) – identificatore di aggregazione
di livello più alto: un campo di 13 bit il cui scopo doveva essere quello di
identificare l'Autorità responsabile per l'indirizzamento al livello più alto della
gerarchia. Era anche previsto che i router dovessero mantenere nelle loro
tabelle di instradamento tutte le rotte verso ognuno dei TLA ID. Con 13 bit,
potevano esserci fino a 8.192 TLA;
RES (Reserved) – Riservato: questi bit erano riservati da IETF, nell'eventualità

di crescita futura, poteva essere dato più spazio o per il campo TLA ID o per
quello successivo NLA ID a seconda dei casi;
NLA ID (Next-Level Aggregation identifier) – identificatore di aggregazione

di livello successivo: Ogni Autorità di livello gerarchico superiore aveva a
disposizione questo campo di 13 bit, per poter identificare i singoli fornitori si
servizi Internet ISP sotto la propria giurisdizione. Ogni ISP a sua volta aveva
l'opportunità di organizzare a piacimento questo campo, per riflettere la propria
struttura gerarchica interna.
Topologia del Sito (Site Topology): Rappresentava il secondo livello di gerarchia

dell'indirizzo IPv6. Era previsto come livello locale di ogni organizzazione, questo
non doveva fornire connettività se non all'interno dell'organizzazione stessa. La
gestione di questo livello doveva essere a completa discrezione dell'organizzazione
a cui era stato affidato dall'ISP. Questo livello era composto da un singolo campo di
16 bit, SLA ID (Site-Local Aggregation identifier) cioè Identificatore di
aggregazione a livello di sito. Lo scopo originario era appunto quello di consentire
all'organizzazione di creare la propria gerarchia di indirizzi per poter identificare le
differenti sottoreti.
Identificatore d'Interfaccia (Interface ID): Questo campo è rimasto praticamente

invariato sia come scopo che come dimensione.
La decisione iniziale di strutturare in maniera rigida gli indirizzi IPv6 si è rivelata alquanto
inflessibile. Il nuovo formato (oltre ad avere più senso ndr) consente alle differenti autorità
regionali APNIC, ARIN, LACNIC e RIPE, di decidere come utilizzare e distribuire secondo
il caso primi 45 bit degli indirizzi.
Dall'agosto 2003 con RFC 3587 questi campi e la loro funzione sono stati dichiarati
deprecati. L'unica cosa che è rimasta invariata, sono i tre livelli di gerarchia, ma ogni
livello, oltre ad essere identificato con terminologia differente, può avere qualsiasi
dimensione; l'unica cosa che è rimasta praticamente immutata è l'identificatore
d'interfaccia.
2.9.13 Altri Indirizzi unicast IPv6 per usi speciali
Come nel caso di IPv4, anche in IPv6 alcuni indirizzi vengono riservati per usi particolari,
come ad esempio l'indirizzo di loopback o gli indirizzi privati. Inoltre, come ampiamente
spiegato nei precedenti paragrafi, ancora oggi, l'indirizzamento IPv6 risente dell'iniziale
organizzazione a classi attribuita con l'utilizzo di FP prefisso di formattazione (format
prefix). Sebbene gli ultimi RFC, abbiano reso deprecata tale suddivisione a volte per
motivi storici, a volte per motivi di praticità alcune classi di indirizzi sono state mantenute.
RFC 4291 si riferisce a questi indirizzi definendoli con i termini tipi e sottotipi di indirizzi
unicast.
::/128 – Indirizzo non specificato (unspecified address): E' l'indirizzo con tutti i
bit a zero: 0:0:0:0:0:0:0:0; rappresenta l'assenza dell'indirizzo, e non può
essere assegnato ad alcun nodo. Un caso di possibile utilizzo, è come indirizzo
sorgente di un pacchetto IPv6, inviato da un host in fase di inizializzazione, prima
che abbia appreso il suo reale indirizzo IPv6. Non è possibile utilizzare tali indirizzi
nel campo destinazione dei pacchetti IPv6. Un pacchetto IPv6 con un tale indirizzo
sorgente non potrà mai essere instradato da un router
::1/128 – Indirizzo di loopback: E' l'indirizzo unicast: 0:0:0:0:0:0:0:1;

identifica l'interfaccia virtuale locale, ovvero l'interfaccia di loopback. Come tale, non
può essere assegnato a un'interfaccia fisica reale. In pratica, quando
un'applicazione crea un pacchetto destinato a questo indirizzo, questo non viene
inoltrato sulla rete fisica esterna, ma viene rispedito indietro allo stesso nodo.
Quando un interfaccia riceve un pacchetto che proviene da un indirizzo di loopback
deve scartarlo. Corrisponde all'indirizzo IPv4 127.0.0.1;
Indirizzi IPv6 contenenti indirizzi IPv4 (IPv6 Addresses with Embedded IPv4
Addresses): vengono definiti due sottotipi di indirizzi globali unicast IPv6 che
contengono indirizzi IPv4 nei 32 bit meno significativi. Questi indirizzi sono:
::ffff:0:0/96 – Indirizzi IPv4 Incorporati (IPv4 mapped addresses): Tali

indirizzi hanno gli 80 bit più significativi a zero, seguiti da 16 bit a uno e, infine, i
successivi 32 bit rappresentano l'indirizzo IPv4. Vengono normalmente utilizzati
nell'implementazione dei meccanismi di transizione, in particolare per
rappresentare indirizzi IPv4 su applicazioni IPv6; La rappresentazione scritta di
tali indirizzi costituisce un'eccezione alla notazione di IPv6 come visto in
precedenza.
::/96 – Indirizzo IPv4 compatibile (IPv4 compatible addresses): Tali

indirizzi hanno i 96 bit più significativi a zero, i restanti rappresentano indirizzi
IPv4. Si tratta di indirizzi inizialmente previsti dai meccanismi di transizione per
consentire il passaggio da IPv4 a IPv6. Oggi tali meccanismi non li utilizzano
più, pertanto sono stati deprecati. La rappresentazione scritta di tali indirizzi
costituisce un'eccezione alla notazione di IPv6, come visto in precedenza.
La differenza tra i due tipi di indirizzi è subdola, ma molto importante. In ognuno dei
due tipi i primi 80 bit sono sempre impostati a 0, cosicché quando si ha a che fare
con una tale configurazione, salta subito all'occhio che si tratta di un qualche tipo di
indirizzo IPv4. Quindi, gli indirizzi IPv4-Compatibili, sono utilizzati su dispositivi in
grado di gestire anche il protocollo IPv6. Mentre gli indirizzi IPv4-Incorporati
indicano che l'indirizzo proviene da un dispositivo esclusivamente compatibile con
IPv6, e che è stato incorporato in un indirizzo IPv6.
fe80::/64 – Indirizzi Unicast locali al collegamento (Link-Local IPv6 Unicast
Addresses): Sono destinati per indirizzare un singolo collegamento fisico, hanno
validità esclusivamente all'interno di un singolo segmento di rete (per esempio
all'interno di un dominio di brodcast in caso di reti ethernet). Possono essere
utilizzati ad esempio per acquisire automaticamente la configurazione IPv6, oppure
identificare i dispositivi vicini (neighbors), o in assenza di dispositivi di
instradamento come i router. I router non instradano mai i pacchetti che hanno tale
indirizzo come sorgente o destinazione, neanche all'interno dell'organizzazione
stessa.;
fec0::/10 – Indirizzi unicast locali al sito (Site-Local): Questi indirizzi furono
inizialmente previsti per essere utilizzati all'interno di un sito di un'organizzazione, o
per l'intera organizzazione, senza la necessità di specificare un prefisso globale.
Similmente al concetto degli indirizzi privati IPv6. Tale definizione è stata deprecata
nel settembre 2004 in RFC 3879. Lo speciale comportamento previsto per tali
indirizzi in RFC 3513 non è più supportato, e pertanto devono essere trattati come
indirizzi unicast globali.
2001:db8::/32 – Indirizzi per documentazione (documentation addresses):

In RFC 3849, tale spazio di indirizzamento viene utilizzato in tutti gli esempi di
indirizzi IPv6, pertanto quando è necessario rappresentare un indirizzo IPv6 in un
manuale, articolo o documentazione in genere è opportuno utilizzare tali indirizzi;
fc00::/7 – Indirizzi unicast locali univoci (Unique local unicast addresses)

Tali indirizzi sono instradabili solo all'interno di un insieme di siti. Sono stati definiti
in RFC 4193 per sostituire gli indirizzi locali al sito (site-local addresses). Tali
indirizzi includono un numero pseudo-casuale di 40 bit, che minimizza il rischio di
conflitti.
2.9.14 Gli indirizzi Anycast
Questo tipo di indirizzi non ha alcun corrispondente in IPv4. Possiamo definire gli indirizzi
anycast come una via di mezzo tra gli indirizzi unicast e multicast. I primi servono a
identificare un singolo host, i secondi a identificare un gruppo di host, mentre gli indirizzi
anycast consentono di identificare un qualunque host all'interno di un gruppo. Un indirizzo
IPv6 anycast può essere assegnato a differenti interfacce (generalmente appartenenti a
nodi differenti). Quando un pacchetto viene inviato verso un indirizzo anycast questo viene
instradato verso l'interfaccia più vicina alla sorgente, che possiede quell'indirizzo. Con “più
vicina” si intende quell'interfaccia, che in base alle regole del protocollo di instradamento
utilizzato, risulta raggiungibile con un costo minore rispetto a tutte le altre interfacce aventi
lo stesso indirizzo anycast.
Gli indirizzi anycast sono stati previsti per implementare in IPv6, funzionalità che il suo
predecessore non aveva. Per esempio possono essere usati in tutti quei casi in cui è
necessario utilizzare un certo servizio che viene offerto da differenti server o router, non è
importante chi tra loro lo fornirà.
Sintatticamente tra gli indirizzi anycast e gli indirizzi unicast non c'è nessuna differenza,
condividono infatti lo stesso spazio di indirizzamento; in pratica indirizzo unicast, nel
momento in cui viene assegnato a più host diventa automaticamente un indirizzo anycast
La differenza viene fatta a livello software, cioè l'host che possiede un indirizzo anycast
deve essere configurato in modo opportuno.
L'instradamento degli indirizzi anycast come per quelli multicast è per i router
un'operazione abbastanza onerosa; infatti è necessario che le tabelle di instradamento di
ogni router all'interno della rete contengano una voce separata per ogni host anycast
presente, in genere tale tipo di instradamento è chiamato host-route. Tra l'altro ad ogni
indirizzo anycast, è necessario accoppiare un prefisso9 di lunghezza tale da coprire tutte le
sottoreti in cui risiedono gli host ai quali l'indirizzo è stato assegnato.
2.9.15 Gli indirizzi Multicast IPv6
Tali indirizzi sono identificati dal prefisso ff00::/8, consentono di indirizzare un

pacchetto a un gruppo di interfacce (tipicamente installate su nodi differenti). Un'interfaccia
può essere membro di differenti gruppi multicast, cioè può ricevere il traffico diretto a
gruppi diversi. Il formato degli indirizzi multicast è il seguente:
9 Si ricorda che il concetto di prefisso corrisponde a quello di maschera di sottorete utilizzato in IPv4
Gli indirizzi multicast sono strutturati in quattro campi principali:
La sequenza binaria iniziale (11111111)2 che li identifica appunto gli indirizzi

multicast IPv6;
Il campo opzioni o flag, formato da quatto bit, che serve a stabilire la tipologia
dell'indirizzo stesso. Il primo bit di tale campo è sempre impostato a 0 gli altri sono
identificati dalle lettere R, P, T. Tali indicazioni sono state aggiornate in base a RFC
4291, documento al quale si rimanda per eventuali altri approfondimenti:
Bit T – quando impostato a zero indica che l'indirizzo multicast è assegnato

permanentemente, cioè che fa parte di quegli indirizzi ben-conosciuti (well-
known), che IANA ha già riservato per determinate appicazioni; altrimenti indica
l'indirizzo multicast in questione non è stato permanente assegnato, ma è
transiente (transient) o assegnato dinamicamente;
Bit P – impostato a zero indica che l'indirizzo multicast è stato assegnato in

base al prefisso di rete, impostato a uno l'esatto contrario (per ulteriori
informazioni consultare RFC 3306;
Bit R – specifica il formato dell'indirizzo multicast quando si utilizza il protocollo

di segnalazione PIM. In particolare, quando il bit R p impostato a 1 significa che
l'indirizzo multicast incorpora anche l'indirizzo di un Rendezvous Point, cioè di
un router che conosce tutte le sorgenti dei gruppi attivi in un dominio PIM. Per
ulteriori informazioni si consulti RFC 3956.
Il campo ambito (scope), anch'esso formato da 4 bit, indica appunto l'ambito di
validità dell'indirizzo multicast:
Valore Significato
0 Riservato
1 Locale all'interfaccia – valido esclusivamente nella stessa interfaccia;

utile solo per trasmissione multicast in loopback
2 Locale al collegamento – valido all'interno della stessa sottorete.

Come definito con il corrispondente ambito unicast.
3 Riservato
Locale all'amministratore – valido entro il l'ambito di dimensioni più
4 piccole che può essere, amministrativamente configurato, cioè non
derivato automaticamente da un collegamento fisico o altre
configurazioni non correlate al multicast
Valore Significato
5 Locale al sito – valido all'interno dello stesso sito
6 Non assegnato
7 Non assegnato
8 Locale all'organizzazione – valido all'interno di tutti i siti di

un'organizzazione
9 Non assegnato
A Non assegnato
B Non assegnato
C Non assegnato
D Non assegnato
E Globale
F Riservato
Quando l'ambito per una determinata configurazione di bit, è impostato come non
assegnato significa che è disponibile per gli amministratori di rete, per la definizione
di altre regioni multicast.
L'identificatore del gruppo, consente di individuare il gruppo sia esso permanente

che transiente, all'interno dell'ambito di validità specificato. Ulteriori informazioni
sulla struttura di questo campo possono essere reperite in RFC3306.
Un indirizzo multicast non può essere specificato nel comapo sorgente dei pacchetti IPv6,
inoltre questi indirizzi non possono apparire nelle regole di instradamento dei router.
2.10 Esercitazioni di amministrazione avanzata sull'indirizzamento
IP
2.10.1 Configurazione di VLSM e IP Unnumbered
Scenario
Un'Agenzia Turistica Internazionale di piccole dimensioni ha la necessità di configurare la sua
infrastruttura di rete usando un singolo blocco di indirizzi di classe C: 192.168.1.0/24, come mostrato
nell'immagine precedente. Oltre gli indirizzi per le singole interfacce dei router, la società richiede che
vengano allocati 25 indirizzi per gli host su ogni singola LAN, ma desidera anche riservare un numero
sufficiente di indirizzi per futuri ampliamenti.
Affinché ogni sottorete delle singole LAN possa indirizzare 25 host è necessario riservare minimo 5 bit alla
porzione host degli indirizzi. Infatti, con 5 bit è possibile indirizzare un massimo di 30 host, 25 – 2,
rimarrebbero così 5 indirizzi liberi per sottorete, per futuri ampliamenti. I 3 bit dell'ultimo ottetto verranno
utilizzati per creare le sottoreti. In particolare con 3 bit è possibile creare 2 3 = 8 sottoreti (utilizzando il
comando ip subnet zero). Poiché l'indirizzo iniziale della rete è di classe C, la lunghezza predefinita
del prefisso è 24 bit, a questi devono essere aggiunti i 3 bit, presi dalla porzione host dell'indirizzo,
pertanto la maschera di sottorete avrà lunghezza pari a 27 bit, che consente di creare le seguenti
sottoreti:
Inoltre per massimizzare il numero di indirizzi, la sottorete zero è stata a sua volta suddivisa in 8 sottoreti
punto-punto, quindi usando una maschera di sottorete di 30 bit, per indirizzare le intefacce WAN dei router.
Passo 1. Ovviamente, le scelte fatte per le sottoreti impongono l'uso della sottorete zero, pertanto è
richiesto sui router il comando ip subnet-zero.
Su tutti i router configurare il protocollo di instradamento RIPv1, e abilitare gli aggiornamenti su
tutte le interfacca attive con i comandi network appropriati. Essendo RIP un protocollo a classi e
considerato si sta utilizzando un'unica rete di classe C per tutta l'organizzazione, la
configurazione RIP è identica per tutti i tre router:
SanJose1(config)# router rip

SanJose1(config-router)# network 192.168.1.0
Passo 2. Eseguire il comando show ip route sul router Vista, come mostrato nel seguente esempio
Vista# show ip route
<output omitted>
Gateway of last resort is not set

192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.1.64/27 is directly connected, Ethernet0
C 192.168.1.0/30 is directly connected, Serial0
Nella tabella di instradamento del router Vista è assente la sottorete 192.168.1.32 /27.
Anche gli altri router hanno tabelle di instradamento incomplete. Questo avviene perché è stato
utilizzato RIPv1 insieme a VLSM. VLSM non è supportato dai protocolli a classi come RIPv1 o
IGRP. Tali protocolli non inviano le maschere di sottorete nei messaggi di aggiornamento, ed è
proprio questo che causa il problema nel caso dell'esempio. Per poter fare in modo che
l'instradamento funzioni nella rete è necessario abilitare RIPv2.
Passo 3. Su ognuno dei tre router abilitare gli aggiornamenti RIPv2, e disabilitare l'aggregazione
automatica, come mostrato di seguito:

SanJose1(config)# network 192.168.1.0 ;(solo nel caso in cui RIP fosse stato
rimosso)
SanJose1(config-router)# version 2
SanJose1(config-router)# no auto-summary
Il comando no auto-summary disabilita la funzione di aggregazione automatica delle sottoreti

nella rete di classe superiore. Questo comando è essenziale affinché le informazioni sulle
sottoreti vengano inviate correttamente. Fatta la variazione da RIPv1 a RIPv2, le tabelle di
instradamento dei router, dovrebbero risultare adesso complete:
Vista#show ip route
<output omitted>
192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
C 192.168.1.64/27 is directly connected, Ethernet0
R 192.168.1.32/27 [120/1] via 192.168.1.6, 00:00:12, Serial1
[120/1] via 192.168.1.2, 00:00:13, Serial0
Si osservi che il router Vista riceve adesso due rotte di equal costo 192.168.1.32/27 da
entrambi i router SanJose1 e SanJose2.
Passo 4. Sebbene l'uso delle maschere di sottorete a lunghezza variabile VLSM, abbia ridotto lo spreco di
indirizzi IP, utilizzando IP unnumbered è possibile evitare di dover assegnare indirizzi IP ai
collegamenti WAN punto-punto consentendo un risparmio ancora maggiore di indirizzi IP.
Procediamo pertanto alla configurazione di IP unnumbered su ogni interfaccia seriale WAN dei
router:
SanJose1(config)# interface serial 0/0

SanJose1(config-if)# ip unnumbered fastethernet 0/0
Vista(config)# interface serial 0/0

Vista(config-if)# ip unnumbered fastethernet 0/0
Vista(config-if)# interface serial 0/1
Vista(config-if)# ip unnumbered fastethernet 0/0
Si osservi come entrambe le interfacce seriali del router Vista utilizzino l'indirizzo IP
dell'interfaccia fastethernet 0/0.
SanJose2(config)# interface serial 0/0

SanJose2(config-if)# ip unnumbered fastethernet 0/0
Completata la configurazione di IP unnumbered, ognuna delle interfacce seriali acquisisce

all'occorrenza l'indirizzo IP delle interfacce LAN. Ricontrolliamo ancora la tabella di
instradamento del router Vista:
Vista# show ip route
<output omitted>

192.168.1.0/27 is subnetted, 2 subnets
C 192.168.1.64 is directly connected, Ethernet0
R 192.168.1.32 [120/1] via 192.168.1.34, 00:00:00,
Serial1
[120/1] via 192.168.1.33, 00:00:08,
Serial0
Passo 5. Quando IP unnumbered viene configurato sui collegamenti seriali punto-punto, solo le interfacce
LAN richiedono gli indirizzi IP. Poiché ognuno dei collegamenti LAN utilizza la stessa maschera
di sottorete a 27 bit, non è necessario utilizzare schemi VLSM, pertanto, inquesta configurazione
i protocolli di instradamento a classi tornerebbero a funzionare.
2.10.2 Esercizi con VLSM
Esercizio 1
Creare uno schema di indirizzamento usando maschere di sottorete a lunghezza variabile (VLSM). L'indirizzo
assegnato è di classe C 192.168.10.0 e deve supportare tutte le reti presenti in figura. L'uso di IP
unnumbered o NAT non è permesso.
Per indirizzare 60 host sono necessari minimo 6 bit: 2 6 – 2 = 62 restano 2 bit per le sottoreti. La rete
192.168.10.0/24 viene partizionata in 4 reti con prefisso di lunghezza di 26 bit
Rete 192.168.10.0/24
Configurazione Bit Sottorete Note
... 00 000000 192.168.10.0/26 Indirizza la LAN con 60 host
... 01 000000 192.168.10.64/26 LAN 24 host + Scalabilità
... 10 000000 192.168.10.128/26 LAN 12 host + WAN + Scalabilità
... 11 000000 192.168.10.193/26 Libera
Per indirizzare 24 host sono necessari minimo 5 bit: 25 – 2 = 30. Si procede partizionando ulteriormente la
rete 192.168.10.64/26, resta un solo bit per identificare la sottorete:
Rete 192.168.10.64/26
... 01 0 00000 192.168.10.64/27 Indirizza la LAN con 24 host
... 01 1 00000 192.168.10.96/27 Libera per espansione
Per indirizzare 12 host sono necessari minimo 4 bit: 24 – 2 = 14. Si procede partizionando ulteriormente la
rete 192.168.10.128/26. In questo caso otteniamo 4 sottoreti da 14 host ciascuna. Con le prime due
indirizziamo i collegamenti per le due LAN da 12 host. La terza verrà lasciata libera per espansioni. La
quarta verrà ulteriormente partizionata per indirizzare i collegamenti WAN
Rete 192.168.10.128/26
... 10 00 0000 192.168.10.128/28 Prima LAN a 12 host
... 10 01 0000 192.168.10.144/28 Seconda LAN a 12 host
... 10 10 0000 192.168.10.160/28 Libera per espansione
... 10 11 0000 192.168.10.176/28 Indirizzare collegamenti WAN
Per i collegamenti WAN sono necessarie 3 sottoreti di maschera /30. Partizioniamo ulteriormente l'ultima
sottorete della tabella precedente. Otteniamo 4 sottoreti punto-punto l'ultima verrà riservata per future
espansioni.
Rete 192.168.10.176/28
... 10 11 00 00 192.168.10.176/30 Prima WAN
... 10 11 01 00 192.168.10.180/30 Seconda WAN
... 10 11 10 00 192.168.10.184/30 Terza WAN
... 10 11 11 00 192.168.10.188/30 Libero per espansione
Sebbene si sarebbe potuto procedere a soluzioni diverse, questa sembra quella ottimale. Forse, riflettendo
meglio, l'ideale sarebbe stato lasciare libera la sottorete 192.168.10.64/26 per ulteriori espansioni, e
scalare il resto della suddivisione di una riga nella prima tabella. Questo perché nel caso in cui si rendessero
necessari più host nella rete 192.168.10.0/26 si sarebbe potuto procedere all'accorpamento di questa rete
con192.168.10.64/26 in una rete 192.168.10.0/25. Si può notare come la scelta di lasciare libera la
sottorete successiva a quelle occupate sia stata presa in tutte le suddivisioni successive. Tale scelta in questo
caso si è resa necessaria poiché il numero totale di host contenuto in ogni sottorete è a limite con quello degli
host richiesti per ogni sottorete.
Esercizio 2
Creare uno schema di indirizzamento usando maschere di sottorete a lunghezza variabile (VLSM). L'indirizzo
assegnato è CIDR 192.168.24.0/22 e deve supportare tutte le reti presenti in figura. L'uso di IP unnumbered,
NAT o della sottorete /31 (disponibile a partire dalla versione di IOS 12.2 non sono permessi.
Per indirizzare 400 host sono necessari minimo 9 bit: 29 – 2 = 510, essendo l'indirizzo CIDR resta libero 1 bit
per le sottoreti. Possiamo quindi creare 2 sottoreti /23 di 510 host ciascuna:
Rete 192.168.24.0/22
192. 168. 000110 0 0. 192.168.24.0/23 Lan a 400 host
00000000
192. 168. 000110 1 0. 192.168.26.0/23 Ulteriori sottoreti
00000000
L'ultima sottorete della tabella precedente verrà utilizzata per indirizzare la LAN con 200 host. Per tale LAN
sono necessari minimo 8 bit: 28 – 2 = 254. Anche qui rimane un solo bit per le sottoreti. Pertanto otteniamo 2
sottoreti /24 di 254 host ciascuna:
Rete 192.168.26.0/23
192. 168. 000110 1 0. 192.168.26.0/24 Lan a 200 host
00000000
192. 168. 000110 1 1. 192.168.28.0/24 Ulteriori sottoreti
00000000
A questo punto restano da indirizzare le du reti da 50 host e i collegamenti WAN. Per indirizzare 50 host
sono necessari almeno 6 bit: 26 – 2 = 62 . Potremmo in questo caso suddividere la seconda sottorete della
tabella precedente in due sottoreti /25 quindi la prima di queste in due /26, anche perché il numero di host
liberi per future espansioni è di circa 12 host per sottorete, tali valori sono meno stringenti di quelli
dell'esempio precedente.
Rete 192.168.28.0/23
192. 168. 28. 00 000000 192.168.28.0/26 Prima LAN 50 host
192. 168. 28. 01 000000 192.168.28.64/26 Seconda LAN 50 host
Resta libera la sottorete 192.168.28.128/25 da cui dobbiamo ricavare i tre collegamenti WAN. Possiamo
pendere le ultime sottoreti possibili:
Rete 192.168.28.128/25
192. 168. 28. 1 111 00 00 192.168.28.240/30 Prima WAN
192. 168. 28. 1 111 01 00 192.168.28.244/30 Seconda WAN
192. 168. 28. 1 111 10 00 192.168.28.248/30 Terza WAN
192. 168. 28. 1 111 11 00 192.168.28.252/30 Libera per estensioni
Restano libere per estensioni future:

192. 168. 28. 1 000 00 00 192.168.28.128/26 Libera per 62 host
192. 168. 28. 1 100 00 00 192.168.28.196/27 Libera per 30 host
192. 168. 28. 1 110 00 00 192.168.28.224/28 Libera per 14 host
Se è vero che in questa configurazione siamo riusciti a mantenere liberi quasi 106 indirizzi, è anche vero che
questi sono distribuiti su 3 sottoreti non aggregabili. Il risultato non sembra del tutto ottimale come quello
ottenuto nell'esempio precedente. Purtroppo a volte anche utilizzando le VLSM bisogna scendere a
compromessi.
2.10.3 Uso di DHCP e IP helper address
Scenario
I client sulle reti 192.168.3.0/24 e 10.0.0.0/8 richiedono l'accesso ad un servizio DHCP, per poter
ottenere la configurazione IP automaticamente. E' necessario configurare il router SanJose1 affinché serva
entrambe le reti utilizzando due gruppi di intervalli (pool) di indirizzi separati. Infine è necessario configurare
l'interfaccia di fastethernet0/0 del router Vista per inoltrare i pacchetti di broadcast UDP, incluse le
richieste DHCP, verso SanJose1.
Passo 1. Configurare gli host in modo tale da ottenere la configurazione IP da un servar DHCP.
Passo 2. Configurare il protocollo RIP v2 sui due router SanJose1 e Vista. Accertarsi di abilitare gli
aggiornamenti su tutte le interfacce attive:

SanJose1(config)# version 2
Vista(config)# router rip

Vista(config-router)# version 2
Vista(config-router)# network 192.168.1.0
Vista(config-router)# network 192.168.3.0
Usare i comandi ping e show ip route per verificare che la configurazione sia stata
effettuata correttamente e che ci sia connettività tra i due router;
Passo 3. Configurare il router SanJose1 affinché agisca come un server DHCP:
SanJose1(config)# service dhcp
Adesso configuriamo il primo gruppo di indirizzi da rilasciare per la rete 10.0.0.0/8. Il nome di
tale gruppo sarà 10-net:
SanJose1(config)# ip dhcp pool 10-net

SanJose1(dhcp-config)# network 10.0.0.0 255.0.0.0
Passo 4. L'Agenzia Turistica internazionale, utilizza i primi dieci indirizzi del gruppo definito in precedenza
per indirizzare in maniera statica i router e alcuni server. Pertanto gli indirizzi da 10.0.0.1 a
10.0.0.10 dovranno essere esclusi dall'intervallo DHCP definito, in modo tale che il server
DHCP non provi a rilasciarli:
SanJose1(config)# ip dhcp excluded-address 10.0.0.1 10.0.0.10
Passo 5. Ritorniamo ancora in modalità configurazione DHCP, per assegnare al gruppo le altre opzioni,
cioè gli indirizzi del gateway prefdefinito, del server DNS, del server WINS e il nome di dominio:
SanJose1(config)# ip dhcp pool 10-net

SanJose1(dhcp-config)# default-router 10.0.0.1
SanJose1(dhcp-config)# dns-server 10.0.0.3
SanJose1(dhcp-config)# netbios-name-server 10.0.0.4
SanJose1(dhcp-config)# domain-name xyz.net
Passo 6. Il server DHCP è pronto per essere provato. Rilasciare e rinnovare la configurazione IP per
l'Host A. Questo adesso dovrebbe acquisire dinamicamente il primo indirizzo IP disponibile, cioè
10.0.0.11. Controllare la configurazione IP dell'host A con i comandi messi a disposizione dal
sistema operativo10 per verificare che abbia ricevuto l'indirizzo IP, maschera di sottorete e tutti gli
altri parametri in modo corretto.
Passo 7. Poiché anche gli host sulla rete 192.168.3.0/24 richiedono il servizio DHCP, è necessario
che venga definito sul router SanJose1 un altro gruppo DHCP, con indirizzi e opzioni appropriati
per questa rete:
SanJose1(config)# ip dhcp pool 192.168.3-net

SanJose1(dhcp-config)# network 192.168.3.0 255.255.255.0
SanJose1(dhcp-config)# default-router 192.168.3.1
SanJose1(dhcp-config)# dns-server 10.0.0.3
SanJose1(dhcp-config)# netbios-name-server 10.0.0.4
SanJose1(dhcp-config)# domain-name xyz.net
L'agenzia turistica ha recentemente installato dei telefoni IP sulla rete 192.168.3.0. Questi
telefoni richiedono che il server DHCP rilasci anche l'indirizzo IP di un server TFTP per
l'auto-configurazione. Tale server ha indirizzo 10.0.0.5.
Il server DHCP presente nell'IOS Cisco non ha un comando diretto per definire una tale
configurazione. Tuttavia è possibile comunque fare in modo che il server DHCP invii tale
informazione. Praticamente, ogni parametro di configurazione che il server DHCP rilascia viene
identificato da un codice numerico (option number) ad esempio: il codice 3 identifica l'ndirizzo del
gateway predefinito, 50 l'indirizzo IP, e così via11. I telefoni IP Cisco, si aspettano di ricevere
10 Per gli SO Microsoft fino a Windows ME usare il comando winipcfg da windows NT in su utilizzare il comando
ipconfig /all. Per Linux usare ifconfig
11 E' possibile trovare tutti i codici assegnati ai parametri di configurazione rilasciati da un server DHCP a partire da
RFC 2132
l'indirizzo del server TFTP con codice 150. Pertanto è possibile configurare il server DHCP,
specificando il numero di codice seguito dall'indirizzo del server, tale sistema di configurazione è
chiamato raw option number:
SanJose1(dhcp-config)# option 150 ip 10.0.0.5
Passo 8. La configurazione del server DHCP è praticamente completata. Tuttavia gli host della rete
192.168.3.1 usano messaggi UDP in broadcast per trovare l'indrizzo IP del sever DHCP, e il
router Vista non è ancora configurato per inoltrare tali messaggi. Affinché il servizio DHCP
funzioni correttamente anche sulla LAN del router Vista è necessario configurare la sua
interfaccia FastEthernet per inoltrare i pacchetti UDP verso SanJose1:
Vista(config)# interface fastethernet 0/0

Vista(config-if)# ip helper-address 192.168.1.2
Rilasciare e rinnovare la configurazione IP anche sull'host B; verificando che abbia ricevuto i

parametri corretti dal server DHCP.
Sebbene il comando ip dhcp excluded-address non sia stato impartito sul router
SanJose1, per rimuovere l'indirizzo 192.168.3.1, già assegnato all'interfaccia del router Vista,
questo non è un problema perché, il server DHCP dell'IOS prima di assegnare un indirizzo IP,
verifica che questo non sia già stato assegnato. Come risulta evidente dal seguente:
Impartire il comando show ip dhcp ? Osservandone il risultato:
SanJose1# show ip dhcp ?
binding DHCP address bindings

conflict DHCP address conflicts
database DHCP database agents
import Show Imported Parameters
relay Miscellaneous DHCP relay information
server Miscellaneous DHCP server information
Proviamo le opzioni conflict e binding:
SanJose1# show ip dhcp binding
IP address Client-ID/ Lease expiration Type

Hardware address
10.0.0.11 0063.6973.636f.2d30. Mar 02 1993 02:28 AM Automatic
3030.342e.3961.6432.
2e64.3063.302d.4661.
302f.30
192.168.3.2 0063.6973.636f.2d30. Mar 02 1993 03:11 AM Automatic

3030.392e.3433.3566.
2e39.6362.312d.4661.
302f.30
SanJose1# show ip dhcp conflict
IP address Detection method Detection time

192.168.3.1 Ping Mar 01 1993 03:11 AM
2.10.4 NAT Network address translation - NAT statico e NAT Dinamico
Scenario
L'agenzia Turistica Internazionale, necessita approssimativamente 100 indirizzi IP privati, che devono essere
traslati uno-a-uno verso un intervallo di indirizzi pubblici di classe C, allocati dal fornitore ISP1.
Passo 1. Prima di iniziare la configurazione, verificare usando ping la connettività, tra il router NAT e il
router ISP1, quindi tra la gli host interni e il gateway predefinito e infine tra il WebServer e il
router ISP1;
Passo 2. Poiché non verrà abilitato nessun protocollo di instradamento è necessario configurare una rotta
predefinita, verso Internet sul router NAT:
NAT(config)# ip route 0.0.0.0 0.0.0.0 200.200.100.2
D'altra parte anche il router ISP1 deve essere in grado di raggiungere gli host sulla rete
192.168.0/24, per poter instradare i pacchetti di ritorno o comunque richieste esterne.
Tuttavia gli indirizzi di tali host saranno traslati sugli indirizzi IP pubblici 200.200.100.128/25.
E' necessario quindi impostare sul router ISP, una rotta statica verso la rete
200.200.100.128/25:
ISP1(config)# ip route 200.200.100.128 255.255.255.128 200.200.100.1
Passo 3. Creare una lista di accesso standard che definisce gli indirizzi IP di tutti gli utenti interni:
NAT(config)# access-list 1 permit 192.168.1.0 0.0.0.255
Passo 4. E' necessario adesso configurare lo spazio di indirizzi pubblici e privati che dovranno essere
utilizzati dal NAT, quindi impostare la traslazione:
Lo spazio di indirizzamento pubblico è 200.200.100.128/25, su questo saranno traslati gli

indirizzi privati. Qui possiamo prendere due strade, o associare staticamente ogni indirizzo
privato con un indirizzo pubblico; oppure far eseguire quest'operazione dinamicamente al router.
Per possiamo associare staticamente staticamente l'host avente indirizzo privato 192.168.1.2
con l'indirizzo pubblico 200.200.100.252.
NAT(config)# ip nat inside source static 192.168.1.2 200.200.100.252
Questa associazione statica ha il vantaggio di rendere l'host 192.168.1.2 sempre accessibile da

utenti esterni, tramite appunto l'indirizzo pubblico 200.200.100.252 (ovviamente vale anche il
contrario, cioè l'utente l'host 192.168.1.2 potrà accedere a Internet). D'altra parte però questa
accessibilità dall'esterno ha anche lo svantaggio di rendere l'host più vulnerabile ad attacchi.
Ovviamente l'alternativa di lasciare scegliere dinamicamente l'associazione al router è si indirizzi
pubblici. Le associazioni statiche si utilizzano quindi verso quegli host che forniscono servizi agli
utenti esterni, come per esempio i server, o che semplicemente si vogliono rendere raggiungibili
direttamente dall'esterno. Per tutti gli altri host si dovrebbe far scegliere al router dinamicamente
tale associazione. Per esempio per associare dinamicamente gli host nella rete
192.168.1.0/24 verso gli indirizzi IP pubblici nell'intervallo compreso tra 200.200.100.129
a 200.200.100.250, procedere come segue:
NAT(config)# ip nat pool public 200.200.100.129 200.200.100.250

netmask 255.255.255.128
NAT(config)# ip nat inside source list 1 pool public
Nel primo comando viene definito l'intervallo (pool) di indirizzi pubblici a cui viene associato il
nome di public, il secondo comando associa a public la lista di accesso 1 definita in
precedenza, che contiene l'intervallo di indirizzi da associare. Il NAT dinamico viene eseguito per
qualsiasi intervallo di indirizzi privati configurato, per i quali non siano stati già state definite
traslazioni statiche. Si noti che l'intervallo di indirizzi IP pubblici è superiore all'intervallo degli
indirizzi IP privati 128 contro 254. Pertanto se nella rete privata ci sono più di 128 host attivi,
potranno accedere a internet soltanto i primi 128. Gli altri dovranno aspettare che scada per
inattività il contatore che indica al router per quanto tempo deve mantenere l'associazione,
oppure utilizzare il “NAT con overloading” o PAT
Passo 5. Adesso è necessario dichiarare al router qual'è l'interfaccia interna, cioè quella in cui si trovano
gli host con gli indirizzi privati da traslare, e qual'è l'interfaccia esterna, quella cioè sulla quale
dovrà effettuare la traslazione con gli indirizzi pubblici. In topologie di rete più complesse è
possibile avere più interfacce interne:
NAT(config)# interface fastethernet 0/0

NAT(config-if)# ip nat inside
NAT(config-if)# interface serial 0/0

NAT(config-if)# ip nat outside
Ci sono diversi comandi show che possono essere utilizzati per verificare il funzionamento del
NAT come: show ip nat translations, show ip nat statistics e infine il comando
show ip nat translations verbose.
Da uno degli host interni eseguire un ping verso il WebServer (200.200.50.2), per verificare
che sia raggiungibile, provare se possibile anche a collegarsi tramite browser. Eseguire sul
router NAT i tre comandi precedenti. Un esempio di risultato è mostrato in basso:
NAT# show ip nat translations
Pro Inside global Inside local Outside local Outside global

--- 200.200.100.129 192.168.1.5 --- ---
--- 200.200.100.252 192.168.1.2 --- ---
NAT# show ip nat statistics
Total active translations: 2 (1 static, 1 dynamic; 0 extended)

Outside interfaces:
Serial0/0
Inside interfaces:
FastEthernet0/0
Hits: 131 Misses: 9
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 2] access-list 1 pool public refcount 1
pool public: netmask 255.255.255.128
start 200.200.100.129 end 200.200.100.250
type generic, total addresses 122, allocated 1 (0%), misses 0
NAT# show ip nat translations verbose

--- 200.200.100.129 192.168.1.5 --- ---
create 00:02:55, use 00:02:55, left 23:57:04, Map-Id(In): 2,
flags:
none, use_count: 0
--- 200.200.100.252 192.168.1.2 --- ---
create 00:40:36, use 00:02:59,
flags:
static, use_count: 0
Si osservi come l'indirizzo privato 192.168.1.5 sia stato traslato dinamicamente nell'indirizzo
pubblico 200.200.100.129, il primo indirizzo disponibile nel pool di indirizzi “public”. Il
comando clear ip nat translation * può essere utilizzato per cancellare tutte le
traslazioni NAT dinamiche:
NAT# clear ip nat translation *

--- 200.200.100.252 192.168.1.2 --- ---
2.10.5 PAT - Port Address Translation e Port Forwarding
Scenario
L'agenzia Turistica Internazionale, sta pianificando il lancio di un sito Web informativo, che verrà installato su
un di un server interno e che dovrà essere accessibile al pubblico. Tuttavia l'unico indirizzo di Classe C
disponibile, non è sufficiente al fabbisogno di utenti e dispositivi della rete. Pertanto la rete dovrà essere
configurata in modo tale da consentire a tutti gli utenti interni di accedere a Internet e a tutti gli utenti esterni di
accedere al server Web, utilizzando quindi NAT statico e PAT. Gli utenti interni dovranno essere traslati
verso un unico indirizzo pubblico e tutti gli utenti esterni dovranno accedere al server Web, tramite un
indirizzo IP pubblico.
Passo 1. Prima di iniziare la configurazione, verificare usando ping la connettività, tra il router NAT e il
router ISP1, quindi tra la gli host interni e il gateway predefinito e infine tra il WebServer e il
router ISP1;
Passo 2. Poiché non verrà abilitato nessun protocollo di instradamento è necessario configurare una rotta
predefinita, verso Internet sul router NAT:
NAT(config)# ip route 0.0.0.0 0.0.0.0 200.200.100.2
Passo 3. Creare una lista di accesso standard che definisce gli indirizzi IP di tutti gli utenti interni:
NAT(config)# access-list 1 permit 192.168.1.0 0.0.0.255
Passo 4. poiché verrà utilizzato il singolo indirizzo indirizzo pubblico (inside global) 200.200.100.1, che
verrà utilizzato per rappresentare tutti gli host interni con indirizzo privato 192.168.1.x, è
necessario applicare la lista di accesso e configurare il NAT con overload o PAT sull'interfaccia
serial0/0 del router NAT.
NAT(config)# ip nat inside source list 1 interface s0/0 overload
Questa configurazione consente agli utenti interni di accedere a Internet, ma un utente esterno
non può direttamente iniziare una comunicazione con un utente interno;
Passo 5. Specifichiamo adesso quali sono le interfaccie interna ed esterna per il NAT.
NAT(config)# interface fastethernet 0/0

NAT(config-if)# ip nat inside
NAT(config-if)# interface serial 0/0

NAT(config-if)# ip nat outside
Usare il comando ping 200.200.50.2 da un PC interno alla rete. Quindi sul router NAT usare
i comandi:

icmp 200.200.100.1:516 192.168.1.5:516 200.200.50.2:516
200.200.50.2:516
icmp 200.200.100.1:517 192.168.1.5:517 200.200.50.2:517
200.200.50.2:517
icmp 200.200.100.1:518 192.168.1.5:518 200.200.50.2:518
200.200.50.2:518
icmp 200.200.100.1:519 192.168.1.5:519 200.200.50.2:519
200.200.50.2:519
icmp 200.200.100.1:520 192.168.1.5:520 200.200.50.2:520
200.200.50.2:520
NAT# show ip nat statistics
Total active translations: 5 (0 static, 5 dynamic; 5 extended)

Outside interfaces:
Serial0/0
Inside interfaces:
FastEthernet0/0
Hits: 25 Misses: 30
Expired translations: 20
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 interface Serial0/0 refcount 5
NAT# show ip nat translations verbose

icmp 200.200.100.1:516 192.168.1.5:516 200.200.50.2:516
200.200.50.2:516
flags:
extended, use_count: 0
icmp 200.200.100.1:517 192.168.1.5:517 200.200.50.2:517
200.200.50.2:517
flags:
icmp 200.200.100.1:518 192.168.1.5:518 200.200.50.2:518
200.200.50.2:518
flags:
icmp 200.200.100.1:519 192.168.1.5:519 200.200.50.2:519
200.200.50.2:519
flags:
icmp 200.200.100.1:520 192.168.1.5:520 200.200.50.2:520
200.200.50.2:520
flags:
Passo 6. Gli utenti Internet, necessitano di accedere al Web Server informativo tramite l'indirizzo
200.200.100.1 sulla porta 80. E' necessario quindi configurare il PAT, cosicchè gli utenti siano
automaticamente ridirezionati verso il Web Server all'indirizzo 192.168.1.5, quando cercano di
collegarsi all'indirizzo IP 200.200.100.1 tramite un browser Web:
NAT(config)# ip nat inside source static tcp 192.168.1.5 80

200.200.100.1 80 extendable
L'opzione extendable alla fine di questo comando NAT statico indica al router di riutilizzare
l'indirizzo pubblico e di salvare le informazioni sufficienti sulle sessioni di comunicazione, in
modo tale da poter distinguere le differenti traslazioni. Questo comando ha l'effetto di traslare
tentativi esterni di accesso alla porte 80 con indirizzo 200.200.100.1 su tentativi interni di
accesso alla porta 80 e indirizzo 192.168.1.5. Il processo di eseguire traslazioni NAT in base
al valore della porta del pacchetto in ingresso è chiamato port forwarding.
Passo 7. Una corretta configurazione del port forwarding è indicata dal fatto che si è in grado di
raggiugere dall'esterno il Web server.

Indirizzamento IP Avanzato

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Indirizzamento IP Avanzato

Caricato da

Copyright:

Formati disponibili

Modulo 2 - Indirizzamento IP Avanzato

Possiamo dunque affermare che la stragrande maggioranza delle organizzazioni utilizza

Sfortunatamente, quando i protocolli TCP/IP furono sviluppati, i progettisti non avevano

2.1 Indirizzamento IPv4

Rappresentazione in notazione decimale puntata (dotted-decimal notation)

I bit possono essere raccolti in ottetti, cioè gruppi di otto bit

10101100 00011110 10000000 00010001

Ogni ottetto o byte viene convertito nel corrispettivo decimale:

172 030 128 017

2.1.2 Indirizzi di classe A e B

Classe B Rete (Network) Host

Classe C Rete (Network) Host

L'appartenenza di ad una classe o a un'altra, determina in un indirizzo IP quali ottetti

In pratica un numero limitato di organizzazioni controllano quasi la metà degli indirizzi

Con gli indirizzi di classe B i progettisti di Internet pensarono di servire le società e le

2.1.3 Indirizzi di classe C, D ed E

Per esempio, un router configurato con il protocollo di instradamento dinamico EIGRP,

Un messaggio multicast è differente da un messaggio broadcast. Mentre questi ultimi

2.1.4 Maschere di sottorete (subnet-mask)

Il mascheramento o subnetting, viene utilizzato per partizionare una rete di grandi

La maschera di sottorete è un numero a 32 bit, che agisce come controparte dell'indirizzo

Quando la maschera di sottorete è definita, ha la precedenza sulla classe di appartenenza

La maschera di sottorete applicata all'indirizzo determina senza ambiguità numero di rete

Maschera di sottorete 255.255.0.0

Le regole dell'indirizzamento a classi prevedono che i primi due ottetti di un indirizzo di

Indirizzo IP 172.24.100.45 Sottorete

Maschera di sottorete 255.255.0.0

Gli indirizzi di Classe A e B costituiscono insieme circa il 75% dello spazio di

Inoltre se anche fossero disponibili ulteriori indirizzi di Classe A, B e C la gestione di così

Infine il sistema originario di suddivisione a classi si è dimostrato poco scalabile e anche

Esaurimento degli indirizzi IPv4 rimanenti. All'epoca gli indirizzi di Classe B

Rapida e sostanziale crescita della dimensione delle tabelle di instradamento

Per affrontare questi problemi l'IETF decise:

2.2.2 CIDR Classess Interdomain Routing – Instradamento interdomini senza classi

I problemi identificati da IETF

I router utilizzano una forma di indirizzamento IPv4 chiamanta CIDR Classless

Caratteristiche del CIDR

Fortemente diminuito lo spreco di indirizzi IP – grazie all'uso di uno schema di

Gestione più efficiente dell'aggregazione delle rotte – chiamata anche con i

Aggregazione delle reti – consente di raggruppare differenti reti contigue

L'immagine precedente elenca una serie di reti di Classe B. Seguendo le regole

10101100 00011000 00000000 00000000 = 172.024.000.000

Pertanto utilizzando 172.024.0.0/13 cioè un singolo indirizzo di rete e la rispettiva

Questa tecnica è consentendo di aggregare le rotte permette di contenere le dimensioni

Processo di instradamento più efficiente;

L'aggregazione o supernetting è dunque una pratica che consente, utilizzando una

2.2.4 Aggregazione e distribuzione degli indirizzi IP

11001111 00010101 0011011

Grazie al CIDR gli indirizzi IP possono essere distribuiti in maniera gerarchica e

Distribuzione efficiente degli indirizzi;

Le maschere di sottorete a lunghezza variabile o VLSM Variable-Length Subnet Mask

Num. Sottorete Indirizzo di sottorete

Applicando una maschera di sottorete di 27 bit

Sfortunatamente rimangono soltanto tre sottoreti disponibili per eventuali espansioni

Utilizzo della tecnica VLSM

Partizionare subnetting ulteriormente la sottorete 207.21.24.192/27 consente di

Le maschere di sottorete a lunghezza variabile o VLSM forniscono un meccanismo

Utilizzando VLSM è possibile utilizzare maschere di differente lunghezza per ogni

2.3.2 Protocolli di Instradamento con classi e senza classi

Protocolli di instradamento a Classi Protocolli di instradamento senza classi

Per determinare il prefisso di rete di un indirizzo i protocolli di instradamento a classi

Gli aggiornamenti inviati non comprendono le informazioni sulle maschere di

Gli aggiornamenti vengono inviati utilizzando indirizzi di broadcast con conseguente

Non è previsto nessun meccanismo di autenticazione;