Università degli Studi di Padova

Transcript

1 Università degli Studi di Padova Facoltà di Scienze MM.FF.NN. Laurea in Informatica Migrazione verso IPv6 Analisi del meccanismo IPv4-over-IPv6 Candidato: Alfonso Miraglies Relatore: Claudio Enrico Palazzi Anno Accademico

2 2

3 Abstract Gli indirizzi del protocollo di rete Internet Protocol, anche denominato IPv4, sono ormai quasi estinti. La gargantuesca crescita di dispositivi che richiedono un indirizzo IP per poter navigare sulla grande rete ne ha accelerato ulteriormente l esaurimento. IPv4 verrà, quindi, sostituito dalla nuova versione IPv6 che non solo aumenterà lo spazio di indirizzamento da 32 bit a 128 bit, ma apporterà miglioramenti su tutti i fronti. Il passaggio verso il nuovo protocollo dovrà avvenire in modo graduale e dovrà garantire elevata interoperabilità tra gli host IPv4- only e gli host IPv6-only. Quando la maggior parte delle dorsali e delle reti lavoreranno su IPv6, rimarrano ancora alcune aree IPv4. In questo contesto si inserisce il meccanismo di tunneling IPv4-over-IPv6, il cui scopo è, appunto, quello di permettere la comunicazione tra aree IPv4 immerse in un mondo IPv6-only. 3

4 4

5 Indice 1 Introduzione Scopo del progetto Azienda ospitante Piano di lavoro Requisiti Struttura della tesi Convenzioni tipografiche Il protocollo IPv Header IPv Version Traffic Class Flow Label Payload Length Hop Limit Next Header Source e Destination Address Extension Headers Hop-by-hop Option Routing Fragment Destination Options Authentication ed Encapsulating Security Payload No Next-Header Ordine degli Extension Headers Confronto tra header IPv6 e header IPv Indirizzi unicast, multicast, anycast Scope degli indirizzi: Link-local e Global Link-local Global Neighbor Discovering Protocol

6 INDICE 2.7 Path MTU Discovery Address auto-configuration Generazione dell Interface-identifier Router Advertisement e Router Solicitation Novità al livello applicazione DHCP in IPv DHCPv6 e Router Advertisement Daemon DHCPv6 Stateful auto-configuration DHCPv6 Stateless auto-configuration Confronto tra DHCPv6 e DHCPv DNS in IPv Cambiamenti rispetto a DNS in IPv Procedura di risoluzione dei nomi Meccanismo di tunneling IPv4-over-IPv Introduzione ai meccanismi di transizione La necessità del tunneling 4over Forwarding dei pacchetti 4over Applicabilità del tunneling 4over Architettura di rete comune Architettura di rete 4over Utilizzo di macchine virtuali Configurazione di Router A Configurazione di Host A Configurazione di Router B Test conclusivi Firewall Vantaggi 4over Svantaggi 4over Compatibilità sistemi operativi Quality of Service Introduzione QoS in IPv Type of Service QoS in IPv Traffic Class Flow Label Shaping in IPv Limitare il traffico IPv

7 INDICE Limitare traffico HTTP Utilizzo del modulo u Considerazioni sulla QoS in IPv Conclusioni Conclusioni sulla configurazione 4over Considerazioni sull esperienza dello stage Glossario 93 Bibliografia 97 7

8 8 INDICE

9 Elenco delle figure 2.1 Struttura dell header IPv Header IPv4 e IPv6 messi a confronto Struttura di un indirizzo global unicast generico Struttura di un indirizzo multicast Struttura di un indirizzo link-local Struttura di un indirizzo unicast global address Esempio di indirizzo MAC (48 bit) MAC aumentato a 64 bit Interface ID finale Crescita degli AS annuncianti indirizzi IPv Datagramma IPv4 generato da un host IPv4-only Datagramma IPv4 incapsulato Architettura di rete 4over Architettura di rete comune alle tre proposte di stage Tunnel dal punto di vista di Router A Firewall sul server-router dual-stack Campo Type of Service dell header IPv Campo Traffic Class dell header IPv Banda disponibile senza filtri Banda disponibile dopo aver attivato i filtri Lato server: senza filtri (1252 Kb/s) e con filtri (477 Kb/s) Raffronto ore preventivate e ore a consuntivo

10 10 ELENCO DELLE FIGURE

11 Elenco delle tabelle 1.1 Pianificazione delle attività dello stage Ordine degli Extension Header Record del DNS per la risoluzione in avanti Record del DNS per la risoluzione inversa Schema degli indirizzi di Router A Schema degli indirizzi di Host A Schema degli indirizzi di Router B Schema degli indirizzi di Host B

12 12 ELENCO DELLE TABELLE

13 Capitolo 1 Introduzione Nelle sezioni che seguono saranno trattati a grandi linee gli obiettivi dello stage svolto presso l azienda Miriade, il piano di lavoro e la struttura della presente tesi. Saranno infine elencate le convenzioni tipografiche utilizzate nella stesura di questo documento. 1.1 Scopo del progetto Il protocollo di comunicazione Internet Protocol versione 4 (da qui in poi IPv4 oppure IP) è in grado di supportare al massimo 2 32 indirizzi. Nonostante tecniche come il subnetting e l utilizzo del NAT abbiano rallentato l esaurimento degli indirizzi IP, si prevede che essi si estinguano nel La soluzione a questo problema è l innovativo Internet Protocol versione 6 (d ora in poi IPv6), che permette di assegnare (circa 3, ) indirizzi. Se pensiamo che attualmente la popolazione mondiale conta all incirca 6, persone, ci renderemo immediatamente conto della vastità dello spazio di indirizzamento. Non essendo IPv6 retrocompatibile, si pone a questo punto il problema del passaggio dal vecchio al nuovo protocollo. La migrazione verso IPv6 avverrà in modo graduale grazie allo sviluppo di infrastrutture dual-stack ed ai meccanismi di tunneling denominati IPv6 over IPv4 e IPv4 over IPv6. L argomento di questa tesi fa parte di un progetto di più ampio respiro il cui obiettivo è analizzare le tre soluzioni appena citate. Data la vastità del tema trattato, si è ritenuto opportuno suddividere il progetto in tre stage distinti. Non è possibile capire al meglio i meccanismi utili alla transizione senza prima conoscere le innovazioni ed i cambiamenti apportati da IPv6. È stato svolto nella prima fase dello stage un approfondito studio sia teorico che 13

14 CAPITOLO 1. INTRODUZIONE pratico sulla struttura del pacchetto, la tipologia di indirizzi, le nuove funzionalità messe a disposizione quali il Neighbour Discovering Protocol, il Path MTU Discovery, le novità riguardanti il DHCPv6, il DNSv6 e la Quality of Service. Nella fase successiva è stata studiata, implementata e testata la tecnica di incapsulamento IPv4-over-IPv6. Per meglio comprendere il contesto in cui si inserisce il meccanismo di tunneling IPv4 over IPv6, oggetto della presente tesi, è necessaria una breve premessa: arriverà un momento in cui la cartina geografica della rete Internet mostrerà un mondo in cui la maggior parte delle dorsali avrà connettività IPv6-only, mentre solo piccole aree saranno dotate di indirizzi IPv4, con la necessità di interconnettersi tra loro. Lo scopo di questa tesi è analizzare in dettaglio la tecnica di tunneling IPv4- over-ipv6 il cui obiettivo principale è quello di consentire a due host dotati di connettività IPv4-only di scambiarsi dati e fornire reciprocamente servizi tramite un infrastruttura esclusivamente IPv6. Ognuno degli host dovrà disporre di un entità che riesca ad incapsulare i pacchetti IPv4 uscenti in pacchetti IPv6, in modo tale che essi possano essere instradati nella rete IPv6. Questa entità dovrà anche essere in grado di decapsulare i pacchetti IPv6 entranti e di inviarli al destinatario corretto. I due estremi del tunnel che viene creato tra i due host saranno le due entità appena citate, le quali, come spiegato in dettaglio nel capitolo 4, risulteranno essere fisicamente dei serverrouter dual-stack. In questo particolare scenario sono stati implementati e testati i principali oggetti di rete quali il DHCP, il DNS, il routing ed il firewalling. Sono state, inoltre, evidenziate le criticità, le soluzioni e le opportunità che questa configurazione offre dal punto di vista aziendale. È stato eseguito, infine, un breve confronto tra la qualità del servizio (QoS) in IPv4 e la QoS in IPv6, con test basati sullo shaping della banda disponibile. 1.2 Azienda ospitante Miriade S.p.a è un azienda con sede in Thiene (VI) che da dieci anni è impegnata nel settore IT. La struttura aziendale è composta da cinque brand tecnici: MITIWORKS: consulenza MIDATI: database 14

15 1.2. AZIENDA OSPITANTE MIDLAND: midware MICORE: system integration MIRARE: business intelligence L azienda ha messo a disposizione di ciascun stagista tutte le risorse software e hardware necessarie. Per la parte di documentazione Miriade dispone di una sorta di wikipedia interna denominata dokuwiki in cui è stata creata l apposita sezione Stage IPv6 che, di giorno in giorno, è stata arricchita di informazioni, test, documenti e link riguardanti il protocollo IPv6 e i metodi di migrazione. Questa documentazione veniva prodotta alla fine di ogni giornata lavorativa ed è stata enormemente utile per fissare le idee e ripescare velocemente le informazioni anche a distanza di molto tempo. Per la redazione del business plan e delle configurazioni testate e funzionanti ci si è, invece, serviti dei documenti di Google (i Google Docs) poichè facilmente condivisibili. Per le comunicazioni con il nostro tutor aziendale Giorgio Canale riguardo ai progressi dello stage e per le altre comunicazioni con il personale di Miriade ci è stato fornito un account di posta elettronica personalizzato dall azienda stessa. Sono stati, inoltre, utilizzati Google Talk e Skype per rimanere sempre in contatto nel caso il tutor fosse fuori sede. Tra tutto il software che ci è stato fornito, una menzione particolare va a VMWare Workstation che, come spiegato più avanti in questa tesi, è stato utilizzato per la creazione di macchine virtuali. Sono stati forniti, infine, alcuni sistemi operativi su cui effettuare i test: centos, Ubuntu, Windows XP e Windows 7. A ciascun stagista è stato assegnato un portatile con cui lavorare, sia durante la fase di studio del protocollo IPv6, sia durante la parte di implementazione dello scenario di rete. È stato, infine, fornito un PC in comune alle tre proposte di stage, affettuosamente soprannominato PC Osso (perchè montava hardware datato), che fungeva da server-router dual-stack (vedere 4.5 per approfondimenti). Concludo questo paragrafo menzionando una particolare politica aziendale di grande utilità sia dal punto di vista tecnico che da quello sociale: è consuetudine di Miriade organizzare le cosiddette Weekly Quickies, cioè delle riunioni in cui si può esporre ai colleghi il lavoro svolto durante la settimana. In questo modo chi lavora nell aera business intelligence o database può apprendere, ad esempio, cosa si sta producendo nell area system integration. Anche noi stagisti in qualche occasione abbiamo fatto da docenti su IPv6 15

16 CAPITOLO 1. INTRODUZIONE e ne abbiamo tratto interessanti domande a cui rispondevamo alla riunione successiva. 1.3 Piano di lavoro Sono state preventivamente pianificate le attività da svolgere durante lo stage, scindibili in tre fasi principali: una prima fase di studio del dominio e di raccolta informazioni a carattere generale su IPv6; nella seconda fase è stato dato un risvolto pratico agli elementi studiati nella prima parte ed è stata implementata l architettura di rete atta a testare la configurazione 4over6 ; la terza fase comprende il testing dell architettura sviluppata ed il raggiungimento di eventuali obiettivi opzionali. Le ore preventivate sono in totale 310, divise per attività come si può vedere dalla tabella 1.1. Attività Ore Studio del dominio e raccolta informazioni 60 Preparazione documentazione architettura e modalità operative 25 Realizzazione infrastruttura di rete di prova 95 Attivazione tunnel IPv4 over IPv6 30 Test funzionali scenari tipici: NAT, routing, firewalling 60 Redazione business plan 40 Totale ore 310 Tabella 1.1: Pianificazione delle attività dello stage Requisiti I requisiti sono stati suddivisi in tre categorie: Obbligatori: sono quegli obiettivi che si dovranno necessariamente raggiungere entro la fine dello stage, senza di cui il progetto non proporrebbe una soluzione completa al problema Desiderabili: sono quegli obiettivi non espressamente richiesti ma che danno valore aggiunto al progetto e se immessi devono essere obbligatoriamente raggiunti Opzionali: sono quegli obiettivi che, per motivi di tempo, potrebbero non essere completati ma che al contempo non inficiano la buona riuscita del progetto 16

17 1.3. PIANO DI LAVORO Gli obiettivi obbligatori da raggiungere sono elencati di seguito: Analisi relativa al sistema DNS evidenziando pregi, difetti e come influisca nello scenario IPv4-over-IPv6 Analisi relativa al DHCP evidenziando pregi, difetti e come influisca nello scenario IPv4-over-IPv6 Evidenziare problematiche e soluzioni relative alla gestione delle tabelle di routing Evidenziare problematiche e soluzioni relative al firewall Configurazione di un server-router per l incapsulamento di un pacchetto IPv4 in uno IPv6 Creazione di un server ssh: test del funzionamento di un servizio IPv4- only tramite infrastruttura IPv6 Redazione del business plan Migrazione infrastruttura di rete IPv4- over-ipv6 Gli obiettivi desiderabili sono i seguenti: Verificare su quali sistemi operativi è compatibile la soluzione IPv4- over-ipv6 Infine, sono stati individuati alcuni obiettivi opzionali: Analisi e confronto sulla Quality of Service in IPv4 e IPv6 Analisi e confronto su MobileIP in IPv4 e IPv6 Approfondimento sulla sicurezza in ambito IPv6. Tutti gli obiettivi obbligatori e desiderabili sono stati raggiunti. Degli obiettivi opzionali è stata svolta l analisi e confronto tra la QoS IPv4 e IPv6. Come accennato in precedenza la durata totale è di 310 ore. Lo stage si è svolto nel periodo che va dal 10/05/2010 al 08/07/

18 CAPITOLO 1. INTRODUZIONE 1.4 Struttura della tesi La tesi è costituita da un primo capitolo introduttivo in cui vengono esplicati a grandi linee gli obiettivi ed il funzionamento del meccanismo di migrazione 4over6 ; segue una breve descrizione dell azienda in cui si è svolto lo stage ed il piano di lavoro iniziale con i requisiti da raggiungere. Si trovano inoltre questo paragrafo e le convenzioni tipografiche usate nello scrivere la presente tesi. Nel capitolo 2 è analizzato e descritto l header IPv6 e le novità introdotte rispetto a IPv4. Il capitolo 3 spiega nel dettaglio i cambiamenti apportati ai protocolli del layer applicazione DHCP e DNS. Il capitolo 4 è riservato alla dissertazione circa il meccanismo di tunneling IPv4-over-IPv6 e dell architettura di rete sviluppata. Nel capitolo 5 vengono analizzate e messe a confronto la Quality of Service IPv4 ed IPv6. Sono, inoltre, riportati i test effettuati sulla QoS in IPv6. Il capitolo 6 trae le conclusioni sul lavoro svolto e le considerazioni personali circa l esperienza dello stage in azienda. 1.5 Convenzioni tipografiche I nomi dei protocolli, dei campi dell header o gli altri nomi tecnici sono riportati con il loro nome inglese, scritto in corsivo (es: Dynamic Host Configuration Protocol). I termini che hanno maggiore importanza sono anch essi scritti in corsivo. Nel caso siano riportati righe di codice, file di configurazione, comandi, ecc. essi sono scritti con un carattere particolare e centrati all interno della pagina. 18

19 Capitolo 2 Il protocollo IPv6 L Internet Protocol è il protocollo a livello rete dello stack ISO/OSI che ha subito radicali modifiche e migliorie. In questo capitolo saranno analizzati i campi dell header IPv6 (sezione 2.1), i nuovi Extension Headers (sezione 2.2) e le differenze tra l header IPv4 e quello IPv6 (sezione 2.3). Sono in seguito trattate le tipologie di indirizzo (sezione 2.4) e gli indirizzi locali e globali (2.5). Nella sezione 2.6 è descritto il Neighbor Discovering Protocol e le sue funzionalità multiple. La sezione 2.7 è dedicata al Path MTU Discovery mentre l ultima parte (2.8) spiegherà la generazione automatica degli indirizzi. 2.1 Header IPv6 L header IPv6, a differenza dell header IPv4 che può variare da un minimo di 20 byte ad un massimo di 60 byte, ha una lunghezza fissata a 40 byte, allo scopo di velocizzare il parsing dell header stesso. Il maggiore peso in byte è dovuto al fatto che è stato quadruplicato lo spazio di indirizzamento. Dai 32 bit per Source e Destination Address si è passati a 128 bit ciascuno. L header IPv6 risulta semplificato rispetto al suo predecessore, in quanto si è passati da 12 a 8 campi totali: quelli riguardanti la frammentazione sono stati spostati tra gli Extension Header; il campo Checksum, poichè già presente a livelli superiori e quindi ridondante, è stato eliminato; il campo Header Length è stato rimosso, dal momento che la lunghezza dell header IPv6 è fissa. I successivi paragrafi spiegheranno brevemente i campi dell header IPv6, la cui struttura è descritta in figura

20 CAPITOLO 2. IL PROTOCOLLO IPV Version Figura 2.1: Struttura dell header IPv6 Il campo Version (4bit) contiene la versione del pacchetto IP. Un datagramma IPv4 contiene in questo campo il numero 4; similmente, un datagramma IPv6 contiene il numero 6. La versione 5 è assegnata ad un protocollo sperimentale, chiamato Internet Stream Protocol (ISP), per la trasmissione di traffico voce e video Traffic Class Il Traffic Class è utilizzabile per distinguere tra differenti classi o priorità dei pacchetti IPv6 (vedere capitolo 5 per maggiori dettagli) ed è formato dai campi: Differentiated Services Code Point (DSCP): un campo di 6 bit usato per classificare i pacchetti, definito in RFC 2474 [4]. In una rete è possibile classificare i datagrammi in 64 (2 6 ) classi diverse. Ogni classe corrisponde ad un preciso Per-Hop Beahviour, il comportamento che i router dovranno intraprendere per garantire diverse qualità di servizio Explicit Congestion Notification (ECN ): è un estensione opzionale per TCP/IP definita in RFC 3168 [5]. Permette, in connessioni endto-end, di fornire notifiche in caso di rete congestionata, evitando di scartare pacchetti Da notare che questo campo corrisponde perfettamente al campo Type of Service di IPv4. 20

21 2.1. HEADER IPV Flow Label Il Flow Label è un campo di 20 bit che può essere usato da un mittente per etichettare sequenze di pacchetti per cui viene richiesto un trattamento particolare dai router. Tutti i pacchetti che appartengono allo stesso flusso devono contenere lo stesso Flow Label (generato randomicamente) e, se presenti, anche gli Hop-by-Hop Extension Header e Routing header devono essere uguali. Se un pacchetto possiede un Flow Label con tutti i bit a zero significa che esso non appartiene ad alcun flusso. Il vantaggio chiave nell utilizzo del Flow Label è che i router non sono costretti ad analizzare l interno di un pacchetto per identificare un flusso. Con il vecchio protocollo IP l unico modo per identificare un flusso era scorrere gli header interni di un pacchetto e recuperare questi 5 elementi: Indirizzo Sorgente Indirizzo Destinatario Porta sorgente Porta destinatario Protocollo di trasporto Per ulteriori approfondimenti vedere il capitolo Payload Length Payload Length è composto da 16 bit e specifica la lunghezza del payload, cioè quella parte di datagramma che segue l header. Il payload, quindi, comprende sia le informazioni del livello di trasporto o delle applicazioni, sia eventuali Extension Headers (vedere sezione 2.2), sia i dati utili del pacchetto. Nell header IPv4 vi sono, al contrario, due campi che specificano la lunghezza: Header Length e Total Length. Il primo indica quanti byte occupa l header, il secondo quanto è lungo il pacchetto in totale. Dal momento che il Payload Length consta di 16 bit, è possibile specificare una lunghezza massima di (2 16 ) byte. E possibile superare questo limite con l utilizzo dei jumbograms, utilizzati in particolar modo per gli scambi di dati tra super-computer (l utente medio con alta probabilità non ha bisogno di jumbograms). Un jumbogram richiede un processamento particolare dai router ed è identificato da: 21

22 CAPITOLO 2. IL PROTOCOLLO IPV6 Payload Length posto a zero Next Header impostato a Hop-by-hop L Hop-by-Hop Extension Header contiene un campo di 32 bit che specifica la grandezza del jumbogram, che può per questo motivo arrivare al massimo a 4 GB (2 32 ) Hop Limit Questo campo di 8 bit permette di specificare il limite di hop (letteralmente salti ) che un pacchetto IPv6 può subire. Per hop, più tecnicamente, si intende il numero di volte che il pacchetto può essere inoltrato da un router. Ogni volta che il pacchetto subisce un forwarding da un router, il valore di questo campo viene decrementato. Se raggiunge lo zero, il router scarta il pacchetto ed invia un messaggio ICMPv6 di errore (Time Exceeded) Next Header Il campo Next Header è costituito da 8 bit e contiene un valore che identifica quale header è presente in seguito a quello IP. Tipicamente il Next Header indica il protocollo di trasporto utilizzato. Per esempio, se in Next Header è scritto il valore 6, significa che il prossimo header da leggere è quello di TCP. Se, altrimenti, è presente il valore 17, il protocollo di trasporto utilizzato è UDP Source e Destination Address Source e Destination Address contengono, come in IPv4, rispettivamente l indirizzo del mittente e del destinatario del pacchetto. Ciascuno di essi occupa 128 bit e permette di indirizzare, perciò, fino a 2 128, circa 3, entità. Per le tipologie di indirizzi consultare la sezione Extension Headers Gli Extension Headers vengono posti in seguito ad un header IPv6. In questa sezione saranno elencati e descritti brevemente questi header opzionali che corrispondono, dal punto di vista funzionale, alle Options di IP. 22

23 2.2. EXTENSION HEADERS Hop-by-hop Option L opzione Hop-by-hop ha due principali utilità: Router Alert: alcuni dei nuovi protocolli che riguardano la QoS hanno bisogno che i router controllino ed aggiornino determinate informazioni all interno dei pacchetti. Con IPv4 l unico modo che un router ha per determinare se deve esaminare un pacchetto prima di spedirlo, è quello di leggere in tutti i datagrammi almeno fino al livello di trasporto. Questo comportamento è costoso e lento. La soluzione è, appunto, utilizzare l opzione Router Alert in modo che solo i pacchetti contrassegnati debbano essere esaminati. Jumbogram: un datagramma IPv6 può avere un payload massimo di 64K byte (2 16 ), dal momento che il campo Payload Length occupa 16 bit. Per superare questo limite viene utilizzata l opzione Jumbogram, che dona la possibilità di avere un payload con grandezza massima di 4G byte (2 32 ) Routing Il Routing Extension Header è utilizzato per modifiche di routing lungo il cammino, utilizzato in particolar modo per MobileIPv Fragment Il Fragment Extension Header è utilizzato per identificare i diversi frammenti in cui il pacchetto IPv6 originario è stato frazionato. L unica novità rispetto a IPv4 è che solo gli end-point di una connessione possono frammentare i pacchetti. Tutto il carico di lavoro dovuto alla frammentazione è stato scevrato dai router Destination Options Le opzioni contenute nel Destination Options Header sono utilizzate solo dal nodo destinatario. Esse sono particolarmente utili nell ambito MobileIPv Authentication ed Encapsulating Security Payload L Autentication Header (AH) e l Encapsulating Secruity Payload (ESP) sono header appartenenti al protocollo di sicurezza IPSec e sono processati 23

24 CAPITOLO 2. IL PROTOCOLLO IPV6 solo dal nodo destinatario. IPSec funziona allo stesso modo tanto in IPv4 quanto in IPv6. Poichè non vi sarà più la necessità del NAT, esso sarà di più facile utilizzo e, cosa non meno importante, sarà obbligatorio No Next-Header Indica che non sono presenti altri header oltre a quello IPv6, quindi che non è presente il payload Ordine degli Extension Headers Se presenti più Extension Header in un datagramma, essi non possono essere disposti casualmente ma secondo un criterio particolare al fine di garantire velocità di parsing ottime. La tabella 2.1 riassume l ordine che devono avere gli Extension Header. Posizione Extension Header 1 Hop-by-Hop 2 Destination Options (1) 3 Routing 4 Fragment 5 Authentication Header 6 Encapsulating Security Payload 7 Destination Options (2) 8 Header del livello superiore (TCP, UDP, ecc.) Tabella 2.1: Ordine degli Extension Header Poichè i nodi intermedi devono sempre controllare l Hop-by-Hop Header, è naturale che esso si trovi al primo posto nella catena degli Extension Header. Il Routing Header non deve essere processato da tutti i router intermedi in una comunicazione end-to-end, ma poichè fornisce importanti indicazioni (per esempio, dove e come instradare i pacchetti) è il secondo in ordine di importanza. Quando un datagramma giunge a destinazione, l host destinatario ha come prima necessità quella di ricostruire il pacchetto, nel caso quest ultimo sia 24

25 2.2. EXTENSION HEADERS stato frammentato. Da qui la necessità di immettere il Fragment Header immediatamente dopo al Routing Header. Generalmente gli Extension Header compaiono una sola volta all interno della catena. L unica eccezione riguarda il Destination Options che può essere immesso due volte: se si trova prima del header di Routing deve essere analizzato dai nodi intermedi lungo il cammino; se si trova in posizione 7 allora deve essere esaminato dal nodo finale. 25

26 CAPITOLO 2. IL PROTOCOLLO IPV6 2.3 Confronto tra header IPv6 e header IPv4 L header IPv6 è più snello rispetto a quello IPv4, in quanto consta di soli 8 campi contro i 12 dell header IPv4 (vedi Fig. 2.2) ed è strutturato in modo tale da velocizzare il parsing da parte dei router. Figura 2.2: Header IPv4 e IPv6 messi a confronto [9] Il cambiamento più evidente riguarda lo spazio dedicato al Source Address e Destination Address: in IPv4 vi erano dedicati 32 bit ciascuno, nella nuova versione sono stati assegnati 128 bit. Il numero teorico massimo di indirizzi IPv4 è 2 32 cioè circa 4, mentre il numero teorico massimo di indirizzi IPv6 è 2 128, pari a circa 3, Il controllo di errore svolto dal vecchio campo Checksum non è necessario perchè svolto dai protocolli dei layer superiori ed è stato, perciò, eliminato. Alcuni campi sono stati ereditati dalla versione 4 ed hanno cambiato nome: è il caso del Type of Service che è stato rinominato in Traffic Class. Il campo IPv4 Time To Live (TTL) era inizialmente stato definito per contenere il tempo di vita del pacchetto espresso in secondi. Scaduto questo tempo, il pacchetto doveva essere scartato. Ma a causa di problemi relativi alla sincronizzazione degli orologi in Internet, si è preferito istruire i router in modo che diminuiscano di una unità il valore del TTL ogni volta che eseguono il forwarding del pacchetto. Se il TTL raggiunge lo zero, il pacchetto 26

27 2.4. INDIRIZZI UNICAST, MULTICAST, ANYCAST deve essere scartato e viene spedito un messaggio di errore. In IPv6 viene utilizzato proprio questo comportamento ed il TTL è stato rinominato nel più corretto Hop Limit. Il campo Total Length è stato rinominato in Payload Length. Il payload è l unica parte del datagramma IPv6 che può avere una lunghezza variabile, al contrario di IPv4 che poteva avere anche l header variabile. L unico campo effettivamente nuovo è il Flow Label, utile per applicazioni audio, video, online gaming ed altri applicativi real-time. Un importante ottimizzazione riguarda la frammentazione: solo gli host dovranno occuparsi di frammentare pacchetti eccessivamente grandi, mentre i router dovranno assolvere semplicemente alla funzione di forwarding, velocizzando quindi il processo di inoltramento dei pacchetti (per ulteriori dettagli fare riferimento alla sezione 2.7). Un ultima novità riguarda la grandezza minima di un pacchetto IP che un qualsiasi host è obbligato a supportare. Si è passati da pacchetti del peso minimo di 576 byte a pacchetti di 1280 byte. Questo ha migliorato il rapporto tra dati utili del payload e dati di gestione dell header, ed ha ridotto la necessità di frammentare i datagrammi. 2.4 Indirizzi unicast, multicast, anycast Gli indirizzi possono essere di tre tipologie differenti: Unicast: sono utilizzati per la comunicazione tra due host. Un indirizzo unicast individua una ed una sola interfaccia di rete. Come si può Figura 2.3: Struttura di un indirizzo global unicast generico notare dalla figura 2.3, un indirizzo unicast generico può essere diviso in tre blocchi. Il primo è un prefisso di rete lungo n bit. Il secondo è un prefisso di sottorete lungo m bit. L ultima parte è costituita dall identificatore dell host. Se i router dovessere conoscere tutti gli indirizzi di tutti gli host del pianeta, avrebbero della tabelle di routing mastodontiche. Per questo 27

28 CAPITOLO 2. IL PROTOCOLLO IPV6 motivo Internet è stata fortemente gerarchizzata: i router al livello più alto della gerarchia conoscono solo pochi prefissi di rete a cui inviare i pacchetti. I router del secondo livello conoscono a loro volta i prefissi di altre sottoreti, e così via fino ad arrivare ai router che conoscono l indirizzo completo di un host. Inizialmente la gerarchia era stata descritta da RFC 2374[3]: la parte di rete di un indirizzo era stato diviso in Top Level Domain (TLA), Next Level Domain (NLD) e Site Level Domain (SLA) ma era eccessivamente rigida ed è quindi stata abbandonata e sostituita dalla più flessibile struttura che abbiamo appena visto in figura 2.3. Multicast: sono utilizzati per la comunicazione tra un host e nodi multipli. Un indirizzo multicast, la cui struttura è mostrata in figura 2.4, identifica un insieme di nodi. Un indirizzo multicast inizia sempre Figura 2.4: Struttura di un indirizzo multicast con un prefisso di 8 bit posti ad 1 (in esadecimale è ff ) ed è seguito da alcuni flag e dallo scope (rispettivamente F ed S nella figura 2.4). I restanti 112 bit sono l identificativo del gruppo cui possono appartenere più nodi. Anycast: sono dei particolari indirizzi multicast in cui il mittente comunica con il nodo più vicino di un gruppo. Hanno la struttura di un indirizzo unicast e sono utili nel DNS, ad esempio, per raggiungere il più vicino dei root server. Essi servono, in altre parole, in tutti quei casi in cui si necessita di un servizio fornito da più server sparsi per la rete Internet. Di questi server, però, vorremmo sia scelto quello più vicino, in termini di routing, per evitare ovvi problemi di inefficienza. Attualmente sono ancora poco usati e in fase di analisi, poichè la complessità nel gestirli aumenta con il crescere della distanza tra due nodi che condividono lo stesso indirizzo anycast. Da notare che gli indirizzi di tipo broadcast non esistono più, o meglio, la loro funzionalità viene svolta da quelli multicast. Con IPv4 se un host appartiene 28

29 2.4. INDIRIZZI UNICAST, MULTICAST, ANYCAST alla rete /24 e vuole contattare tutti i nodi collegati ad essa, deve utilizzare l indirizzo più elevato in quella rete, il Lo stesso effetto in IPv6 è svolto dall indirizzo ff02::1 (all-hosts multicast address). Un indirizzo multicast ha l intento di evitare inutile flooding (letteralmente inondazione ) nella rete, consentendo messaggi più specifici e mirati. 29

30 CAPITOLO 2. IL PROTOCOLLO IPV6 2.5 Scope degli indirizzi: Link-local e Global Gli indirizzi IPv6 possono avere due tipi di visibilità (o scope): quella locale e quella globale. La prima non permette la navigazione in Internet perchè, appunto, serve solo per comunicazioni nella propria LAN. La seconda è la visibilità massima e permette di essere raggiungibili dall esterno della propria rete. Nelle prossime sezioni saranno descritti gli indirizzi unicast con visibilità link-local e global Link-local Per ogni interfaccia di un nodo viene generato automaticamente un indirizzo unicast con visibilità link-local (come in figura 2.5). Questo particolare indirizzo non è sufficiente per essere visibili sulla rete Internet ma è utilizzabile solo a livello locale. Il prefisso per i link-local unicast è fe80, mentre l interface-id (64 bit) è Figura 2.5: Struttura di un indirizzo link-local ricavato dall indirizzo fisico (MAC address) dell interfaccia. Poichè il MAC ha 48 bit viene aggiunto a metà la stringa ff:fe (16 bit). Per esempio, se una scheda di rete ha il MAC 00:bb:cc:dd:ee:ff il suo indirizzo locale sarà fe80::02bb:ccff:fedd:eeff. Come spiegato nella sezione 2.8, il settimo bit a partire da sinistra viene impostato a 1, è per questo motivo che la parte più a sinistra dell indirizzo 00 diventa 02. Cosa accade con IPv4 quando un nodo si connette ad una rete? Se non si configura manualmente un indirizzo statico, l interfaccia aspetta che un server DHCP le assegni un indirizzo. Se, sfortunatamente, non è presente alcun server o relay agent entra in gioco il protocollo Automatic Private IP Address (APIPA) che assegna in modo causale un indirizzo scelto nel range Questo protocollo però non fa parte delle specifiche IPv4 ma fu ideato ed utilizzato da Microsoft nei propri sistemi operativi diventando, col tempo, uno standard. 30

31 2.6. NEIGHBOR DISCOVERING PROTOCOL La generazione di un indirizzo link-local avviene non appena l interfaccia è collegata, e si ha quindi immediatamente un indirizzo con cui poter parlare nella propria rete privata. Nonostante l inserimento dell indirizzo MAC in quello IP comporti teoricamente la sicurezza del 100% che il link-local address sia univoco, vedremo che è necessario effettuare un controllo di duplicazione degli indirizzi (Duplicate Address Detection) come spiegato nella sezione Global I Global Address sono indirizzi a visibilità pubblica, la cui struttura è osservabile in figura 2.6. Figura 2.6: Struttura di un indirizzo unicast global address Il prefisso è formato dai bit 001 che in esadecimale diventa 2. Quindi un indirizzo unicast globale è del tipo 2a00:1450:8002::63. Il prefisso di rete globale è costituito in totale, compresi i primi tre bit, da 48 bit. I successivi 16 bit sono utilizzati per gestire le sottoreti. In questo modo ad un organizzazione oppure ad un azienda verrà assegnato un prefisso di rete (48 bit) e potrà usare i 16 bit per creare una propria gerarchia. Gli ultimi 64 bit sono la parte host dell indirizzo e possono essere impostati manualmente o generati automaticamente a partire dall indirizzo MAC tramite una variante della procedura EUI-64 (vedi sezione 2.8). 2.6 Neighbor Discovering Protocol Il Neighbor Discovering Protocol (da qui in avanti NDP) è un protocollo che integra numerose funzionalità riguardanti l interazione sia host-router che host-to-host. Vediamo quali ruoli ricopre nell interazione host-router: NDP è utile ad un 31

32 CAPITOLO 2. IL PROTOCOLLO IPV6 host per determinare l indirizzo dei router della propria rete (router discovery). È, inoltre, usato dai router per inviare periodicamente dei Router Advertisement, messaggi che pubblicizzano il prefisso della rete in cui si trova il router stesso. I messaggi di Router Advertisement e Router Solicitation fanno essi stessi parte del NDP e verranno approfonditi in sezione Per quanto concerne la comunicazione host-to-host, NDP esegue il lavoro svolto dall Address Resolution Protocol (ARP) di IPv4. Quando un nodo IPv6 vuole inviare un pacchetto ad un proprio vicino (dall inglese neighbor) deve conoscerne l indirizzo del livello link-layer, ovvero l indirizzo dell interfaccia fisica, esattamente alla stessa maniera di IPv4. Facciamo un semplice esempio. Host A conosce solo l indirizzo IPv6 di host B, ed entrambi sono collegati alla stessa sottorete. Host A per comunicare direttamente con host B di certo non dovrà spedire pacchetti verso l esterno, visto che il nodo è lì vicino! Perciò invia un messaggio di Neighbor Solicitation ad un particolare indirizzo multicast contenente l indirizzo IPv6 di host B. Essendo quest ultimo un messaggio multicast, più host lo riceveranno, ma solo host B, proprietario dell indirizzo IPv6 specificato, risponderà con un Neighbor Advertisement. Nella risposta mandata da host B è contenuto il proprio indirizzo al livello link-layer. Ora è possibile che i due nodi comunichino direttamente fra di loro, in quanto entrambi conoscono i reciproci indirizzi link-layer. Sempre nell interazione host-to-host, ogni volta che un nodo vuole usare un indirizzo IPv6 deve controllare che esso sia univoco. È stato definito un nuovo meccanismo, chiamato Duplicate Address Detection (DAD), anche esso facente parte della suite di funzionalità offerte da NDP. Il funzionamento è identico a quello espresso poco fa. Ogni volta che un host vuole utilizzare un indirizzo, che sia quello link-local oppure uno assegnato staticamente, deve utilizzare il DAD. Anche in questo caso un esempio chiarirà al meglio la questione: l host A con indirizzo fe80::1234:56ff:fe78:9abc invia un Neighbor Solicitation ad un particolare indirizzo multicast chiedendo quale nodo possiede fe80::1234:56ff:fe78:9abc (il proprio indirizzo). Se il nodo A non riceve alcuna risposta non ci sono problemi di alcun tipo. Nel caso in cui un nodo risponda con un Neighbour Advertisement, viene rilevata una duplicazione e host A non potrà utilizzare quel particolare indirizzo. 32

33 2.7 Path MTU Discovery 2.7. PATH MTU DISCOVERY L unità massima di trasmissione (Maximum Transmission Unit) consiste nella grandezza massima di un pacchetto che una rete può supportare. A seconda della tecnologia utilizzata, una rete può assicurare la corretta trasmissione di pacchetti più o meno grandi, senza necessità di frammentarli. Come già visto nella sezione 2.1, in IPv6 la minima unità di trasmissione è di 1280 byte, contro i soli 576 byte di IPv4. Nel caso un pacchetto superi queste dimensioni è necessario frammentarlo in pacchetti più piccoli che rispettino la MTU di quel particolare link. È abitudine consolidata dei router farsi carico di questo lavoro di spezzettamento dei pacchetti durante il loro viaggio da un host ad un altro. Ciò che di questo comportamento non è affatto desiderabile è che i router siano costretti a frammentare un grande numero di datagrammi, generando in questo modo enormi ritardi. La nuova idea introdotta con IPv6 è fare in modo che i router eseguano il forwarding dei pacchetti senza interruzioni di alcuna sorta. Per raggiungere tale obiettivo è stato deciso che solo i nodi mittenti dovranno preoccuparsi di frammentare e/o inviare datagrammi della giusta dimensione. Il seguente esempio ci chiarirà le idee. Un host A che voglia comunicare con un host B deve attuare un processo di Path MTU Discovery, ovvero deve conoscere quale sia la taglia giusta dei pacchetti da inviare nel percorso da A verso B. La Maximum Transmission Unit del percorso da A verso B è la minima tra tutte le MTU. Tra host A e host B ci sono i router C e D. Host A invia un pacchetto indirizzato a B, che arriva al router C. Ma router C si accorge che la MTU del prossimo link (quella tra router D e host B) è più piccola delle dimensioni del pacchetto. Quindi risponde con un messaggio di errore Packet too big contenente la MTU del successivo link. Host A riceve il messaggio di errore e re-invia pacchetto usando la nuova MTU, che viene memorizzata in un apposita tabella. Per ogni destinazione host A memorizza la corrispondente MTU. Il datagramma raggiunge, infine, correttamente host B. Nel caso in cui la MTU sia più piccola delle dimensioni necessarie al pacchetto, host A lo suddivide in più parti utilizzando il Fragment Extension Header (vedere sezione 2.2). È palese che il PMTU Discovery non è esente da difetti. Quello più evidente è che non riesce ad evitare i colli di bottiglia costituiti da reti poco performanti. Se un cammino da un host ad un altro possiede link capaci di supportare una MTU di 1800 byte, mentre solo l ultimo tratto supporta pacchetti di massimo 1280 byte, l host mittente sarà obbligato ad utilizzare proprio la MTU più piccola (1280 byte). 33

34 CAPITOLO 2. IL PROTOCOLLO IPV6 Il secondo problema è che la conformazione della rete cambia di continuo. Di conseguenza il PMTU Discovery dovrà essere eseguito periodicamente dal nodo mittente per aggiornare le informazioni presenti nella tabella delle MTU. Il vantaggio di evitare frammentazioni dei pacchetti a carico dei nodi intermedi, a dispetto di un tempo di over-head prima della spedizione dei datagrammi permette, tuttavia, di sorvolare sui difetti appena espressi. 2.8 Address auto-configuration Plug&play (in italiano suonerebbe come Connetti e gioca ) è la direzione verso cui si è lavorato con IPv6. Rispecchia questo concetto la funzionalità di generazione automatica degli indirizzi. Non appena connesse ad una rete, le interfacce fisiche generano in modo autonomo un indirizzo IP formato dall unione di un prefisso di rete più una parte host. Il segmento di rete, lungo 64 bit, è pubblicizzato dai router, mentre il segmento host è costruito dalla scheda stessa a partire dal suo MAC address: esso si chiama interface-identifier (più brevemente interface ID) ed è lungo altri 64 bit. Vedremo nelle sezioni qui di seguito la procedura di generazione dell interface ID e l acquisizione del prefisso di rete Generazione dell Interface-identifier L interface ID di un indirizzo IPv6 è un segmento di 64 bit generato a partire dall indirizzo fisico di una scheda di rete. In altre parole, l indirizzo del livello data-link (per esempio, quello Media Access Control, d ora in poi MAC) viene inserito all interno dell indirizzo del livello rete (IPv6). Per ottenere l interface ID si segue una variante della procedura Extended Unique Identifier (EUI-64): 1. Viene estratto il MAC dell interfaccia fisica, la cui lunghezza è di 48 bit Figura 2.7: Esempio di indirizzo MAC (48 bit) 34

35 2.8. ADDRESS AUTO-CONFIGURATION 2. Poichè il MAC è lungo 48 bit, è necessario completarlo con altri 16 bit per avere un segmento lungo in totale 64 bit. Questi 16 bit sono ricavati aggiungendo nel mezzo dell indirizzo MAC la sequenza ff:fe Figura 2.8: MAC aumentato a 64 bit 3. Il settimo bit a partire da sinistra viene impostato ad 1 se il MAC non è stato modificato. Questo significa che è univoco. Nel caso esso sia stato modificato si perde la proprietà di univocità, e quindi il bit viene impostato a 0. Come mostrato in figura 2.9, le prime due cifre del MAC scritte in esadecimale 0 0 corrispondono ai bit Se il settimo bit viene impostato ad 1 diventano cioè 0 2 in esadecimale Figura 2.9: Interface ID finale Una volta ottenuto l interface-id, che riveste il ruolo di parte host dell indirizzo IP, viene aggiunto il prefisso di rete pubblicizzato dai router (vedere sezione 2.8.2). L indirizzo IPv6 generato in modo automatico è pronto ad essere utilizzato. A questo punto è opportuno notare un problema relativo alla privacy. Ricordiamo che un indirizzo unicast globale viene generato a partire dal MAC address di una delle interfacce di rete di un nodo secondo la procedura appena descritta. Un indirizzo MAC è di per sè univoco, di conseguenza anche l interface-id sarà unico. Da questo possiamo dedurre che, indipendentemente dal prefisso di rete che viene assegnato ad un utente, il traffico generato da quest ultimo sarà rintracciabile semplicemente basandosi sull interface-id. Al fine di evitare questo problema e garantire un certo livello di anonimità è offerta l opzione di generare randomicamente l interface-id: questi particolari indirizzi sono detti Temporary Address e vengono creati a partire da un numero random e con l ausilio della funzione di hash MD5. Quando scade 35

36 CAPITOLO 2. IL PROTOCOLLO IPV6 il tempo di validità dell indirizzo, viene forgiato nuovamente un indirizzo temporaneo Router Advertisement e Router Solicitation Il prefisso di rete di un indirizzo IPv6 viene diffuso sul segmento di rete (anche detto link) dai router tramite dei messaggi di Router Advertisement (RA). Essi sono inclusi in pacchetti di tipo Internet Control Message Protocol version 6 (ICMPv6) che contengono tutte le informazioni riguardanti i parametri di rete, tra cui anche il prefisso. I RA possiedono come sorgente l indirizzo link-local del router e sono destinati all indirizzo multicast ff02::1 il quale raggruppa tutti i nodi collegati ad un determinato link. In questo modo qualsiasi host in una rete li può ricevere ed apprendere le informazioni contenute in essi. I RA vengono diffusi sul link ad intervalli di tempo regolari ma un host può sollecitare, tramite un messaggio di Router Solicitation (RS), i router affinchè inviino i RA. Questo accade tipicamente nell istante in cui l host si collega ad una rete: esso invia un RS all indirizzo multicast ff02::2 che identifica tutti i router del link cui si è connesso. 36

37 Capitolo 3 Novità al livello applicazione In questo capitolo saranno evidenziate le novità introdotte nei protocolli dell ultimo livello della pila ISO/OSI, quello delle applicazioni. In particolare saranno trattati il Dynamic Host Configuration Protocol (DHCP) ed il Domain Name System (DNS) in IPv DHCP in IPv6 Nelle network basate su Internet Protocol, ogni volta che un host si aggancia ad una particolare rete, gli si dovrebbe assegnare manualmente un indirizzo IP univoco, l indirizzo dei server DNS, la maschera di sottorete, il default gateway, e tutti gli altri parametri necessari ad operare su quella rete. La gestione di questi parametri diventa ancora più gravosa quando ci si trova ad amministrare una rete molto estesa con host che si connettono e disconnettono in continuazione. Questo scenario rispecchia fedelmente quello che accade ogni giorno in un organizzazione qualsiasi. La soluzione, consolidata ormai da anni, è il Dynamic Host Configuration Protocol (DHCP), il protocollo per la gestione dinamica degli indirizzi e di tutti gli altri parametri di rete utili a configurare un host in modo del tutto automatico. Grazie ad esso, infatti, ad un host su cui è attivo il processo di DHCP client vengono inviati automaticamente tutti i parametri di rete da un apposito server DHCP. Questo protocollo è stato implementato sia per IPv4 (DHCPv4) che per IPv6 (DHCPv6). Sebbene lo scopo sia rimasto praticamente immutato, ci sono alcune differenze apportate all ultima versione di questo fondamentale protocollo, che saranno spiegate nelle prossime sezioni. 37

38 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE DHCPv6 e Router Advertisement Daemon Dynamic Host Configuration Protocol version 6 è la nuova versione del protocollo in grado di gestire dinamicamente gli indirizzi e gli altri parametri di rete dei client che si collegano ad una rete. La novità rispetto al proprio antenato è che DHCPv6 collabora strettamente con il software chiamato Router ADVertisement Daemon (RADVD). È, infatti, RADVD ad inviare, ad intervalli regolari, dei particolari messaggi ICMPv6 (Internet Control Message Protocol), i Router Advertisement (RA). I RA svolgono più funzioni: possono contenere il prefisso di rete; servono ad avvertire i client se dovranno generare in automatico l indirizzo IPv6 tramite l Address auto-configuration (vedi Sez. 2.8) o se contattare un server DHCP. Poichè RADVD invia questi segnali ogni volta che scade un timer specificato nel file di configurazione, potrebbe capitare che un host si colleghi ad una rete e non riceva alcun RA. Per questo motivo, ad un host è data la possibilità di sollecitare i router ad inviare i RA tramite un messaggio di Router Solicitation (RS). Ma vediamo nel dettaglio i vari step che occorrono quando un host si connette ad una rete in cui è attivo uno o più server DHCPv6. Nell esempio che andremo ad analizzare, i server-router possiedono sia il software che implementa il DHCPv6 (ad esempio, dhcp6s) sia il software che gestisce gli Advertisement, RADVD. Il primo passo che un host compie quando si aggancia ad una rete, è l invio di un messaggio di Router Solicitation (RS), tramite cui può forzare gli eventuali server-router all invio di un RA. Il messaggio inviato dall host è di tipo multicast con destinazione ff02::2, che identifica tutti i router su quel determinato link. Se presenti, i server-router rispondono con un RA che contiene il Managed Configuration Flag: nel caso in cui il flag sia impostato a off significa che gli host dovranno eseguire la configurazione automatica dell indirizzo (per i dettagli riferirsi alla sezione 2.8); se, invece, è impostato ad on vuol dire che l indirizzo e gli altri parametri di rete sono gestiti dal DHCPv6. Nel secondo caso l host invia un messaggio di DHCP Solicit per cercare i server DHCPv6 presenti sulla rete. Il server DHCPv6 risponde con un DHCP Advertise contenente l indirizzo cui è raggiungibile. Una volta che l host è in grado di raggiungere il server, invia un messaggio di DHCP Request con cui richiede i parametri di configurazione. Il server invia i dati richiesti tramite un messaggio di DHCP Reply. Il processo termina con una conferma dei parametri da parte dell host, tramite l invio di un DHCP Confirm. 38

39 3.1. DHCP IN IPV6 Ci sono due tipologie di configurazioni di DHCPv6 e RADVD: Stateful auto-configuration Stateless auto-configuration Esse verranno trattate in dettaglio nelle sezioni successive DHCPv6 Stateful auto-configuration Nella configurazione stateful, RADVD avvisa i client che dovranno cercare un server DHCPv6 per l assegnazione dell indirizzo, impostando ad on il Managed Config Flag. RADVD si limita quindi ad inviare: MTU di quel particolare segmento di rete ed indirizzo del default gateway. Il server DHCPv6 invia i seguenti parametri: range entro cui un host può scegliere un indirizzo, indirizzi dei server DNS, nome di dominio DNS di default, indirizzi dei server Network Time Protocol (NTP) ed indirizzi dei server Session Initial Protocol (SIP). Riassumento, in totale vengono scambiati i seguenti messaggi: Solicit: inviato dall host ai server-router, per forzare l invio di un RA Advertise: inviato dal server-router che ha attivo RADVD agli host Request: l host richiede al server DHCP i parametri Reply: il server risponde con l indirizzo, i server DNS, ecc. In seguito viene riportata la configurazione testata e funzionante del DHCPv6 installato sul server in modalità stateful. Configurazioni stateful lato Server Il presente paragrafo propone un esempio di configurazione stateful. È stato creato un server-router operante su centos 5.4 con i processi RAD- VD e dhcp6s attivi. Quindi questo server farà sia da server DHCPv6 sia da router che invia gli Advertisement. Questo server-router è dotato di un interfaccia eth1 a cui è connesso uno switch: in tal modo è possibile collegare molti host allo switch e verificare che il server gli assegni automaticamente degli indirizzi. Per testare il DHCPv6 è sufficiente creare la sottorete con prefisso 2001:1418:1c6:1::/64 ed assegnare ai client un indirizzo IPv6 compreso tra 2001:1418:1c6:1::2 e 39

40 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE 2001:1418:1c6:1::1000. Il file da modificare è /etc/dhcp6s.conf : interface eth1 { option dns_servers 2001:1418:1c6:1::1; link AAA { allow unicast; send unicast; server-preference 5; renew-time 1000; rebind-time 2400; valid-life-time 20000; pool{ range 2001:1418:1c6:1::2 to 2001:1418:1c6:1::1000/64; prefix 2001:1418:1c6:1::/64; }; }; }; Come è possibile osservare dal codice qui sopra i comandi sono molto intuitivi. Di seguito sono descritti quelli utilizzati: interface: è l interfaccia su cui viene pubblicizzato il servizio di DHCPv6. Se un host si collega ad un interfaccia diversa da quella specificata, non gli verrà assegnato alcun indirizzo IP options dns servers: serve per specificare gli indirizzi dei server DNS server-preference: permette di assegnare una priorità al server DHCPv6. Un host sceglierà di comunicare con un server DHCPv6 con priorità maggiore valid-life-time: ogni indirizzo ha un tempo di vita entro cui è valido, passato il quale deve essere rinnovato. Questo parametro, espresso in secondi, indica il tempo di validità degli indirizzi renew-time: è il tempo entro cui un host può rinnovare l indirizzo rebind-time: se il rinnovo dell indirizzo fallisce, l host può tentare di contattare un altro server durante il tempo specificato in questo campo allow unicast: solitamente i client DHCPv6 devono usare indirizzi multicast per contattare il server DHCPv6 e i Relay Agent. Con questa dichiarazione dhcp6s accetta messaggi unicast dai client, se anche essi includono l opzione Server Unicast 40

41 3.1. DHCP IN IPV6 send unicast: permette l invio di messaggi unicast agli hosts range: è il range entro cui il server DHCPv6 assegna gli indirizzi ai client prefix: è il prefisso della sottorete Come detto in precedenza il carico di lavoro più grosso nella modalità stateful viene svolta dal software che implementa DHCPv6, dhcp6s. Infatti RADVD si limita a settare ad on il Managed Config Flag, tramite cui avvisa i client che dovranno ricercare un server DHCPv6. Impostando, inoltre, ad off il flag AdvAutonomous, RADVD comunica che non è prevista la generazione autonoma degli indirizzi. Esso, infine, fornisce il default gateway ai client e la MTU del segmento di rete. Qui di seguito è riportato il file /etc/radvd.conf che è stato modificato per ottenere una configurazione stateful: interface eth1 { AdvSendAdvert on; AdvLinkMTU 1480; AdvManagedFlag on; AdvOtherConfigFlag on; MinRtrAdvInterval 3; MaxRtrAdvInterval 5; AdvSourceLLAddress on; prefix 2001:1418:1c6:1::/64 { AdvAutonomous off; }; }; Anche in questo caso i comandi sono piuttosto intuitivi: AdvSendAdvert: indica se inviare o meno i RA e se rispondere alle Solicitation AdvLinkMTU: il valore specificato in byte consiste nella Maximum Transmission Unit AdvOtherConfigFlag: indica agli host di richiedere i parametri di rete al server DHCPv6. In altri termini attiva la modalità stateful Min/MaxRtrAdvInterval: specificano l intervallo di tempo a cui inviare i RA 41

42 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE AdvSourceLLAddress: include nei RA l indirizzo link-layer dell interfaccia da cui è partito il RA Configurazioni stateful lato client Se un server-router DHCPv6 è presente in un determinato link, i client che vorranno utilizzarlo per l assegnazione automatica degli indirizzi, dovranno possedere la controparte client del DHCPv6. L unica nota dolente in questo ambito è che i sistemi operativi Windows XP e Ubuntu non supportano nativamente il DHCPv6. Con Windows 7 non ci sono stati problemi di alcuna sorta, poichè le funzionalità di client DHCPv6 sono già integrate. Per questa motivazione si è costretti ad installare il software gratuito Dibbler (su Windows XP) e wide-dhcpv6-client (su Ubuntu). Vediamo come agire sul calcolatore Windows XP. Dopo avere installato Dibbler, è necessario modificare il file dei settaggi che si trova al percorso Start-Programmi-Dibbler-Edit Client Config File aggiungendo in coda queste poche righe: iface "Connessione alla rete locale (LAN)" { ia option dns-server option domain } Le opzioni utilizzate sono: ia: il client richiede indirizzi non temporanei. Può essere combinata con l opzione ta ta: sta per Temporary Address, cioè il client richiede indirizzi temporanei. Può essere combinata con l opzione ia option dns-server: il client DHCPv6 richiede gli indirizzi dei server DNS option domain: opzione utilizzata per richiedere il nome di dominio L ultimo passo da eseguire è avviare Dibbler in modalità client cliccando su Start-Programmi- Dibbler-Client Run in the console. A questo punto è sufficiente aprire una shell e digitare: ipconfig /all 42

43 3.1. DHCP IN IPV6 Se tutto è andato per il verso giusto il client possiede un indirizzo entro il range specificato nel file di configurazione di dhcp6s, i server DNS, ecc. ed ha la facoltà di navigare in Internet. Un client con sistema operativo Ubuntu richiede l utilizzo del software wide-dhcpv6-client per ottenere le funzionalità di client DHCPv6. Dopo l installazione del pacchetto appena citato, scriviamo nel file /etc/widedhcpv6/dhcp6c.conf le seguenti righe di codice: interface eth1 { request domain-name-servers; request domain-name; send ia-na 1; script "/etc/wide-dhcpv6/dhcp6c-script"; }; id-assoc na 1{}; Anche in questo caso non è molto difficile intuire a cosa servano i comandi. Per completezza sono descritti di seguito: Interface: indica su quale interfaccia rendere attivo il servizio di DHCPv6 client. In questo modo dall interfaccia specificata verranno inviati i RS e sarà assegnato dal server DHCP un indirizzo IP Request domain-name-servers: richiede gli indirizzi dei server DNS Request domain-name: richiede il nome di dominio Send ia-na: questa opzione serve a richiedere indirizzi temporanei o meno al server DHCPv6. Se impostata ad 1 il client richiede un indirizzo non temporaneo id-assoc na: nelle parentesi graffe di questa dichiarazione è possibile specificare ulteriori parametri di configurazione, che non sono stati approfonditi in questo esempio Per avviare il servizio in questione digitiamo da shell: service wide-dhcpv6-client start Se qualcosa non funziona, è possibile avviare il servizio con un utile debugger che ci avviserà su cosa non è andato a buon fine. Il comando da eseguire è il seguente: sudo /usr/sbin/dhcp6c -ddf -c /etc/wide-dhcpv6/dhcp6c.conf eth1 43

44 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE DHCPv6 Stateless auto-configuration In questa configurazione RADVD, impostando ad off il Managed Config Flag, rende noto ai client che non dovranno contattare un server DHCPv6 per la creazione dell indirizzo IPv6. Nei RA, inoltre, è settato ad on il flag AdvAutonomous, che indica ai client di generare l indirizzo con il processo di auto-configurazione. Riassumendo, RADVD invia i seguenti dati: il prefisso di rete, la MTU di quel particolare link, l indirizzo del default gateway. Gli host richiederanno al server DHCPv6 parametri aggiuntivi quali: indirizzi dei server DNS, nome di dominio DNS di default, indirizzi dei server NTP, indirizzi dei server SIP. In seguito viene riportata la configurazione testata e funzionante di dhcp6s installato sul server in modalità stateless. Configurazioni stateless lato Server Come nella precedente modalità (sezione 3.1.2) viene fornito un esempio per la creazione della sottorete 2001:1418:1c6:1::/64. Il server-router continua ad essere quello già descritto precedentemente, di cui ci basterà ricordare che riveste il ruolo di server DHCPv6 e che è in grado di inviare i RA. Il codice da scrivere nel file di configurazione di dhcp6s (/etc/dhcp6s.conf ) è il seguente: interface eth1 { option dns_servers 2001:1418:1c6:1::1; send information-only; link AAA { allow unicast; send unicast; server-preference 5; renew-time 1000; rebind-time 2400; prefer-life-time 2000; }; }; L opzione pool non è più presente in quanto il server DHCPv6 non verrà più contattato per assegnare indirizzi. Il parametro send information-only indica a dhcp6s di inviare tutti i rimanenti parametri di rete. 44

45 3.1. DHCP IN IPV6 Segue la configurazione testata e funzionante di RADVD installato sul server in modalità stateless: interface eth1 { AdvSendAdvert on; AdvLinkMTU 1480; AdvManagedFlag off; AdvOtherConfigFlag on; MinRtrAdvInterval 3; MaxRtrAdvInterval 5; AdvSourceLLAddress on; prefix 2001:1418:1c6:1::/64 { AdvAutonomous on; }; }; Come già accennato, i parametri modificati rispetto alla precedente configurazione di RADVD sono AdvManagedFlag ed AdvAutonomous. Configurazioni stateless lato client Anche nella configurazione stateless Windows 7 dimostra di essere già pronto all uso. I client Windows XP e Ubuntu, invece, necessitano di particolari configurazioni, riportate di seguito. Sui calcolatori che montano Windows XP il codice da scrivere nel file di configurazione di Dibbler è il seguente. Nella pratica è stato aggiunto il comando stateless e sono state eliminate le parti riguardanti la richiesta degli indirizzi: stateless iface "Connessione alla rete locale (LAN)" { option dns-server option domain } I client Ubuntu utilizzano il software wide-dhcp-client il cui file di configurazione deve essere impostato come di seguito: interface eth0 { information-only; 45

46 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE send ia-na 1; script "/etc/wide-dhcpv6/dhcp6c-script"; }; id-assoc na 1{}; Possiamo notare come non ci siano state grandi modifiche, semplicemente nel client è stato aggiunto il comando information-only con cui vengono richiesti tutti i parametri di rete eccetto gli indirizzi Confronto tra DHCPv6 e DHCPv4 Nonostante la Address auto-configuration abbia diminuito la necessità in IPv6 del DHCP, esso rimane comunque un utile strumento per la gestione delle reti. Una netta miglioria rispetto all antenato consiste nella facilità con cui è possibile aggiornare i parametri di rete degli host: in DHCPv4 non è presente alcun meccanismo che aggiorni dinamicamente, per esempio, gli indirizzi dei server DNS. Con DHCPv6 questo, invece, è possibile: se l indirizzo del DNS cambia, il server invia un messaggio di Reconfig-init agli hosts della propria rete, che riceveranno i parametri aggiornati. Dal punto di vista aziendale è tipico effettuare una rinumerazione (cioè cambiare il prefisso di rete, gli indirizzi dei server, delle stampanti, ecc.) quando si cambia ISP o quando si vuole modificare la gerarchia della propria rete. In passato non c era alcun meccanismo automatico per effettuare il renumbering. Con DHCPv6 grazie al messaggio di Reconfig-init è possibile effettuare una rinumerazione senza troppi sforzi. A differenza della versione 4 che utilizza messaggi broadcast, il DHCPv6 permette un utilizzo più efficiente delle risorse di rete, dal momento che utilizza indirizzi mirati solo agli host (ff02::1 ) o solo ai router/server (ff02::2 ). In questo capitolo ci siamo sempre riferiti alla possibilità che più di un server spedisca RA. Questo implica che gli host possano richiedere indirizzi multipli per la stessa interfaccia, modalità non prevista con il vecchio protocollo. Un ultima considerazione personale riguarda un punto su cui mi sono posto diversi interrogativi. La direzione verso cui si è lavorato per IPv6 è quella plug&play. RADVD è nato proprio con l intenzione di consentire ad un host di avere immediatamente un indirizzo IP con pochi scambi di messaggi, il tutto in modo automatico. RADVD, tuttavia, non è sufficiente affinchè l host in questione possa navigare in Internet: al client manca ancora l indirizzo dei server DNS. Questo parametro viene fornito solo da un server DHCPv6, cioè un calcolatore in cui sia installato il software (per esempio dhcp6s o wide- 46

47 3.2. DNS IN IPV6 dhcp-server) che implementa il DHCPv6. La domanda che mi sono posto è: perchè non implementare l invio dell indirizzo del DNS direttamente in RADVD, così da evitare l installazione e la configurazione di ulteriore software? Allo stesso modo, un server DHCPv6 da solo non fornisce il set completo dei parametri, perchè non è in grado di diffondere il default gateway. La situazione attuale è quindi avere attivi e configurati tutti e 2 i programmi (quello per il DHCPv6 e RADVD). Se in una rete piccola questo non rappresenta un grave problema, in una rete con N server-router ci si troverebbe a dover installare e configurare 2 N volte i programmi sopra menzionati. La questione è già stata sollevata e l idea che mi sono fatto è che con alta probabilità vedremo implementazioni di RADVD capaci di diffondere anche gli indirizzi dei server DNS. 3.2 DNS in IPv6 Il Domain Name System (DNS) è tecnicamente un database distribuito i cui records associano ad ogni indirizzo IP un nome. Dal momento che un sito Internet è raggiungibile solo tramite il proprio identificatore, l indirizzo IP, si dovrebbe digitare sulla barra degli indirizzi del nostro browser, ad esempio, 2001:4860:0:1001::68. Se lo facciamo si aprirà la pagina IPv6 di Google. Tuttavia risulterebbe faticoso, se non impossibile, memorizzare molti indirizzi. Per questo motivo è sorta la necessità di associare ad ogni indirizzo IP un nome comprensibile e più facile da ricordare per l uomo. L effetto finale è che se vogliamo raggiungere il sito che corrisponde all indirizzo 2001:4860:0:1001::68 ci basterà digitare sulla barra degli indirizzi del nostro browser ipv6.google.com. Il DNS si occupa proprio di gestire l operazione di traduzione, anche detta risoluzione in avanti, di un indirizzo IP nel corrispondente nome, e viceversa. L operazione che traduce un nome nel corrispondente indirizzo IP è detta risoluzione inversa. L organizzazione del DNS è di tipo gerarchico: ci sono 13 server principali, i root servers, che gestiscono gli indirizzi dei top-level domain (.it,.com,.org, ecc.). I server del secondo livello si occupano del sotto-dominio (ad esempio google.com) e così via fino ad un massimo di 127 sotto-domini. 47

48 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE Cambiamenti rispetto a DNS in IPv4 Il DNS è un protocollo facente parte del livello applicazione, ben quattro layer sopra quello di IP. Dal punto di vista teorico un cambiamento apportato ad un livello inferiore non comporta modifiche ai livelli superiori. Purtroppo non è così anche nella pratica: poichè strettamente collegato ad IP, il DNS ha subito alcune modifiche che saranno discusse nei successivi paragrafi. La nuova versione del DNS è concettualmente una tabella che contiene informazioni tanto per IPv4 quanto per IPv6. Ogni riga della tabella, detta anche record, contiene un indirizzo IP con il corrispondente nome. Questo record è di un tipo denominato A, che sta per Address. Poichè gli indirizzi IPv6 sono 4 volte più lunghi dei predecessori, è stata introdotta una nuova tipologia di record chiamata AAAA. Un host potrebbe avere un unico nome a cui sono associati più indirizzi IP, sia versione 4 che 6. La tabella 3.1 esemplifica i concetti appena espressi. Nome Tipo di record Indirizzo A AAAA 2001:5c0:150a::1 Tabella 3.1: Record del DNS per la risoluzione in avanti Per la risoluzione in avanti basterà cercare nella tabella il nome richiesto (nell esempio è a quale indirizzo corrisponde. Vengono forniti entrambi i risultati di tipo A e AAAA. La risoluzione inversa, ovvero la traduzione di un indirizzo IP in un nome, ha lo stesso funzionamento della risoluzione in avanti, ma con qualche modifica strutturale. La tipologia del record memorizzato diventa PTR, dall inglese pointer, puntatore al nome associato all indirizzo. I record PTR sono memorizzati aggiungendo un suffisso, il top-level domain, che in IPv4 è inaddr.arpa. Nel caso di un indirizzo IPv6 il suffisso diventa ip6.arpa, il resto è identico. La tabella 3.2 esemplifica questi concetti. Si può notare come gli indirizzi siano memorizzati nell ordine inverso: questo per coerenza con quanto accade nella risoluzione in avanti. Infatti quando richiediamo la risoluzione dell indirizzo ad esempio, si fa una query a partire dalla fine.it. In seguito viene fatta la richiesta al server che 48

49 3.2. DNS IN IPV6 Indirizzo Tipo di record Nome in-addr.arpa PTR [...].a c ip6.arpa PTR Tabella 3.2: Record del DNS per la risoluzione inversa conosce l indirizzo per la parte google.it fino ad arrivare al server che conosce tutto l indirizzo del sito La risoluzione inversa non è utilizzata molto spesso, se non a scopi statistici o di sicurezza di base. Riepilogando, gli aggiornamenti apportati al DNS sono: Capacità di restituire sia indirizzi IPv4 che IPv6 Aggiunta di una nuova tipologia di record AAAA Aggiunta di un nuovo top-level domain (ip6.arpa) nella risoluzione inversa Procedura di risoluzione dei nomi Dopo aver effettuato una query per la risoluzione di un nome, il server fornisce una risposta che deve essere trasportata tramite pacchetti IPv4 oppure IPv6. Il trasporto utilizzato è indipendente dal tipo di record richiesto. Se, ad esempio, viene richiesto l indirizzo del sito ipv6.google.com, il tipo di dato richiesto è un record di tipo AAAA (un indirizzo IPv6) ma la risposta può essere trasportata sia tramite IPv4 che IPv6. Lo stesso discorso vale se viene richiesto un record A: nulla impedisce che il dato possa essere trasportato anche via IPv6. Un test pratico in ambiente Linux è utilizzare il comando: dig ipv6.google.com aaaa per ottenere l indirizzo IPv6 di google trasportato su IPv4. Vediamo adesso nel dettaglio quale sia la procedura per la risoluzione del nome Poniamo il caso che questo sito fittizio abbia entrambe le connettività: 1. L host richiede la risoluzione di al proprio server DNS. Poichè è la prima volta che l utente richiede questo sito, il server non ne conosce l indirizzo IP completo 49

50 CAPITOLO 3. NOVITÀ AL LIVELLO APPLICAZIONE 2. Il server DNS locale invia la query ad uno dei 13 root server. I root server non sanno risolvere l intero nome, quindi restituiscono l indirizzo dei server in grado di gestire il Top-Level Domain (TLD).it 3. Il server DNS locale invia la stessa richiesta al server di cui ha appena conosciuto l indirizzo. Questo server, ancora una volta, non sa risolvere l intero nome perchè gestisce solo il TLD.it. Quindi risponde con l indirizzo del server DNS in grado di gestire il dominio esempio.it 4. La query viene inviata, a questo punto, al server DNS che gestisce il dominio esempio.it. Questa volta il server DNS conosce l intero indirizzo per il nome e vengono forniti come risposta entrambi i record A ed AAAA 5. E al livello applicazione che viene scelto a quale tra i due indirizzi (IPv4 oppure IPv6) connettersi. Tipicamente viene data priorità all indirizzo IPv6. 50

51 Capitolo 4 Meccanismo di tunneling IPv4-over-IPv6 In questo capitolo verrà fornita una panoramica generale sui meccanismi di migrazione verso il nuovo protocollo di rete IPv6 e sarà trattata nel dettaglio la tecnica di incapsulamento 4over6. Nella sezione 4.2 sono esplicate le motivazioni che hanno portato al bisogno del meccanismo di tunneling 4over6, oggetto di questa tesi. In seguito viene descritto il modo in cui viene effettuato il forwarding dei pacchetti IPv4 incapsulati in pacchetti IPv6. Nella sezione 4.4 sono riportati i casi d uso della configurazione 4over6. Seguono gli schemi della rete sviluppata, le configurazioni dei server-router e dei client, i test effettuati per accertarsi del perfetto funzionamento del progetto. In 4.7 viene implementato il firewall, mentre le ultime due sezioni ricapitolano i vantaggi e gli svantaggi che il tunneling 4over6 offre. 4.1 Introduzione ai meccanismi di transizione Quando fu studiato e sviluppato IP, definito in RFC 791[6] del 1981, 32 bit di spazio per l assegnazione di indirizzi sembravano più che sufficienti. Ciò che non si era previsto era una diffusione su così larga scala di Internet, con la conseguente necessità di indirizzare moltissimi dispositivi. Ormai Internet permea la nostra vita ed inizierà a penetrare sempre più all interno delle cose di tutti i giorni: sveglie, orologi, lavatrici e perfino le T-shirt saranno dotati di connettività con la grande rete. Dispositivi sempre più piccoli avranno bisogno di connettersi ad Internet e ad una stessa interfaccia fisica sarà possibile associare indirizzi multipli. Non si deve, perciò, pensare che i 3, indirizzi IPv6 disponibili siano 51

52 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 un esagerazione. Non manca molto tempo prima che comincino a svilupparsi le prime aree IPv6: si ricordi che la data prevista per l esaurimento degli indirizzi IPv4 è il luglio 2011, nonostante l utilizzo del Network Address Translation abbia permesso di allungarne la vita. Inizierà poco alla volta a delinearsi una geografia di Internet in cui conviveranno isole IPv6 circondate dal mare IPv4. Con il tempo le dorsali e le reti principali passeranno dalla situazione attuale (IPv4-only) ad avere solo connettività IPv6. Soprattutto nella fase iniziale della migrazione si dovrà garantire a nodi IPv6-only la possibilità di raggiungere servizi IPv4 o altri host IPv6-only attraverso l infrastruttura IPv4 esistente. In RFC 4213[7] sono definiti i meccanismi che host e router agenti su stack IPv6 dovrebbero implementare per essere compatibili con host e router agenti su stack IPv4. Essi comprendono: Meccanismo Dual-stack: questa tecnica prevede l utilizzo contemporaneo di implementazioni di entrambi i protocolli sullo stesso calcolatore. Quest ultimo può utilizzare IPv4 o IPv6 in modo indipendente. In altre parole, un calcolatore dual-stack avrà entrambe le connettività attive nello stesso momento; dovrà implementare il DHCPv4 per l assegnazione dinamica di indirizzi IPv4; dovrà implementare il DHCPv6 per l assegnazione dinamica di indirizzi IPv6. Un interfaccia fisica sarà, di conseguenza, raggiungibile sia via indirizzo IPv6 sia tramite indirizzo IPv4 Meccanismo di tunneling di IPv6-over-IPv4: comprende meccanismi, sia automatici che manuali, che incapsulano pacchetti IPv6 in datagrammi IPv4. Un host o una rete IPv6-only grazie alla tecnica del tunneling che consiste nell inserire un pacchetto di un protocollo all interno di un altro, avranno modo di inviare e ricevere pacchetti IPv6 utilizzando l infrastruttura IPv4 esistente Vi è una terza tecnica, ancora sperimentale, definita in RFC 5747[2] che è stata oggetto del mio studio. Si tratta della tecnica di tunneling di pacchetti IPv4 in pacchetti IPv6, che d ora in poi sarà riferita anche con le espressioni meccanismo 4over6 oppure configurazione 4over6. Le sezioni che troviamo di seguito ne descriveranno obiettivi, applicabilità, pregi e difetti. 4.2 La necessità del tunneling 4over6 Il costante esaurirsi di indirizzi IPv4 sta portando al continuo sviluppo di reti agenti sul nuovo protocollo IPv6. La migrazione verso la nuova tecnologia 52

53 4.2. LA NECESSITÀ DEL TUNNELING 4OVER6 nel biennio ha subito una rapida crescita (vedi Fig. 4.1), e con il passare degli anni ci sarà la conversione della totalità delle dorsali alla nuova tecnologia IPv6. Figura 4.1: Crescita degli AS annuncianti indirizzi IPv6 È opportuno evidenziare tre principali fasi della transizione ad IPv6: Prima fase: tutte le reti principali, le dorsali e la maggior parte di router ed host implementano lo stack IPv4. Ci sono solo poche isole con connettività IPv6 Seconda fase: buona parte delle reti principali e delle dorsali hanno effettuato il passaggio al nuovo protocollo. La cartina geografica di Internet evidenzia un misto di aree dual-stack, IPv6-only ed IPv4-only Terza fase: siamo al termine della migrazione. Tutte le reti principali e le dorsali lavorano su stack IPv6. Restano solo poche isole con connettività IPv4 Date queste premesse, è lecito aspettarsi che si giungerà ad un momento nella storia di questa migrazione informatica in cui le dorsali IPv6 dovranno fornire connettività ad isole di reti IPv4 (fase 3). Allo scopo sarà necessario attivare il meccanismo di incapsulamento 4over6, capace di inserire i pacchetti versione 4 all interno di quelli versione 6 e di veicolarli attraverso segmenti di rete prettamente IPv6. Gli host IPv4-only che sono inframmezzati da un infrastruttura IPv6 non potranno comunicare direttamente fra loro ma solo attraverso l ausilio di server-router appositamente configurati. Questi server-router saranno di tipo dual-stack e dovranno soddisfare i seguenti requisiti: 53

54 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 Incapsulamento: dei pacchetti che gli host IPv4-only vogliono inviare all esterno. I datagrammi IPv4 saranno inseriti all interno di quelli IPv6. Il processo che inserisce i pacchetti di un protocollo all interno di un altro è anche riferito con il termine tunneling Instradamento: del pacchetto appena creato all interno della rete IPv6-only. Il datagramma IPv6 subirà il forwarding come fosse un normale datagramma IPv6 Decapsulamento: dei pacchetti in arrivo dall esterno, destinati agli host IPv4-only. Il pacchetto IPv6 contenitore viene scartato in modo da ottenere un semplice datagramma IPv4 Consegna: del datagramma IPv4 all host IPv4-only specificato nel campo Destination Address Si permetterà, in questo modo, a reti isolate IPv4-only di scambiare dati e fornire servizi reciprocamente sfruttando le risorse IPv6 disponibili. È possibile trasporre questa soluzione ad un livello più locale, contestualizzandola in ambito aziendale: il meccanismo 4over6 è necessario per connettere due filiali di una stessa organizzazione che operano su IPv4 attraverso un infrastruttura IPv6-only, magari perchè l acquisto di hardware e software nuovo e compatibile con IPv6 richiede sforzi eccessivi per questa ipotetica azienda. 54

55 4.3. FORWARDING DEI PACCHETTI 4OVER6 4.3 Forwarding dei pacchetti 4over6 In questa sezione si cercherà di chiarire al meglio come avvenga il processo di forwarding di un pacchetto. Si mostreranno le fasi che costituiscono la spedizione di un pacchetto, dalla sua creazione fino alla consegna all host destinatario. Il forwarding di un pacchetto IPv4 attraverso una dorsale IPv6 si compone di tre parti: incapsulamento, trasmissione del pacchetto incapsulato attraverso l infrastruttura IPv6 e decapsulamento. Un datagramma IPv4 viene generato dall host sorgente IPv4-only (Fig. 4.2): Figura 4.2: Datagramma IPv4 generato da un host IPv4-only Esso contiene come destinazione l indirizzo IPv4 dell host con cui vuole comunicare. Il campo Source Address contiene ovviamente l indirizzo dell host mittente. In seguito l end-point del tunnel, un server-router dual-stack, si occupa del tunneling o incapsulamento (Fig. 4.3): Figura 4.3: Datagramma IPv4 incapsulato Il pacchetto IPv6 appena creato contiene nel campo Source Address l indirizzo IPv6 del server-router mittente. Il campo Destination Address contiene l indirizzo IPv6 dell altro end-point del tunnel. Esso viene immesso all esterno e attraversa la rete Internet come fosse un normale datagramma IPv6. Quando il pacchetto raggiunge l altra estremità del tunnel, il server-router 55

56 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 dual-stack si occupa di estrarre il datagramma IPv4 e di inviarlo all host IPv4-only specificato nel Destination Address. 56

57 4.4. APPLICABILITÀ DEL TUNNELING 4OVER6 4.4 Applicabilità del tunneling 4over6 Il tunneling IPv4-over-IPv6 ha come intento la risoluzione del problema di interconnettere due reti agenti su protocollo IPv4 attraverso un infrastruttura IPv6-only. Un caso d uso, mettendosi nell ottica aziendale, potrebbe essere il seguente (vedi Fig 4.4): un azienda possiede due filiali con connettività IPv4, aventi necessità di scambiare dati e fornire servizi sviluppati esclusivamente per il vecchio protocollo TCP/IP. Figura 4.4: Architettura di rete 4over6 Un host della filiale A (Host A) vuole contattare un host della filiale B (Host B) ma tra le due filiali vi è un infrastruttura basata sul nuovo protocollo IPv6. La soluzione è il meccanismo 4over6, che consiste nell attivare un tunnel che incapsuli i pacchetti IPv4 provenienti dall Host A all interno di pacchetti IPv6, così che possano essere instradati nella rete IPv6. Essi, in seguito, raggiungono la filiale B, sono successivamente decapsulati ed inoltrati all Host B. Sia Router A (d ora in avanti RA) che Router B (RB) sono macchine che fungono da server-router dual stack, ovvero parlano sia il dialetto IPv4 che quello IPv6. RA gestisce una propria sottorete IPv4 a cui è connesso il calcolatore Host A (HA). RA inoltre comunica con RB tramite un interfaccia a cui è assegnato un indirizzo IPv6. RB ha una configurazione simmetrica: gestisce una propria sottorete IPv4 a cui è connesso HB e comunica con RA tramite un interfaccia cui è assegnato un indirizzo IPv6. L obiettivo è fare in modo che HA comunichi con HB. Per testare questo comportamento è sufficiente che HA riesca a pingare un qualsiasi indirizzo IPv4 di una sottorete che non sia la propria. 57

58 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 Infatti se il ping ha successo significa che il pacchetto originato da HA è stato incapsulato correttamente da RA, ha percorso la rete IPv6, è stato recapitato all altro end-point del tunnel, RB, che lo ha decapsulato ed inviato al destinatario specificato nel pacchetto IPv4. Come accennato in precedenza, il destinatario potrebbe essere un host in una sottorete gestita da RB, ma ai fini di verifica del funzionamento di tale scenario, basterà effettuare un ping verso uno dei server di Nel mio caso l indirizzo ha assunto, in definitiva, la funzione di host IPv4-only (HB). 4.5 Architettura di rete comune Durante lo stage è stata costruita un architettura di rete comune da cui si sono dipanate le tre proposte. Essa consiste in un server-router centrale di tipo dual-stack con 4 interfacce fisiche: eth0, eth1, eth2, eth3. Si è riusciti ad ottenere connettività IPv6 grazie all utilizzo del Tunnel Broker denominato Freenet6. Esso offre il servizio di tunneling di pacchetti IPv6 all interno della rete IPv4 (è in pratica uno dei meccanismi di transizione di cui si è parlato nella sezione 4.1). È stato richiesto un prefisso di rete lungo 56 bit, così sono rimasti 16 bit da gestire per le 3 sub-net (una sottorete per ogni proposta di stage). Figura 4.5: Architettura di rete comune alle tre proposte di stage Eth0 ci è servita per ottenere entrambe le connettività, grazie all ausilio del 58

59 4.6. ARCHITETTURA DI RETE 4OVER6 tunnel broker. Essa, quindi, possiede un indirizzo IPv6 che ci è stato fornito da Freenet6 ed un indirizzo IPv4 privato statico fornitoci dall azienda Miriade ( ). Ad eth1 sono stati assegnati un indirizzo IPv6 ed un indirizzo IPv4 statico. Questa interfaccia servirà per lo sviluppo della configurazione dual-stack. Ad eth2 è stato assegnato un indirizzo IPv4 statico e servirà per l implementazione della proposta di stage IPv6-over-IPv4. Ad eth3 è stato assegnato un indirizzo IPv6 statico e servirà per lo sviluppo della configurazione IPv4-over-IPv Architettura di rete 4over6 In questa sezione viene trattata l implementazione in locale dell architettura di rete descritta precedentemente in figura 4.4, nel senso che fisicamente Router A e Router B si trovano nella stessa stanza e non in due filiali differenti. I concetti e le configurazioni riportate, comunque, sono generali e valgono anche nel caso in cui i Router A e B siano in due sottoreti distinte. Router A (RA) è un server-router dual-stack ed appartiene logicamente alla sottorete privata IPv /24. Possiede due interfacce: eth1 ed eth2. Questo perchè dovrà con una comunicare con i propri host IPv4, con l altrà dovrà scambiare informazioni con Router B attraverso la rete IPv6. Ad eth1 è assegnato l indirizzo IPv6 unicast globale 2001:5c0:150a:1201::2/64, mentre ad eth2 è assegnato l indirizzo IPv4 statico privato RA avrà il compito di effettuare il tunneling dei pacchetti IPv4 in quelli IPv6. Lo schema degli indirizzi è riassunto in tabella 4.1. Router A eth1: 2001:5c0:150a:1201::2/64 eth2: /24 Tabella 4.1: Schema degli indirizzi di Router A Nella stessa sottorete di RA possono esserci più host, ma al fine di testare il funzionamento del tunnel è sufficiente configurarne solo uno, Host A (HA). Esso è un host IPv4-only e possiede un interfaccia fisica a cui è assegnato l indirizzo IP HA, essendo un host IPv4 isolato, non può comunicare con altri host IPv4 direttamente, ma deve servirsi di RA (vedi Tab.4.2). 59

60 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 Host A eth0: /24 Default gateway: /24 Tabella 4.2: Schema degli indirizzi di Host A Il server che farà la parte di Router B (RB) è quello descritto nella sezione precedente 4.6, ovvero il server-router dual-stack che è in comune alle tre proposte di stage. RB presenta l interfaccia eth0 cui è assegnato l indirizzo IPv6 unicast globale 2001:5c0:150a:1201::1/64. RB logicamente gestisce la sottorete privata /24. Router B eth0: 2001:5c0:150a:1201::1/64 eth2: /24 Tabella 4.3: Schema degli indirizzi di Router B Come Host B (HB) appartenente alla rete offerta da RB si è scelto di utilizzare l indirizzo IPv4 di google oppure dell interfaccia eth2 di RB (vedi Tab. 4.4). Ripetiamo che è sufficiente pingare uno di questi due indirizzi per verificare il funzionamento del tunnel. Infatti se il ping ha successo significa che il pacchetto originato da HA è stato incapsulato correttamente da RA, ha percorso la rete IPv6, è stato recapitato all altro end-point del tunnel, RB, che lo ha decapsulato ed inviato al destinatario specificato nel pacchetto IPv4. Host B IPv4 di eth2 di RB ( ) IPv4 di ( ) Tabella 4.4: Schema degli indirizzi di Host B Utilizzo di macchine virtuali L architettura descritta in Fig. 4.4 presuppone l utilizzo di macchine fisiche ma potrebbe essere utile, soprattutto quando si vuole effettuare una simulazione, utilizzare macchine virtuali. Nella realtà l architettura che è stata sviluppata ha fatto uso proprio di macchine virtuali, grazie al software VMWare Workstation. Sono riportati di 60

61 4.6. ARCHITETTURA DI RETE 4OVER6 seguito i passi per creare Router A (RA) e Host A (HA) virtuali. RA è una server-router virtuale con due interfacce di rete: la prima, presente già di default, è connessa alla macchina fisica in modalità bridged. Dopo aver avviato Ubuntu virtuale bisogna aprire il menù VM-Settings, cliccare su Network Adapter e spuntare le opzioni Bridged e Replicate physical network connection state. Questa interfaccia corrisponde a eth1 a cui assegneremo un indirizzo IPv6. Aggiungiamo la seconda interfaccia di rete al nostro server/router: VM- Settings, clicchiamo su Add e selezioniamo Network Adapter. Clicchiamo sulla nuova interfaccia Network Adapter 2 e scegliamo dal menù a tendina Custom una delle reti virtuali proposte (ad esempio: VMnet2 ). Questa interfaccia corrisponde a eth2 a cui assegneremo un indirizzo IPv4 e a cui collegheremo i vari host virtuali. HA è un host virtuale con sistema operativo Windows 7 collegato alla VMnet2 con un unica interfaccia. Da VM-Settings bisogna cliccare su Network Adapter e selezionare dal menù a tendina Custom la stessa rete virtuale scelta per RA, nel nostro caso VMnet Configurazione di Router A RA monta il sistema operativo Ubuntu Server con kernel aggiornato alla versione Non è possibile utilizzare versioni del kernel precedenti, in quanto non prevedono il modulo capace di creare il tunnel che ci serve. Come prima cosa, essendo questa macchina anche un router, dobbiamo abilitare il forwarding IPv4 ed IPv6, modificando il file /etc/sysctl.conf e decommentando queste righe: #Abilita il forwarding IPv4 net.ipv4.ip_forward=1 #Abilita il forwarding IPv6 net.ipv6.conf.all.forwarding=1 Successivamente assegniamo ad un interfaccia un indirizzo IPv4 statico. In questo caso l interfaccia è eth2 a cui assegniamo l indirizzo con maschera di rete Attribuiamo in seguito ad un altra interfaccia di rete un indirizzo statico IPv6: nel mio caso eth1 con indirizzo 2001:5c0:150a:1201::2 che sarà quella con connettività only-6 ed anche uno degli estremi del tunnel. 61

62 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 Apriamo il file in /etc/network/interfaces e scriviamo quanto segue: auto lo eth1 eth2 iface lo inet loopback #configurazione ipv6 statico eth1 iface eth1 inet6 static address 2001:5c0:150a:1201::2 netmask 64 gateway 2001:5c0:150a:1201::1 #configurazione ipv4 statico eth2 iface eth2 inet static address netmask broadcast #gateway Da notare che non deve essere specificato il default gateway. Tutto il traffico IPv4 deve essere dirottato verso l interfaccia virtuale che creeremo a breve. Controlliamo che gli indirizzi siano quelli voluti tramite il comando ifconfig -a Nel caso le interfacce presentino altri indirizzi oltre a quelli richiesti, perchè assegnati dal DHCP o perchè settati manualmente in precedenza, è necessario rimuoverli tramite uno di questi comandi: dhclient -r & dhclient ifdown & ifup Riavviamo la network al fine di assegnare i parametri appena specificati alle interfacce: /etc/init.d/networking restart Creiamo ora l interfaccia virtuale che riesca ad incapsulare i pacchetti IPv4 provenienti dalla rete privata di RA in pacchetti IPv6. Il tunnel (vedi Fig. 4.6) ha due estremità, chiamate end-point, una locale che corrisponde all interfaccia connessa al mondo IPv6 (nel caso di RA è eth1 ) ed una remota che verrà configurata in RB. Digitiamo quindi da shell: 62

63 4.6. ARCHITETTURA DI RETE 4OVER6 Figura 4.6: Tunnel dal punto di vista di Router A modprobe ip6_tunnel ip -6 tunnel add tun2 mode ipip6 remote 2001:5c0:150a:1201::1 local 2001:5c0:150a:1201::2 Ed attiviamo l interfaccia appena creata tun2: ip link set dev tun2 up Impostiamo la route verso la sottorete /24: ip route add /24 dev eth2 Il passaggio cruciale è quello di indirizzare tutti i pacchetti IPv4 verso il tunnel, in modo che subiscano l incapsulamento. E necessario agire sulle tabelle di routing v4: ip route add default dev tun2 Se non già presenti, aggiungiamo anche le route verso l interfaccia v6 e quella di default: ip -6 route add 2001:5c0:150a:1201::/64 dev eth1 ip -6 route add default via 2001:5c0:150a:1201::2 dev eth1 Tipicamente in un server-router è presente anche il servizio di DHCP, in modo tale che un qualsiasi host connesso ad una determinata sottorete ottenga automaticamente un indirizzo IP e gli altri parametri di configurazione utili alla navigazione Internet. Sebbene il fine di questo studio non sia il protocollo DHCP, esso è stato configurato ed attivato correttamente al solo fine di 63

64 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 simulare uno scenario corrispondente alla realtà aziendale. Su Ubuntu per ottenere questo servizio si deve scaricare il pacchetto dhcp3-server. E necessario che il DHCP sia pubblicato su una determinata interfaccia (nel nostro caso è eth2 ), azione che è possibile effettuare modificando il file al percorso /etc/default/ dhcp3-server: INTERFACES="eth2" Nel file di configurazione dobbiamo specificare un range di indirizzi entro cui scegliere l IP che verrà offerto ad un client che si connette; il nome di dominio, l indirizzo dei server DNS, il tempo di validità di quel determinato IP, ecc. Modifichiamo il file di configurazione che troviamo al percorso /etc/dhcpd.conf : ddns-update-style none; option domain-name "miriade.it"; option domain-name-servers , ; option subnet-mask ; option broadcast-address ; option routers ; default-lease-time 600; max-lease-time 7200; subnet netmask { range ; } log-facility local 7; È preferibile che HA abbia un indirizzo IP statico, in modo da facilitare la fase di verifica, dal momento che sarà possibile individuarlo univocamente sempre con lo stesso indirizzo IP. Nel prossimo paragrafo configureremo HA in tal senso Configurazione di Host A È stata adoperata una macchina con sistema operativo Windows 7, ma si potrebbe installarne uno qualsiasi che supporti il vecchio protocollo TCP/IP. L importante è assicurarsi che questa macchina lavori solamente su stack IPv4, per cui è necessario disabilitare il protocollo IPv6 dalle proprietà di rete. HA appartiene alla subnet , è collegato direttamente all interfaccia 64

65 4.6. ARCHITETTURA DI RETE 4OVER6 eth2 di RA, che è il suo default gateway, ed utilizza il server DNS di Miriade S.p.a. L host può essere configurato manualmente, impostando i parametri come mostrato all inizio di questo capitolo in tabella 4.2. In Windows 7: Centro connessioni di rete-modifica impostazioni scheda, click destro su Connessione alla rete locale (LAN) e selezioniamo la voce Proprietà. Scegliere il protocollo TCP/IP versione 4 ed impostare manualmente gli indirizzi. Nel caso in cui sia attivo il servizio DHCP su RA, impostare la configurazione automatica dell indirizzo. Cosa testare a questo punto? Per controllare che la sottorete /24 funzioni, da HA pingare RA e viceversa Se si effettua il ping verso (l indirizzo del server DNS di Miriade, o comunque un qualsiasi indirizzo di un altra rete) non dovrebbe avere successo, in questo momento. L altro endpoint del tunnel, infatti, non è stato ancora attivato Da Router A sniffiamo i pacchetti su eth1 con il comando tcpdump -i eth1 Se da HA proviamo a pingare un qualsiasi indirizzo ipv4 dovremmo vedere grazie a tcpdump i pacchetti incapsulati che hanno la seguente sintassi: IP6 indirizzoserverlocale > indirizzoserverremoto IP indirizzoha > indirizzohb Configurazione di Router B La configurazione di RB è perfettamente simmetrica a quella di RA. RB ha un interfaccia con connettività IPv6, eth0 : iface eth0 inet6 static address 2001:5c0:150a:1201::1 netmask 64 eth2 invece è connessa alla rete privata Miriade /24 ed ha l indirizzo Per attivare il tunnel: 65

66 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 modprobe ip6_tunnel ip -6 tunnel add tun1 mode ipip6 remote 2001:5c0:150a:1201::2 local 2001:5c0:150a:1201::1 Ed attiviamo l interfaccia appena creata tun1 : ip link set dev tun1 up Il passaggio più importante è quello di indirizzare tutti i pacchetti diretti verso la sottorete /24 verso il tunnel tun1, in modo che subiscano il tunneling. E necessario agire sulle tabelle di routing v4: ip route add /24 dev tun1 Se non già presenti, aggiungiamo anche le routes verso l interfaccia v6 e quella di default: ip -6 route add 2001:5c0:150a:1201::/64 dev eth0 ip -6 route add default via 2001:5c0:150a:1201::2 dev eth0 L unica cosa diversa e fondamentale per permettere ad HA di navigare è il concetto di NAT Postrouting. Poichè i pacchetti che arrivano da HA hanno come indirizzo sorgente il , quando il pacchetto arriva a RB viene ridirezionato al proprio default gateway il quale, però, non conosce la sottorete Il default gateway quindi non saprebbe dove instradare, ad esempio, il reply di un ping iniziato da HA. Quindi, poco prima che il pacchetto arrivato a RB venga inviato all esterno da eth2, è necessario cambiargli l indirizzo sorgente con quello di eth2 stessa. iptables -t nat -A POSTROUTING -s / o eth2 -j SNAT --to-source Cosa testare una volta giunti a questa configurazione? Per prima cosa dobbiamo sincerarci che i due end-point del tunnel riescano a comunicare tra di loro. Verificare che RB riesca a raggiungere RA: da una shell di RB digitiamo quindi il comando 66

67 4.6. ARCHITETTURA DI RETE 4OVER6 ping6 2001:5c0:150a:1201::2 Dobbiamo verificare anche la comunicazione in senso opposto, cioè se RA riesce a pingare RB. Digitiamo quindi da una shell di RA il comando ping6 2001:5c0:150a:1201::1 Il tunnel dovrebbe essere stato attivato correttamente, permettendo ad Host A di contattare Host B attraversando l infrastruttura IPv Test conclusivi Se tutto è stato configurato in modo corretto, il ping da HA verso ha successo: ping Esecuzione di Ping [ ] con 32 byte di dati: Risposta da : byte=32 durata=37ms TTL=52 Risposta da : byte=32 durata=48ms TTL=52 Risposta da : byte=32 durata=37ms TTL=52 Risposta da : byte=32 durata=44ms TTL=52 Statistiche Ping per : Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi: Minimo = 37ms, Massimo = 48ms, Medio = 41ms Come ulteriore prova del perfetto funzionamento del nostro scenario, da HA proviamo ad accedere ad un qualsiasi servizio IPv4 (per esempio il protocollo Secure SHell) che non si trovi sulla nostra sottorete. SSH è un protocollo che permette di stabilire una connessione sicura con un server remoto di cui si utilizza un interfaccia a linea di comando (la shell, appunto). In altri termini, SSH permette di connettersi e di utilizzare un PC in remoto, impartendogli i comandi tramite shell (il tutto avviene utilizzando la crittografia). SSH è, per i vantaggi appena espressi, utilizzato per l amministrazione remota di sistemi unix. Allo scopo di testare questo servizio IPv4 è stato installato un server SSH su di una macchina connessa alla sottorete di RB rispondente all indirizzo In HB, con sistema operativo Ubuntu 10.04, bisogna scaricare ed installare 67

68 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 il pacchetto openssh-server. Non sono rischieste altre operazioni. Se HA è un client Windows 7 installiamo il software PuTTY ed inseriamo l indirizzo di HB. Se, invece, è un client Linux digitiamo da shell: ssh ed inseriamo le credenziali di accesso che ci verranno richieste. Il protocollo SSH funziona correttamente con la tecnica di incapsulamento 4over6. Gli host continuano a funzionare in modo trasparente, cioè come se non ci fosse stato alcun cambiamento alla rete. Sono stati testati, inoltre, la navigazione tramite browser, il download di un file da un sito di hosting, il protocollo FTP, ecc. tutti funzionanti in modo trasparente per il client. 68

69 4.7. FIREWALL 4.7 Firewall In questa sezione sarà chiarito come gestire il firewall nello scenario di rete sviluppato. La regola aurea del firewalling è applicare il firewall sull elemento più esposto di una rete. Nella configurazione 4over6 fin qui descritta ci sono due importanti elementi su cui eseguire firewalling: Router A e Router B. Figura 4.7: Firewall sul server-router dual-stack RA (oppure RB) sono dei server-router dual-stack che comunicano con la rete IPv6 attraverso un interfaccia che possiede un indirizzo IPv6 globale e, contemporaneamente, gestiscono una rete privata IPv4 a cui sono collegati svariati host. Poichè siamo in un contesto in cui IPv6 si è enormemente diffuso e quasi la totalità delle aree sono passate al nuovo protocollo, appare evidente che, al fine di evitare attacchi dall esterno, è necessario impostare delle regole di firewall che agiscano su IPv6, tramite il software ip6tables. Il server-router gestisce una rete IPv4 i cui indirizzi non sono visibili all esterno: questo, in teoria, comporta un livello di protezione maggiore (ma non totale!) per gli host IPv4. Inoltre, a causa della natura stessa di un server-router dual-stack, potrebbero esserci alcuni casi in cui esso disponga anche di un indirizzo IPv4 pubblico. In questo caso è necessario impostare un firewall apposito, sempre al fine di evitare attacchi esterni, provenienti, questa volta, dal mondo IPv4. In definitiva, sia che il server-router abbia un indirizzo IPv4 privato o pubbli- 69

70 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 co, allo scopo di rendere sicura una rete, è consigliabile applicare delle regole di firewall tanto per lo stack IPv4 che per quello IPv6. I programmi da utilizzare sono iptables e ip6tables. Nella pratica le regole riportate di seguito sono state impostate sulle interfacce del server-router dual-stack ampiamente descritto nella sezione 4.5, ma in questo paragrafo sarà descritto un firewall il più generale possibile in modo che esso possa essere applicato in qualsiasi contesto. Nel caso della configurazione 4over6 esso andrà applicato sui server-router dual-stack Router A e Router B. Riferendoci ad eth0 con il nome dell interfaccia dotata di un indirizzo IPv4, su di essa imposteremo le regole di firewalling per IPv4 mentre su eth1, l interfaccia dotata di indirizzo IPv6 globale, applicheremo quelle per IPv6. L intento è quello di bloccare qualsiasi tentativo di connessione non richiesto dall esterno verso l interno e permettere, invece, l uso dei protocolli ICMP, SSH, HTTP, HTTPS, DNS e FTP. Sull interfaccia eth1 utilizziamo il comando ip6tables. Come asserisce il nome stesso, è la nuova versione del firewall-software che lavora su stack IPv6. L unica cosa in cui porre attenzione è il fatto che in alcuni casi, rispetto alla precedente versione, cambia leggermente la sintassi dei comandi. #Accetta qualsiasi connessione in local loop ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT #Accetta le connessioni già stabilite o "figlie" #di una connessione già conosciuta ip6tables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT #Accetta verso l esterno anche le connessioni nuove ip6tables -A OUTPUT -o eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT #Accetta in input pacchetti ICMPv6 ip6tables -A INPUT -i eth1 -p icmpv6 -j ACCEPT #Accetta in input connessioni SSH ip6tables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT #Accetta in input connessioni HTTPS 70

71 4.7. FIREWALL ip6tables -A INPUT -i eth1 -p tcp --dport 443 -j ACCEPT #Accetta in input connessioni HTTP ip6tables -A INPUT -i eth1 -p tcp --dport 80 -j ACCEPT #Accetta in input connessioni dai server DNS ip6tables -A INPUT -i eth1 -p udp --dport 53 -j ACCEPT #Accetta in input connessioni FTP ip6tables -A INPUT -i eth1 -p tcp --dport 21 -j ACCEPT #Setta la policy dei pacchetti a drop ip6tables -P INPUT DROP Le regole utilizzate su eth0 sono simmetriche: #Accetta qualsiasi connessione in local loop iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Accetta le connessioni già stabilite o "figlie" #di una connessione già conosciuta iptables -A INPUT -i eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT #Accetta verso l esterno anche le connessioni nuove iptables -A OUTPUT -o eth0 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT #Accetta in input pacchetti ICMP iptables -A INPUT -i eth0 -p icmp -j ACCEPT #Accetta in input connessioni SSH iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT #Accetta in input connessioni HTTPS iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT #Accetta in input connessioni HTTP iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT #Accetta in input connessioni dai server DNS 71

72 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT #Accetta in input connessioni FTP iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT #Setta la policy dei pacchetti in input a DROP iptables -P INPUT DROP 4.8 Vantaggi 4over6 È stato svolto un analisi sulle possibilità offerte dalla configurazione 4over6. Sono riportati, nel seguente elenco, i pregi che sono stati evidenziati: Semplicità di attivazione del tunnel: l attivazione del tunnel è molto semplice in quanto richiede solo tre comandi e la conoscenza di soli due indirizzi IPv6 (end-point locale ed end-point remoto) Trasparenza: è sufficiente apportare modifiche solo alle configurazioni del server-router più esterno della rete IPv4-only: host, server DNS e le altre entità di rete non richiedono software aggiuntivo o modifiche DNS: uno degli elementi del networking che non ha sollevato problematiche di alcun tipo in questo scenario è stato il DNS. Non è richiesta l implementazione di un DNSv6 ed è stato possibile sfruttare un server già presente nell infrastruttura di rete aziendale Sicurezza: questo vantaggio è un effetto collaterale del Network Address Translation. Grazie all uso del NAT una rete privata continuerà ad essere tale e quindi i propri host non saranno raggiungibili dall esterno (sono mascherati da un unico indirizzo IP pubblico visibile) Uso del tunnel in locale: il meccanismo di tunneling 4over6 può essere utilizzato in qualsiasi contesto che abbia delle zone IPv4 inframmezzate da un infrastruttura IPv6. Il tunnel potrebbe essere quindi utilizzato sia per connettere due filiali di un azienda distanti fra loro, sia potrebbe trovarsi all interno dell azienda stessa Utilizzo della rete IPv6 esistente: verso la fase finale della transizione esisteranno ancora piccole aree IPv4. Ciò implica che un ISP ha assegnato loro un indirizzo IPv4 raggiungibile dall esterno. Queste aree possono già comunicare tra loro sfruttando le routes IPv4 che ancora permangono. Non è possibile prevedere con certezza come sarà 72

73 4.9. SVANTAGGI 4OVER6 strutturata la rete Internet in futuro, ma proviamo a fare un ipotesi: nel caso in cui il 90% delle dorsali e dei segmenti di rete diventino IPv6-only ed il restante 10% sia costituito da segmenti dual-stack, le isole IPv4 di cui sopra potranno utilizzare solo quel 10% di reti per raggiungersi, probabilmente utilizzando percorsi non ottimi. Grazie al meccanismo 4over6, invece, avranno a disposizione il 100% delle routes Economicità: per alcune aziende potrebbe essere un costo oneroso effettuare il passaggio ad IPv6, perchè questo potrebbe richiedere l acquisto di hardware e software compatibile con IPv6. La soluzione di tunneling 4over6 permette di continuare ad utilizzare le proprie reti IPv4 in modo semplice ed economico 4.9 Svantaggi 4over6 La configurazione 4over6 implementata e testata evidenzia anche alcuni difetti o elementi di difficile gestione: Complessità routing: la gestione delle tabelle di routing è complessa Network Address Translation: a causa del NAT è necessario specificare nella tabella di iptables una regola nella catena di POSTROUTING per mascherare il pacchetto in uscita con l indirizzo del server-router Kernel Linux aggiornato: per la creazione del tunnel sono necessari sistemi operativi Linux con kernel successivi al Altri svantaggi dovuti al NAT: rete meno performante, complessità nella gestione di determinati protocolli (FTP, IPSec) 4.10 Compatibilità sistemi operativi Nell implementare la configurazione 4over6 non tutti i sistemi operativi sono utilizzabili. Il server-router dual-stack (come RA o RB descritti in 4.6) deve montare sistemi operativi Linux con Kernel successivo al In corso d opera era stato, purtroppo, implementato lo scenario con un server-router avente il sistema operativo centos che si è rivelato inutilizzabile perchè mancavano i moduli per il tunnel IPv4-over-IPv6 (il kernel di centos verrà aggiornato solo con la versione 6.0)! A parte questo, non ci sono stati altri problemi di incompatibilità. 73

74 CAPITOLO 4. MECCANISMO DI TUNNELING IPV4-OVER-IPV6 Per quanto riguarda la compatibilità dei sistemi operativi con gli stack IPv4 ed IPv6, non esistono particolari problemi se non per Windows XP: se con entrambi gli stack attivi funziona in modo soddisfacente, lavorare solo su stack IPv6 è impossibile. Inoltre è necessario utilizzare software di terze parti (Dibbler) per ottenere le funzionalità di DHCP. Ubuntu 9.10 presenta una situazione piuttosto simile: solo in modalità dualstack è perfettamente funzionante ed anch esso non integra le funzionalità di client DHCP. Windows 7 e Mac OS X si sono dimostrati essere i migliori dal punto di vista della compatibilità con IPv6: lavorano egregiamente in tutte le modalità (IPv4-only, dual-stack, IPv6-only) e non abbisognano di software esterno. 74

75 Capitolo 5 Quality of Service Gli argomenti di questo capitolo saranno la Quality of Service sia in IPv4 che in IPv6. Dopo un introduzione sui parametri di cui tenere conto per fornire qualità ad una rete (sez 5.1), saranno descritti in dettaglio i campi Type of Service (sezione 5.2.1) ed il corrispondente Traffic Class del nuovo protocollo (sez ). In sezione verrà descritto il nuovo campo Flow Label. In sezione 5.4 vengono, inoltre, riportati i test effettuati sulla QoS IPv6. Il capitolo si conclude con alcune considerazioni circa i test svolti. 5.1 Introduzione Con il termine QoS (dall inglese Quality of Service) ci si riferisce a quell insieme di requisiti che devono essere rispettati da una rete nel trasporto di un flusso. I parametri che influiscono sulla qualità del servizio in una rete a pacchetto sono: Throughput (Bandwidth): è il bit-rate (il massimo volume di output) che può essere fornito ad un certo flusso di dati Dropped packets: quando un pacchetto arriva ad un router il cui buffer è pieno, esso viene scartato e non giunge a destinazione. La perdita di un pacchetto viene gestita in modi diversi dai protocolli di trasporto: in un protocollo senza riscontro come UDP si avrebbe la mancata trasmissione dell informazione; in un protocollo con riscontro come TCP il ricevente, dopo aver atteso un tempo prestabilito, deve chiedere che l informazione venga ritrasmessa, causando anche gravi ritardi (delay) nella trasmissione 75

76 CAPITOLO 5. QUALITY OF SERVICE Delay (Latency): la latenza è il tempo che intercorre tra l istante in cui viene inviato un pacchetto e l istante in cui arriva a destinazione. Le cause di una connessione con elevata latenza sono principalmente due: i router devono gestire code di pacchetti eccessivamente lunghe oppure i pacchetti vengono instradati in routes subottimali, magari per evitare tratti congestionati. In alcuni casi un delay eccessivo può rendere applicazioni come VoIP o online-gaming inutilizzabili. Il delay può essere suddiviso in due componenti: quella fissa riguarda il tempo di codifica e decodifica dei segnali ed il tempo che essi impiegano ad attraversare il media elettrico od ottico per giungere a destinazione. La QoS non può influire sui ritardi fissi, in quanto essi dipendono meramente dalle proprietà del mezzo fisico attraverso cui passano i pacchetti e dall hardware utilizzato per la codifica e la decodifica; la componente variabile concerne la congestione in uno specifico momento degli apparati di rete e la gestione delle code (queuing-delay). QoS agisce su questa componente Jitter: è la variazione del ritardo tra pacchetti inviati in sequenza da un nodo ad un altro. Può affliggere gravemente la qualità di streaming audio o video. Per compensare il jitter gli apparati di rete utilizzano dei buffer atti ad accumulare i pacchetti in arrivo con ritardi differenti e, in seguito, ad uniformarne il delay. Nel caso in cui il ritardo tra pacchetti sia eccessivo, il buffer si svuota e va in una condizione detta jitterbuffer-underrun causando l interruzione, ad esempio, di uno streaming video fino a quando non arrivino ulteriori pacchetti. Al contrario, se il delay tra un pacchetto e il successivo è eccessivamente basso, il router potrebbe trovarsi nella condizione di jitter-buffer-overrun ed essere incapace di processare nuovi pacchetti in quanto la coda è piena. Anche in questo caso l applicazione video ne risentirà e salterà alcuni frame Out-of-order delivery: su alcune reti è possibile che una sequenza di pacchetti inviati da un nodo ad un altro venga consegnata in un ordine diverso da quello originale. Ciò accade tipicamente perché i pacchetti vengono instradati su percorsi diversi. Questo problema richiede che i protocolli di trasporto riordino i pacchetti una volta che sono giunti a destinazione, e comporta ulteriori ritardi nella ricostruzione del flusso di dati a livello applicativo Error: un pacchetto può essere consegnato a destinazione, ma non essere identico a quello inviato. Molte reti riconoscono la gran parte degli errori di trasmissione, e alcune sono anche in grado di correggerli. Normalmente i protocolli di trasporto riconoscono un pacchetto errato 76

77 5.2. QOS IN IPV4 e ne richiedono la ritrasmissione come se questo fosse stato perso, ma è anche possibile che l errore raggiunga l applicazione finale. La causa di un errore può essere il mezzo fisico È possibile ottenere qualità in una rete tramite due tecniche: tagging e shaping. La prima consiste nel marcare i pacchetti con simboli differenti per far si che vengano processati secondo priorità prestabilite. Il secondo metodo consiste nell affettare la banda disponibile e distribuirla in base alle necessità della rete (ad esempio, per garantire maggiore banda al traffico voce). 5.2 QoS in IPv4 Nell header IPv4 è presente un unico campo dedicato alla QoS: il Type of Service. Esso è descritto nel paragrafo successivo Type of Service In origine (RFC 791[6]) gli 8 bits del campo Type of Service (ToS) dell header IPv4 erano divisi come in Fig.5.1. Teniamo presente fin da subito che esso è stato ridefinito ed attualmente assume la stessa formattazione e funzione del campo Traffic Class di IPv6: Figura 5.1: Campo Type of Service dell header IPv4 Precedence: i primi 3 bit identificano la priorità del datagramma. La priorità di default è zero, la priorità massima è 7 Delay (D): se impostato ad 1 il pacchetto richiede bassa latenza Throughput (T): se impostato ad 1 il pacchetto richiede throughput elevato. Il throughput è il massimo volume di output che può essere fornito ad un certo flusso di dati Reliability (R): se impostato ad 1 il pacchetto richiede affidabilità elevata. Per affidabilità si intende la sicurezza che il pacchetto arrivi a destinazione e che non venga perso. 77

78 CAPITOLO 5. QUALITY OF SERVICE Riservati: gli ultimi due bit erano riservati ad usi futuri. Attualmente sono utilizzati come Explicit Congestion Notification (ECN), protocollo descritto in RFC 3168[5] Il campo Type of Service (ToS) dell header IPv4 ha assunto diversi scopi con il passare del tempo ed è stato definito da 5 RFC (RFC 791[6], RFC 1122[8], RFC 1349[1], RFC 2474[4] ed RFC 3168[5]). L attuale definizione degli 8 bit di ToS è descritta in RFC 2474 (e corrisponde al campo Traffic Class dell header IPv6): i primi 6 bit rappresentano il Differentiated Services Code Point (DSCP), mentre i successivi 2 bit formano il campo Explicit Congestion Notification (ECN). DSCP, quindi, rimpiazza il precedente campo Precedence, pur rimanendo retrocompatibile (i valori che si inserivano nel campo Precedence sono rimasti uguali anche in DSCP). Verrà descritto in dettaglio nella sezione QoS in IPv6 Nell header IPv6 sono presenti due campi dedicati alla QoS: Traffic Class e Flow Label. Il primo viene trattato in sezione 5.3.1, mentre il secondo è descritto in Traffic Class Il Traffic Class in IPv6 è utilizzabile per distinguere tra differenti classi o priorità dei pacchetti IPv6 ed è formato dai campi (vedere Fig. 5.2): Figura 5.2: Campo Traffic Class dell header IPv6 Differentiated Services Code Point (DSCP): un campo di 6 bit usato per classificare i pacchetti. In una rete è possibile classificare i datagrammi in 64 classi (2 6 ) diverse. Ad ogni classe corrisponde un preciso Per-Hop Beahviour (PHB), il comportamento che i router dovranno intraprendere per garantire diverse qualità di servizio Explicit Congestion Notification (ECN): è un estensione opzionale definita in RFC 3168[5]. Permette, in connessioni end-to-end, di fornire notifiche in caso di rete congestionata senza scartare pacchetti 78

79 5.3. QOS IN IPV6 Da notare che il Traffic Class (IPv6) e i valori in esso specificati corrispondono perfettamente a quelli di ToS (IPv4). Nonostante i PHB (le politiche che i router dovranno applicare) non siano standardizzati, nella pratica sono utilizzati i seguenti: Expedited Forwarding (EF): assicura bassa perdita dei pacchetti e bassa latenza. Viene realizzato tramite gestione delle code con svariati metodi (priorità semplice, weighted round robin, coda basata sulla tipologia di classe, ecc.) Assured Forwarding (AF): corrisponde al concetto di affidabilità, assicura la consegna dei pacchetti sotto determinate condizioni Class Selector: sono PHB definiti per mantenere la retrocompatibilità con il vecchio campo Precedence Flow Label Prima di scoprire i vantaggi introdotti dal nuovo campo Flow Label, definiamo cosa sia un flusso. Un flusso è una sequenza di pacchetti inviati da una sorgente ad una destinazione riconosciuto dalla quintupla: 1. Source Address 2. Destination Address 3. Source Port 4. Destination Port 5. Transport Protocol Tra i tanti miglioramenti apportati ad IPv6, l IETF ha cercato una soluzione per velocizzare il riconoscimento di un flusso. A causa del processo di frammentazione o della crittografia, alcune delle informazioni appena elencate non sono sempre disponibili. Posizionarle in header opzionali non sarebbe stato efficiente perchè avrebbe inutilmente appesantito il pacchetto ed allungato i tempi di parsing dei router. Questi motivi hanno portato al concepimento del nuovo campo Flow Label, grazie al quale è possibile individuare un flusso di dati dalla tripla: 1. Source Address 79

80 CAPITOLO 5. QUALITY OF SERVICE 2. Destination Address 3. Flow Label Il Flow Label è un campo di 20 bit che può essere usato da un mittente per etichettare sequenze di pacchetti per cui viene richiesto un trattamento particolare dai router. Tutti i pacchetti che appartengono allo stesso flusso devono contenere lo stesso Flow Label (generato randomicamente) e, se presenti, anche gli Hop-by-Hop Extension Header e Routing Header devono essere uguali. Se un pacchetto possiede un Flow Label con tutti i bit a zero significa che esso non appartiene ad alcun flusso. Anche se l host mittente non richiede un servizio speciale, un router potrebbe riconoscere un cospicuo scambio di dati tra due end-point ed usare questa etichetta per determinare un instradamento che agevoli la connessione (per esempio, al fine di ottenere delay minore o maggiore banda). Il vantaggio chiave è che i router attraverso cui passa un flusso non sono costretti ad analizzare l interno dei pacchetti per identificare il flusso stesso. Come detto in precedenza, un flusso solitamente era identificato dalla combinazione di indirizzo sorgente, indirizzo destinatario, porta sorgente, porta destinazione e tipo di trasporto. Per conoscere le porte un router deve ispezionare l header del protocollo di trasporto usato da un pacchetto, cioè dovrebbe analizzare tutti gli Extension Header fino ad arrivare all header TCP o UDP: questo processo è del tutto inefficiente. Marcare, invece, nel modo appropriato il Flow Label di un datagramma permette ad un router di processare solo l header. Nonostante questo campo sia ancora in fase sperimentale è lecito aspettarsi che esso diverrà utile per fornire una QoS a grana ancora più fine rispetto a quella IPv4 per applicazioni come Voice over IP (VoIP), streaming audio e video, online-gaming o, in generale, in qualsiasi applicazione in tempo reale. 80

81 5.4. SHAPING IN IPV6 5.4 Shaping in IPv6 Sono riportati in questa sezione alcuni test sulla QoS che si basano sul traffic shaping, cioè quella tecnica basata sul ripartire la banda disponibile tra le diverse tipologie di traffico. Si è deciso di effettuare solo test di shaping poichè le ore rimanenti non consentivano di analizzare in modo completo questo capitolo, che da solo avrebbe probabilmente richiesto un intero stage. Si è escluso di effettuare test basati anche sul tagging, cioè fare QoS a seconda dei valori inseriti in Traffic Class. Questo poichè il controllo sui pacchetti marchiati viene effettuato solo da router appositamente istruiti e con molta probabilità i router esterni alle mura aziendali non effettuano alcun tipo di controllo sulla QoS. Si sarebbe potuto creare uno scenario di testing in locale, ma avrebbe richiesto sforzi in termini di hardware e tempo non disponibili. I software utilizzati in questi esperimenti sono stati Iperf e Traffic Control. Come generatore di datagrammi è stato usato il programma Iperf il quale permette di configurare svariati parametri sia per TCP che per UDP e di tenere traccia della bandwidth, delay, jitter e perdita di pacchetti. Questo software si basa su un architettura di tipo client-server: il client forgia la quantità di pacchetti specificata dall utente. Il server li cattura e calcola le statistiche su bandwidth, delay, ecc. Traffic Control è uno strumento in grado di filtrare le diverse tipologie di datagrammi. Ogni pacchetto filtrato può essere convogliato in code o classi opportunamente definite in termini di data-rate massimo, priorità, ecc. 81

82 CAPITOLO 5. QUALITY OF SERVICE Limitare il traffico IPv6 Il primo test è stato quello di limitare il traffico IPv6: generiamo da un client pacchetti IPv6 su protocollo TCP e limitiamo il throughput ad un volume massimo di 500 Kb/sec. Avviamo il programma nel lato server: iperf -s -P 0 -i 1 -p V -f k Avviamo il programma nel lato client: iperf -c 2001:5c0:150a:5e0f::1 -P 1 -i 1 -p V -f k -t 10 -T 1 In questo modo vengono inviati per 10 secondi dei pacchetti IPv6 su protocollo di trasporto TCP sulla porta Si ricorda che, non disponendo di una linea nativa IPv6, si è utilizzato il servizio di tunnel broker fornito da Freenet6. Quindi le regole sono state impostate sull interfaccia virtuale tun, per la quale passano i pacchetti IPv6. Creiamo una queue discipline (qdisc) radice, ovvero una coda basata sulla classe (Class Based Queue) e specifichiamo quali proprietà debba avere in termini di bandwidth, numero medio di pacchetti, Minimum Packet Unit (MPU): tc qdisc add dev tun handle 1: root cbq bandwidth 100Mbit avpkt 1000 mpu 64 tc class add dev tun parent 1: classid 1:1 cbq bandwidth 500Kbit avpkt 1000 prio 1 rate 500Kbit maxburst 10 bounded isolated tc filter add dev tun protocol ipv6 parent 1: prio 1 handle 1 fw classid 1:1 Marchiamo con il simbolo 1 il traffico IPv6 uscente da tun: ip6tables -A OUTPUT -o tun -j MARK --set-mark 1 È anche possibile filtrare solo i pacchetti diretti verso un particolare indirizzo: tc filter add dev tun parent 1:0 protocol ipv6 prio 1 u32 match ip6 dst 2001:5c0:150a:5e0f::1 flowid 1:1 Prima di applicare questi filtri il traffico generato dal client raggiungeva i 1500 Kb/s Kb/s circa (Fig. 5.3). 82

83 5.4. SHAPING IN IPV6 Figura 5.3: Banda disponibile senza filtri Dopo aver applicato le regole, il client mostra un sensibile calo di banda. Il grafico mostra dei picchi di 700 Kb/s che in teoria non dovrebbero essere possibili, in quanto si è limitata la banda a 500 Kb/s. Probabilmente è un imprecisione di Iperf stesso, che comunque in media mostra una banda intorno ai 500 Kb/s (Fig. 5.4) Per essere certi che il filtro funzioni correttamente, Figura 5.4: Banda disponibile dopo aver attivato i filtri controlliamo le statistiche calcolate dal server: si nota che effettivamente il bit-rate non supera mai i 500 Kb/s. In figura (Fig. 5.5) si può notare il 83

84 CAPITOLO 5. QUALITY OF SERVICE confronto tra il bit-rate con filtri attivi (477 Kb/s) e senza (1252 Kb/s). Figura 5.5: Lato server: senza filtri (1252 Kb/s) e con filtri (477 Kb/s) È possibile accertare che i pacchetti vengano catturati dal filtro e che entrino nella coda da noi creata con questo comando: watch /sbin/tc -s -d class show dev tun 84

85 5.4. SHAPING IN IPV Limitare traffico HTTP Assegniamo ad HTTP una banda massima di 500 Kb/s. Se avessimo una linea IPv6 nativa basterebbero i seguenti comandi: tc qdisc add dev eth2 handle 1: root cbq bandwidth 100Mbit avpkt 1000 mpu 64 tc class add dev eth2 parent 1: classid 1:1 cbq bandwidth 500Kbit avpkt 1000 prio 1 rate 500Kbit maxburst 10 bounded isolated tc filter add dev eth2 protocol ipv6 parent 1: prio 1 handle 1 fw classid 1:1 ip6tables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --setmark 1 Poichè i pacchetti IPv6 sono incapsulati all interno di un pacchetto IPv4, su eth2 dovremo agire diversamente. Ci viene in aiuto il modulo u32, uno strumento molto potente in grado di leggere i datagrammi a basso livello. Quando un datagramma IPv6 viene incapsulato, nel campo Protocol del pacchetto IPv4 contenitore viene specificato il protocollo numero 41: l obiettivo è riconoscere questi pacchetti contenitori e marchiarli con il numero 1 in modo che possano essere catturati da un filtro appositamente definito. Nonostante anche altre guide online riportino i seguenti comandi, in fase di test non sono riuscito a catturare i pacchetti incapsulati. I comandi da me eseguiti sono: tc qdisc add dev eth2 handle 1: root cbq bandwidth 100Mbit avpkt 1000 mpu 64 tc class add dev eth2 parent 1: classid 1:1 cbq bandwidth 500Kbit avpkt 1000 prio 1 rate 500Kbit maxburst 10 bounded isolated tc filter add dev eth2 protocol ip parent 1: prio 1 u32 match ip protocol 41 0xff classid 1:1 85

86 CAPITOLO 5. QUALITY OF SERVICE Utilizzo del modulo u32 Ho condotto alcuni test sul modulo u32 del software Traffic Control, perchè è uno strumento estremamente versatile. Può essere infatti utilizzato allo scopo di effettuare il parsing di un qualsiasi tipo di pacchetto. Non è di facile utilizzo in quanto bisogna specificare: Numero di bit da leggere: 32, 16 oppure 8 bit. Se scegliamo di controllare 32 bit, dopo l invocazione del modulo u32 bisogna utilizzare la sintassi match u32. Se, invece, scegliamo di leggere 16 bit è necessario usare il comando match u16. Se specifichiamo match u8 leggeremo solo 8 bit. Non sono possibili altre taglie di lettura Pattern: una volta presi 32, 16 oppure 8 bit dobbiamo specificare il pattern da ricercare. Esso deve essere fornito in esadecimale, e deve quindi iniziare con il prefisso 0x Maschera: dobbiamo specificare una maschera per far capire su quali bit eseguire il pattern matching. Una maschera è anch essa scritta in esadecimale. Su 8 bit se vogliamo controllare i 4 bit più a sinistra dobbiamo scrivere 0xf0. Se vogliamo controllare i 4 bit più a destra dobbiamo scrivere 0x0f. Se vogliamo fare pattern matching su tutti e 8 i bit scriveremo 0xff Offset: è richiesto di specificare il bit da cui iniziare la lettura, tramite il comando at, espresso in byte. Se vogliamo leggere i primi 4 bit di un pacchetto dobbiamo partire dall inizio, quindi scriveremo at 0. Se vogliamo saltare i primi 32 bit e cominciare a leggere dal 33-esimo bit, dovremo scrivere at 4 (8 4 = 32 bit). Nel caso di u32 l offset deve essere un multiplo di 4, per u16 un multiplo di 2, per u8 un multiplo di 1 La parte più complessa è realizzare esattamente in quale porzione del pacchetto si trova il campo che vogliamo controllare. Facciamo un esempio con un pacchetto MAC con indirizzo di destinazione 12:34:56:78:9A:BC. Il campo Destination Address si trova nei primi 48 bit, quindi dovremo usare 2 volte match u32 (i bit in più non li controlleremo). Con il comando qui sotto ricerchiamo l indirizzo 12:34:56:78 in tutti i primi 32 bit (per questo la maschera è 0xffffffff ) a partire dall inizio del pacchetto (at 0 ). tc filter add dev eth1 parent 1: protocol prio 1 u32 match u32 0x xffffffff at 0 86

87 5.5. CONSIDERAZIONI SULLA QOS IN IPV6 Però ci manca ancora di ricercare la parte finale dell indirizzo 9A:BC. Con il comando scritto di seguito leggiamo altri 32 bit, di cui però ci interessano solo i primi 16 (maschera 0xffff0000 ). Il match deve iniziare a partire dal 33-esimo bit, per cui abbiamo specificato l offset at 4 (4 8 = 32): match u32 0x9abc0000 0xffff0000 at 4 flowid 1:11 Un semplice test per verificare il funzionamento del modulo u32 è provare a distinguere un pacchetto IPv6 da uno IPv4. Nel campo Version è specificato il numero 4 oppure 6, a seconda della versione. Il seguente filtro identifica un pacchetto v4: tc filter add dev eth2 protocol ip parent 1: prio 1 u32 match u8 0x40 0xf0 at 0 classid 1:1 Similmente per v6: tc filter add dev eth2 protocol ipv6 parent 1: prio 1 u32 match u8 0x60 0xf0 at 0 classid 1:1 Un operazione più complessa è leggere il valore inserito nel Traffic Class. Dal momento che non c è alcuna funzionalità appositamenete sviluppata per controllarlo, se vogliamo dare maggiore priorità, per esempio, al traffico VoIP che taggeremo opportunamente, dovremo creare manualmente un filtro come segue: tc filter add dev eth2 protocol ipv6 parent 1: prio 2 u32 match u16 0xVALORE 0x0ff0 at 0 classid 1:1 Il Traffic Class occupa 8 bit e si trova subito dopo il campo Version, il che significa che parte dal quinto bit e termina al 12-esimo bit: per questo motivo la maschera utilizzata è 0x0ff0. Al posto di VALORE dobbiamo inserire il Differentiated Service Code Point (per i dettagli vedere sezione 5.3.1). 5.5 Considerazioni sulla QoS in IPv6 La QoS in IPv6, almeno per quanto riguarda il campo Traffic Class, funziona esattamente allo stesso modo che in IPv4: i due campi ToS e TC infatti sono equivalenti, dal momento che utilizzano DSCP ed ECN. Il miglioramento della QoS in IPv6 più evidente è stato l introduzione del campo Flow Label che permette ai router di gestire con molta più velocità i 87

88 CAPITOLO 5. QUALITY OF SERVICE flussi di dati: i router, infatti, non sono più costretti a leggere un pacchetto fino a ricavare le informazioni presenti nel protocollo di trasporto! Allo scopo di individuare un flusso sono sufficienti il Flow Label e gli indirizzi mittente e destinatario. A livello pratico la QoS non è per niente banale da implementare nè da testare. Fare traffic shaping è una buona via per garantire a determinate applicazioni o protocolli un servizio migliore ma è una piccolissima parte di quello che può essere attuato (ad esempio una commistione di tagging e shaping). Traffic Control si è dimostrato un software valido anche in ambito IPv6 ma al contempo assai complesso da usare e poco user-friendly, visto che costringe l utente a creare delle regole di pattern matching sui pacchetti manualmente. Anche Iperf si è rivelato un ottimo programma che fa della sua portabilità e semplicità d uso dei punti di forza, grazie anche ad un interfaccia grafica molto ben curata ed intuitiva da usare. Se Iperf con IPv4 ha dimostrato piena compatibilità, non è possibile affermare lo stesso per IPv6: i valori inseribili in Traffic Class sembra che non vengano effettivamente scritti nel pacchetto, tant è che possiamo specificare una qualsiasi stringa (anche caratteri a caso) senza notare alcuna differenza dal punto di vista delle prestazioni nè messaggi di errore da parte del programma. 88

89 Capitolo 6 Conclusioni Il presente capitolo nasce allo scopo di trarre le fila del lavoro svolto durante il progetto attuato in azienda. In sezione 6.1 vengono ricapitolati l applicabilità e i vantaggi che la configurazione 4over6 offre. L ultima sezione (Sez. 6.2) contiene delle considerazioni personali riguardanti lo stage esterno. Figura 6.1: Raffronto ore preventivate e ore a consuntivo Viene mostrato in questo paragrafo il resoconto degli obiettivi raggiunti durante lo stage effettuato presso l azienda Miriade S.p.a dal 10/05/2010 al 89