TECNOLOGIE E SERVIZI DI RETE

Transcript

1 Politecnico di Torino Corso di Laurea Magistrale in Ingegneria Informatica Dispense del corso di TECNOLOGIE E SERVIZI DI RETE A.A PROF. CIMINIERA LUIGI Realizzato da: Maggio Luigi E- mail: luis_may86@libero.it

2 LEZIONI N. 1,2,3,4 Il programma del corso verterà su 3 grossi argomenti: IPv6, una nuova versione dell' IP. Il problema della v6 stà nella sua totale incompatibilità con la precedente v4, nonostante i due protocolli condividano alcuni principi di base. Questo ostacola la diffusione della v6 essendo che la v4 ha ormai una enorme diffusione negli apparati di rete di tutto il mondo. VPN, un gruppo di tecniche e protocolli che hanno lo scopo di costruire una rete privata (quindi separata dal resto di Internet) utilizzando l' Internet pubblico. VOICEoverIP, i metodi e i protocolli utilizzati per il controllo delle chiamate su IP. In una parte finale saranno trattate le tecnologie per le connessioni geografiche (le MPLS) e alcune tecniche che hanno lo scopo di garantire la QoS. L evoluzione di IP: InternetProtocolVersione 6 La decisione di passare ad una nuova versione dell'ip risale alla prima metà degli anni 90' ed è dovuta a molteplici ragioni: Esaurimento dello spazio di indirizzamento IPv4: l'indirizzo IPv4 è composto da 32 bit, che corrispondono a circa 4 miliardi di combinazioni. Di contro però alcuni tipi di combinazioni non possono essere usate perchè riservate per particolari utilizzi (multicast, etc etc). Come se non bastasse si riscontra una certa frammentazione interna dovuta al fatto che quando si concede un pool di indirizzi ad una organizzazione solitamente non tutto il pool viene utilizzato. Come vengono assegnati gli indirizzi IP? Esistono 5 agenzie regionali (RIR). IANA fornisce delle reti \8 (quindi circa 16 milioni di combinazioni) ai RIR. Un RIR può andare a chiedere un nuovo blocco a IANA solo quando gli è rimasto da assegnare meno di un \9 oppure se proiettando i dati statistici nel futuro ci si rende conto che quelli a disposizione saranno esauriti in meno di un anno e mezzo. Il consumo di indirizzi IPv4 è attualmente rallentato grazie ad una più oculata politica di concessione di pool di questi ultimi da parte dei RIR, nonchè mediante l'introduzione di tecniche quali ad esempio il NAT. Problematiche di scalabilità del routing: i router di backbone hanno avuto una crescita vertiginosa delle righe nelle loro tabelle di instradamento, il che va ad allungare i tempi di ricerca al loro interno nel momento in cui si esegue la ricerca del Longest Prefix Match per eseguire l'instradamento dei pacchetti. Ci sono molti che criticano il campo di indirizzamento da 128 bit perchè se da un lato così facendo le righe sono state ridotte, dall'altro si sono allungate (ma era inevitabile vista la necessità di aumentare il campo di indirizzamento). Richiesta di servizi nuovi e/o più efficienti: in termini di Mobilità, poichè uno dei problemi dell'indirizzamento IP è che se ci si collega ad una diversa sottorete è necessario cambiare l'indirizzo IP per renderlo coerente con il prefisso di rete della sottorete in cui ci si è spostati (nonchè l'indirizzo del defaul gateway). Si vorrebbe invece in ogni caso mantenere il proprio indirizzo IP. In altre parole, le soluzioni che prevedono solamente l'assegnazione degli indirizzi non sono in grado di gestire le problematiche di roaming (spostamento da un gestore all'altro), di handover (spostamento da una rete all'altra),

3 ossia in generale non gestiscono il problema della portabilità (per alcuni versi detta raggiungibilità) dell'indirizzo di rete assegnato. Sicurezza, con la possibilità di autenticare l'indirizzo IP. In tal modo non si andrebbe a cifrare solo il carico dell'applicazione, ma anche il carico a livello 3 (ad esempio messaggi ICMP). Autoconfigurazione, ovvero collegare una macchina alla rete senza la necessità di dover operare una configurazione manuale delle impostazioni di rete. QoS, con la necessità di fornire diversi tipi di servizio a seconda dei tipi specifici di flusso di pacchetti. Multicast, poichè in IPv4 non sono trattate delle funzionalità quali ad esempio l'ingresso e l'uscita da un gruppo multicast. Di fatto però sono stati introdotti nell'ipv4 dei protocolli per tamponare alcune delle lacune funzionali trattate, ovvero rispettivamente MobileIP, IP Sec, DHCP, campo Type nel pacchetto IP, IGMP. Per quanto riguarda il formato dell'header, uno dei principali obiettivi della proposta SIPP (equindi di IPv6) era la semplificazione del protocollo. Questo corrispondeva innanzitutto ad eliminare i campi superflui o a fare un uso estremamente limitato dall'header del protocollo stesso. Questa operazione aveva come obiettivo la semplificazione del cosiddetto critical router loop, ossia quella porzione di codice che un router deve eseguire per tutti i pacchetti che si trova a dover instradare e che influisce quindi direttamente sulle sue prestazioni. E' evidente (in figura) come il numero di campi si sia ridotto da 12 a 8 (escludendo i campi opzionali), mentre lo spazio occupato da tutti i campi esclusi gli indirizzi di sorgente e di destinazione è passato da 12 a 8 bytes. L'ampiezza totale dell'header è tuttavia aumentata (da 20 a 40 bytes) a causa dei due campi contenente l indirizzo sorgente e destinazione, grandi ognuno 128 bit, per un totale di 40 bytes, che è la lunghezza fissa dell header. I risultati di questa semplificazione non sono tuttavia completamente positivi. In particolare, la dimensione dell'indirizzo IPv6, a parte un po' di folclore ("ci sono più indirizzi IPv6 che atomi nell'universo") non trova effettive giustificazioni tecniche tranne la volontà di voler evitare a tutti i costi di incorrere in nuove penurie di indirizzi come è accaduto per il protocollo IPv4. Questa scelta, peraltro, complica notevolmente le operazioni di route lookup ossia la procedura che serve a localizzare, per ogni pacchetto in transito in un router, l'effettiva strada (route) di destinazione. Infatti, questa operazione consiste in un confronto tra l'indirizzo IP di destinazione e ogni route memorizzata nel router per cercare quella che ha in comune un maggior numero di bit (da sinistra verso destra) con l'indirizzo di destinazione. Mettiamo quindi ora a confronto più dettagliatamente le intestazioni delle due versioni dell' IP

4 Dove il campo: VERSIONE: in teoria dovrebbe permettere a chi riceve un datagram di interpretare l'intestazione secondo il formato della v6 o della v4. In realtà però questo viene deciso a livello inferiore, ovvero a livello 2, poichè nella trama ethernet è specificato un campo Protocol Type che indica il tipo del carico utile trasportato. In tal modo è possibile avere distinte realizzazioni software (che si ignorano a vicenda) per le versioni di IP: sarà il driver della scheda di rete che si occuperà di smistare correttamente i datagram tra le due a seconda del campo Protocol Type. E' l unico campo che ha mantenuto la stessa posizione e lo stesso significato, è grande 4 bit e contiene il numero 6. HLEN: indica la lunghezza dell'intestazione. Nella v4 deve essere scritta poichè tale lunghezza può essere variabile e c'è quindi la necessità di indicare dove inizia il carico utile. Nella v6 invece l'intestazione ha lunghezza fissa a 40 byte, con lo scopo di favorire la commutazione dei pacchetti operata in hardware. SOURCE/DESTINATION IP ADDRESS: gli indirizzi mittente sono da 32 bit nell'ipv4 e da 128 bit nell'ipv6. TRAFFIC CLASS: permette di distinguere il datagram in funzione del servizio che ci si aspetta per quel tipo di datagram. E' uno di quei campi che servono per la gestione della QoS. FLOW LABEL: è lungo 20 bit e consente al nodo mittente di contraddistinguere un insieme di pacchetti appartenenti allo stesso flusso di dati. Un flusso è un gruppo di pacchetti che richiede un trattamento coerente da parte della rete. Tutti i pacchetti appartenenti allo stesso flusso dovranno avere stesso indirizzo di mittente, di destinatario e la stessa Flow label; inoltre eventuali Extension Header di tipo Hop- by- Hop oppure Routing presenti devono essere uguali in tutti i pacchetti dello stesso flusso. Tale campo può contenere valori tra 1 e FFFFFF. PAYLOAD LENGHT: E' lungo 16 bit; rimpiazza il campo total length di IPv4, in cui essendo l header di lunghezza variabile è necessario indicare la lunghezza totale del pacchetto; in IPv6 invece, essendo l header di lunghezza fissa è sufficiente indicare la dimensione del campo dati trasportato col pacchetto; essendo questo campo lungo 16 bit la dimensione massima del campo dati di un pacchetto IPv6 può quindi essere 64Kbyte. TOTAL LENGHT: indica la lunghezza del datagram inclusa l'intestazione. Il massimo per un datagram v4 è 64 kb compresa l'intestazione. HOP LIMIT: corrisponde al TTL della v4. E' lungo 8 bit; tale campo viene decrementato di un unità ogni volta che un router trasmette il pacchetto. Se il campo Hop Limit assume il valore zero il pacchetto deve essere scartato. Serve per evitare che pacchetti entrati in condizione di loop continuino a circolare nella rete indefinitamente. Data la lunghezza di questo campo, tra due nodi non potranno esserci più di 255 hop, cioè non più di 254 router. OPTIONS: in IPv4 è utilizzato per la frammentazione insieme ai campi IDENTIFICATION, FLAGS e FRAGMENT OFFSET. Tali campi spariscono nella v6 in quanto non è più permesso che i router operino la

5 frammentazione dei datagram in funzione della MTU della sottorete. In IPv6 la frammentazione e successivo riassemblaggio sono realizzati rispettivamente dal user mittente e destinatario. HEADER CHECKSUM: è stato abolito nella v6 poichè quello della v4 era debole (non permetteva di identificare alcuni tipi di errore) e soprattutto alcune delle medesime mansioni venivano svolte in maniera più efficiente a livello 2. PROTOCOL: nella v4 indica a quale protocollo appartiene il carico utile del datagram che si sta considerando (TCP, UDP, ICMP..) NEXT HEADER: è lungo 8 bit; indica di quale tipo è l intestazione che viene subito dopo quella dell'ipv6. Potrebbe esserci un'intestazione di tipo TCP, UDP, ICMP.. e in tal caso funzione in modo del tutto analogo al campo PROTOCOL della v4. Potrebbero però anche esserci delle altre intestazioni dell'ipv6 opzionali (ad esempio quelle di sicurezza per la cifratura..) IPv6 Ov6 Ov6 Ov6 TCP Tale tecnica crea dei problemi perchè in alcuni casi è necessario andare a guardare alcuni campi che si trovano nell'intestazione di base dell' IP e poi andare a vedere alcuni campi dell'intestazione TCP. Chi deve fare questa operazione sono di solito i firewall, per i quali una regola potrebbe essere di impedire tutte le connessioni se non quelle dirette ad un certo indirizzo IP e ad una certa porta TCP. In IPv4 per leggere l'intestazione TCP è sufficiente prendere il campo HLEN e calcolare l'offset, mentre in IPv6 bisogna scorrere tutta l'eventuale catena dei NEXT HEADER fino ad arrivare a quello che mi interessa. I principali valori ammessi per il campo NEXT HEADER sono i seguenti: dove in particolare: HBH: sono delle informazioni che vengono passate da un router all'altro AH: permette di essere sicuri che l'indirizzo IP mittente non sia stato modificato mentre il pacchetto attraversava la rete ESP: permette di cifrare il carico utile del pacchetto per assicurare la riservatezza della trasmissione

6 OSPF: è il meccanismo utilizzato dai router per comunicarsi informazioni riguardo lo stato della rete (se ad esempio un link è andato giù) Un pacchetto IPv6 può contenere nessun Extension Header, un Extension Header o più Extension Header. In linea di massima un nodo IPv6 deve accettare e cercare di elaborare gli Extension Header in qualsiasi ordine si presentino, anche se esiste un ordine preferenziale che in alcuni casi è piuttosto vincolante. L'ordine è il seguente: Hop By Hop Option Header, Routing Header, Fragment Header, Authentication Header, Encrypted Security Payload Header e Destination Option Header. Da notare è che dall' ESP in poi è tutto cifrato e quindi un router non è in grado di leggere il DOH, motivo per cui ad esempio RH deve stare per forza prima di ESP contenendo il percorso (specificato dal mitt) che il datagram deve compiere. Da sottolineare è inoltre che l Hopby- Hop Extension Header può trovarsi soltanto immediatamente dopo l'header IPv6; questo accorgimento consente di limitare il carico computazionale dei nodi intermedi della rete: infatti l unico tipo di Extension Header che deve essere elaborato anche dai nodi intemedi è l Hop- by- Hop Option Header. Ogni nodo intermedio dovrà pertanto soltanto analizzare l'header IPv6 e verificare il suo campo Next Header che indica la presenza o meno di un Hop- by- Hop Option Header, ossia l eventuale presenza di ulteriori informazioni da elaborare per gestire correttamente il pacchetto. Il formato delle intestazioni opzionali è il seguente dove in testa c'è il NEXT HEADER che fornisce l'informazione su "cosa viene dopo" seguito da un EXTENSIONE HEADER LENGHT che permette di localizzare subito l'inizio dell'header che segue quello in esame, ma potrebbero essere presenti anche altri campi opzionali quali ad esempio TYPE. Il ROUTING HEADER contiene una lista di indirizzi di router che devono essere attraversati e un SEGMENT LEFT che specifica quanti elementi dal basso devono essere ancora considerati. Per esempio se il valore di tale campo fosse due stà a significare che il router che lo riceve deve rispedirlo al penultimo router prima della destinazione, mentre se è 0 significa che il router è lui stesso il destinatario. Questo extension header implementa la tecnica di instradamento di tipo source routing; la sorgente è pertanto in grado di condizionare il cammino di instradamento di un pacchetto scavalcando il normale instradamento IPv6. Per esempio

7 La figura riporta un esempio di impiego di routing header. Il pacchetto viene originato dalla sorgente S verso la destinazione D, ma al pacchetto IPv6 viene aggiunto un Routing Header che lo forza a passare attraverso i router intermedi R1 ed R2. Pertanto, il pacchetto originale avrà il router R1 come apparente destinazione, mentre la vera destinazione (D) è indicata come ultimo passo nella lista del router da attraversare indicata dal Routing Header. All'arrivo del pacchetto nel router R1, questo riconosce il pacchetto Ipv6 come, apparentemente, destinato a lui; infatti, il suo indirizzo compare nel campo destination address dell'header Ipv6. Ne controlla gli header successivi e scopre che il pacchetto contiene un Routing Header: questo cambia pertanto le carte in tavola perchè, solo ora, il router riconosce che non è lui il destinatario finale del pacchetto ma un altro host. Al router R1, in effetti, non importa conoscere il destinatario effettivo: quello che si limita a fare è selezionare il prossimo hop a cui mandare il pacchetto (in questo caso il router R2, in quanto il valore del campo Segment Left indica che devono essere ancora effettuati 2 passi verso la destinazione) e sostituire a quel campo (campo Hop1) del Routing Header il proprio indirizzo IPv6. Il procedimento continuerà di hop in hop; l'host destinazione (D) riceverà un pacchetto IPv6 con un Routing Header riportante il valore zero nel campo Segment Left, che corrisponde al fatto che il pacchetto ha raggiunto la destinazione prefissata. Per quanto riguarda il FRAGMENT HEADER, esistono dei meccanismi definiti nello standard RFC 1981 che permettono il Path MTU Discovery, ovvero permettono di andare a scoprire il minimo valore della MTU lungo un certo percorso. Una volta in possesso di tale informazione, il mittente è in grado di frammentare opportunamente i datagrams. Se la frammentazione è necessaria viene inserito nei datagram l'header Occorre ricordare che anche il TCP (o l'udp) opera una frammentazione dei propri pacchetti, generando dei blocchi compatibili con la MTU della sottorete in cui si trova (per esempio se è una rete locale di tipo Ethernet allora di solito il TCP genera dei segmenti da caricare in un datagram tali per cui dati+headerethernet=1500byte che è il limite per Ethernet ma che potrebbe non esserlo per tutte le sottoreti che devono essere attraversate). A seguito del riscontro di MTU più piccole lungo il percorso, per evitare di risalire fino al TCP (o UDP) per operare una differente frammentazione, è appunto l'ip mittente che deve essere in grado di frammentare i pacchetti ricevuti dal TCP. Ogni pacchetto è formato da due parti, una frammentabile e una non frammentabile. Questo perchè ad esempio l'intestazione IPv6 non può essere frammentata così come anche tutti gli Extension Header che precedono il FRAGMENT HEADER. Ovvero ogni frammento è pertanto costituito da:

8 Parte non frammentabile, con il valore originale del campo Payload Length modificata per indicare la lunghezza del frammento e il Next Header dell ultima intestazione della parte non frammentabile indicante che, a seguire, vi sarà il Fragment Header. Fragment Header, che contiene il campo Next Header (che identifica il primo header della parte frammentabile del pacchetto originale), l offset relativo all inizio della parte frammentabile del pacchetto originale, il flag M che indica se il frammento corrente è l ultimo, e il valore Identification del pacchetto originale, tramite il quale il ricevitore è in grado di riunire i frammenti e ricostruire il pacchetto di partenza. Frammento, che contiene la porzione di dati del pacchetto originale. Un esempio esaustivo del meccanismo di frammentazione in IPv6 è riportato nella figura seguente dove la MTU si ritiene comprensiva di Header, motivo per cui il carico di dati è stato frammentato in tre blocchi da 520 byte, 544 byte e 348 byte. Da notare è che nel primo blocco il Fragment Header è stato posto tra quello che può essere frammentato e quello che non può esserlo e che il Fragment Header

9 riporta, come campo Next Header, sempre il valore del prossimo header incontrato nel pacchetto originale. Pertanto questo valore del campo Next Header viene ripetuto anche nei frammenti successivi anche se l'header a cui si riferisce quella codifica è ormai stato trasmesso. Per quanto riguarda la Sicurezza in IPv6, si è già detto precedentemente che l' AUTHENTICATION HEADER è utilizzato per garantire l'autenticità dell'indirizzo mittente mentre l'encrypted SECURITY PAYLOD (che può essere accoppiato al precedente) permette di ottenere la cifratura dell carico, che quindi diventa non leggibile per chiunque non possieda la chiave per decifrarlo. L architettura di indirizzamento IPv6 In IPv6 esistono tre diversi tipi di indirizzi: UNICAST: identifica una singola interfaccia. Un pacchetto con un indirizzo unicast è inviato alla sola interfaccia associata a tale indirizzo; MULTICAST: identifica un insieme di interfacce, tipicamente appartenenti a nodi diversi. Un pacchetto con un indirizzo multicast è inviato a tutte le interfacce con tale indirizzo; ANYCAST: un indirizzo anycast è associato ad un gruppo di macchine come il multicast. La differenza stà nel fatto che quando io spedisco un datagram ad un indirizzo multicast voglio che tutte le macchine che fanno parte di quel gruppo lo ricevano, mentre quando spedisco un datagram ad un indirizzo anycast voglio che questo raggiunga anche solo una delle macchine che appartengono a quel gruppo. In tal modo posso avere uno stesso servizio replicato su tante macchine e poi con una trasmissione anycast cercare di raggiungere la più vicina (nel senso della rete, non geografico). Tale tecnica è utilizzata soprattutto per raggiungere il server DNS più vicino senza conoscerne necessariamente l'indirizzo IP. In IPv6 scompare il broadcast (trasmissione che in IPv4 era diretta a tutte le macchine della sottorete o sulla rete generale, a seconda dell'indirizzo broadcast utilizzato), eliminato perchè era dispendioso sia dal punto di vista del tempo di trasmissione che di quello di elaborazione. Il broadcast in IPv6 è stato sostituito dall'istituzione di un insieme di gruppi standard multicast. Esistono tre tipi di indirizzi IPv6 UNICAST: LINK- LOCAL: è obbligatorio, una interfaccia deve sempre e comunque avere un indirizzo di questo tipo. Tale tipo di indirizzo serve per comunicare con altre macchine che appartengono alla propria sottorete, non mi permette di attraversare nessun router. Cioè un indirizzo link- local ha un valore solo all'interno della sottorete in cui mi trovo, di modo che potrebbe ripetersi in altre sottoreti perchè tanto non è un indirizzo globale. Sono euivalenti a quelli dell'autoconfigurazione stateless dell'ipv4 perchè anche quelli sono indirizzi scelti a caso estraendo in un range di indirizzi IP nell'ipotesi che ho bisogno di un indirizzo IP per avvisare una comunicazione esclusivamente con le macchine che fanno parte della mia sottorete.

10 SITE- LOCAL: sono simili ai link- local, nel senso anche in questo caso non si esce su tutto l'ip, però si riesce ad attraversare qualche router. Si pensi ad esempio ad una rete aziendale così grossa che, nonostante sia tagliata fuori da Internet, sia organizzata in sottoreti e abbia quindi dei router all'interno. Gli indirizzi site- local servono per essere indirizzati e raggiungibili all'interno di una simile rete. GLOBAL: equivalenti agli indirizzi pubblici, permettono di essere indirizzati su tutto l'ip (e quindi che la macchina sia raggiungibile dall'esterno). Solitamente i global e i site- local sono in alternativa, mentre un indirizzo link- local deve sempre essere presente. Di conseguenza ogni interfaccia di rete ha assegnati almeno un paio di indirizzi (link- local+global), perchè in IPv6 ad una stessa interfaccia possono anche essere assegnati più indirizzi di tipo global. Come si scrivono gli indirizzi IPv6? Si scrivono in esadecimale come otto numeri naturali separati da ":", ognuno equivalente a 16 bit. es. FEDC:BA98:0876:45FA:0562:CDAF:3DAF:BB01 es. 1080:0000:0000:0007:0200:A00C:3423:A037 Siccome la stringa è molto lunga sono state introdotte delle semplificazioni che possono essere apportate nella scrittura si possono omettere gli zero iniziali es. 1080:0:0:7:200:A00C:3423:A037 si possono sostituire gruppi di zero con "::" (può essere usato una volta sola nella stringa) es. 1080::7:200:A00C:3423:A037 es. ::1 (Indirizzo di Loopback) Ci sono inoltre alcuni indirizzi IPv4 che possono essere scritti in v6 in diversi modi 0:0:0:0:0:0:A00:1 ::A00:1 :: dove gli ultimi 32 bit rappresentano l'indirizzo v4. In IPv6 scompare il concetto di Netmask sostituito da quello di PREFIX LENGHT che permette un'allocazione degli indirizzi strettamente gerarchica. Questo si indica aggiungendo alla destra di un indirizzo "/N" dove N è la lunghezza in bit del prefisso. Da notare è che si solito in IPv6 il prefisso si muove a blocchi di 4 perchè in tal modo è possibile manipolarli più facilmente in una scrittura in base 16 (perchè un gruppo di 4 bit corrisponde ad una cifra esadecimale). es. FEDC:0123:8700::/36 Gli indirizzi assegnati ai vari gruppi sono i seguenti

11 dove quelli che iniziano per 00 esadecimale sono riservati ad indirizzi che provengono dalla v4, perchè devono in qualche modo essere riadttati alla v6. gli indirizzi publici globali (Aggregatable Global Unicast) iniziano con 2 o 3 esadecimale. gli indirizzi di tipo link- local (Link Local Use) iniziano con un valore tra FE8 e FEB gli indirizzi privati di tipo site- local (Private) iniziano con FD gli indirizzi multicast iniziano con FF il terzo e quarto intervallo erano riservati per incamerare nella v6 indirizzi che derivano da altri tipi di protocollo di livello Rete quali appunto NSAP e IPX. La colonna più a destra indici la frazione dello spazio totale di indirizzamento coperta da ognuno degli intervalli elencati. Sorge spontanea la domanda: ma perchè definire un intervallo per gli indirizzi site- local? essendo una rete privata separata dall'internet pubblico non posso assegnare alle macchine un qualsiasi indirizzo? Ebbene fino a quando la rete privata rimane separata dall'internet pubblica questo è vero. Purtroppo però quando si crea una grande rete privata prima o poi viene il desiderio di collegarla all'esterno. In tal caso nell' IPv4 la soluzione sarebbe l'inserimento di un NAT per non doversi sobbarcare l'incombensa di rinumerare tutte le macchine. Il problema sorge però quando all'interno della rete privata è stato impostato un indirizzo utilizzato anche da qualcun altro nell'internet pubblica. In tal caso il NAT non saprà verso quale delle due macchine instradare un pacchetto essendo che verrà utilizzata preferenzialmente una delle due possibili righe nella tabella di routing verso una stessa destinazione IP. I pacchetti arrivandogli dall'interno verranno risputati dentro o arrivandogli da fuori verranno rimandati nell'internet pubblica. Altro problema riguardo gli indirizzi site- local sorge poi nel momento in cui due organizzazioni, aventi ognuna la propria rete privata aziendale, vogliano mettere in comunicazione le loro reti in virtù di un accordo commerciale. In tal caso ci sarà da risolvere un possibile problema di conflitto di indirizzi. In IPv6, al fine di minimizzare il numero di righe presenti nelle tabelle di routing degli ISP di più alto livello, si è iniziato a distribuire e assegnare gli indirizzi in modo gerarchico in modo tale che l'aggregazione dei prefissi fosse automatica. In particolare gli indirizzi sono distribuiti secondo il seguente schema

12 la distribuzione è nelle mani di IANA che li distribuisce attraverso i RIR, che a loro volta li distribuiscono agli ISP di più alto livello (TLA Top Level Authority). La TLA riceve un grosso blocco di indirizzi, quindi con un prefisso di rete abbastanza corto. Alla TLA si possono rivolgere una NLA (Next Level Authority), un Provider locale o anche un cliente finale. Al di sotto di una NLA di solito ce sempre soltanto o un cliente finale o un cliente finale. L allocazione gerarchica unisce i vantaggi dell allocazione geografica, che non tiene conto dei vincoli sulla rete del provider, e di quella provider- based, che distribuisce il traffico semplicemente in base al provider indipendentemente dalla loro locazione; tuttavia un provider può essere molto esteso con molti punti di accesso al backbone internazionale e quindi potrebbe essere più conveniente assegnare gli indirizzi in maniera parzialmente geografica. Il formato degli indirizzi IPv6 di tipo UNICAST GLOBAL è diviso logicamente in tre parti di dimensione fissa chiamate rispettivamente Public Topology, Site Topology e Interface ID. La prima è utilizzata per il routing all interno della public Internet ed individua il provider o l exchange fornitore del servizio di accesso alla rete, Site Topology identifica l organizzazione interna del sito e di conseguenza è usata per l instradamento intrasite, infine Interface ID identifica l interfaccia sul link. dove: INTERFACE ID: parte riservata per numerare tutte le macchine presenti all'interno di una specifica sottorete. Ovvero il valore presente in tale campo da 64 bit è assegnato ad una interfaccia per numerarla all'interno di una sottorete. Se un sito dovesse essere riconfigurato, perché ad esempio ha cambiato provider, gli identificativi TLA e NLA cambierebbero mentre l SLA e l identificativo di interfaccia rimarrebbero uguali. SLA ID: questi 16 bit sono utilizzati per numerare possibili sottoreti presenti all'interno di un unica grossa rete privata (che quindi al suo interno comprende dei router). NLA ID: m bit riservati alla NLA. Di solito tale campo si assume lungo 24 bit. RES: riservato per un utilizzo futuro per l'espansione della dimensione dell'id TLA o dell'id NLA. La dimensione del campo è assunta di solito a 8 bit.

13 TLA ID: k bit riservati alla TLA. Di solito tale campo si assume lungo 13 bit. FP: prefisso da 3 bit che indica il tipo di indirizzo IPv6. Negli indirizzi pubblici vale 001. I primi 48 bit dell'indirizzo sono quelli di cui effettivamente mi servo quando devo andare sull'internet pubblico. Inoltre va notato che scrivendo un indirizzo IPv6 in notazione esadecimale non vi è alcuna cifra hex che comprende bit da due campi diversi. I 64 bit bassi dell'indirizzo possono essere scelti arbitrariamente, perchè tanto saranno i 64 bit alti a garantirne l'unicità. Tali bit devono essere inseriti manualmente? Con l'introduzione dell'ipv6 ci si era posti l'obiettivo dell'autoconfigurazione (funzionalità fornita nella v4 mediante protocollo DHCP), di modo che sono stata introdotte delle tecniche mediante la quale tali 64 bit bassi possono essere automaticamente calcolati. Per esempio si può farlo a partire dall'indirizzo MAC cablato all'interno di ogni interfaccia di rete (che è unico a livello mondiale). L'indirizzo MAC è un indirizzo di livello 2, utilizzato quindi per identificare il destinatario o il mittente all'interno della rete locale. Un indirizzo MAC è composto da 48 bit, i cui 24 alti sono di solito un codice del costruttore e i 24 bassi sono gestiti dal costruttore che li userà per numerare le interfaccie prodotte. Il meccanismo utilizzato è il seguente Figura a. Processo per ricavare i 64 bit bassi dal MAC Si divide l'indirizzo MAC in due parti. I 24 bit alti saranno i 24 bit alti dell'interface ID con l'unica differenza che il settimo bit da sinistra da 0 viene posto a 1 (Universal bit). I 24 bit bassi del MAC a loro volta saranno i 24 bit bassi dell'interfaccia e in mezzo vengono infilati due byte standard FF FE. Da notare è che potrebbe succedere che qualcuno, settando i 64 bit bassi del suo indirizzo a mano, li abbia scelti identici ai miei calcolati automaticamente a partire dall'indirizzo MAC. Tale probabilità è davvero bassa, ma non è neanche zero! Per quanto riguarda gli indirizzi di tipo UNICAST LOCALI invece il formato è il seguente: SITE- LOCAL: questi indirizzi possono essere utilizzati solo all interno di un singolo link, per scopi quali l autoconfigurazione degli indirizzi e le procedure di neighbor discovery. Inoltre questi indirizzi possono essere utilizzati per le comunicazioni tra terminali direttamente connessi quando non siano presenti dei router sul link.