Il protocollo IPv6 e progetto di una rete aziendale

UNIVERSITA’ DEGLI STUDI DI PISA

FACOLTA’ DI INGEGNERIA Corso di Laurea Triennale in Ingegneria Informatica

Il protocollo IPv6 e progetto di una rete aziendale

Relatore: Prof. ENZO MINGOZZI

Tesi di Laurea di: IRENE BONTA’

Matricola: 302917

Anno Accademico 2008-2009

Il protocollo IPv6 e progetto di una rete aziendale Pagina 2

Sommario

1. INTRODUZIONE ................................................................................................................................... 6

1.1. Cos’è IPv6 ..................................................................................................................................................... 6

1.2. Perché IPv6 ................................................................................................................................................... 7

1.3. La nascita di IPv6 ........................................................................................................................................... 8

1.4. Problemi pratici per gli ISP ............................................................................................................................ 9

1.5. Riferimenti ...................................................................................................................................................10

2. CARATTERISTICHE DI IPV6 ......................................................................................................... 11

2.1. Indirizzo IPv6, notazione e rappresentazione del prefisso di rete .................................................................11

2.2. Allocazione dello spazio degli indirizzi IPv6 ..................................................................................................12

2.3. Formato degli indirizzi IPv6 Global Unicast ..................................................................................................13

2.4. Identificatori di interfaccia e mapping degli indirizzi fisici ............................................................................15

2.5. Indirizzi speciali ............................................................................................................................................18

2.6. Indirizzi multicast e anycast .........................................................................................................................18 2.6.1. Indirizzi multicast .......................................................................................................................................... 19 2.6.2. Indirizzi anycast ............................................................................................................................................. 21

2.7. Il pacchetto IPv6 ..........................................................................................................................................22

2.8. Autoconfigurazione e rinumerazione ...........................................................................................................25

2.9. Riferimenti: ..................................................................................................................................................26

3. IPV6: CHE COSA CAMBIA ............................................................................................................... 27

3.1. Nuovo formato di intestazione ....................................................................................................................27

3.2. Spazio di indirizzi più esteso .........................................................................................................................28

3.3. Frammentazione ..........................................................................................................................................29

3.4. Multicast ......................................................................................................................................................29

3.5. Configurazione di indirizzi con e senza informazioni sullo stato ...................................................................30

3.6. Protocollo DHCPv6 .......................................................................................................................................30

3.7. Protocollo ICMPv6 .......................................................................................................................................30

3.8. Protezione incorporata ................................................................................................................................31

3.9. Miglior supporto della qualità del servizio (QoS) .........................................................................................31


3.10. Nuovo protocollo per l'interazione tra nodi adiacenti ..................................................................................32

3.11. Estensibilità ................................................................................................................................................32

3.12. Riferimenti ...................................................................................................................................................32

4. LA TRANSIZIONE AD IPV6 ............................................................................................................ 33

4.1. Migrazione degli host ...................................................................................................................................33

4.2. Migrazione a livello di rete ...........................................................................................................................34 4.2.1. Tunnel configurati ......................................................................................................................................... 36 4.2.2. Indirizzi “IPv4-compatible” ........................................................................................................................... 36 4.2.3. Tunnel 6over4 ............................................................................................................................................... 37 4.2.4. Tunnel 6to4 ................................................................................................................................................... 37 4.2.5. Tunnel Broker ................................................................................................................................................ 40 4.2.6. ISATAP ........................................................................................................................................................... 41 4.2.7. Teredo ........................................................................................................................................................... 41

4.3. Traduttori di protocollo ...............................................................................................................................41

4.4. Traduttori a livello IP ...................................................................................................................................42 4.4.1. SIIT ................................................................................................................................................................. 42 4.4.2. NAT-PT ........................................................................................................................................................... 43

4.5. Traduttori a livello di trasporto ....................................................................................................................44 4.5.1. Transport Relay Translator ........................................................................................................................... 44

4.6. Traduttori implementati via software ..........................................................................................................45 4.6.1. BIS e BIA ........................................................................................................................................................ 45

4.7. Una rete eterogenea ....................................................................................................................................46

4.8. Riferimenti ...................................................................................................................................................47

5. CONCLUSIONI .................................................................................................................................... 48

6. BIBLIOGRAFIA .................................................................................................................................. 49


PROGETTO DI RETE LOCALE PER UNA REALTÀ AZIENDALE: NCBN SRL ............... 50

1. SCENARIO DI PROGETTO E SPECIFICA DEI REQUISITI UTENTE ..................................... 50

1.1. Scenario di progetto ....................................................................................................................................50

1.2. Task individuale ...........................................................................................................................................52

1.3. Planimetrie ..................................................................................................................................................53

2. ANALISI DEL PROGETTO, SPECIFICA DEI REQUISITI TECNICI E ORGANIZZAZIONE DELLE ATTIVITÀ DI PROGETTO. ........................................................................................................ 57

2.1. Analisi del progetto ......................................................................................................................................57

2.2. Specifica dei requisiti tecnici ........................................................................................................................57

2.3. Funzionalità utilizzate per soddisfare i requisiti ...........................................................................................59

2.4. Architettura d'insieme del progetto .............................................................................................................61

2.5. Convenzioni e linee guida di progettazione ..................................................................................................62

2.6. Organizzazione dei moduli di progetto e attribuzione delle relative risorse .................................................63

3. RETE AREA COMUNE ...................................................................................................................... 67

3.1. Architettura della rete a comune .................................................................................................................67

3.2. Cablaggio strutturato della rete comune .....................................................................................................68

3.3. Dispositivi attivi e layer 2 della rete comune ...............................................................................................69

3.4. Piano di indirizzamento ...............................................................................................................................70 3.4.1. Suddivisione dello spazio di indirizzamento interno ..................................................................................... 70 3.4.2. Piano di indirizzamento pubblico .................................................................................................................. 71

3.5. Dispositivi impiegati in ogni Distribution Facilities della rete comune .........................................................73 3.5.1. MDF ............................................................................................................................................................... 73 3.5.2. Tabella riassuntiva dispositivi impiegati ........................................................................................................ 74

3.6. Configurazione dei dispositivi della rete comune .........................................................................................75

4. GUIDA AL CAMBIO DI ISP .............................................................................................................. 80

5. AREA SINGOLA AZIENDA .............................................................................................................. 86

5.1. Cablaggio strutturato della rete dell’azienda NcbN .....................................................................................86

5.2. Struttura della rete dell’azienda NcbN ........................................................................................................90 5.2.1. Struttura logica .............................................................................................................................................. 90

5.2.2. Domini di sicurezza della rete dell’azienda NcbN ........................................................................................91


5.3. Piano di indirizzamento della rete dell’azienda NcbN .................................................................................93

5.4. Dispositivi impiegati in ciascuna Distribution Facilities dell’azienda NcbN ..................................................98 5.4.1. IDF .................................................................................................................................................................. 98 5.4.2. Tabella riassuntiva. ...................................................................................................................................... 101

5.5. Configurazione dei dispositivi della rete dell’azienda NcbN ....................................................................... 102 Router NcbN .............................................................................................................................................................. 102 Switch North Building ................................................................................................................................................ 105 Switch Polo E .............................................................................................................................................................. 107 Switch Polo F .............................................................................................................................................................. 109

6. CARATTERISTICHE SPECIFICHE DELLA SIMULAZIONE CON PACKET TRACER ....... 111

1. NAT statico (NcbN.pkt – scenario 0) ............................................................................................................... 111

2. Comunicazione tra PC e server appartenenti alla stessa VLAN (NcbN.pkt – scenario 1) .................................. 114

3. DHCP (NcbN.pkt – scenario 2) ......................................................................................................................... 116

4. ACL (NcbN.pkt – scenario 3) ........................................................................................................................... 118

5. Una comunicazione non permessa (NcbN.pkt – scenario 4) ............................................................................ 119


1. Introduzione

Sono passati alcuni anni da quando il protocollo IPv6 è stato specificato. In questi anni l‟attuale

versione del protocollo IP ha mostrato capacità di sopravvivenza inimmaginabili, pur tuttavia le

ragioni per un nuovo protocollo non sono venute meno e l‟esaurimento degli indirizzi IP sta

diventando una preoccupazione concreta per gli Internet Service Provider.

IPv6 offre uno spazio d‟indirizzamento davvero ampio e propone nuovi meccanismi per la

configurazione automatica dei terminali; queste novità sono sufficienti a fare di IPv6 un protocollo

incompatibile con IPv4 e quindi a rendere il problema della migrazione alquanto complesso.

I Service Provider stanno studiando le modalità più opportune per affiancare il trasporto di IPv6 a

quello di IPv4 con i minimi impatti su tutte le componenti tecnologiche, infrastrutture di rete,

piattaforme di controllo, servizio e gestione e terminali d‟utente.

Si prospetta all‟orizzonte uno scenario in cui i due protocolli coesisteranno a lungo e anche altri

segnali fanno intravedere la prospettiva di una rete sempre più eterogenea. La nuova frontiera del

networking potrebbe proprio essere quella di gestire secondo nuovi paradigmi questa realtà

diversificata.

1.1. Cos’è IPv6

IPv6 è la nuova versione di IP che succede a IPv4, protocollo che è alla base di Internet, delle

Intranet e di molte reti aziendali.

Alla fine degli anni ‟70, quando fu definito il protocollo IPv4 ancora oggi in uso [1], un campo

indirizzo di 32 bit, corrispondente ad uno spazio di 2^32 (circa 4,3 miliardi) di indirizzi, sembrò

sufficiente a soddisfare ogni possibile espansione di Internet.

Tuttavia, già nella metà degli anni ‟90, apparve chiaro che la limitazione dello spazio di

indirizzamento, anche a causa delle soluzioni tecniche e delle politiche di assegnazione adottate,

sarebbe diventato a breve un vincolo all‟espansione della rete. Furono quindi adottate soluzioni

tecniche per contrastare l‟esaurimento degli indirizzi (principalmente CIDR e NAT [2]), e fu

operata una prima revisione delle politiche di assegnazione.

Le soluzioni tecniche introdotte e le nuove politiche di assegnazione hanno determinato, nella

seconda metà degli anni ‟90, un evidente rallentamento nella corsa agli indirizzi, come evidente

dall‟andamento della curva in figura.


Tuttavia, dal 2001, in corrispondenza dell‟espansione della rete in tutti i continenti ed, ultimamente,

dell‟accesso alla rete dati anche da parte dei terminali mobili, la crescita è ripresa.

Sono state fatte varie previsioni realistiche sulla possibile data di esaurimento [3]. Dal 2004 al 2009

sono state assegnate 54 classi A, circa 10 l‟anno, con un picco di 13 nel 2007. Ne rimangono 31 da

allocare; a questi ritmi, potranno bastare per 24/36 mesi. Quindi, se nulla di nuovo succede, entro il

2012 non saranno più disponibili indirizzi IPv4.

1.2. Perché IPv6

La risposta è semplice: "Internet sta diventando vittima del suo successo".

Il grande successo di Internet e delle Intranet va di pari passo con quello dell‟architettura di rete che

ne è alla base. Il protocollo IPv4 si è dimostrato affidabile, facile da implementare e interoperativo,

nonché scalabile dalle dimensioni di un sistema di reti semplice fino a quelle di un'utilità globale

qual è Internet oggi. Ciò va ascritto alla struttura di progettazione iniziale.

La configurazione iniziale non prendeva tuttavia in considerazione i seguenti elementi:

La recente crescita esponenziale di Internet e il sempre più prossimo esaurimento dello

spazio indirizzi IPv4: gli indirizzi IPv4 sono diventati relativamente rari, per cui in alcune è

necessario utilizzare un traduttore di indirizzi di rete (NAT, Network Address Translator)

per la mappatura di più indirizzi privati su un unico indirizzo IP pubblico. I NAT

consentono il riutilizzo dello spazio indirizzi privato, ma non supportano la protezione dei

livelli di rete basata sugli standard, né il mapping corretto di tutti i protocolli di livello

superiore e possono creare problemi in caso di connessione tra due organizzazioni che

utilizzano lo spazio indirizzi privato. Inoltre, la crescita continua del numero di dispositivi e

apparecchiature connesse a Internet fa prevedere che lo spazio indirizzi IPv4 pubblico verrà

esaurito.


La crescita di Internet e la capacità di gestione di tabelle di routing di grandi dimensioni da

parte dei router backbone di Internet: la modalità precedente e corrente di allocazione degli

ID di rete IPv4 fa sì che nelle tabelle di routing dei router backbone di Internet siano

normalmente presenti oltre 70.000 route. L'infrastruttura di routing Internet IPv4 corrente è

una combinazione di routing semplice e routing gerarchico.

La necessità di una configurazione più semplice: la maggior parte delle implementazioni

IPv4 correnti va configurata manualmente o tramite un protocollo di configurazione

indirizzi con informazioni sullo stato, quale DHCP. A fronte del numero crescente di

computer e dispositivi che utilizzano il protocollo IP è necessaria una struttura di

configurazione più semplice e automatizzata degli indirizzi e di altre impostazioni non

basate sull'amministrazione di un'infrastruttura DHCP.

I requisiti di protezione a livello del protocollo IP: le comunicazioni private su un supporto

pubblico quale Internet richiedono servizi di crittografia, che impediscano la visualizzazione

e la modifica dei dati inviati durante il transito. Sebbene sia presente uno standard per la

protezione dei pacchetti IPv4, denominato Internet Protocol Security o IPSec, tale standard è

facoltativo e spesso sostituito da soluzioni interne.

La necessità di un supporto migliore per la trasmissione di dati in tempo reale (definita come

qualità del servizio): sebbene esistano standard di qualità del servizio (QoS, Quality of

Service) per IPv4, il supporto del traffico in tempo reale si basa sul campo IPv4 TOS (Type

of Service) e sull'identificazione del payload, in genere tramite una porta UDP o TCP. Il

campo IPv4 TOS ha tuttavia una funzionalità limitata ed è soggetto a diverse interpretazioni.

Inoltre, l'identificazione del payload tramite una porta TCP e UDP non è possibile quando il

payload del pacchetto IPv4 è crittografato.

Per ovviare a tali inconvenienti, il gruppo IETF ha sviluppato una suite di protocolli e standard noti

come IPv6 (IP versione 6). La nuova versione applica molti metodi proposti per l'aggiornamento del

protocollo IPv4. Per garantire un impatto minimo di IPv6 sui protocolli di livello superiore e

inferiore, l'aggiunta arbitraria di nuove funzionalità è stata limitata al minimo indispensabile.

Ma allora che fine ha fatto IPv5? Il numero di versione 5 è stato assegnato a un protocollo

sperimentale di streaming flow-oriented (ST2+, definito nel RFC 1819 [4]), simile a IPv4, ma

rivolto al supporto video e audio.

1.3. La nascita di IPv6

Il protocollo IPv6 rappresenta l'evoluzione di molte proposte di IETF e di diversi gruppi di lavoro

incentrati sullo sviluppo di un IP Next Generation. Esso rappresenta oltre tre anni di sforzi

concentrati su quest‟argomento.

La creazione di gruppi di lavoro avvenne al meeting IETF del 1992 svoltosi a Boston.

Dall‟inverno del 1992, la comunità di Internet sviluppò quattro proposte separate per IPng. Queste

erano "CNAT", "IP encaps", "Nimrod", e "Simple CLNP". Dal dicembre 1992 si aggiunsero altre

tre proposte: "The P Internet Protocol" (PIP), "The Simple Internet Protocol" (SIP) e "TP/IX". Nella

primavera del 1992, il "Simple CLNP" si evolse in "TCP and UDP with Bigger Addresses" (TUBA)

mentre "IP encaps" si evolse in "IP Address Encapsulation" (IPAE).


Nell‟autunno del 1993, IPAE si fuse con SIP, pur mantenendo il nome di SIP. Questo gruppo si

fuse poi con PIP e il gruppo di lavoro risultante prese il nome di "Simple Internet Protocol Plus"

(SIPP), in seguito chiamato IPv6. Allo stesso tempo il gruppo di lavoro TP/IX cambiò nome in

"Common Architecture for the Internet" (CATNIP).

Ogni proposta prevedeva soluzioni diverse per risolvere il problema:

TUBA proponeva l‟utilizzo di indirizzi Network Service Access Point (NSAP) fissi a 20

ottetti;

SIP proponeva un IP con indirizzi su 64 bit;

IPAE proponeva una sorta di “IP in IP”; in altre parole due livelli di IP uno sopra l‟altro, un

IP per interconnessioni mondiali e un IP per interconnessioni locali;

PIP prevedeva un approccio innovativo riguardo alle politiche di routing e alla mobilità;

CATNIP prevedeva l‟integrazione di diversi protocolli di rete (IP, CLNP, IPX) e di

trasporto (TP4, SPX, TCP, UDP);

SIPP proponeva indirizzi su 128 bit.

SIPP puntava al mantenimento delle caratteristiche positive, alla correzione di quelle negative e alla

semplicità, estendendo gli indirizzi e eliminando i campi superflui.

Grazie alla sua semplicità architetturale, IPv6 (SIPP) fu raccomandato dagli IPng Area Directors di

IETF al meeting IETF di Toronto il 25 Luglio 1994 nel RFC 1752 [5], The Recommendation for the

IP Next Generation Protocol. La raccomandazione fu approvata dall‟Internet Engineering Steering

Group e resa standard il 17 Novembre 1994.

Il nucleo dei protocolli IPv6 fu steso in una draft standard il 10 Agosto 1998.

1.4. Problemi pratici per gli ISP

L‟esaurimento degli indirizzi IPv4 sta progressivamente trasformandosi da un tema di studio, ad un

problema pratico per gli ISP: ad oggi le richieste di indirizzi da parte degli ISP verso gli enti di

assegnazione regionali vengono ancora soddisfatte, ma sono aumentati i tempi burocratici per

ottenere gli spazi di indirizzamento richiesti.

Le tecniche di NAT, se da una parte sono sempre state osteggiate da parte degli architetti di

Internet, hanno sempre trovato terreno abbastanza fertile tra gli ISP.

IPv6 dal punto di vista degli ISP è sicuramente una scelta molto più controversa. Il regime di

concorrenza impone ad essi attenzione alle richieste del mercato, alla stabilità delle reti e ai costi

delle soluzioni fornite. IPv6 sembra andare contro tutti questi principi basilari della fase

commerciale di Internet. Non vi è richiesta da parte del mercato perché non vi sono ad oggi nuove

prestazioni abilitate in IPv6 che non siano già disponibili in IPv4. Dal punto di vista della stabilità

della rete, anche se negli ultimi dieci anni si sono moltiplicate le sperimentazioni, vale la massima

generale, che ogni cambiamento introduce necessariamente transitori in cui si creano disservizi. Da

ultimo i costi: per partire occorre intervenire riprogettando la rete, formando il personale,

aggiornando le release sulle macchine; nel transitorio in cui la rete sarà dual stack, occorre disporre


di macchine con prestazioni maggiori in grado di gestire entrambi i protocolli; per completare la

migrazione infine occorre sostituire gli apparati più vecchi, non in grado di evolvere ad IPv6 e

migrare conseguentemente l‟utenza che da questi è servita.

Nei Service Provider è, quindi, ancor oggi radicata la convinzione che, anche se il passaggio ad

IPv6 sarà inevitabile, saranno necessariamente coloro che si muoveranno per primi a sostenere i

maggiori costi e ad avere maggiori ritorni negativi. Secondo questa logica è quindi conveniente

procrastinare l‟introduzione di IPv6 il più a lungo possibile. Ma è davvero questa la logica corretta?

Il dubbio è più che legittimo; la migrazione verso IPv6 come detto è un processo molto lungo e chi

parte troppo tardi rischia di trovarsi in difficoltà, esattamente come chi inizia la migrazione troppo

presto.

Dal punto di vista degli ISP quindi l‟unica strategia vincente, o forse non perdente, è quella di un

progressivo adeguamento dell‟infrastruttura, con una realistica attenzione ai costi.

1.5. Riferimenti

[1] RFC 791 Internet Protocol http://www.rfc-editor.org/rfc/rfc791.txt

[2] CIDR: RFC 4632 http://www.rfc-editor.org/rfc/rfc4632.txt; NAT: RFC 3022 http://www.rfc-

editor.org/rfc/rfc3022.txt

[3] http://www.potaroo.net/tools/ipv4/index.html

[4] RFC 1819 Internet Stream Protocol http://www.rfc-editor.org/rfc/rfc1819.txt

[5] RFC 1752 http://www.rfc-editor.org/rfc/rfc1752.txt

http://www.rfc-editor.org/rfc/rfc791.txt




http://www.potaroo.net/tools/ipv4/index.html




2. Caratteristiche di IPv6

Vediamo ora quali sono le principali caratteristiche di IPv6, necessarie per comprendere al meglio

le relazioni di interoperabilità con l‟attuale versione del protocollo.

Analizzeremo quindi nel dettaglio lo spazio di indirizzamento e le tipologie di indirizzi IPv6, il

formato dell‟header IPv6 e le sue estensioni, i sistemi di autoconfigurazione e di rinumerazione.

2.1. Indirizzo IPv6, notazione e rappresentazione del prefisso di rete

Per soddisfare l‟incremento esponenziale del numero di utenti e dispositivi connessi a Internet, la

nuova versione dell‟Internet Protocol introduce un nuovo formato di indirizzi a 128 bit.

Un indirizzo IPv6 è di solito rappresentato da sedici campi ognuno dei quali rappresenta un numero

decimale da 0 a 255 o da otto campi di quattro cifre esadecimali (otto parole di 16 bit ciascuna)

separati da “:”. Per esempio:

128.91.45.157.220.40.0.0.0.0.252.87.212.200.31.255 (notazione dotted decimal)

805B:2D9D:DC28:0000:0000:FC57:D4C8:1FFF (notazione colo hexadecimal)

Per brevità di notazione, poi, è possibile sostituire (tecnica zero compression) sequenze contigue di

valori nulli con un unico campo vuoto ed omettere eventuali zeri in testa di ciascun campo.

805B:2D9D:DC28::FC57:D4C8:1FFF

È possibile sapere quanti zeri sono stati rimpiazzati dai due punti poiché si vedono quanti campi

non compressi ci sono nell‟indirizzo. In questo caso sono sei, quindi :: rappresenta due campi di

zeri. Per evitare ambiguità, i doppi due punti possono apparire solo una volta in ogni indirizzo IP,

perché se così non fosse, non si potrebbe sapere quanti zeri sono stati rimpiazzati da ognuno di loro.

C‟è un‟ultima notazione alternativa, detta notazione mista, usata in alcuni casi, soprattutto per

esprimere indirizzi IPv6 che incorporano al loro interno indirizzi IPv4. Per questi, è utile mostrare

la porzione di indirizzo IPv4 nella vecchia notazione decimale puntata. Poiché si usano 32 bit per

l‟indirizzo IPv4, la notazione presenta i primi 96 bit in notazione esadecimale e gli ultimi 32 in

notazione decimale. A tal proposito, si può scrivere per esempio:

805b2D9D:DC28::FC57:212.200.31.255

Come gli indirizzi IPv4 classless, gli indirizzi IPv6 sono fondamentalmente divisi in una parte

identificativa della rete (prefisso) seguita da una parte identificativa dell‟host. La lunghezza del

prefisso è indicata come per gli indirizzi classless IPv4 da un carattere “/” seguito dal numero di bit

che lo compongono. Per esempio:

805B: 2D9D:DC28::FC57:D4C8:1FFF/48


2.2. Allocazione dello spazio degli indirizzi IPv6

Come era stato per IPv4, due delle cose principali che riguardavano la divisione dello spazio degli

indirizzi IPv6 furono l‟assegnamento degli indirizzi e il routing. I progettisti di IPv6 volevano

strutturare lo spazio degli indirizzi in modo da rendere l‟allocazione degli indirizzi da parte degli

ISP, delle organizzazioni e dei singoli il più semplice possibile.

L‟allocazione di parti diverse dello spazio degli indirizzi è ancora una volta basata su particolari

sequenze di bit più significativi (da tre a dieci) dell‟indirizzo, così da permettere ad alcune categorie

di avere più indirizzi degli altri.

Per comprendere la tabella, è utile vedere l‟indirizzo IPv6 come suddiviso in otto parti. Di queste,

una (001) è stata riservata agli indirizzi unicast, una seconda (000) è stata usata per ricavarvi

blocchi di indirizzi riservati più piccoli, una terza (111) è stata usata per sottoblocchi per indirizzi

local e multicast. Cinque non sono ancora state assegnate.


2.3. Formato degli indirizzi IPv6 Global Unicast

Gli indirizzi unicast sono quelli più utilizzati per il traffico Internet in IPv6, così come in IPv4. Per

questo motivo il più grande blocco dello spazio degli indirizzi IPv6 (001) è dedicato

all‟indirizzamento unicast.

Il modo più semplice per dividere i 128 bit dello spazio degli indirizzi unicast è in tre parti:

CAMPO LUNGHEZZA

(BIT)

DESCRIZIONE

Prefisso n ID della rete o prefisso dell‟indirizzo usato per il routing

ID sottorete m Numero che identifica una sottorete

ID

interfaccia

128-n-m Identificatore univoco di una particolare interfaccia

dell‟host

Il prefisso e l‟identificatore di sottorete rappresentano i due livelli base sui quali gli indirizzi devono

essere costruiti gerarchicamente, ovvero livello globale e livello specifico locale. La topologia

pubblica è l'insieme degli ISP maggiori e minori che offrono accesso alla rete Internet IPv6. La

topologia locale è l'insieme delle subnet all'interno del sito di un'organizzazione. L'identificatore di

interfaccia identifica un'interfaccia specifica in una subnet all'interno del sito di un'organizzazione

(RFC 2374 An IPv6 Aggregatable Global Unicast Address Format [1]).

In teoria possono essere usati due valori n e m qualsiasi, ma in genere si assegnano 48 bit al prefisso

e 16 bit all‟identificatore di sottorete. Gli altri 64 bit sono così disponibili per gli identificatori di

interfaccia.

Come si vede, i 16 bit dell‟identificatore di sottorete permettono una certa flessibilità nella

creazione di sottoreti. Per esempio:

Una piccola organizzazione può semplicemente lasciare tutti i bit dell‟identificatore di

sottorete a zero per avere una struttura interna piatta;

Un‟organizzazione di media grandezza potrebbe utilizzare tutti i bit dell‟identificatore e

implementare una sorta di subnetting come in IPv4, assegnando un diverso identificatore a

ogni sottorete. Con 16 bit, si possono identificare 65536 sottoreti diverse!

Una grande organizzazione può usare ogni bit e creare una gerarchia multilivello di sottoreti,

proprio come per il VLSM in IPv4.


Il prefisso è diviso gerarchicamente in modo simile. Ci sono 45 bit disponibili (48 meno i primi tre

fissi a 001), sufficienti a creare una topologia gerarchica a due livelli. L‟organizzazione è la

seguente:

ID TLA: il campo ID TLA indica l'identificatore dell'aggregazione del livello superiore

(Top Level Aggregation Identifier) dell'indirizzo. La dimensione del campo è 13 bit. Il TLA

identifica il livello più alto della gerarchia di routing. I TLA sono amministrati dalla IANA e

allocati in registri Internet locali che a loro volta allocano i singoli ID TLA a provider di

servizi Internet (ISP, Internet Service Provider) globali. Un campo di 13 bit può contenere

fino a 8.192 ID TLA diversi. Per i router del livello più alto della gerarchia di routing di

Internet IPv6 non è disponibile una route predefinita ma solo route con prefissi di 16 bit che

corrispondono ai TLA allocati.

Riservato: il campo Riservato è riservato per un utilizzo futuro per l'espansione della

dimensione dell'ID TLA o dell'ID NLA. La dimensione del campo è 8 bit.

ID NLA: il campo ID NLA indica l'identificatore dell'aggregazione del livello successivo

(Next Level Aggregation Identifier) dell'indirizzo. L'ID NLA identifica il sito di un cliente

specifico. La dimensione del campo è 24 bit. L'ID NLA consente all'ISP di creare più livelli

di gerarchia di indirizzamento per organizzare l'indirizzamento e il routing e per identificare

i siti. La struttura della rete dell'ISP non è visibile ai router senza route predefinita.

I 48 bit del prefisso possono, dunque, essere suddivisi in tre livelli:

CAMPO LUNGHEZZA

(BIT) DESCRIZIONE

Identificatore

unicast 3 Ogni indirizzo unicast comincia con 001.

ID livello 1 10

Identificatore del livello più alto della gerarchia. Viene

usato per assegnare un grande blocco di indirizzi nella rete

globale alle più grandi organizzazioni.

ID livello 2 12

Ogni blocco assegnato a un‟organizzazione di livello 1

dispone di 12 bit per creare 4096 blocchi di indirizzi da

dividere tra le organizzazioni di livello più basso che essa

serve.

ID livello 3 23 Ogni organizzazione di livello 2 ha 23 bit da usare per


dividere il suo blocco di indirizzi di livello 2. In questo

modo possono essere creati oltre 8 miliardi di blocchi di

indirizzi /48 da assegnare a utenti finali. Altrimenti, i 23 bit

possono essere ulteriormente divisi in livelli più bassi.

I vari modi di suddivisione sono riassunti nel seguente schema:

2.4. Identificatori di interfaccia e mapping degli indirizzi fisici

Con IPv6 viene creato un miglior modo di mappare indirizzi IP unicast e indirizzi fisici di rete. I bit

a disposizione per l‟identificatore di interfaccia sono 64. Questo consente una maggiore flessibilità

e permette di amministrare le reti in maniera più semplice.

Di seguito sono descritti i diversi modi in cui viene determinato un identificatore di interfaccia:


Nel RFC 2373 [2] viene affermato che in tutti gli indirizzi unicast con i prefissi da 001 a 111

è necessario utilizzare anche un identificatore di interfaccia di 64 bit derivato dall'indirizzo

(EUI)-64 (Extended Unique Identifier);

Nella RFC 3041 [3] viene descritto un identificatore di interfaccia casuale che viene

modificato nel tempo per garantire l'anonimato;

Un identificatore di interfaccia viene assegnato durante la configurazione automatica degli

indirizzi con informazioni sullo stato;

Un identificatore di interfaccia può essere configurato manualmente.

Gli identificatori di interfaccia tradizionali delle schede di rete utilizzano un indirizzo a 48 bit

denominato indirizzo IEEE 802. Questo tipo di indirizzo include l'ID azienda di 24 bit e l'ID

estensione di 24 bit, denominati anche rispettivamente ID produttore e ID scheda. La combinazione

dell'ID azienda, specifico del produttore di schede di rete, e dell'ID scheda, specifico di ogni scheda

di rete assemblata, dà origine a un indirizzo a 48 bit univoco globale. L'indirizzo a 48 bit è noto

anche come indirizzo fisico, hardware o MAC (Media Access Control).

L'indirizzo IEEE 802 include i seguenti bit definiti:

Universale/Locale (U/L): il bit U/L è il settimo bit del primo byte e consente di determinare

se l'indirizzo è amministrato universalmente o localmente. Se il bit U/L è impostato su 0,

l'indirizzo è amministrato dall'IEEE attraverso la designazione di un ID azienda univoco. Se

il bit U/L è impostato su 1, l'indirizzo è amministrato localmente, ovvero l'amministratore di

rete ha ignorato l'indirizzo originale e ha specificato un indirizzo diverso;

Individuale/di gruppo (I/G): il bit I/G è il bit meno significativo del primo byte e consente di

determinare se l'indirizzo è individuale (unicast) o di gruppo (multicast). Se il bit è

impostato su 0, l'indirizzo è unicast. Se il bit è impostato su 1, l'indirizzo è multicast.

Nell'indirizzo di una scheda di rete 802.x, entrambi i bit U/L e I/G sono impostati su 0 indicando un

indirizzo MAC unicast universale.

L'indirizzo IEEE EUI-64 (extended unique identifier), invece, rappresenta un nuovo standard per

l'indirizzamento delle interfacce di rete. Gli indirizzi EUI-64 vengono assegnati alla scheda di rete o

derivati dagli indirizzi IEEE 802. L'ID azienda di 24 bit e l'ID estensione di 40 bit creano uno

spazio di indirizzi di dimensioni maggiori per il produttore di schede di rete. I bit U/L e I/G

vengono utilizzati nell'indirizzo EUI-64 in modo analogo all'indirizzo IEEE 802.

Per creare un indirizzo EUI-64 da un indirizzo IEEE 802, i 16 bit di 11111111 11111110 (0xFFFE)

vengono inseriti nell'indirizzo IEEE 802 tra l'ID azienda e l'ID estensione.


Per ottenere l'identificatore di interfaccia a 64 bit per gli indirizzi unicast IPv6, il bit U/L

nell'indirizzo EUI-64 viene reso complementare (modified EUI-64), ovvero se il valore è 1, viene

impostato su 0, mentre se il valore è 0, viene impostato su 1.

Per ottenere un identificatore di interfaccia IPv6 da un indirizzo IEEE 802, è necessario innanzi

tutto eseguire il mapping dell'indirizzo IEEE 802 su un indirizzo EUI-64, quindi rendere

complementare il bit U/L.


2.5. Indirizzi speciali

Una piccola parte dello spazio di indirizzi IPv6 (0,1%) è riservato ad indirizzi speciali. Il compito di

questi indirizzi o blocchi di indirizzi è quello di fornire indirizzamento per servizi particolari e per

l‟utilizzo privato in reti IPv6.

Ci sono quattro tipi di indirizzi speciali:

Riservati: una parte dello spazio di indirizzi è riservato per vari usi di IETF. Il blocco di

indirizzi riservati si trova in cima allo spazio di indirizzi e comincia con 0000 0000. Esso

rappresenta 1/256 dello spazio totale;

Privati: gli indirizzi privati sono validi esclusivamente su uno specifico link fisico o

all‟interno dell‟organizzazione locale. Hanno i primi nove bit a 1111 1110 1, ovvero in

esadecimale hanno un primo ottetto FE. Questi indirizzi sono ulteriormente divisi in due

tipi: site-local e link-local:

▪ Indirizzi site-local (FEC0::/10): sono validi esclusivamente all‟interno

dell‟organizzazione locale. In notazione esadecimale, questi indirizzi cominciano

con FE, seguiti poi da C a F per la terza cifra; quindi cominciano con FEC, FED,

FEE, FEF. Il loro uso è stato sconsigliato nel settembre 2004 con il RFC 3879 [4].

▪ Indirizzi link-local (FE80::/10): sono validi esclusivamente sullo specifico link

fisico. Servono, quindi, solo per la comunicazione locale su un particolare segmento

di rete. Possono essere usati per la configurazione degli indirizzi o per funzioni di

neighbor discovery. Cominciano con FE, seguiti poi da 8 a B per la terza cifra

esadecimale. Quindi cominciano con FE8, FE9, FEA, FEB.

Loopback: è un indirizzo associato al dispositivo di rete che ripete come eco tutti i pacchetti

che gli sono indirizzati. L‟indirizzo di loopback è 0:0:0:0:0:0:0:1, espresso usando la tecnica

zero compression come ::1;

Non specificato: l‟indirizzo composto da tutti zeri (::) viene utilizzato per indicare qualsiasi

indirizzo e viene utilizzato esclusivamente a livello software. Di solito viene utilizzato nel

campo sorgente di un datagramma da un dispositivo che richiede un indirizzo IP per la

configurazione.

2.6. Indirizzi multicast e anycast

Una delle modifiche più significative introdotte dal modello di indirizzamento IPv6 riguarda i tipi di

indirizzi e il modo in cui esse vengono utilizzati. Sebbene gli indirizzi unicast siano ancora la

stragrande maggioranza nelle comunicazioni, i metodi di indirizzamento sono diversi in IPv6. Gli

indirizzi broadcast come specifica classe di indirizzamento sono stati eliminati. Invece, il supporto

al multicast è stato espanso e ciò ha richiesto l‟introduzione di un nuovo tipo di indirizzi detti

anycast.


2.6.1. Indirizzi multicast

Il multicasting è utilizzato per permettere a un singolo dispositivo di inviare un datagramma a un

gruppo di destinatari. Mentre IPv4 supportava l‟indirizzamento multicast mediante l‟utilizzo del

blocco di indirizzi di classe D, sotto IPv6 gli indirizzi multicast appartengono al rispettivo blocco.

Esso rappresenta 1/256 dello spazio degli indirizzi e comprende tutti gli indirizzi che cominciano

con 1111 1111, ovvero ogni indirizzo che comincia con FF in notazione decimale è un indirizzo

multicast IPv6. L‟allocazione degli indirizzi multicast è simile in un certo senso a quella vista per

gli indirizzi unicast. Il formato degli indirizzi multicast è il seguente:

Flags: il campo “flags” identifica gli indicatori impostati sull'indirizzo multicast. La

dimensione del campo è 4 bit. Come descritto nella RFC 2373, l'unico indicatore definito è

l'indicatore T (Transitorio). L'indicatore T utilizza il bit di ordine inferiore del campo flags (i

primi tre sono inutilizzati e vengono lasciati a 0). Se impostato su 0, l'indicatore T indica che

l'indirizzo multicast è un indirizzo multicast assegnato permanentemente (conosciuto)

allocato dalla IANA (Internet Assigned Numbers Authority). Se impostato su 1, l'indicatore

T indica che l'indirizzo multicast è un indirizzo temporaneo (non assegnato

permanentemente);

Scope: il campo “scope” indica l'ambito del sistema di reti IPv6 a cui è destinato il traffico

multicast. La dimensione del campo è 4 bit. In aggiunta alle informazioni fornite dai

protocolli di routing multicast, i router utilizzano l'ambito multicast per determinare la

posizione nella quale è possibile inoltrare il traffico multicast.

VALORE DEL CAMPO SCOPE AMBITO

0 Riservato

1 Locale al nodo

2 Locale al collegamento

5 Locale al sito

8 Locale all‟organizzazione

E Globale

F Riservato

Per capire meglio il significato di “ambito” e come tale nozione permetta al multicast IPv6

di essere limitato a precise sfere di influenza è interessante la seguente figura:


Group ID: Il campo ID gruppo identifica il gruppo multicast ed è univoco all'interno

dell'ambito. La dimensione del campo è 112 bit. Gli ID gruppo assegnati permanentemente

sono indipendenti dall'ambito. Gli ID gruppo temporanei sono validi solo per l'ambito

specifico. Gli indirizzi multicast compresi tra FF01:: e FF0F:: sono indirizzi riservati e

conosciuti.

Per identificare tutti i nodi degli ambiti locali al nodo e al collegamento, vengono definiti i seguenti

indirizzi multicast:

FF01::1 (indirizzo di tipo "tutti i nodi" con ambito locale al nodo)

FF02::1 (indirizzo di tipo "tutti i nodi" con ambito locale al collegamento)

Per identificare tutti i router degli ambiti locali al nodo, al collegamento e al sito, vengono definiti i

seguenti indirizzi multicast:

FF01::2 (indirizzo di tipo "tutti i router" con ambito locale al nodo)

FF02::2 (indirizzo di tipo "tutti i router" con ambito locale al collegamento)

FF05::2 (indirizzo di tipo "tutti i router" con ambito locale al sito)


Oltre ai tradizionali indirizzi multicast, ogni indirizzo unicast ha uno speciale indirizzo multicast

chiamato solicited-node. Quest‟indirizzo viene creato attraverso un particolare mapping

dell‟indirizzo unicast del dispositivo e viene utilizzato per avere una più efficiente tecnica di

risoluzione degli indirizzi rispetto alla tecnica ARP usata in IPv4. Tutti gli indirizzi di questo tipo

hanno il flag T a 0 e lo scope a 2. I 112 bit del group ID sono così settati:

Otto bit, consistenti di settantanove 0 e un 1;

FF

24 bit presi dai primi bit dell‟indirizzo unicast

2.6.2. Indirizzi anycast

Gli indirizzi anycast sono un tipo particolare di indirizzi introdotto con IPv6 [5]. Un indirizzo

anycast identifica più interfacce. Utilizzando la topologia di routing appropriata, i pacchetti

indirizzati a un indirizzo anycast vengono recapitati a una singola interfaccia, ovvero l'interfaccia

più vicina identificata dall'indirizzo. Si tratta dell'interfaccia più vicina in termini di distanza di

routing. A differenza degli indirizzi multicast che vengono utilizzati per la comunicazione uno-a-

molti con recapito a più interfacce, gli indirizzi anycast vengono utilizzati per la comunicazione

uno-a-uno-di-molti con recapito a una singola interfaccia.

Per facilitare il recapito al membro del gruppo anycast più vicino, è necessario che l'infrastruttura di

routing riconosca le interfacce a cui sono state assegnati indirizzi anycast e la loro distanza in

termini di metrica di routing. Attualmente, gli indirizzi anycast vengono utilizzati come indirizzi di

destinazione e assegnati solo ai router. Gli indirizzi anycast vengono assegnati dallo spazio di

indirizzi unicast. L'ambito di un indirizzo anycast corrisponde all'ambito del tipo di indirizzo

unicast dal quale l'indirizzo anycast viene assegnato.

L'indirizzo anycast subnet-router è predefinito e obbligatorio. Questo tipo di indirizzo viene creato

dal prefisso della subnet di una determinata interfaccia. Per creare l'indirizzo anycast subnet-router,

i valori appropriati dei bit del prefisso della subnet rimangono fissi, mentre i bit rimanenti vengono

impostati su 0. L'indirizzo anycast subnet-router viene assegnato a tutte le interfacce di router


collegate a una subnet. L'indirizzo anycast subnet-router consente di comunicare con uno dei router

collegati a una subnet remota.

L‟anycast fu specificamente pensato per incrementare la flessibilità in situazioni dove occorre un

servizio offerto da un certo numero di server o router diversi, ma non importa quale di essi

provveda ad attivarlo.

2.7. Il pacchetto IPv6

Il pacchetto IPv6 si compone di due parti principali: l'header e il payload.

L'header è costituito dai primi 40 byte del pacchetto e contiene 8 campi:

Version [4 bit] - Indica la versione del datagramma IP: per IPv6, ha valore 6 (da qui il nome

IPv6);

Traffic Class [8 bit] - Si traduce come "classe di traffico", permette di gestire le code by

priority assegnando ad ogni pacchetto una classe di priorità rispetto ad altri pacchetti

provenienti dalla stessa sorgente. Viene usata nel controllo della congestione. I valori

possibili sono i seguenti:


Flow Label [20 bit] - Usata dal mittente per etichettare una sequenza di pacchetti

appartenenti allo stesso flusso. Supporta la gestione del Qos (Quality of Service),

consentendo ad esempio di specificare quali etichette abbiano via libera rispetto ad altre. Ha

un valore compreso tra 1 e FFFFFF;

Payload Length [16 bit] - È la dimensione del payload, ovvero il numero di byte di tutto ciò

che viene dopo l'header. Da notare che eventuali estensioni dell'header (utili ad esempio per

l'instradamento o per la frammentazione) sono considerate payload, e quindi conteggiate

nella lunghezza del carico. Se il suo valore è 0, significa che ho un pacchetto di dimensione

massima, anche detto Jumbo Payload;

Next Header [8 bit] - Indica quale tipo di intestazione segue l'header di base IPv6;

Hop Limit [8 bit] - È il limite di salti consentito. Il suo valore viene decrementato di 1 ogni

volta che il pacchetto passa da un router: quando arriva a zero viene scartato;

Source Address [128 bit] - Indica l'indirizzo IP del mittente del pacchetto;

Destination Address [128 bit] - Indica l'indirizzo IP del destinatario del pacchetto.

La parte successiva contiene il carico utile (payload in inglese) lungo come minimo 1280 byte o

1500 byte se la rete supporta un MTU variabile. Il carico utile può raggiungere i 65.535 byte in

modalità standard o può essere di dimensioni maggiori in modalità "jumbo payload".

IPv6 è molto flessibile riguardo al supporto delle opzioni attraverso le estensioni dell'header. Le

estensioni dell'header sono disposte fra l‟header e l'intestazione di livello superiore e sono

concatenate insieme usando il campo Next Header nell'intestazione IPv6. I possibili valori sono:


Se si necessita di più estensioni dell'header, il campo NEXT dell'intestazione indica la tipologia

dell‟estensione successiva fino a indicare la tipologia del protocollo di livello superiore.

Di seguito si vede un esempio di ciò:


2.8. Autoconfigurazione e rinumerazione

Una delle più interessanti caratteristiche implementate in IPv6 è una funzione che permette ai

dispositivi presenti su una rete IPv6 configurarsi indipendentemente. In IPv4 gli host erano

generalmente configurati manualmente. Solo più tardi, i protocolli di configurazione come il DHCP

permisero ai server di allocare indirizzi IP agli host che venivano ad unirsi alla rete.

IPv6 si allontana da questo concetto, definendo un metodo con il quale i dispositivi possano

automaticamente configurare i loro indirizzi IP e altri parametri senza bisogno di un server.

Inoltre definisce un metodo con il quale gli indirizzi IP su una rete possono essere rinumerati

(cambiati in massa).

I meccanismi di autoconfigurazione e di rinumerazione sono definiti nel RFC 2462, “IPv5 Stateless

Address Autoconfiguration” [6]. La parola stateless contrasta con il metodo detto stateful che

utilizza una sorta di protocollo DHCPv6. Tale metodo viene detto stateless perché l‟host

inizialmente non ha nessuna informazione e non ha bisogno di un server DHCP.

Questi sono i passi che un dispositivo deve fare quando utilizza l‟autoconfigurazione stateless:

1. Generazione di un indirizzo link-local: il dispositivo genera un indirizzo link-local con i

primi 10 bit a 1111 1110 10, seguiti da 54 zeri e poi l‟identificativo di interfaccia a 64 bit

(che viene derivato dall‟indirizzo MAC);

2. Test dell‟unicità dell‟indirizzo link-local: viene verificato che l‟indirizzo generato non sia

già in uso sulla rete locale (questo è molto difficile che accada visto che l‟indirizzo viene

generato da un indirizzo MAC). Se è già in uso, o viene generato un nuovo indirizzo o

l‟autoconfigurazione fallisce o viene usato un altro metodo;

3. Assegnamento dell‟indirizzo link-local: se il test di unicità è stato passato, il dispositivo

assegna l‟indirizzo link-local alla sua interfaccia. Questo indirizzo può essere utilizzato per

la comunicazione sulla rete locale, ma non sulla rete Internet;

4. Contatto del router: il nodo cerca di contattare un router locale per informazioni su come

continuare la configurazione. Questo viene fatto mettendosi in ascolto di particolari

messaggi (RA router advertisement) che i router periodicamente inviano oppure inviando un

messaggio di richiesta (RS router solicitation) a un router per informazioni su cosa fare

successivamente;

5. Direttive del router: il router provvede a informare il nodo su come procedere con

l‟autoconfigurazione. Può dire al nodo che su quella rete è in uso una autoconfigurazione di

tipo stateful e dargli l‟indirizzo di un server DHCP a cui fare richiesta, oppure può dire

all‟host come determinare il suo indirizzo per la rete globale Internet;

6. Configurazione dell‟indirizzo global: se sulla rete è in uso l‟autoconfigurazione stateless,

l‟host configurerà se stesso con un indirizzo globale. Questo indirizzo di solito è formato da

un prefisso di rete fornito dal router combinato con l‟identificativo del dispositivo.

Questo metodo presenta degli evidenti vantaggi rispetto sia alla configurazione manuale sia a quella

basata su server soprattutto per quanto riguarda la mobilità dei dispositivi.

La rinumerazione dei dispositivi, infine, è un meccanismo collegato all‟autoconfigurazione. Può

essere implementato usando protocolli come DHCP attraverso l‟uso di indirizzi IP che “scadono”

dopo un certo periodo di tempo. Sotto IPv6, le reti possono essere rinumerate se i router hanno

specificato un intervallo di tempo di validità per i prefissi di rete al momento

dell‟autoconfigurazione. Successivamente, essi possono inviare un nuovo prefisso per comunicare


ai dispositivi che devono rigenerare i loro indirizzi IP. I dispositivi possono mantenere per un po‟ il

vecchio indirizzo scaduto e poi cambiarlo con il nuovo [7].

2.9. Riferimenti:

[1] RFC 2374: http://www.rfc-editor.org/rfc/rfc2374.txt


[3] RFC 3041Privacy Extensions for Stateless Address Autoconfiguration in IPv6: http://www.rfc-


[4] RFC 3879 Deprecating Site Local Addresses: http://www.rfc-editor.org/rfc/rfc3879.txt

[5] RFC 1546 Host Anycasting Service: http://www.rfc-editor.org/rfc/rfc1546.txt


[7] RFC 2894 Router Renumbering for IPv6: http://www.rfc-editor.org/rfc/rfc2894.txt










3. IPv6: che cosa cambia

Nel progettare il nuovo protocollo ci si pose l‟obiettivo di espandere lo spazio di

indirizzamento e di migliorare alcuni aspetti di IPv4 che si erano rivelati critici, quali la sicurezza,

la semplicità di configurazione, la gestione della mobilità, il multicast, la qualità di servizio.

Le differenze fondamentali si limitano al formato del header dei pacchetti, alla struttura degli

indirizzi ed ai meccanismi per assegnare ed utilizzare gli indirizzi all‟interno della rete. Queste

differenze sono sufficienti a fare di IPv6 un protocollo simile ma incompatibile con IPv4 e quindi a

determinare i conseguenti problemi di migrazione.

Vediamo quali sono i cambiamenti principali introdotti dal protocollo IPv6 rispetto alla versione

precedente.

3.1. Nuovo formato di intestazione

L'intestazione IPv6 dispone di un nuovo formato creato per ridurre al minimo il sovraccarico. Sia i

campi non essenziali sia i campi facoltativi vengono spostati in intestazioni di estensione, poste

dopo l'intestazione IPv6. L'intestazione IPv6 così semplificata garantisce un‟elaborazione più

efficiente nei router intermedi.


Le intestazioni IPv4 e IPv6 non sono interoperabili e il protocollo IPv6 non è compatibile con il

protocollo IPv4. Per riconoscere ed elaborare le intestazioni in entrambi i formati, un host o un

router deve utilizzare sia un'implementazione di IPv4 sia un'implementazione di IPv6. Sebbene gli

indirizzi IPv6 siano quattro volte più grandi degli indirizzi IPv4, la nuova intestazione IPv6 è

soltanto due volte più grande dell'intestazione IPv4.

3.2. Spazio di indirizzi più esteso

La più importante caratteristica di IPv6 è un maggiore spazio degli indirizzi rispetto a IPv4: gli

indirizzi in IPv6 sono di 128 bit, contro i 32 bit degli indirizzi IPv4.

Questo maggiore spazio di indirizzi supporta un totale di 2^128 (circa 3.4x10^38) indirizzi, vale a

dire 655.570.793.348.866.943.898.599 indirizzi IPv6 per metro quadrato di superficie terrestre.

Sebbene questi numeri siano impressionanti, l‟intento non è certamente quello di assicurare un

numero sufficiente di indirizzi. Piuttosto, un maggior numero di bit consente una migliore,

sistematica e gerarchica allocazione degli indirizzi e un‟efficiente aggregazione delle rotte. In altre

parole: flessibilità.

La dimensione di una sottorete in IPv6 è di 264 indirizzi (subnet mask a 64 bit), ovvero il quadrato

delle dimensioni dell‟intera Internet IPv4.

Pertanto,il tasso di utilizzo effettivo dello spazio di indirizzi sarà probabilmente minore in IPv6, ma

la gestione della rete e il routing saranno più efficaci per le decisioni di progettazione inerenti alla

grandezza delle sottoreti e all‟aggregazione gerarchica delle rotte. Inoltre il numero molto più


elevato di indirizzi disponibili le tecniche di risparmio degli indirizzi, quali l'applicazione del

protocollo NAT, non risultano più necessarie.

3.3. Frammentazione

Le differenze più importanti fra IPv4 ed IPv6 riguardo a datagram size, MTU, frammentazione e

riassemblaggio, sono:

Aumento del default MTU: in IPv4, l'MTU minimo che i router ed i collegamenti fisici

possono gestire era di 576 byte. In IPv6, tutti i collegamenti gestiscono formati dei

datagrammi di almeno 1280 byte. Tale incremento nel formato migliora l'efficienza

aumentando il rapporto fra carico utile massimo e la lunghezza dell'intestazione e riducendo

la frequenza con cui la frammentazione è richiesta.

Eliminazione della frammentazione da parte dei Router: in IPv4, i datagrammi possono

essere frammentati dal nodo sorgente o dai router intermedi durante la consegna. In IPv6,

soltanto la sorgente può effettuare la frammentazione, i router non hanno questa possibilità

per motivi di efficienza. La sorgente deve quindi frammentare fino al più piccolo MTU

sull'itinerario prima della trasmissione. Ciò presenta sia vantaggi sia svantaggi. Il

riassemblaggio dei frammenti naturalmente è fatto soltanto dalla destinazione, come in IPv4.

3.4. Multicast

Il multicast, ovvero la capacità di inviare un singolo pacchetto a più destinatari, fa parte delle

specifiche di base di IPv6, ma in modo diverso che in IPv4, dove è facoltativo (anche se in genere

implementato).

IPv6 non implementa il broadcast, ovvero la possibilità di inviare un pacchetto a tutti gli host

presenti sul link diretto. Lo stesso effetto può essere raggiunto inviando un pacchetto multicast al

gruppo composto da tutti gli host del link locale.

Il multicast in IPv6 condivide alcune caratteristiche e alcuni protocolli con il multicast di IPv4, ma

fornisce anche modifiche e miglioramenti. Quand‟anche il più piccolo prefisso IPv6 di routing

globale viene assegnato a un‟organizzazione, all‟organizzazione viene assegnato l‟uso di 4,2

miliardi di gruppi multicast, da utilizzare per applicazioni multicast intra ed extra dominio (RFC

3306 [1]). In IPv4 invece era molto difficile per un‟organizzazione ottenere anche un solo gruppo

multicast per il routing extra dominio e quindi l‟implementazione di soluzioni era veramente

complicata.

IPv6 supporta anche nuove soluzioni multicast, come Embedded Rendezvous Point (RFC 3956 [2]),

che semplifica lo sviluppo di soluzioni extra dominio.


3.5. Configurazione di indirizzi con e senza informazioni sullo stato

Per semplificare la configurazione di host, IPv6 supporta sia la configurazione di indirizzi con

informazioni sullo stato (ad esempio la configurazione in presenza di un server DHCP) che la

configurazione di indirizzi senza informazioni sullo stato (configurazione di indirizzi in assenza di

un server DHCP). Tramite la configurazione di indirizzi senza informazioni sullo stato gli host

appartenenti a un collegamento vengono configurati automaticamente con indirizzi IPv6 per il

collegamento (indirizzi locali del collegamento) e con indirizzi derivati da prefissi annunciati dai

router locali. Anche in assenza di un router gli host dello stesso collegamento possono essere

configurati automaticamente con indirizzi locali del collegamento e comunicare senza richiedere

operazioni di configurazione manuali.

3.6. Protocollo DHCPv6

Anche in IPv6, il protocollo di configurazione dinamica degli host si basa su modello client/server,

ma in questo caso affianca il metodo di autoconfigurazione stateless degli host introdotto dalla

nuova versione. Tale protocollo può dunque essere usato per assegnare dinamicamente gli indirizzi

su una rete se l‟amministratore desidera un maggiore controllo rispetto al metodo automatico.

Oppure può essere utilizzato anche per distribuire informazioni che non sono ricavabili in nessun

altro modo, come ad esempio il DNS server (tuttavia, l‟indirizzo del DNS server può essere inviato

tramite il Neighbor Discovery Protocol [3]).

I messaggi disponibili sono i seguenti:

Solicit;

Advertise;

Request;

Reply;

Release;

Reconfigure.

3.7. Protocollo ICMPv6

È l‟evoluzione del protocollo ICMPv4. In esso vengono aggiunte nuove funzionalità che nel

protocollo precedente erano demandate ad altri livelli protocollari (come ad esempio l‟ARP) e tolte

altre che, invece, erano poco usate. Come nel caso della versione precedente, ICMPv6 [8] viene

usato per monitorare lo stato della rete e per inviare pacchetti di gestione e di errore.

La struttura del pacchetto ICMPv6 è la seguente:


Il campo type indica il tipo del pacchetto ICMPv6;

Il campo code indica il codice del messaggio di errore;

Il campo checksum è utilizzato per rilevare errori di trasmissione dell‟intero pacchetto;

Il campo body contiene un messaggio ed è di lunghezza variabile.

L'ICMPv6 viene, inoltre, utilizzato anche per gestire i gruppi multicast, questa funzione è svolta dal

protocollo IGMP nelle reti IPv4. Per decidere il gruppo multicast i router o server inviano pacchetti

di membership query e gli host appartenenti ad un gruppo rispondono con un messaggio di

membership report. Questi ultimi vengono inviati costantemente dai client e per non provocare un

appesantimento della rete un campo di maximum response delay indica l'intervallo di invio dei

membership report. Nel momento in cui un host abbandona il gruppo multicast, viene inviato un

ICMPv6 di termination.

3.8. Protezione incorporata

Sebbene compatibile anche con IPv4, IPSec (RFC2401) si è dovuto scontrare con la diffusione dei

dispositivi di NAT, che ne hanno reso impossibile una diffusione su larga scala. IPv6 è

stato invece progettato in modo tale da integrare nativamente i meccanismi di sicurezza

previsti da IPSec. La definizione di uno standard di questo genere a livello IP permette a tutte le

applicazioni, anche quelle non sicure per definizione, di usufruire di un canale comunicativo

affidabile anche dal punto della sicurezza. IPSec garantisce infatti l‟integrità, la provenienza e la

confidenzialità dei dati definendo un header per l‟autenticazione (AH) ed una funzionalità di

incapsulamento sicuro del payload (ESP), insieme a metodologie per la gestione delle chiavi e

particolari algoritmi di cifratura o autenticazione.

3.9. Miglior supporto della qualità del servizio (QoS)

I nuovi campi dell'intestazione IPv6 definiscono le modalità di gestione ed identificazione del

traffico. L'identificazione del traffico tramite l'utilizzo di un campo etichetta di flusso (Flow Label)

nell'intestazione IPv6 consente ai router l'identificazione e la gestione speciale dei pacchetti

appartenenti a un flusso. Un flusso è una serie di pacchetti scambiati tra un'origine e una

destinazione. Poiché il traffico è identificato nell'intestazione IPv6, il supporto della qualità del

servizio (QoS) può essere ottenuto facilmente anche quando il payload del pacchetto è crittografato

con IPSec.


3.10. Nuovo protocollo per l'interazione tra nodi adiacenti

Il protocollo di rilevamento adiacente (ND, Neighbor Discovery) per IPv6 è una serie di messaggi

ICMPv6 (Internet Control Message Protocol per IPv6) che gestisce l'interazione dei nodi adiacenti

(ovvero dei nodi posti sullo stesso collegamento). Il protocollo di rilevamento adiacente sostituisce

il protocollo ARP (Address Resolution Protocol), il rilevamento router ICMPv4 e i messaggi

ICMPv4 con messaggi multicast e unicast di elevata efficienza, fornendo inoltre funzionalità

aggiuntive.

3.11. Estensibilità

In IPv4 le opzioni sono uno strumento attraverso cui è possibile aggiungere nuovi campi alla

header di base; si tratta comunque di uno strumento piuttosto limitato, dal momento che lo

spazio massimo disponibile è di soli 40 byte.

IPv6 invece supera il concetto di IP Options, implementando un meccanismo estremamente

modulare e flessibile che prevede che un header di base concatenata ad una serie di header

successive che specificano di volta in volta opzioni aggiuntive. Una scelta di questo tipo

presenta indubbiamente due principali vantaggi: la dimensione dell‟header principale non ha

più dimensione variabile (come accadeva in IPv4) bensì fissa e l‟aggiunta di nuove

funzionalità o la modifica di alcune di esse non ha alcuna ricaduta sull‟header base di IPv6 né

sulle altre Extension header.

3.12. Riferimenti

[1] RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses http://www.rfc-


[2] RFC 3956: Embedding the Rendezvous Point (RP) Addressing an IPv6 Multicast Address



[4] RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6

(IPv6) Specification: http://www.rfc-editor.org/rfc/rfc2463.txt







4. La transizione ad IPv6

Il problema che sta alla base del passaggio alla nuova versione del protocollo IP è il fatto che IPv6 e

IPv4 sono di per sé protocolli incompatibili. Per potersi affermare IPv6 deve garantire la

compatibilità con i dispositivi IPv4 esistenti e fornire strumenti che facilitino il processo di

transizione.

La necessità di meccanismi di transizione efficaci è stata riconosciuta sin dalle prime fasi di

definizione di IPv6. Sono state fatte negli anni ripetute analisi sulle modalità di introduzione di IPv6

in una rete IPv4, con l‟obiettivo di preservare il più possibile gli investimenti, ridurre i disservizi e

procedere in modo graduale all‟abilitazione del nuovo protocollo.

I meccanismi proposti sono numerosi e variano a seconda dello scenario. La transizione sarà

graduale; non ci sarà un “D-Day”, ma un lungo periodo di coesistenza dei due protocolli. Il

processo non sarà breve, anzi potrebbe durare decenni.

Possiamo pensare ad un processo in tre fasi:

Fase iniziale: la rete IPv6 si appoggia all‟infrastruttura IPv4 e i nodi IPv6 utilizzano

prevalentemente i servizi IPv4 esistenti;

Fase intermedia: i due protocolli coesistono;

Fase finale: la rete IPv4 si appoggia all‟infrastruttura IPv6 e i nodi IPv4 devono poter

utilizzare i servizi IPv6.

In generale le applicazioni devono comunque essere modificate per poter utilizzare IPv6. Bisogna

quindi prevedere meccanismi di transizione implementati sugli host, a livello di rete e basati su

traduttori di protocollo.

4.1. Migrazione degli host

Da lungo tempo viene proposto l‟approccio cosiddetto dual-stack, basato sulla capacità di un router

di instradare pacchetti appartenenti a protocolli differenti.

Tale approccio è sicuramente il più semplice. Prevede che un nodo implementi entrambi i protocolli

e di conseguenza abbia, anche sulla stessa interfaccia, sia un indirizzo IPv4 che un indirizzo IPv6.

In questo caso le applicazioni IPv4-only utilizzano sempre IPv4. Per quanto riguarda, invece, le

applicazioni che supportano IPv6, il DNS risolve sia indirizzi IPv4 sia indirizzi IPv6; quindi, se la

destinazione ha un indirizzo IPv6 si utilizzerà IPv6, altrimenti se la destinazione ha soltanto un

indirizzo IPv4, si utilizzerà IPv4.


Come già detto, tale soluzione presenta tra i vantaggi il fatto di essere molto semplice e di non

richiedere alcun supporto particolare. Di contro però ha come svantaggi il fatto di non ridurre il

fabbisogno di indirizzi IPv4 e il fatto di richiedere la gestione di una doppia infrastruttura di rete.

Tale meccanismo, infatti, non fa nulla per integrare la rete IPv6 con quella IPv4. Da un punto di

vista di un nodo dual stack, le due reti sono completamente separate, tanto da poter dire che questo

è un meccanismo di compatibilità, più che di transizione.

4.2. Migrazione a livello di rete

Per quanto riguarda i meccanismi di compatibilità a livello di rete, una delle soluzioni principali è

quella dei tunnel [1]. Tale soluzione permette di collegare reti IPv6 tra loro, anche se interconnesse

da nuvole IPv4.

I tunnel sono comunemente usati per trasportare un protocollo in una rete basata su un altro

protocollo. I tunnel IPv6-in-IPv4 permettono di utilizzare IPv6 senza disporre di una infrastruttura


di rete IPv6 nativa: i pacchetti IPv6 vengono incapsulati in pacchetti IPv4 con la semplice aggiunta

di un header IPv4.

All‟ingresso del tunnel i pacchetti IPv6 vengono incapsulati in pacchetti IPv4, vengono poi

instradati normalmente sulla rete IPv4 fino all‟altro estremo del tunnel dove vengono de capsulati.

A questo punto i pacchetti IPv6 contenuti sono elaborati normalmente, come se fossero giunti su

una qualunque altra interfaccia.

Ovviamente gli estremi del tunnel devono essere nodi dual stack. Da fuori il tunnel appare come un

solo hop IPv6. Dal punto di vista di IPv6, è come se la rete IPv4 fosse semplicemente una

tecnologia trasmissiva di livello due. L‟MTU di un tunnel è inferiore di 20 byte per via della

presenza dell‟header IPv4.


Ci sono vari meccanismi di tunneling in uso. Essi si dividono in:

Tunneling configurato:

▪ Tunneling manuale.

Tunneling automatico:

▪ Indirizzi “IPv4-compatible”;

▪ 6over4;

▪ 6to4;

▪ Tunnel Broker;

▪ ISATAP;

▪ Teredo.

Vediamo i principali.

4.2.1. Tunnel configurati

Vengono creati configurando manualmente gli estremi, specificando gli indirizzi IPv4 e IPv6

(qualunque tipo di indirizzo unicast) dell‟interfaccia del tunnel su entrambi. L‟utilizzo tipico di

questo genere di tunneling è quello di stabilire un collegamento punto-punto permanente tra due

router dual stack. Per questo motivo essi sono ampiamente utilizzati.

4.2.2. Indirizzi “IPv4-compatible”

Questo tipo di tunneling viene spesso indicato impropriamente col nome di “automatic tunneling”.

In questo caso, viene definita una pseudo-interfaccia. Tutti i pacchetti uscenti da essa vengono

“tunnellati” in base all‟indirizzo IPv6 di destinazione: l‟indirizzo IPv4 dell‟estremo del tunnel è

determinato automaticamente dall‟indirizzo destinazione, usando il meccanismo degli indirizzi IPv6

“IPv4-compatibili” (del tipo ::a.b.c.d).


È necessario definire una route per instradare in questo modo solamente i pacchetti indirizzati verso

la rete ::/96. Teoricamente è possibile annunciare anche route più specifiche di ::/96 sulla rete IPv6,

ma questo porterebbe ad un‟esplosione delle tabelle di routing.

I tunnel automatici di questo tipo purtroppo però non riducono il fabbisogno di indirizzi IPv4,

poiché il tunnel è verso un solo nodo, identificato con il suo indirizzo IPv4; se il mittente è un nodo

dual stack, tanto vale allora utilizzare IPv4.

4.2.3. Tunnel 6over4

6over4 è un meccanismo di transizione volto a trasmettere pacchetti IPv6 tra nodi dual stack agli

estremi di una rete multicast IPv4. IPv4 viene usato come livello data link virtuale (da qui anche il

nome di “virtual ethernet”) sul quale IPv6 può viaggiare.

Tale meccanismo definisce un metodo banale per generare un indirizzo IPv6 link-local da un

indirizzo IPv4. Ogni host che desidera prendere parte a 6over4 su una rete IPv4 data può definire

un‟interfaccia di rete IPv6 virtuale. L‟indirizzo link-local è determinato nel modo seguente:

Comincia con FE80::

I 32 bit meno significativi, in binario, devono essere quelli dell‟indirizzo IPv4 dell‟host.

I limiti di questo metodo stanno nel confidare sulla disponibilità del multicast IPv4, che in realtà

non è così ampiamente supportato dalle infrastrutture di rete IPv4. Per questo motivo 6over4 ha un

uso pratico limitato e non è supportato dai più comuni sistemi operativi. Il suo uso è circoscritto alla

rete aziendale e non all‟intera Internet.

4.2.4. Tunnel 6to4

6to4 è un sistema che permette di trasferire pacchetti IPv6 su una rete IPv4 (generalmente la parte

IPv4 di Internet) senza il bisogno di configurare tunnel espliciti. Esistono convenzioni di routing

che permettono agli host 6to4 di comunicare con la parte IPv6 di Internet. È utilizzato

comunemente quando si vuole accedere alla parte IPv6 di Internet da una connessione con solo

accesso IPv4 (preferibilmente con indirizzo pubblico).

Dal punto di vista pratico 6to4 non fa altro che creare in modo automatico dei tunnel punto-punto

tra ogni host 6to4 e ogni altro, senza bisogno però di configurarli manualmente. Dato che tra due

host dual-stack configurati per 6to4 i pacchetti IPv6 viaggiano incapsulati in normali pacchetti

IPv4, non è necessario che i router e le altre apparecchiature di rete che li collegano supportino

IPv6.

6to4 ha tre funzioni:


assegna un blocco di indirizzi IPv6 ad ogni host che abbia un indirizzo IPv4 pubblico;

incapsula i pacchetti IPv6 dentro pacchetti IPv4, in modo che possano essere trasmessi su

una normale rete IPv4;

instrada il traffico tra la rete 6to4 e la rete IPv6 "nativa", tramite opportuni router connessi

ad entrambe.

Per ogni indirizzo IPv4 pubblico assegnato ad un determinato host, si ha un prefisso di rete IPv6 di

48 bit formato dal prefisso esadecimale 2002 seguito dai 32 bit dell'indirizzo IPv4 stesso [2].

Nell'utilizzo classico, ad ogni prefisso di 48 bit seguono uno SLA di 16 bit e un indirizzo di

interfaccia di 64 bit (che generalmente è calcolato automaticamente utilizzando il MAC univoco

della scheda di rete): questo permette di assegnare indirizzi IPv6 a 65536 sottoreti ognuna

contenente un numero pressoché arbitrario di host.


6to4 incapsula ogni pacchetto IPv6 all'interno di un pacchetto IPv4 con tipo di protocollo 41; in

pratica questo corrisponde a porre "in testa" al pacchetto un header IPv4 aggiuntivo (di 20 byte).

L'indirizzo IPv4 di destinazione da utilizzare nell'header IPv4 viene estratto dall'indirizzo IPv6 del

pacchetto incapsulato, estraendo i 32 bit che seguono il prefisso 2002::/16. Il pacchetto IPv4

risultante viene instradato alla sua destinazione IPv4 normalmente, come qualsiasi altro pacchetto

IPv4.

Per permettere ad un host configurato con 6to4 di comunicare con host IPv6 "nativi" vengono

utilizzati dei "relay router" che sono raggiungibili sia dalla rete nativa IPv4 che da quella IPv6.

Questi router instradano tutti i pacchetti 6to4 in arrivo sull'interfaccia IPv4 verso la rete IPv6 e

solamente i pacchetti IPv6 la cui destinazione ha il prefisso 2002::/16 al corrispondente indirizzo

IPv4.

Un host o router configurato con 6to4 che voglia comunicare con un indirizzo IPv6 "nativo" non

dovrà fare altro che utilizzare uno di questi "relay router" come gateway di default. Per facilitare

ulteriormente la configurazione è stato allocato l'indirizzo IPv4 anycast 192.88.99.1 (che in

notazione 6to4 corrisponde all'indirizzo IPv6 2002:c058:6301::) appositamente per indicare questi

router: utilizzandolo si comunicherà automaticamente con il "relay router" più vicino dal punto di

vista della topologia di rete.


I vantaggi di questo tipo di meccanismo sono i seguenti:

semplice da configurare;

permette di utilizzare IPv6 senza disporre di indirizzi e senza avere un provider Ipv6 nativo;

non richiede alcun supporto particolare ai nodi.

Di contro però ci sono alcuni svantaggi:

gli indirizzi IPv6 sono legati all‟indirizzo IPv4 del router di bordo (quindi se cambia

l‟indirizzo IPv4, l‟intera rete deve essere rinumerata);

il relay router può essere molto lontano sia dal nodo sorgente (in IPv4) sia dal nodo

destinazione (in IPv6).

4.2.5. Tunnel Broker

Il tunnel broker [3] è un‟applicazione web raggiungibile tramite IPv4 che crea automaticamente i

tunnel configurati. Un utente che desidera stabilire un tunnel lo richiede al broker attraverso una

pagina web, il broker identifica l‟utente e configura un router per creare il tunnel verso l‟utente e ne

comunica i parametri. Questo tipo di tunnel è molto utilizzato per utenti “occasionali”.


4.2.6. ISATAP

in 6to4 è necessaria la connettività nativa IPv6 all‟interno della rete, in quanto non è previsto il

concetto di router advertisement sul tunnel. ISATAP (“Intra_Site Automatic Tunnel Addressing

Protocol”) rimuove questo limite. Il router può essere identificato attraverso una query al DNS ed è

possibile interagire con il router attraverso router advertisement o router solicitation conoscendone

il suo indirizzo IPv4. È ancora in fase di definizione.

4.2.7. Teredo

Teredo (“Tunneling IPv6 over UDP Through NATs”) incapsula i pacchetti IPv6 in pacchetti UDP

(IPv4) anziché direttamente in pacchetti IPv4. Questo ha infatti lo scopo di permettere l‟utilizzo di

tunnel anche in presenza di NAT IPv4. È ancora in fase di definizione

4.3. Traduttori di protocollo

Per consentire l‟interoperabilità tra i diversi protocolli è necessario ricorrere ad un meccanismo di

translation, ovvero di „conversione‟ di un protocollo in un altro attraverso la trasformazione

dell‟header ed, eventualmente, del payload.

L‟utilizzo di traduttori di protocollo è l‟unico modo di far comunicare nodi IPv4-only con nodi

IPv6-only e viceversa. Questo meccanismo può essere un‟alternativa ai nodi dual stack che


richiedono per forza un indirizzo IPv4 per ogni nodo. Il problema sta nell‟individuare il posto

giusto in cui posizionarli; poiché tutto il traffico tradotto passa per il nodo traduttore, ciò può

causare problemi di robustezza, sicurezza, traffico, ecc.

La traduzione può avvenire a livelli diversi dello stack di rete (a livello IP, a livello di trasporto o

modificando la pila protocollare dell‟host) e può essere implementata in vari modi. In molti di

questi meccanismi gli indirizzi IPv4 sono rappresentati come particolari indirizzi IPv6. Questo è

possibile perché lo spazio di indirizzamento è più ampio. Gli indirizzi IPv4 rappresentati in questo

modo sono instradati verso il traduttore.

La traduzione molto spesso ha il difetto di introdurre perdite di informazioni. In tutti quei casi

in cui non esiste una corrispondenza tra i campi dei due protocolli i valori possono infatti essere

persi o impostati a valori standard senza particolare significato; la traduzione di un datagram

IPv6 in IPv4 comporterà sicuramente la perdita, ad esempio, del valore di Flow_Label.

In base al funzionamento, i meccanismi di traduzione possono essere distinti in stateless e stateful.

Un traduttore stateless è in grado di effettuare ogni singola conversione indipendentemente

dalle altre; un traduttore stateful invece necessita di mantenere in memoria informazioni sulle

traduzioni effettuate in precedenza (es. corrispondenze tra le due tipologie di indirizzi).

4.4. Traduttori a livello IP

4.4.1. SIIT

Essenziale per il processo di transizione è sicuramente la conversione dei pacchetti IP e ICMP; a

questo proposito è stato ideato SIIT. L‟algoritmo SIIT (“Stateless IP/ICMP Translation” [4]) indica

le modalità di traduzione bidirezionale degli header IPv4 e IPv6 e dei messaggi ICMPv4 e

ICMPv6. Questo meccanismo, su cui si basano diversi traduttori, ignora molte delle estensioni

dell‟header IPv6 così come diverse opzioni di IPv4; tuttavia è stato progettato appositamente

in maniera da mantenere inalterato nel processo di traduzione il checksum di UDP e TCP calcolato

utilizzando le pseudo-header.

Il funzionamento è il seguente:

gli indirizzi IPv4 sono mappati su indirizzi IPv6. Le destinazioni IPv4 sono indicate con

indirizzi IPv6 IPv4-mapped (::FFFF:a.b.c.d), che sono instradati verso il traduttore. I nodi

ottengono indirizzi IPv4 temporanei che vengono mappati in indirizzi IPv6 “IPv4-transated”

(::FFFF:0:a.b.c.d) e usati come indirizzo sorgente;

il traduttore traduce i pacchetti in transito;

la traduzione effettuata dal traduttore è stateless poiché gli indirizzi sono desunti

direttamente dagli indirizzi IPv6.

Un vantaggio sicuramente importante di questo meccanismo di traduzione sta nel fatto che il nodo

traduttore non deve mantenere informazioni sullo stato delle connessioni. Questo va a favorire la


scalabilità (è possibile utilizzare più nodi traduttori) e la robustezza della rete (in caso di guasto di

un traduttore la rete non viene interrotta).

Ha però anche alcuni svantaggi da non sottovalutare. Innanzitutto esso richiede modifiche alle

implementazioni IPv6; inoltre, richiede la presenza di un meccanismo per l‟assegnazione dinamica

degli indirizzi temporanei e richiede di gestire il routing per gli indirizzi IPv4-translated all‟interno

della rete e questo rende difficile gestire la distribuzione in subnet degli indirizzi IPv4.

4.4.2. NAT-PT

Network Address Translation – Protocol Translation [5] è un traduttore IPv4/IPv6 stateful che basa

il proprio funzionamento sull‟algoritmo descritto da SIIT.

Funziona in modo simile al NAT IPv4:

Il nodo traduttore dispone di un pool di indirizzi IPv4 che vengono assegnati ai nodi che lo

utilizzano;

Il traduttore mantiene lo stato delle associazioni;

Gli indirizzi IPv4 sono rappresentati mediante indirizzi IPv6 aggiungendo i 32 bit

dell‟indirizzo ad un prefisso arbitrario di 96 bit instradato verso il traduttore (la mappatura

di un indirizzo IPv6 in un indirizzo IPv4 avviene in maniera dinamica, mentre il contrario

avviene in maniera deterministica).

Esistono differenti modalità di funzionamento di questo traduttore ma, in linea di massima, è

possibile pensare a NAT-PT come ad un traduttore in grado di permettere ad uno o più nodi

IPv6 di comunicare con host IPv4 in maniera analoga a quanto avviene in presenza di un

Proxy, allocando temporaneamente per ciascuno di essi indirizzi IPv4 e tenendo traccia delle

associazioni.

Utilizzando inoltre appositi ALG (Application Level Gateway) NAT-PT è in grado di effettuare la

traduzione dei protocolli di livello applicativo (FTP, DNS, ecc.).

Tale meccanismo è quindi trasparente ai nodi che lo utilizzano. Tuttavia, poiché questo meccanismo

deve tenere traccia delle associazioni effettuate tra gli indirizzi (stateful), è necessario che

tutti i datagram di una sessione vengano inoltrati attraverso il medesimo dispositivo NAT-PT. In

poche parole, esso ha gli stessi problemi del NAT IPv4. Questi svantaggi non hanno però impedito

la diffusione di esso, tanto che molte applicazioni già lo supportano.


4.5. Traduttori a livello di trasporto

4.5.1. Transport Relay Translator

E‟ possibile anche pensare di utilizzare un router posto a cavallo di due distinti segmenti di

rete, ciascuna delle quali basata su una versione differente del protocollo IP. Il Transport

Relay Translator [6] converte sessioni TCP/UDPv6 in sessioni TCP/UDPv4. La traduzione ha

quindi luogo solo a livello 4; anche in questo caso, operando su sessioni comunicative, è

necessario che tutto il traffico relativo alla stesso flusso attraversi lo stesso router (stateful).

La comunicazione, iniziata dal lato IPv6, attraversa il router traduttore; quest‟ultimo

provvederà a terminare la sessione IPv6 e inizierà quindi una nuova sessione comunicativa

IPv4 verso il destinatario, il cui indirizzo viene ricavato direttamente dall‟indirizzo IPv6 (al

prefisso di 64 bit deve seguire infatti l‟indirizzo IPv4 dell‟host destinatario).

Tale meccanismo si basa su un nodo che funziona da “tramite” (relay), il quale agisce in maniera

simile ad un proxy trasparente: il nodo sorgente crede di connettersi al nodo destinazione, ma la

connessione viene intercettata dal relay, che stabilisce a sua volta la connessione IPv4 con la

destinazione.

Purtroppo questo sistema richiede modifiche al server DNS o al resolver sui nodi e richiede che si

mantengano informazioni sullo stato.


4.6. Traduttori implementati via software

4.6.1. BIS e BIA

Alcune tipologie di traduttori operano direttamente sugli end-system, inserendosi sotto forma

di modulo aggiuntivo all‟interno dello stack TCP/IP. IETF ha proposto due diversi

meccanismi, entrambi pensati per consentire ad applicazioni IPv4 di operare all‟interno di reti IPv6.

La soluzione BIS (“Bump-in-the-Stack” [7]) permette a nodi IPv4 di comunicare con nodi IPv6

senza utilizzare trasduttori esterni. Prevede un modulo traduttore inserito tra lo stack IP e il

livello 2 in grado di identificare i pacchetti di livello applicativo che attraversano lo stack

TCP/IPv4 e di conseguenza tradurli prima di inoltrarli via IPv6. In caso che l‟host contattato sia

IPv6, il resolver DNS ritorna all‟applicazione un finto indirizzo IPv4; i pacchetti IPv4 diretti a

questo host vengono così intercettati e trasformati in IPv6.

Anche BIA (“Bump-in-the-API” [8]) permette alle applicazioni pensate per IPv4 di comunicare

con host IPv6 ma, trovandosi ad un livello superiore rispetto a BIS, è in grado di intercettare

direttamente le chiamate alle Socket API. Questo permette a BIA di evitare la traduzione di

pacchetti IP e non è nemmeno necessaria la modifica del nucleo del sistema operativo.

L‟approccio è molto più efficiente rispetto al precedente.


Sia BIS che BIA utilizzano per il loro funzionamento due componenti comuni: un name resolver

ed un address mapper. Il primo ha il compito di effettuare richieste DNS per decidere se il

destinatario del datagram IP supporta solamente IPv6 (ovvero se la traduzione è

effettivamente necessaria o meno); il secondo si incarica invece di allocare temporaneamente

un indirizzo IPv4 utilizzato dall‟applicazione e associato all‟interfaccia IPv6 destinataria.

Entrambi i meccanismi presentano tuttavia il grosso limite di non poter gestire (e quindi

tradurre) eventuali indirizzi inseriti nei protocolli di livello applicativo.

4.7. Una rete eterogenea

Quando fu proposta in IETF per la prima volta la soluzione dual stack IPv4/IPv6 l‟obiettivo era una

migrazione tra i due protocolli del tutto trasparente: partendo con un sufficiente anticipo vi era la

possibilità di avere il 100% dell‟utenza Internet connessa in IPv6 prima di giungere ad un

esaurimento degli indirizzi IPv4; in una situazione di questo tipo ogni applicativo, poteva essere

migrato ad IPv6 in modo del tutto scorrelato dall‟evoluzione di rete. Se a livello applicativo si

fosse a questo punto privilegiato IPv6 rispetto a IPv4 in tutti i casi in cui questo fosse stato

possibile, il traffico IPv4 sarebbe gradatamente diminuito in rete, sino a rendere di fatto inutili

nuove assegnazioni di indirizzi IPv4, se non per esigenze molto specifiche.

È molto probabile che questa situazione ottimale non si possa più verificare neanche con

un‟accelerazione improvvisa dell‟introduzione di IPv6 . È quindi molto probabile che

l‟esaurimento degli indirizzi IPv4 si verifichi prima che IPv6 abbia raggiunto una penetrazione

significativa. Da quel momento in poi a nuovi utenti potranno essere assegnati solo indirizzi

pubblici IPv6. Internet sarà di fatto partizionata in tre categorie di utenza, IPv4 only, IPv4/IPv6 ed

IPv6 only.


Emerge chiaramente la considerazione che se da un lato la possibilità di gestire la coesistenza di reti

eterogenee rappresenta un indubbio vantaggio (non è richiesto l‟aggiornamento immediato o

veloce dei terminali e delle piattaforme di servizio) la promessa che IPv6 fa di una rete più semplice

e meno costosa sarà effettivamente realizzabile solo con la prospettiva di lungo termine di una

sostituzione completa di IPv4 in Internet.

4.8. Riferimenti

[1] RFC 2893 Transition mechanism for IPv6 hosts and routers: http://www.rfc-


[2] RFC 3068 An anycast prefix for 6to4 relay routers: http://www.rfc-editor.org/rfc/rfc3068.txt

[3] RFC 3053 Ipv6 tunnel broker: http://www.rfc-editor.org/rfc/rfc3053.txt

[4] RFC 2765 Stateless IP/ICMP translation algorithm: http://www.rfc-editor.org/rfc/rfc2765.txt

[5] RFC 2766 Network Address Translation – Protocol Translation: http://www.rfc-


[6] RFC 3142 IPv6-to-IPv4 transport relay translator: http://www.rfc-editor.org/rfc/rfc3142.txt

[7] RFC 2767 Dual stack hosts using the Bump-In-the-Stack technique: http://www.rfc-


[8] RFC 3338 Dual stack hosts using Bump-In-the-API: http://www.rfc-editor.org/rfc/rfc3338.txt













5. Conclusioni

Una delle motivazioni che portarono alla definizione di IPv6 è sicuramente la visione di una

Internet del futuro che a partire dal Web e dai servizi telematici, si espande prima all‟ambito

delle telecomunicazioni in generale (telefoni IP, cellulari, sistemi di videoconferenza, ecc.), per

diventare infine pervasiva e permettere la comunicazione ed il controllo remoto di un‟ampia varietà

di oggetti all‟interno e all‟esterno degli edifici.

In futuro gli ambienti (le case, gli uffici, le automobili, le città) diventeranno sempre più intelligenti

e informatizzati e i nuovi dispositivi saranno in grado di interagire e sfruttare l'intelligenza

largamente distribuita in questi ambienti. In futuro si tenderà ad utilizzare sempre più applicazioni

che, a partire dalle funzionalità di localizzazione, permetteranno ai terminali di “capire il

contesto” in cui operano consentendo alle applicazioni di adattarsi alla situazione.

Le nuove applicazioni non comporteranno solo interazione fra esseri umani e servizi, ma anche fra

macchine e macchine. I servizi possibili spaziano dalle applicazioni relative alla sanità e al

wellness a quelle relative al controllo remoto di apparati e sistemi di produzione e controllo, dai

sistemi di infomobilità, ad applicazioni complesse di smistamento merci. Questo nuovo “tipo” di

Internet forse non consumerà grandi quantità di banda, ma avrà sicuramente dei requisiti stringenti

su come i dati saranno trasportati e inviati agli estremi della rete.

Occorre tuttavia notare che questi scenari, pur se da tempo dibattuti, tardano a concretizzarsi: in

passato, ed in certa misura ancora oggi, lo spazio di indirizzamento non ha costituito una

limitazione al collegamento ad Internet di nuovi terminali, ma non per questo vi è stato un

pervasivo proliferare di dispositivi IP.

In questo quadro, non si può quindi affermare che l‟industria sia compatta nell‟attesa della

diffusione del nuovo protocollo. Tuttavia IPv6, con la sua abbondanza di indirizzi, costituisce un

elemento importante affinché i fornitori di tecnologia IP e i Service Provider possano aspirare ad un

ruolo in questo nuovo potenziale mercato.


6. Bibliografia

“IPv6 (IP versione 6)”, http://technet.microsoft.com/it-it/library/cc738636(WS.10).aspx

Baldi M., Risso F., Nicoletti P., “L‟evoluzione di IP: Internet Protocol Versione 6.

Introduzione al nuovo protocollo di livello network della suite TCP/IP”,

http://www.studioreti.it/slide/IPv6-core.pdf;

Fasano P., Marocco D., Siviero M. (2009), “IPv6 e l‟Internet che verrà”, Notiziario tecnico

Telecom Italia, anno 18 numero 2;

Florent Parent, “IPv6 Tutorial” in atti del RIPE 40 Meeting (Praga, 1 ottobre 2001);

Gai S. (1997), “IPv6. Il nuovo protocollo IP per Internet e le Intranet”;

Gai S. (1998), Internetworking IPv6 with Cisco routers, Mcgraw-Hill

Gai S., Baldi M. (2001), “Internet Protocol Version 6”;

Hinden R., “IP Version 6 (IPv6)”, http://playground.sun.com/ipv6/ipng-main.html;

Kozierok Charles M. (2005), The TCP/IP Guide: a comprehensive, illustrated Internet

protocols reference, San Francisco, No Starch Press;

Marin E., “IPv6 Security” in atti del convegno 6NET (Zagabria, maggio 2003).

Paolini G. (2006), “Transizione IPv4-IPv6 e meccanismi di compatibilità”,

http://www.euchinagrid.org/IPv6/IPv6_presentation/IPv6-euchina-2-IT.pdf;

Sommani M., “IPv6 è ora di svegliarsi”, ottavo workshop GARR (Milano, 1-4 aprile 2008);

http://technet.microsoft.com/it-it/library/cc738636(WS.10).aspx

http://www.studioreti.it/slide/IPv6-core.pdf

http://playground.sun.com/ipv6/ipng-main.html

http://www.euchinagrid.org/IPv6/IPv6_presentation/IPv6-euchina-2-IT.pdf


Progetto di rete locale per una realtà aziendale NcbN srl

1. Scenario di progetto e Specifica dei requisiti utente

1.1. Scenario di progetto

La WATB Srl, la NcbN Srl, e la PNcS Srl sono tre aziende di consulenza e sviluppo prodotti

software. In previsione di una crescita dimensionale, hanno costituito una joint venture per acquisire

un immobile da destinare alla realizzazione dei loro nuovi uffici. Per motivi di costo, le tre aziende

hanno stabilito di condividere l’accesso alla rete pubblica attraverso un’unica connessione ad

un ISP. I rispettivi uffici logistici, dopo una prima analisi dell‟immobile, hanno già individuato:

le porzioni di immobile che saranno occupate da ciascuna delle aziende (vedi planimetrie

allegate);

un‟area “condominiale”, dove ospitare le apparecchiature necessarie alla connessione alla

rete pubblica, ed i server accessibili da Internet che sono condivisi;

gli uffici in cui si desidera siano forniti punti di connessione all‟infrastruttura dati, e stabilito

le caratteristiche di ciascun punto di presenza dell‟infrastruttura dati (vedi planimetrie

allegate).

Le aziende hanno quindi stabilito di commissionare ad un‟azienda terza, specifica del settore, la

realizzazione delle infrastrutture di rete dell‟immobile, per le quali sono stati fissati i seguenti

requisiti:

A) Ciascun punto di presenza dell‟infrastruttura dovrà mettere a disposizione 4 prese di rete

associate a cablaggio almeno in cat. 5e UTP. Salvo dove specificato diversamente, ogni

stanza dovrà ospitare fino a 5 postazioni di lavoro, per ciascuna dovrà essere disponibile una

banda minima di 1 Mbps fino ai server aziendali. Le stanze da cablare sono indicate dalla

presenza, nella pianta dell'edificio, di un carattere '1' cerchiato e/o di una lettera alfabetica;

quando presente, a ciascuna lettera alfabetica corrisponde una sola postazione di lavoro. Le

stanze destinate ad ospitare i server, due per ciascuna azienda scelte tra quelle individuate al

punto 3 sopra, dovranno essere in grado di ospitare fino a 24 macchine per stanza. I server

ospitati in queste stanze saranno di tre tipi: server che devono accedere, ed essere accessibili,

dalla rete pubblica per ricevere e smistare la posta spedita o ricevuta dall'azienda (protocolli

smtp e pop3, fino a un massimo di 2), enterprise server (fino a un massimo di 31) e

workgroup server (2 dedicati al lavoro di formazione – vedi p.to H – sotto e fino a un

massimo di 9 per ciascuno degli altri gruppi di lavoro/dominio di sicurezza); l'insieme dei tre

tipi di server non supererà, comunque, le 48 unità.

B) I server condivisi accessibili da Internet, di cui al punto 2, sono il server per DNS ed il server

web. I server di posta elettronica sono inseriti nella rete aziendale, e non nella parte

condominiale (vedere punto A). Questa differenziazione e` giustificata dalla considerazione

funzionale/organizzativa che per gestire appieno questi server e` necessario che entrambe le

aziende dispongano della password di root e mentre questo non e`, necessariamente, un

problema per macchine come un server web pubblico – che per definizione contiene dati da

diffondere – potrebbe esserlo per un server di posta che vede transitare e riconosce messaggi


potenzialmente riservati, in particolare se si tratta di corrispondenza interna all'azienda (salvo

prevedere un ulteriore server smtp come enterprise server privato).

C) La sicurezza dei dati e dei sistemi di ciascuna azienda deve essere garantita sia rispetto ad

accessi da Internet sia rispetto a quelli da parte delle altre aziende nel complesso edilizio. Le

tre aziende vogliono essere messe in grado di controllare autonomamente e in sicurezza le

politiche di accesso alla propria rete dall‟esterno (Internet, la rete dell'altra azienda).

D) Sulla rete è ammesso solo traffico appartenente ai protocolli dello stack TCP/IP.

E) Per motivi di costo, il numero di indirizzi IP pubblici (estratti dalla subnet 131.114.28.0/24)

l‟interconnessione a Internet (e per permettere la irraggiungibilità` dei server) deve essere

pari al minimo necessario;

F) Le tre aziende chiedono di fornire una configurazione iniziale della propria rete con tre

diversi domini di sicurezza che fanno riferimento alla struttura organizzativa, indicati, per

comodità, come A (Amministrativo), M (Marketing), e P (Produzione). Le macchine del

dominio di sicurezza A potranno aprire connessioni con protocolli basati su TCP verso

macchine del dominio P ed M ma non viceversa. Solo le macchine dei domini M e P

potranno accedere a Internet.

G) Le macchine che forniscono i servizi di posta elettronica e di presenza nel World Wide Web,

dovranno essere accessibili alle macchine di tutti e tre i domini (e da Internet), con il minimo

livello di esposizione: ad esempio, i server di posta elettronica dovranno permettere di

ricevere la posta indirizzata all'azienda (e spedire quella da essa originata, protocollo SMTP)

oppure di accedere alla lettura della stessa (protocollo POP3), ma non devono permettere

accessi ad altri servizi/protocolli.

H) Il protocollo di routing utilizzato all'interno della rete del complesso edilizio e` EIGRP

I) Nel complesso edilizio è presente anche un ulteriore edificio (non riportato nelle mappe) che

occupa tre locali che le aziende hanno stabilito di condividere, utilizzandoli ciascuno al

bisogno, come aule didattiche per l‟erogazione di corsi di formazione avanzata. I tre locali

sono in grado di ospitare, rispettivamente fino a 5, 12 e 30 allievi. In ciascuno di questi

locali, l‟accesso alla rete sarà consentito da un punto di accesso wireless (che svolgerà

esclusivamente funzione di media converter) e la rete assegnerà automaticamente i parametri

di configurazione IP ai portatili utilizzati dai clienti che assistono al corso di formazione in

modo tale che sia loro consentito esclusivamente l‟accesso ai server dedicati alla formazione

dell‟azienda erogatrice.

J) La connessione con l'ISP avviene attraverso un link Frame Relay

In vista della dinamicità del settore (e in particolare dell‟elevato livello di concorrenza tra ISP) le

aziende richiedono, inoltre, che sia fornita una guida dettagliata (in grado di far loro determinare i

costi intrinseci al progetto proposto) delle operazioni da effettuare sulla loro rete nel caso di una

loro eventuale decisione di cambiare il fornitore di accesso a Internet.


1.2. Task individuale

Progettazione e realizzazione della rete di NcbN e della sua connessione con la rete pubblica e quelle di WATB e PNcS

Sulla base delle indicazioni fornite nello scenario, e assumendo che la collocazione della MDF di

Campus sia nella stanza di cui al punto 2 dello scenario:

Progettare l’infrastruttura fisica, con particolare riferimento al cablaggio verticale, della

rete di NcbN e per la connessione con la rete pubblica e quelle di WATB e PNcS,

necessaria al supporto delle funzionalità richieste, tenendo conto che:

le caratteristiche del cablaggio della rete dati dovranno essere adeguate ai requisiti di banda

descritti e permettere la loro crescita fino a un fattore 10x;

il backbone della rete deve garantire tempi di interruzione della connessione non superiori al

centinaio di secondi;

devono essere scelti i mezzi di cablaggio (rame o fibra) che permettono di soddisfare i

requisiti funzionali e le buone norme di cablaggio ai costi più bassi (si ricordi che il

cablaggio UTP ha costi molto minori di quello in fibra ma anche specifiche limitazioni: di

lunghezza, di eventuali interferenze, ecc.);

il progetto deve essere realizzato nel rispetto degli standard TIA/EIA-568-A e TIA/EIA-569.

Per quanto riguarda questo punto, si richiede che venga fornita la seguente documentazione di

progetto:

collocazione dei punti di distribuzione della rete (MDF e IDF);

mappa logica e mappa fisica dettagliata dei percorsi del cablaggio verticale (tra xDF);

Tutte le scelte di progetto dovranno essere adeguatamente giustificate.

Progettare e descrivere la realizzazione delle funzionalità di switching e routing della rete

di cui sopra tenendo conto che:

si dispone degli oltre 16.000 indirizzi IP nella rete 172.17.128.0/18 su cui applicare il

subnetting (eventualmente con tecnica VLSM) da utilizzare nel modo più efficiente possibile

(considerare eventuali implicazioni della presenza di WATB e PNcS, ed eventualmente

stabilire un partizionamento preventivo, tra le tre aziende, dello spazio degli indirizzi);

Le postazioni di lavoro (macchine client) che potranno appartenere al dominio A sono al

massimo (fine vita) 20, quelle che potranno appartenere al dominio M sono al massimo

(fine vita) 52.

si vogliono raggiungere le condizioni di massima sicurezza rese possibili dalla tecnologia

(L2/L3) utilizzata.

Le scelte effettuate dovranno essere adeguatamente giustificate (in termini di costi, funzionalità,

ecc.) e dovrà essere fornita tutta la documentazione del caso:

numero e tipo degli switch/router installati in ciascuna delle Distribution Facilities;

configurazione di uno degli switch, a scelta, a cui faccia capo almeno una macchina per

ciascuno dei domini di sicurezza descritti sopra.

configurazione di tutti i router di interesse per la gestione del traffico di NcbN

(connessione con l'ISP compresa, per quanto riguarda le interfacce DTE).

Viene, infine, richiesto di fornire una dimostrazione della rete progettata attraverso una simulazione

della stessa, costruita con Packet Tracer limitatamente alle funzionalità supportate dal simulatore.

La simulazione deve contenere uno scenario con almeno 5 PDU che permettano di verificarne il

funzionamento.


1.3. Planimetrie





2. Analisi del progetto, specifica dei requisiti tecnici e organizzazione delle attività di progetto.

2.1. Analisi del progetto

Come si può vedere dalle planimetrie allegate il campus da cablare è composto da più edifici così

partizionati:

per la WATB srl abbiamo:

Il South Building 1 di dimensioni 25x26m su due piani.

Due edifici su di un piano di dimensioni 30x6m e 38x6m.

Per la NcbN srl abbiamo:

Il North Building di dimensioni 25x26m su due piani.

Il Multi Purpose Building di dimensioni 27x14m su di un piano, dove è stata concordata

l'area a comune tra le tre aziende in quanto contiene il POP.

Due edifici di un piano di dimensioni 38x6m 38x6m

Per la PNcS srl abbiamo:

Il South Building 2 di dimensioni 25x26m su due piani.

Il Media Center di dimensioni 20x12m su di un piano.

Due edifici di un piano di dimensioni 38x6m .

inoltre è presente un edificio (non riportato nelle planimetrie) a comune tra le tre aziende

per l'erogazione dei corsi di formazione. Questo è supposto vicino al Multi-Purpose

Building.

Dalle specifiche fornite si deduce che:

è prevista una ridondanza dei cavi sia di bandwidth che di numero. Questo per ragioni di

eventuali guasti, eventuale ampliamento della rete (crescita di un fattore 10x) o del

servizio, per i costi che comporterebbe il tornare sopra il cablaggio;

Nell‟edificio sono già presenti le canaline principali, quindi non sarà necessario

apportare molte modifiche alla sua struttura fisica. Inoltre sono già presenti anche i

controsoffitti.

Per il cablaggio verticale si usano multifibre composte di 4 fibre di cui solo due sono

utilizzate e collegate allo stesso dispositivo per permettere un collegamento full-duplex;

le altre due rimangono libere e già posate per un successivo ampliamento o per non

perdere il collegamento con un piano in caso di guasto.

Sono previste le seguenti topologie di server:

Workgroup: contiene dati accessibili solo agli utenti che appartengono al gruppo di

lavoro del server;

Enterprise: contiene dati accessibili a tutti gli utenti che appartengono alla rete

dell'azienda.

2.2. Specifica dei requisiti tecnici

È stato seguito lo standard EIA/TIA-568-A e EIA/TIA-569 ragion per cui:

La topologia è a stella estesa su tre livelli gerarchici:

primo livello il permutatore di campus;

secondo livello i permutatori degli edifici principali;


terzo livello i permutatori di piano e di edifici secondari.

Questa topologia offre diversi vantaggi, tra cui:

scalabilità;

manutenibilità e facilità di gestione;

sicurezza (dal punto di vista delle politiche di traffico);

semplice distribuzione della ridondanza.

il VCC in dorsali tra gli edifici sono in fibra ottica multimodale 62.5/125 цm;

permette immunità dai disturbi elettromagnetici, banda elevata e un'ampia copertura

(2000m).

il HCC in cavi UTP multicoppia CAT 5e da 100 MHz con connettore RJ45; in questo modo

è sempre garantita una banda minima di 1Mbps con una certa ridondanza.

Si deve inoltre precisare che, anche se una postazione di lavoro contiene quattro prese di

rete, solo una verrà usata per collegarvi un calcolatore.

il MDF è posto nell'edificio Multi Purpose nella stanza in cui c'è il POP. La collocazione

permette la copertura di tutte le postazioni di lavoro presenti nell'edificio.

gli IDF sono posti in maniera da rispettare il raggio di copertura dell'UTP cat 5e nei locali in

cui sono già presenti le canaline.

Server usati:

Server DNS che gestisce la corrispondenza tra gli indirizzi IP pubblici di internet e i nomi

simbolici.

Server WEB che gestisce il servizio internet mediante il protocollo http.

Server e-mail che gestisce l'invio e la ricezione di posta elettronica rispettivamente tramite il

protocollo SMTP e POP3.

Visto i costi elevati dell'assegnazione di un indirizzo pubblico si cerca di limitarne il numero e

quindi, grazie al NAPT, servono solo quattro indirizzi IP pubblici quindi dovremmo prendere una

subnet da 8 indirizzi pubblici. È immediato osservare che in questo modo rimarrebbero degli

indirizzi IP pubblici non utilizzati, ragion per cui diamo un indirizzo IP pubblico anche ai server

WEB e DNS.

Vista la presenza di diversi domini si prevedono sette VLAN per ogni rete aziendale più cinque

nell'area condivisa:

Amministrazione, indicata con la lettera A:

Postazioni di lavoro e server workgroup appartenenti all'amministrazione;

si occupa dell'amministrazione della azienda;

Marketing, indicata con la lettera M:

Postazioni di lavoro e server workgroup appartenenti al marketing.

Produzione, indicata con la lettera P:

Postazioni di lavoro e server workgroup appartenenti alla produzione.

Formazione, indicata con la lettera F:

Server workgroup dell'azienda specifica.

Enterprise, indicata con la lettera E:

Server enterprise appartenenti all'azienda.

SMTP, indicata con la lettera S:

Server MAIL;

ForW:


contiene i portatili degli studenti del corso di formazione tenuto dall'azienda

WATB;

ForN:

contiene i portatili degli studenti del corso di formazione tenuto dall'azienda

NcbN;

ForP:

contiene i portatili degli studenti del corso di formazione tenuto dall'azienda PNcS;

(ovviamente per le VLAN con la stessa denominazione sarà aggiunta una lettera maiuscola in fondo

indicante l'azienda d'appartenenza; ad esempio: AmministrazioneW sarà la sottorete

dell'amministrazione di WATB)

Il protocollo di routing usato è l'EIGRP realizzato da Cisco. Questo protocollo permette:

una veloce convergenza e l'uso di pacchetti di update per mantenere le tabelle consistenti;

questi vengono mandati solo quando ho cambiamenti topologici così risparmio banda;

prevenzione di loop grazie al DUAL;

la tabella di routing non contiene anche la topology table;

può imparare rotte esterne che riguardano anche altri protocolli;

fornisce meccanismi di criptaggio delle informazioni di routing;

la metrica può tenere conto di: (quelli sottolineati sono quelli considerati per default)

bandwidth;

delay;

load;

reliability.

Può supportare più protocolli di layer 3 grazie alla sua progettazione a PDM.

Per quanto riguarda la connessione con l‟ISP, questa avviene attraverso un link Frame Relay. Tale

tecnica di trasmissione permette di inviare dati con “banda a richiesta”: l‟utente può richiedere

banda più alta secondo il bisogno. Comunque si possono specificare banda minima garantita oltre

che banda massima, grazie ai meccanismi di controllo del flusso e della congestione. Inoltre ha

anche il vantaggio di usare una sola interfaccia sul DTE e una sola linea di accesso al servizio.

2.3. Funzionalità utilizzate per soddisfare i requisiti

In questo paragrafo per sicurezza s'intende le regole che vincolano il traffico tra le tre reti aziendali.

Per soddisfare i requisiti di sicurezza si utilizzano i seguenti meccanismi:

Access Control List. Sono un insieme di regole tramite le quali si permette o si nega il

traffico basato su indirizzo IP della sorgente, indirizzo IP del destinatario, porta sorgente e

porta di destinazione e protocollo del pacchetto. Le ACL permettono di:

Limitare il traffico sulla rete in modo da aumentarne le prestazioni

Operare un controllo di flusso

Creare un livello base di sicurezza per l‟accesso alla rete

Decidere quale tipo di traffico inoltrare o evitare di inviare alle interfacce dei router


Controllare quali aree di un client possono accedere a una rete

Proibire o permettere l‟accesso ai servizi della rete a determinati host.

Le VLAN che permettono di separare il dominio di broadcast e di separare il traffico tre le

tre aziende in quanto queste, oltre al server WEB, al server DNS e al POP, non devono

condividere altro.

Per soddisfare i requisiti di segregazione del traffico:

Si usano gli switch che separano il dominio di collisione e quindi rendono la rete più

performante avendo un uso migliore della banda.

Si usano i router che separano il dominio di broadcast e quindi si risparmia in termini di

bandwidth e si riducono le possibilità di congestione.

Per rendere la rete più robusta viene implementata una politica di ridondanza esclusivamente a

livello di cablaggio. Infatti, viste le dimensioni ridotte della rete non è strettamente necessario

prevedere anche una ridondanza a livello di dispositivi di rete che porterebbero ad una spesa

eccessiva. Invece, la ridondanza del cablaggio è opportuna per non perdere i contatti con un edificio

appartenente all'azienda. Questa parte verrà meglio approfondita nella parte pertinente ad ogni

singola azienda.


2.4. Architettura d'insieme del progetto

La rete aziendale è costituita da una parte su rete pubblica e da una parte di “core” interna alla rete

stessa.

Il confine tra la rete esterna e la rete interna è rappresentato dal router di confine che provvede a

mostrare all'esterno la rete aziendale come un unico Autonomous System.

Al router viene ovviamente connesso uno switch al quale si collegheranno i due server, il DNS e il

WEB, comuni alle tre aziende e i tre router aziendali, anch'essi terminali di confine delle reti delle

singole aziende.

Lo schema generale è questo:


2.5. Convenzioni e linee guida di progettazione

In fase di configurazione del protocollo EIGRP sui router che formano la rete delle aziende si deve

inserire l'AS (Autonomous System) che, per permettere la comunicazione tra questi, deve

coincidere. Quindi l'AS è unico e di valore 1.

Avremo bisogno di configurare anche il NAPT (Network Address Ports Translation) per permettere

agli utenti della rete aziendale di accedere ed essere visibili all'esterno.

Infatti, visti i costi e lo scarso numero di indirizzi pubblici, all'interno della rete aziendale si usano

indirizzi privati. Questo viene configurato su ogni router di confine dell'azienda i quali hanno

sull'interfaccia che da sull'esterno un indirizzo IP pubblico.

In particolare usiamo il NAPT, che permette la differenziazione per indirizzo IP più porta, per la

seguente osservazione: abbiamo otto server (tre server SMTP, tre server POP3, un web server e un

DNS server) che necessitano di indirizzo pubblico, questi offrono quattro servizi diversi (SMTP,

POP3, DNS, HTTP) ovvero quattro porte diverse (25, 110, 53, 80) e quindi anziché usare nove

indirizzi pubblici (uno per il router del MDF) ne uso sei (agli altri host le porte vengono assegnate

automaticamente dal Sistema Operativo), così distribuiti:

uno per il router contenuto nel MDF;

uno per il server DNS;

uno per il server WEB;

uno per ogni router di confine dell'azienda che, in overloading, gestisce gli host interni e i

due server di posta.

In particolare visto che i server che sono visibili su internet devono avere un indirizzo IP statico si

utilizza il NAPT statico.

Per gestire i diversi “permessi” associate alle VLAN (Virtual Loacal Area Network) si usano le

ACL (Access Control List) che operano a livello di filtraggio di pacchetti. È utile specificare che ne

esistono di due tipi:

Standard, sono posizionate il più vicino possibile alla destinazione.

Estese, sono posizionate il più vicino possibile alla sorgente del traffico da bloccare. Con

queste si specificano condizioni più dettagliate in quanto è possibile inserire più parametri

discriminanti.

Le tre aziende adottano una stessa politica nella gestione delle ACL; queste sono poste in ingresso

alla sottointerfaccia logica (le motivazioni per l'uso delle sottointerfacce logiche è rimandato alla

parte personale) corrispondente al dominio stesso. Il traffico controllato da queste ACL è quindi

quello che proviene dal dominio di sicurezza a loro associato ed è diretto fuori dal dominio stesso,

in tal modo viene evitato un inutile spreco di banda.

Inoltre ci saranno ACL per impedire la comunicazione tra le tre aziende.


2.6. Organizzazione dei moduli di progetto e attribuzione delle relative risorse

Per quanto riguarda il partizionamento dello spazio di indirizzamento IP, occorre tenere presente il

costo eccessivo derivante dall'utilizzo di numerosi indirizzi IP pubblici. La subnet da cui possiamo

estrarre gli indirizzi IP pubblici è la 131.114.28.0/24.

Da una prima analisi vediamo che, per permettere la raggiungibilità dei server e l'interconnessione a

internet, sono necessari nove indirizzi pubblici, di cui uno per il router di confine MDF, sei per i

server di posta delle tre aziende, due rispettivamente per i server condivisi WEB e DNS.

Per cercare di ridurre al minimo necessario il numero di tali indirizzi, però consideriamo che

potrebbero bastare tre indirizzi IP pubblici, uno per il router di confine della rete complessiva e due

indirizzi IP pubblici per i server di posta elettronica (2 per ogni azienda). Questo perché i server

WEB e DNS a comune tra le tre aziende e due server di posta di una delle aziende vengono

discriminati in base al numero di porta sulla quale presentano le proprie richieste (25 per l'SMTP,

110 per il POP3, 53 per il DNS, 80 per il server WEB).

In questo modo avremmo bisogno di una sottorete da 8 host (tre indirizzi IP pubblici più un

indirizzo di rete e uno di broadcast).

Quindi, visto che rimangono tre indirizzi IP pubblici liberi, decidiamo di sfruttarli con la seguente

configurazione:


Per quanto riguarda la parte privata abbiamo a disposizione di oltre 16.000 indirizzi IP estraibili

dalla rete 172.17.128.0/18. Quindi all‟interno del complesso aziendale, costituito da tre aziende, questi

indirizzi devono essere univocamente assegnati in modo da non creare conflitti, quindi si suddivide lo

spazio di indirizzamento fornito in modo che ogni amministratore delle tre reti possa fare riferimento ad

un preciso pool d'indirizzi privati.

Le macroclassi in cui viene divisa la rete aziendale applicando la tecnica VLSM (Variable Length

Subnet Mask) sono: (sono tre formazioni)

Macroclasse # host Indirizzo IP di rete Maschera

WATB 4094 172.17.128.0 255.255.240.0

NcbN 4094 172.17.144.0 255.255.240.0

PNcS 4094 172.17.160.0 255.255.240.0

Area Comune 4094 172.17.176.0 255.255.240.0

(Nel numero di host abbiamo già considerato un eventuale crescita di un fattore 10x.)


Abbiamo considerato la seguente nomenclatura degli edifici:


Quindi, considerando le planimetrie date, è possibile individuare il seguente conteggio di postazioni

di lavoro:

Edificio # postazioni di lavoro

South Building 1 140 (calcolatori) + 48 (server)

South Building 2 184

North Building 133

Media Center 20

Multi-Purpose Building 27

Edificio adibito alla formazione 47

Polo B 30

Polo C 20

Polo E 25

Polo F 25

Polo I 25

Polo L 25

Dallo spazio di indirizzi pubblici 131.114.28.0/24 prendiamo una sottorete da otto host, ovvero

131.114.28.0/29.

Ovviamente gli indirizzi IP privati delle interfacce dei router che danno verso l'interno delle singole

reti aziendali e dei server dell'azienda, saranno assegnati staticamente, mentre gli indirizzi IP privati

degli host saranno assegnati dinamicamente dal meccanismo DHCP implementato dal router

aziendale.

Per quanto riguarda l'assegnamento degli indirizzi IP ai portatili dei corsi di formazione il DHCP

viene implementato sul router condiviso (quello contenuto nel MDF) per tutte e tre le aziende.


3. Rete Area Comune

3.1. Architettura della rete a comune

Viene progettata un unica rete aziendale che sfrutta le VLAN per permettere alle tre aziende di

gestirsi in modo indipendente adottando le proprie politiche di sicurezza e di amministrazione. In

questo modo il cablaggio è comune e questo permette un notevole risparmio.

Come già detto (vedi p.to 2.1) è prevista un'area condominiale, ovvero comune alle tre aziende, che

viene a coincidere con il MDF dove risiedono il server WEB, il server DNS e il POP, ovvero i

dispositivi condivisi dalle aziende e alcuni mezzi trasmissivi (router MDF, uno switch).

E' composta da tre aree, ovvero:

la ForW;

la ForN;

la ForP.

Queste possono comunicare solo con le reciproche VLAN presenti in ogni azienda; ovvero possono

accedere solo ai server della formazione. Per assicurarci che questo metodo funzioni si

implementano delle opportune VLAN.

L'altra parte comune riguarda l'infrastruttura dell'edificio di formazione.

L'edificio adibito ai corsi di formazione si suppone vicino al MDF, di modo da risparmiare sui costi

di cablaggi che, essendo esterni all'edificio, devono essere fatti in fibra ottica. Dallo switch

contenuto nel MDF parte la fibra ottica fino allo switch all'interno dell'edificio della formazione; a

questo sono attaccati tre access point, uno per ogni azienda, a cui i partecipanti dei corsi si

collegano inserendo la specifica WEP dell'azienda erogatrice del corso. Con questa scelta

implementativa non è necessario fare particolari controlli, infatti tutto funziona in maniera

automatica senza l'intervento di un amministratore che configuri i dispositivi trasmissivi di giorno

in giorno (tenendo conto che le aule possono essere tutte fissate da un'azienda, oppure una aula per

ogni azienda e così via ogni possibile permutazione).

Si assume che ogni singolo access-point riesca a ricoprire con il suo raggio di copertura le tre aule

dell'edificio della formazione; inoltre non sono stati richiesti requisiti di banda minima all'interno di

tale edificio, quindi non ci preoccupiamo, nella scelta del numero di access-point necessari, di

questo fattore.

Il collegamento della rete aziendale con l'lSP, ovvero con il provider dei servizi, avviene attraverso

il punto di interconnessione POP presente nel Multi Purpose Building con un link frame relay.

Se ci sono particolari esigenze sulla capacità di banda, sulla velocità e sulla garanzia del servizio, è

consigliabile l'utilizzo della tecnologia VDSL (Very High Digital Subcriber Line), che consente di

avere un collegamento simmetrico e un'elevata velocità garantita.


3.2. Cablaggio strutturato della rete comune

La rete comune è quella all'interno dell'edificio Multi Purpose Building dove risiede il permutatore

di campus (MDF), da cui si dipartono le dorsali in fibra ottica tra gli edifici principali delle tre

aziende. È stata scelta la stanza con il POP di modo da ridurre l'estensione dei cavi per il

collegamento tra questo e il router centro stella di comprensorio.

Il locale scelto per l'area comune presenta delle particolari caratteristiche ambientali, ovvero deve

mantenere una temperatura intorno ai 21° e un tasso di umidità adeguato per le apparecchiature al

suo interno.

Il cablaggio è così disposto:

All'interno del locale MDF ci sono i seguenti mezzi trasmissivi:

router, che da la connettività esterna. Dispone di:

una porta FastEthernet, per permettere il collegamento tramite cavo UTP cat. 5e con lo

switch MDF;

una porta Console, per permettere la sua configurazione;

una porta seriale, per il collegamento con il punto di presenza offerto dal provider.

Switch, che raccorda i router centro stella di ogni edificio principale i due server condivisi

(DNS e WEB)e lo switch dell'edificio. Dispone di ventiquattro porte.


Diagramma logico dei collegamenti del MDF che mostrano la topologia a stella estesa su tre livelli

gerarchici:

3.3. Dispositivi attivi e layer 2 della rete comune

Nell'area condominiale, ovvero nel MDF, abbiamo un router e due switch.

Il router è il centro stella di campus e fa da frontiera con l'esterno. Su tale router sono configurate

alcune ACL per bloccare il traffico proveniente dall'esterno che non usa richieste del seguente tipo:

SMTP, POP3, DNS e HTTP.

Infatti occorrerà bloccare le connessioni provenienti dall‟esterno della rete aziendale globale,

limitandole alle sole richieste http (per quanto riguarda il server web), dns (per quanto riguarda il

server DNS) , smtp e pop3 (per quanto riguarda i server di posta), applicando una ACL

sull‟interfaccia seriale del router in ingresso verso l‟interno della rete. Poi occorrerà bloccare il

traffico che dall‟interno della rete vuole dirigersi verso l‟esterno, limitando anch‟esso alle sole

richieste http da parte dei domini di sicurezza autorizzati, naturalmente con una ACL applicata

all‟interfaccia fast ethernet del router in uscita verso l‟esterno della rete. Infine, occorrerà bloccare

le connessioni dei domini della formazione, tranne che verso la rete della rispettiva azienda; questo

verrà fatto ponendo una ACL sulle sottointerfacce fast ethernet del router in uscita verso l‟interno

della rete.


Poi ci sono due switch, uno che raccorda i router delle tre aziende e uno di edificio per le postazioni

di lavoro presenti nel Multi Purpose (quest'ultimo si trova nel MDF ma fa parte della rete

dell'azienda NcbN).

3.4. Piano di indirizzamento

3.4.1. Suddivisione dello spazio di indirizzamento interno

Nell'area comune sono presenti tre domini distinti già individuate al p.to 3.1.

Vediamo come sono state inizializzate, l'indirizzo di partenza è 172.17.176.0/20:

Nome sottorete IP sottorete subnet mask Broadcast Range hosts

ForW 172.17.176.0 255.255.255.192 172.17.176.63 172.17.176.1 a 172.17.176.62

ForN 172.17.176.64 255.255.255.192 172.17.176.127 172.17.176.65 a 172.17.176.126

ForP 172.17.176.128 255.255.255.192 172.17.176.191 172.17.176.129 a 172.17.176.190

Inoltre abbiamo i due server condivisi a cui sono assegnati indirizzi pubblici:

Dispositivo IP Maschera

Server WEB 131.114.28.5 255.255.255.248

Server DNS 131.114.28.6 255.255.255.248

Router MDF:

Dispositivo Interfaccia IP Maschera

Router MDF:

Fa0/0 131.114.28.1 255.255.255.248

Fa0/0.2 172.17.176.1 255.255.255.192

Fa0/0.3 172.17.176.65 255.255.255.192

Fa0/0.4 172.17.176.129 255.255.255.192

Ser0/3/0 Data dal ISP


3.4.2. Piano di indirizzamento pubblico

Seguendo la strategia descritta al p.to 2.5 si adotta la seguente corrispondenza tra indirizzi local

(interni alla sottorete) e global (visibili all'esterno).

L'indirizzamento pubblico è stato così gestito:

Dispositivo Indirizzo privato Indirizzo pubblico

Router MDF (Fa0/0) / 131.114.28.1

Router W / 131.114.28.2

Router N / 131.114.28.3

Router P / 131.114.28.4

Server WEB / 131.114.28.5

Server DNS / 131.114.28.6

Server SMTP W 172.17.141.129 NAPT --> 131.114.28.2::25

Server POP3 W 172.17.141.130 NAPT --> 131.114.28.2::110

Tutti gli altri dispositivi di WATB a.b.c.d NAPT --> 131.114.28.2::x

Server SMTP N 172.17.146.66 NAPT --> 131.114.28.3::25

Server POP3 N 172.17.146.67 NAPT --> 131.114.28.3:110

Tutti gli altri dispositivi di NcbN a.b.c.d NAPT --> 131.114.28.3::x

Server SMTP P NAPT --> 131.114.28.4::25

Server POP3 P NAPT --> 131.114.28.4::110

Tutti gli altri dispositivi di PNcS a.b.c.d NAPT --> 131.114.28.4::x

Ovviamente la corrispondenza viene ottenuta applicando opportunamente il NAPT sui router di

confine delle tre aziende; per la configurazione si rimanda al p.to 3.6.

Come si nota dalla tabella, il router di frontiera dell‟MDF e i server MAIL hanno la necessità di

utilizzare un proprio ben determinato indirizzo pubblico in uscita pur conservando il proprio

indirizzo privato. In questo caso tramite il NAT statico si può fare una mappatura 1:1 in cui è

garantito il mascheramento ma l'unicità dell'host in uscita permette di tradurre solamente l'indirizzo

IP sorgente lasciando inalterata la porta TCP/UDP.

Nel caso, invece, dei server WEB e DNS si utilizza il NAT dinamico, un caso particolare di source

NAT, in cui le connessioni generate da un insieme di macchine diverse vengono "presentate" verso

l'esterno con un solo indirizzo IP. La tecnica è detta anche Port Address translation (PAT), IP

Overloading o NAPT (Network Address and Port Translation), in quanto vengono modificati non

solo gli indirizzi IP ma anche le porte TCP e UDP delle connessioni in transito.

Questo metodo prevede di individuare una rete "interna" (che tipicamente utilizza indirizzi IP

privati) ed una "esterna" (che tipicamente utilizza indirizzi IP pubblici), e permette di gestire solo

connessioni che siano originate da host della rete "interna".


Ciascuna connessione TCP o UDP viene gestita individualmente: quando la connessione viene

iniziata, la porta sorgente originale può essere modificata, e il router NAT mantiene una tabella di

corrispondenze tra porte sull'indirizzo esterno e corrispondenti porte e indirizzi IP privati. Quando

riceve un pacchetto TCP o UDP sull'indirizzo IP esterno, consulta la tabella per sapere a quale host

interno e su quale porta inviarlo. Il router NAT deve quindi tenere traccia di tutte le connessioni

TCP e UDP attive tra la rete interna e quella esterna (e preoccuparsi di eliminare le voci inutilizzate

da questa tabella mediante un meccanismo di scadenza).

Questa tecnica viene dunque qua scelta per collegare la rete interna ad Internet, permettendo di

mantenere un piano di indirizzamento IP che non permetterebbe la connessione diretta ad internet,

di risparmiare indirizzi IP pubblici e di "nascondere" all'esterno l‟intera rete privata. In questo

modo, nella rete interna gli host utilizzano indirizzi IP privati, e tramite il router di frontiera viene

effettuata la traduzione da indirizzo IP privato (valido nella sola Intranet) ad indirizzo IP pubblico

(quindi utilizzabile in Internet).


3.5. Dispositivi impiegati in ogni Distribution Facilities della rete comune

3.5.1. MDF

Elenco dispositivi presenti nel MDF:

Dispositivo Interfaccia Collegata a..

Router MDF

fa0/0 Switch MDF

Fa0/0.2 VLAN forW

Fa0/0.3 VLAN forN

Fa0/0.4 VLAN forP

Ser0/3/0 POP

Switch MDF

Fa0/1 Router MDF

Fa0/2 Router WATB

Fa0/3 Router NcbN

Fa0/4 Router PNcS

Fa0/5 Server DNS

Fa0/6 Server WEB

Fa0/7 Switch della formazione

Switch AP

Fa0/1 AP dell‟azienda WATB

Fa0/2 AP dell‟azienda NcbN

Fa0/3 AP dell‟azienda PNcS

Server WEB Fa Switch MDF

Server DNS Fa Switch MDF


3.5.2. Tabella riassuntiva dispositivi impiegati

Per riassumere sono stati usati i seguenti dispositivi nell'area comune:

Dispositivo Caratteristiche

Router MDF Router di confine della intera rete aziendale.

Qui implemento il DHCP per la formazione.

Ha tre sottointerfacce logiche per le VLAN della formazione.

Ha due porte FastEthernet per i cavi UTP.

Ho due porte seriali, di cui una usata per la connessione con il POP3.

Collocazione --> MDF nel Media Purpose Building

Switch MDF Ha sedici porte FastEthernet:

sei per la fibra ottica

dieci per cavi UTP

Interconnette fisicamente le reti dei vari edifici principali di ogni singola

azienda, i due server condivisi e lo switch dell'edificio della formazione.

Su di esso è attivo lo STP per permettere la ridondanza dei cavi in fibra

ottica tra gli edifici principali.

E' in server mode per il VTP per le VLAN.

Modello Cisco Catalyst 2960-16TT-L.


Switch AP Ha otto porte FastEthernet:

due per la fibra ottica

sei per cavi UTP

Interconnette fisicamente lo switch MDF con i tre access point

dell'edificio della formazione.

E' in server mode per il VTP per le VLAN.


Collocazione --> prima stanza dell'edificio della formazione.

Server DNS Server.


Server WEB Server.



3.6. Configurazione dei dispositivi della rete comune

I dispositivi da configurare sono il router e gli switch.

Quindi presenteremo la startup configuration del router MDF e dello switch MDF.

SWITCH MDF:

Dobbiamo impostare le VLAN. Per farlo usiamo il VTP (Virtual Trunking Protocol) che si occupa

di trasferire le VLAN create sullo switch server agli altri switches a lui collegati. Lo switch server

sarà lo switch MDF, mentre gli sugli altri eseguiremo il comando <(config)#vtp mode client> per

configurarli come client.

Imposteremo come porte trunk quelle tra gli switch mentre le altre saranno access.

Poi procederemo con la creazione delle tre VLAN.

!

version 12.2

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname SwitchMDF

!

!

!

interface FastEthernet0/1

switchport mode trunk

!



!



!



!


!


!



!


!


!



!


!


!


!


!


!


!


!


!


!


!


!


!


!


!

interface GigabitEthernet1/1

!


!

interface Vlan1

no ip address

shutdown

!

!

line con 0

!

line vty 0 4

login

line vty 5 15

login

!

!

end


ROUTER MDF:

Vista la presenza di VLAN useremo delle sottointerfacce del router per permettere la

comunicazione tra queste. Questa soluzione è ottimale in quanto sennò avrei avuto bisogno di router

con più porte, e quindi più costosi, e di un numero maggiore di router.

Associamo alle sottointerfacce le VLAN.

Impostiamo il protocollo EIGRP.

Poi impostiamo le ACL: il router centrale dell‟MDF è il punto focale per la connessione a Internet

dell‟intera rete. Per aiutare il controllo di sicurezza della rete è stato quindi implementato un filtro,

che consente di interfacciare i server residenti DNS, Email e Web a Internet utilizzando il router

come una sorta di spina dorsale, di pubblico confine. In questo modo il traffico inviato dall‟esterno

della rete può interfacciarsi solo con alcune specifiche porte del router di frontiera. Tutto questo

viene fatto dalle ACL. Ogni altro traffico inviato dall‟esterno della rete viene fermato quando tenta

di entrare nella rete e connettersi alle varie LAN aziendali.

Le ACL saranno prevalentemente di tipo esteso e saranno implementate per la suite di protocolli

TCP. Questo permetterà alle ACL di abilitare o bloccare specifiche porte e indirizzi destinatari. Le

ACL saranno implementate su entrambe le interfacce del router in uscita. Questo assicura che ogni

pacchetto che tenta di accedere alla rete da Internet sarà soggetto all‟ACL, per controllare a quale

porta tenta di connettersi. Se non viene trovata una regola per la rispettiva porta nell‟ACL il

pacchetto verrà automaticamente scartato.

!

version 12.4




!

hostname Router

!

!

!

!

!

!

!

!

!

!

ip name-server 0.0.0.0

!

!

!

!

!

!



ip address 131.114.28.1 255.255.255.248

ip access-group formazione out

duplex auto

speed auto

!

interface FastEthernet0/0.2

description vlan 2 forW

encapsulation dot1Q 2

ip address 172.17.176.1 255.255.255.192

!


description vlan 3 forN


ip address 172.17.176.65 255.255.255.192

!


description vlan 4 forP


ip address 172.17.176.129 255.255.255.192

!


no ip address

duplex auto

speed auto

shutdown

!

interface Serial0/3/0

bandwidth 128

ip address 10.1.1.1 255.255.255.224

encapsulation frame-relay

frame-relay map ip 10.1.1.2 102 broadcast

frame-relay lmi-type ansi

ip access-group dall_esterno in

!

interface Serial0/3/1

no ip address

shutdown

!

interface Vlan1

no ip address

shutdown

!

router eigrp 1

network 131.114.28.0 0.0.0.7

network 10.1.1.0 0.0.0.31

auto-summary

!

ip classless

ip route 172.17.146.0 255.255.255.192 131.114.28.3


ip route 0.0.0.0 0.0.0.0 10.1.1.2

!

!

ip access-list extended dall_esterno

permit tcp any 131.114.28.0 0.0.0.7 eq www

permit tcp any 131.114.28.0 0.0.0.7 eq domain

permit tcp any 131.114.28.0 0.0.0.7 eq smtp

permit tcp any 131.114.28.0 0.0.0.7 eq pop3

permit tcp any any established

permit gre any any

ip access-list extended formazione

deny ip 172.17.176.0 0.0.15.255 host 131.114.28.5

deny ip 172.17.176.0 0.0.15.255 host 131.114.28.6

permit ip any any

!

ip dhcp excluded-address 172.17.176.1



!

ip dhcp pool forW

network 172.17.176.0 255.255.255.192

default-router 172.17.176.1

dns-server 131.114.28.6

ip dhcp pool forN

network 172.17.176.64 255.255.255.192


dns-server 131.114.28.6

ip dhcp pool forP

network 172.17.176.128 255.255.255.192


dns-server 131.114.28.6

!

!

!

!

!

line con 0

line vty 0 4

login

!

!

!

end


4. Guida al cambio di ISP

In previsione di un eventuale cambio di fornitore di servizi ISP, si vuole qui fornire una guida

inerente a quello che occorre fare in tal caso. È opportuno sottolineare che se l'azienda prende

questa decisione deve discuterne anche con le altre due aziende.

Ogni ISP ha a disposizione un pool di indirizzi pubblici e li assegna, a seconda della richiesta, a

imprese o aziende. Quando viene effettuato un cambio di ISP, cambiano chiaramente anche gli

indirizzi IP pubblici.

Nel nostro caso, i 6 indirizzi pubblici estratti dalla subnet 131.114.28.0/24 saranno cambiati con i

nuovi indirizzi pubblici assegnati. Per quanto riguarda invece gli indirizzi privati, non ci sarà alcun

cambiamento.

Questa la situazione prima del cambio di ISP:

Dispositivo Indirizzo privato Indirizzo pubblico

Router MDF (Fa0/0) / 131.114.28.1

Router W / 131.114.28.2

Router N / 131.114.28.3

Router P / 131.114.28.4

Server WEB / 131.114.28.5

Server DNS / 131.114.28.6

Server SMTP W 172.17.141.129 NAPT --> 131.114.28.2::25

Server POP3 W 172.17.141.130 NAPT --> 131.114.28.2::110

Tutti gli altri dispositivi di WATB a.b.c.d NAPT --> 131.114.28.2::x

Server SMTP N 172.17.146.66 NAPT --> 131.114.28.3::25

Server POP3 N 172.17.146.67 NAPT --> 131.114.28.3:110

Tutti gli altri dispositivi di NcbN a.b.c.d NAPT --> 131.114.28.3::x

Server SMTP P NAPT --> 131.114.28.4::25

Server POP3 P NAPT --> 131.114.28.4::110

Tutti gli altri dispositivi di PNcS a.b.c.d NAPT --> 131.114.28.4::x

Una volta ottenuti gli indirizzi dal nuovo ISP, si tratta di andare a sostituire la configurazione

corrente di ogni dispositivo con la nuova configurazione aggiornata.

I dispositivi trasmissivi da modificare sono quelli che fanno uso degli indirizzi pubblici in

questione; ovvero:

router MDF;

router delle singole azienda;

server WEB e DNS.

E' opportuno, osservare che anche i server MAIL fanno uso d'indirizzi pubblici, ma questi sono

impostati staticamente dal DHCP.


Per quanto riguarda i due server WEB e DNS il problema è semplice: l'amministratore deve

solamente modificare l‟indirizzo IP, la subnet mask e il gateway di default.

Per quanto riguarda i router invece:

Il primo passo è accedere alla console del router. Per fare ciò, collegare il cavo seriale in

dotazione (maschio/femmina a 9 poli) tra la porta di console del Router e una porta seriale di

un computer (esempio COM-1);

Successivamente avviare il programma “Hyper Terminal” (da Start Programmi

Accessori Comunicazioni Hyper Terminal) incluso in tutte le versioni di Windows

(per sistemi Linux usare minicom).

Le impostazioni della porta da immettere sono:

Bit per secondo: 9600

Bit di dati: 8

Parità: nessuna

Bit di stop: 1

Controllo di flusso: nessuno

Una volta connessi, se è andato tutto a buon fine, battendo Invio dovrebbe apparire il

simbolo del dollaro: $


Innanzitutto occorre cancellare la configurazione esistente di ogni router:

R>en

Password: enter password

R#erase startup-config

Erasing the nvram filesystem will remove all configuration files!

Continue? [confirm] enter

[OK]

Erase of nvram: complete

%SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram

R#

Infine basta caricare in RAM la nuova configurazione.

Le modifiche da apportare alla startup-configuration del router dell‟azienda NcbN, sono riportate

sottolineate in giallo sotto:

!

version 12.4




!

hostname Router

!

!

!

!

!

!

!

!

!

!


!

!

!

!

!

!


no ip address

duplex auto

speed auto

!


description vlan 4 amministrazione



ip address 172.17.145.129 255.255.255.192

ip access-group Aa out

ip nat inside

!


description vlan 2 produzione


ip address 172.17.144.1 255.255.255.0

ip nat inside

!


description vlan 3 marketing


ip address 172.17.145.1 255.255.255.128

ip nat inside

!


description vlan 6 formazione


ip address 172.17.146.1 255.255.255.192

ip access-group formN out

!


description vlan 5 enterprise


ip address 172.17.145.193 255.255.255.192

!


description vlan 7 mail


ip address 172.17.146.65 255.255.255.248

ip access-group mail out

!


ip address 131.114.28.3 255.255.255.248

ip nat outside

duplex auto

speed auto

!

interface Vlan1

no ip address

shutdown

!

router eigrp 1

network 131.114.28.0 0.0.0.7

auto-summary

!

router rip

!


ip nat pool tradotto 131.114.28.3 131.114.28.3 netmask

255.255.255.248

ip nat inside source list P pool tradotto overload

ip nat inside source list M pool tradotto overload

ip nat inside source list A pool tradotto overload

ip nat inside source static tcp 172.17.146.66 25 131.114.28.3 25


ip classless

ip route 172.17.176.0 255.255.255.0 131.114.28.1

!

!

ip access-list extended M

permit udp any any eq bootps

permit tcp 172.17.145.0 0.0.0.127 any eq www


permit tcp 172.17.145.0 0.0.0.127 131.114.28.0 0.0.0.7 eq domain

permit tcp 172.17.145.0 0.0.0.127 172.17.146.64 0.0.0.7 eq smtp

permit tcp 172.17.145.0 0.0.0.127 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended P






permit tcp 172.17.144.0 0.0.0.255 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended A


permit tcp 172.17.145.128 0.0.0.63 172.17.145.0 0.0.0.127

permit tcp 172.17.145.128 0.0.0.63 172.17.144.0 0.0.0.255

permit tcp 172.17.145.128 0.0.0.63 131.114.28.0 0.0.0.7 eq www



permit tcp 172.17.145.128 0.0.0.63 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended Aa


ip access-list extended mail



ip access-list extended formN

permit ip 172.17.176.64 0.0.0.63 172.17.146.0 0.0.0.63

!

ip dhcp excluded-address 172.17.144.1 172.17.144.10




!

ip dhcp pool produzioneN

network 172.17.144.0 255.255.255.0


dns-server 131.114.28.6


ip dhcp pool amministrazioneN

network 172.17.145.128 255.255.255.192


dns-server 131.114.28.6

ip dhcp pool marketingN

network 172.17.145.0 255.255.255.128


dns-server 131.114.28.6

ip dhcp pool formazioneN

network 172.17.146.0 255.255.255.192


dns-server 131.114.28.6

!

!

!

!

!

line con 0

line vty 0 4

login

!

!

!

end


5. Area singola azienda

5.1. Cablaggio strutturato della rete dell’azienda NcbN

Dallo schema generale si vede in giallo il cablaggio in fibra.


L‟MDF è situato nel Multi-Purpose Building e da lì si diramano i cavi in fibra verso i vari IDF. Per

quanto riguarda la NcbN ci sono due IDF nel North Building (uno per piano).

Infine sono stati collocati altri due IDF nei due edifici distaccati, polo E e polo F.

Come già accennato al punto 2.6, il numero massimo di postazioni di lavoro presenti negli edifici

della NcbN è visibile in tabella:

Edificio # postazioni di lavoro

North Building 133

Multi-Purpose Building 27

Edificio adibito alla formazione 47

Polo E 25

Polo F 25


Da qui si deduce che lo switch a cui sono collegati i server è collegato al router e quindi allo switch

di core con un cavo di banda 10Gb, questo per garantire i requisiti di banda verso l‟area dei server.

A tal proposito è necessario sottolineare che tutto il traffico diretto ai server deve necessariamente

passare da tale cavo ed è per questo che è necessario un cavo con banda 10Gb, infatti le potenziali

257 macchine richiedono 2570 Mbps verso i server, e quindi un cavo di banda 10Gb.

Anche il link di collegamento con lo switch centrale ha una banda di 10Gb perché per arrivare ai

server DNS e WEB da tale cavo passa tutto il traffico che esce dalla (o entra nella) sede.

Gli altri collegamenti sono stati effettuati con cavi UTP cat5e, sufficienti a garantire la banda

richiesta verso i server.

Per il posizionamento degli IDF e degli MDF, si è fatto in modo che il raggio di copertura fosse

rispettato. Per i cavi UTP cat 5e si vede che il raggio di copertura, nei casi peggiori, non supera i

40m, quindi non ci sono assolutamente problemi dovute a degradazione del segnale, nonostante si

debba passare da un piano all'altro o dal controsoffitto scendere fino al pavimento.


Una visione schematica della struttura fisica, presentando solo i dispositivi trasmissivi, è la

seguente:

Le specifiche richiedono che la backbone della rete garantisca tempi di interruzione della

connessione non superiori al centinaio di secondi. Per fare questo si implementa opportunamente lo

SPT (Spanning Tree Protocol) che garantisce, in caso di guasto, una ripresa del sevizio di

connessione nei tempi richiesti. Per la configurazione del STP si rimanda al p.to 5.5.

Per ragioni di robustezza della rete si implementa un‟ulteriore ridondanza del cablaggio inserendo

dei collegamenti in fibra ottica tra gli switch aziendali appartenenti ad edifici diversi. Questi

collegamenti ridondanti ulteriori sono riportati nella precedente figura in blu. Ovviamente questo

comporta una spesa per l'azienda, in quanto come già discusso in precedenza, il cablaggio in fibra

ottica ha costi abbastanza alti però bisogna tenere in considerazione che se uno dei due link tra lo

switch centrale del North Building e i poli cade, questi rimarrebbero isolati. Per ridurre i costi si

potrebbe prevedere una ridondanza della fibra ottica facendole fare lo stesso percorso dell'altra,

però in caso d'interruzione accidentale ci sarebbe una forte probabilità di guasto anche della fibra

adiacente. Quindi si preferisce tale soluzione che, se pur a costo maggiore, garantisce una maggiore

robustezza della rete.

Ovviamente in vista di questa soluzione sarà impostato opportunamente lo STP sugli switch

interessati per evitare la creazione di loop. Per la configurazione rimandiamo al p.to 5.5.


5.2. Struttura della rete dell’azienda NcbN

5.2.1. Struttura logica

Il complesso di edifici dell‟azienda NcbN è il seguente:

un edificio, il Multi-Purpose Building, che è stato scelto come area condominiale in comune

con le altre due azienda WATB e PNcS. Tale scelta è giustificata dal fatto che l‟edificio in

questione contiene il POP per il collegamento con l‟ISP. Al suo interno è stato inoltre

collocato il MDF che contiene il router di frontiera e lo switch principale a cui sono

connessi i server WEB e DNS e le reti delle tre aziende;

il North Building, edificio principale dell‟azienda, che si sviluppa su due piani. Contiene

due IDF, uno per piano. Al piano terreno sono disponibili 65 postazioni lavoro, mentre al

primo piano sono disponibili 20 postazioni lavoro.

due edifici distaccati, polo E e polo F, ognuno contenente 25 postazioni lavoro. A tal motivo

entrambi gli IDF dei due poli conterranno uno switch da 48 porte.

Nel North Building sono state collocate anche le macchine server, sia enterprise che

workgroup che mail dell‟azienda. Il numero di prese da gestire è quindi di 85 per le

postazioni di lavoro più fino a 48 server. In particolare, le macchine server vengono

collocate in due delle stanze vuote dell‟edificio al piano terreno. A tal scopo, al primo piano

sarà posto uno switch da 48 porte. Al piano terra invece, poiché dovremo servire 113 host,

serviranno due switch da 48 porte e uno da 24 porte.


La struttura logica della rete invece è la seguente:

E' possibile osservare la presenza di uno switch di raccordo in ogni edificio in cui sono configurate

tutte e sei le VLAN. Il router si occuperà di permettere la comunicazione tra queste. Saranno inoltre

impostate delle ACL per garantire un minimo di sicurezza e di “spartizione” del traffico seguendo

le esigenze espresse dalle aziende.

Inoltre, si può notare il loop tra gli switch dei vari edifici, che consentirà, dopo aver

opportunamente impostato lo Spanning Tree Protocol, a rendere più robusta la rete in caso di guasti.

5.2.2. Domini di sicurezza della rete dell’azienda NcbN

Nell'azienda WATB sono previsti i seguenti domini di sicurezza:

Amministrazione, indicata con amministrazioneN:

Postazioni di lavoro e server workgroup appartenenti all'amministrazione;

si occupa dell'amministrazione della azienda;

Marketing, indicata con marketingN:

Postazioni di lavoro e server workgroup appartenenti al marketing.

Produzione, indicata con produzioneN:

Postazioni di lavoro e server workgroup appartenenti alla produzione.

Formazione, indicata con forN:


I due server workgroup dedicati alla formazione.

Enterprise, indicata con enterpriseN:

Server enterprise appartenenti all'azienda.

Mail, indicata con mailN:

Server MAIL;

I primi tre domini erano esplicitamente chiesti dall'azienda nelle specifiche del progetto; mentre, per

quanto riguarda gli altri è stato opportuno aggiungerli in quanto ad ognuno sono associati permessi

diversi. Nello specifico:

Formazione. Serve per permettere l'accesso dei portatili degli studenti, che seguono il corso

di formazione dell'azienda, ai loro server dedicati a tale scopo. Questi infatti possono

accedere esclusivamente a questi due server. La comunicazione sarà fatta assieme alla

corrispondente VLAN presente nella parte condivisa, ovvero con la forN. Questa

comunicazione esclusiva sarà gestita con opportune ACL poste sulle sottointerfacce del

router MDF.

Enterprise. I server enterprise hanno associati permessi diversi dagli altri server

(workgroup, mail, formazione) e, in particolare, sono accessibili da tutti i gruppi di lavoro

presenti all'interno dell'azienda (ovviamente il gruppo di formazione è escluso).

Mail. I server mail, a differenza degli altri server devono essere visibili all'esterno (sono

permesse solo richieste smtp e pop3), accessibili da tutti i gruppi di lavoro interni

all'azienda, e configurabili solo da utenti privilegiati.

In questo modo ogni dispositivo dello stesso tipo appartiene ad un dominio a lui omogeneo, ovvero

dove il traffico generato e ricevuto è lo stesso e quindi sono sottoposti alle medesime regole.

Ad ognuno di questi domini è associata una VLAN. Per permettere la comunicazione tra queste

VLAN ( i vincoli secondo i quali potranno comunicare verranno definiti successivamente) c'è

bisogno ovviamente di un router.

Sarebbe molto dispendioso prevedere un router con otto (sei per le VLAN più due per la fibra

ottica) porte, ragion per cui si usa un router con sole tre porte e alle sei VLAN si associa un'unica

interfaccia che sarà suddivisa in sottointerfacce logiche.

Per quanto riguarda le impostazioni di sicurezza, possono essere fatte queste considerazioni:

Le macchine del dominio di sicurezza Amministrazione potranno aprire connessioni con

protocolli basati su TCP verso macchine dei domini P ed M ma non viceversa.

Solo le macchine dei domini M e P potranno accedere a internet.

Le macchine del dominio F non potranno aprire alcun tipo di connessione

I server WEB, DNS e di posta potranno essere acceduti rispettivamente solo da richieste di

tipo http, dns, smtp e pop3.

Nonostante le macchine dei domini P ed M non possano aprire connessioni TCP verso

macchine del dominio A, tuttavia occorrerà impostare le ACL in modo tale da permettere i

pacchetti TCP di risposta, in vista per esempio di eventuali richieste http o dns di tali

domini.


5.3. Piano di indirizzamento della rete dell’azienda NcbN

Per quanto riguarda l'indirizzamento è stata associata ad ogni VLAN una subnet. La tecnica usata è

quella della VLSM. In ogni suddivisione è stata prevista una certa ridondanza in vista di una futura

espansione dell'azienda.

Vlan Indirizzo IP Maschera

ProduzioneN 172.17.144.0 255.255.255.0

MarketingN 172.17.145.0 255.255.255.128

AmministrazioneN 172.17.145.128 255.255.255.192

EnterpriseN 172.17.145.192 255.255.255.192

FormazioneN 172.17.146.0 255.255.255.192

SMTPN 172.17.146.65 255.255.255.248

Per la sottorete produzioneN:


Interfaccia router fa0/0.3 172.17.144.1 255.255.255.0

Server PN 1-9 172.17.144.2-10 255.255.255.0

Postazioni di lavoro P 1-210 172.17.144.11-254 255.255.255.0

Per la sottorete amministrazioneN:



Server AN 1-9 172.17.145.130-138 255.255.255.192

Postazioni di lavoro A 1-29 172.17.145.139-190 255.255.255.192

Per la sottorete marketingN:



Server MN 1-9 172.17.145.2-10 255.255.255.128

Postazioni di lavoro M 1-61 172.17.145.8-126 255.255.255.128


Per la sottorete formazioneN:



Server FN 1-2 172.17.146.2-3 255.255.255.192

Per la sottorete SMTPN:



Server MAIL 1-2 172.17.146.66-67 255.255.255.248

Per la sottorete Enterprise:



Server E 1-31 172.17.145.194-255 255.255.255.192


Per comodità dell'amministratore viene dato un nome ad ogni stanza secondo queste direttive:

XXYZ:

XX, iniziali edificio; avremo:

MP, Multi Purpose

NB, North Building;

PE, Polo E;

PF, Polo F.

Y, numero di piano:

0, piano terra;

1, primo piano.

Z, ID stanza.

Vengono contati da sinistra a destra partendo dall'alto.

Quindi avremo le seguenti mappe:




5.4. Dispositivi impiegati in ciascuna Distribution Facilities dell’azienda NcbN

5.4.1. IDF

Il numero di IDF utilizzati è di 4 e sono così distribuiti:

2 nel North Building (uno per piano)

1 nel polo E

1 nel polo F


La collocazione degli IDF è la seguente (stanze nere):


L‟IDF del piano terra del North Building contiene due switch da 48 porte e uno switch da 24 porte

poiché occorre servire 113 macchine.

L‟IDF del primo piano del North Building, invece, contiene un solo switch da 48 porte, in quanto le

macchine da servire sono 20.

Gli IDF dei poli E ed F infine conterranno uno switch da 48 porte ciascuno, poiché le macchine da

servire per ogni edificio sono 25.

Per quanto riguarda l'elenco dei dispositivi contenuti negli IDF abbiamo:

North Building :

IDF piano terra:

Tre switch (2 da 48 porte, 1 da 24 porte);

48 server

IDF primo piano:

Uno switch (da 48 porte);

IDF Polo E:

Uno switch da 48 porte.

IDF Polo F:

Uno switch da 48 porte.


5.4.2. Tabella riassuntiva.

In conclusione, questi sono tutti i dispositivi trasmissivi usati nella sottorete della NcbN:

Dispositivo Caratteristiche

Router NcbN Router di confine della rete NcbN.

Qui viene implementato il NAPT e il DHCP.

Ha tante sottointerfacce logiche quante sono le VLAN della NcbN.

Ha 4 porte FastEthernet:

2 per la fibra ottica

2 per cavi UTP

Collocazione --> NB010

Switch 1 piano

terra North

Building

Ha 48 porte FastEthernet per cavi UTP.


Collocazione --> SB08

Switch 2 piano

terra North

Building




Switch 3 piano

terra North

Building




Switch primo

piano North

Building



Collocazione --> primo piano NB

Switch polo E Ha 48 porte FastEthernet per cavi UTP.


Collocazione --> PE03

Switch polo F Ha 48 porte FastEthernet per cavi UTP.


Collocazione --> PF03

Cisco Catalyst 2960-24TT-L

Cisco Catalyst 2960-48TT-L


Nella scelta degli switch è stato tenuto di conto di una certa ridondanza di porte, in caso di guasto di

alcune di esse. Inoltre si fa uso del protocollo VTP di modo da configurare le VLAN sullo switch

principale del North Building e farle propagare a quest‟ultimo a tutti gli altri switch appartenenti

allo stesso dominio.

5.5. Configurazione dei dispositivi della rete dell’azienda NcbN

Router NcbN

!

version 12.4




!

hostname Router

!

!

!

!

!

!

!

!

!

!


!

!

!

!

!

!


no ip address

duplex auto

speed auto

!


description vlan 4 amministrazione


ip address 172.17.145.129 255.255.255.192


ip access-group Aa out

ip nat inside

!


description vlan 2 produzione


ip address 172.17.144.1 255.255.255.0

ip nat inside

!


description vlan 3 marketing


ip address 172.17.145.1 255.255.255.128

ip nat inside

!


description vlan 6 formazione


ip address 172.17.146.1 255.255.255.192

ip access-group formN out

!


description vlan 5 enterprise


ip address 172.17.145.193 255.255.255.192

!


description vlan 7 mail


ip address 172.17.146.65 255.255.255.248

ip access-group mail out

!


ip address 131.114.28.3 255.255.255.248

ip nat outside

duplex auto

speed auto

!

interface Vlan1

no ip address

shutdown

!

router eigrp 1

network 131.114.28.0 0.0.0.7

auto-summary

!

router rip

!

ip nat pool tradotto 131.114.28.3 131.114.28.3 netmask

255.255.255.248

ip nat inside source list P pool tradotto overload


ip nat inside source list M pool tradotto overload

ip nat inside source list A pool tradotto overload



ip classless

ip route 172.17.176.0 255.255.255.0 131.114.28.1

!

!

ip access-list extended M






permit tcp 172.17.145.0 0.0.0.127 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended P






permit tcp 172.17.144.0 0.0.0.255 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended A


permit tcp 172.17.145.128 0.0.0.63 172.17.145.0 0.0.0.127

permit tcp 172.17.145.128 0.0.0.63 172.17.144.0 0.0.0.255

permit tcp 172.17.145.128 0.0.0.63 131.114.28.0 0.0.0.7 eq www



permit tcp 172.17.145.128 0.0.0.63 172.17.146.64 0.0.0.7 eq pop3

ip access-list extended Aa


ip access-list extended mail



ip access-list extended formN

permit ip 172.17.176.64 0.0.0.63 172.17.146.0 0.0.0.63

!





!

ip dhcp pool produzioneN

network 172.17.144.0 255.255.255.0


dns-server 131.114.28.6

ip dhcp pool amministrazioneN

network 172.17.145.128 255.255.255.192


dns-server 131.114.28.6


ip dhcp pool marketingN

network 172.17.145.0 255.255.255.128


dns-server 131.114.28.6

ip dhcp pool formazioneN

network 172.17.146.0 255.255.255.192


dns-server 131.114.28.6

!

!

!

!

!

line con 0

line vty 0 4

login

!

!

!

end

Switch North Building

!

version 12.1




!

hostname "Switch North Building"

!

!

!


switchport access vlan 7

switchport mode access

!




!




!





!




!




!




!




!



!



!




!




!




!



!


!


!


!


!


!


!



!


!


!


!

interface Vlan1

no ip address

shutdown

!

!

line con 0

!

line vty 0 4

login

line vty 5 15

login

!

!

end

Switch Polo E

!

version 12.2




!

hostname "Switch polo E"

!

!

!



!




!




!





!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!

interface Vlan1

no ip address

shutdown

!

!

line con 0


!

line vty 0 4

login

line vty 5 15

login

!

!

end

Switch Polo F

!

version 12.2




!

hostname "Switch polo F"

!

!

!


!




!




!




!


!


!


!


!


!


!



!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!

interface Vlan1

no ip address

shutdown

!

!

line con 0

!

line vty 0 4

login

line vty 5 15

login

!

!

end


6. Caratteristiche specifiche della simulazione con Packet Tracer

Sono stati scelti i seguenti scenari per la simulazione della rete:

1. NAT statico (NcbN.pkt – scenario 0)

Sul router NcbN abbiamo impostato il NAT statico per i server di posta, ovvero abbiamo tradotto

l‟indirizzo ip privato con quello pubblico del router unito alla porta del servizio richiesto (25 o 110).

Nella simulazione si dimostra come facendo una richiesta smtp sulla porta 25 del router NcbN, il

pacchetto venga inoltrato tradotto al server smtp sempre sulla porta 25. Nello specifico, si ottiene

questo:




2. Comunicazione tra PC e server appartenenti alla stessa VLAN (NcbN.pkt – scenario 1)

In questa simulazione si dimostra come i PC e i server appartenenti allo stesso dominio di sicurezza

possano tranquillamente parlare tra di loro. Nell‟esempio ci concentriamo sulla VLAN della

produzione. In particolare facciamo un ping da PCPN verso PCPFN e verso ServerPN. Questo è

l‟output:



3. DHCP (NcbN.pkt – scenario 2)

In questo scenario si vuole dimostrare come i computer dei vari domini possano fare richiesta di

indirizzo IP al server DHCP implementato sul router MDF. Si vede inizialmente che l‟indirizzo IP

di PCAFN non è impostato staticamente:


Successivamente viene effettuata la richiesta DHCP e al pc vengono assegnati correttamente

indirizzo IP, maschera di rete, gateway di default e DNS server:


4. ACL (NcbN.pkt – scenario 3)

In questo esempio vogliamo dimostrare come sia possibile accedere al server WEB posto nell‟area

condivisa tramite una richiesta http sulla porta 80.


5. Una comunicazione non permessa (NcbN.pkt – scenario 4)

In questo esempio vogliamo dimostrare come le macchine del dominio di sicurezza A possano

inviare richieste TCP verso le macchine dei domini M e P, ma non viceversa. Proviamo prima a fare

una richiesta http da PCAN verso ServerPN e vediamo come essa ha successo:


Adesso invece proviamo a fare una richiesta http da PCPN a ServerAN e vediamo come questa non

venga permessa:


Nel dettaglio vediamo che la richiesta è stata bloccata dall‟ACL Aa posta sulla sottointerfaccia della

VLAN AmministrazioneN in uscita, che consente solo il traffico di ritorno di tipo TCP, non le

richieste:

Date post:	23-Jun-2015
Category:	Documents
Upload:	irene-bonta
View:	2,676 times
Download:	3 times

Il protocollo IPv6 e progetto di una rete aziendale

Documents