Tecnologie e servizi di rete/Migrazione a IPv6

Wikibooks, manuali e libri di testo liberi.
Jump to navigation Jump to search

Introduzione[modifica]

Durante la fase di transizione, gli host devono cominciare gradualmente a poter raggiungere le destinazioni IPv6 continuando a essere in grado di raggiungere le destinazioni IPv4. La migrazione di tutti gli apparati di rete è una condizione necessaria ma non sufficiente: l'utente deve farli lavorare insieme creando un nuovo piano di indirizzamento per l'intera rete.

Migrazione degli host[modifica]

Migrazione delle applicazioni[modifica]

L'introduzione del supporto a IPv6 nelle applicazioni comporta la necessità di modificare il codice sorgente:

  • server: il processo in esecuzione su un server deve aprire due thread, uno in ascolto sul socket IPv4 e l'altro in ascolto sul socket IPv6, al fine di poter servire richieste sia IPv4 sia IPv6;
  • client: le applicazioni come i browser Web devono essere in grado di stampare in output e ricevere in input gli indirizzi nel nuovo formato.

Migrazione dei sistemi operativi[modifica]

Le applicazioni giacciono per lo più sulle librerie del sistema operativo, che possono introdurre il supporto a IPv6 adottando l'approccio dual stack:

  • senza dual layer: il sistema operativo elabora indipendentemente gli indirizzi IPv4 e IPv6 → il software deve essere in grado di gestire indirizzi sia IPv4 sia IPv6;
  • con dual layer: il sistema operativo è in grado di convertire un indirizzo IPv4 in un indirizzo IPv6 IPv4-mapped → il software può limitarsi a supportare gli indirizzi IPv6 senza curarsi degli indirizzi IPv4.

La variante con dual layer è la più utilizzata perché sposta la complessità al core del sistema operativo.

Migrazione degli apparati di rete[modifica]

Migrazione degli switch[modifica]

Anche se in teoria gli switch non dovrebbero essere influenzati assolutamente dai cambiamenti a livello 3 perché essi lavorano fino al livello 2, ci potrebbero essere alcuni problemi con le funzioni aggiuntive: per esempio l'IGMP snooping, una funzionalità utilizzata per filtrare i pacchetti multicast in arrivo, ha bisogno di guardare all'interno del pacchetto → poiché cambiano il formato e i campi del pacchetto lo switch non riesce a riconoscere i pacchetti IPv6 multicast e li scarta.

Migrazione dei router[modifica]

Searchtool.svg Per approfondire, vedi Protocolli e architetture di instradamento/Instradamento IPv6.

Oggi i router sono per lo più pronti per IPv6, anche se le prestazioni in IPv6 sono ancora peggiori rispetto a quelle in IPv4 a causa della mancanza di esperienza e della più bassa domanda di traffico.

Tipicamente i router che supportano IPv6 adottano l'approccio dual stack di tipo "navi nella notte": IPv4 e IPv6 sono supportati da due pile indipendenti per il livello trasporto → questo richiede la completa duplicazione di tutti i componenti: protocolli di instradamento, tabelle di instradamento, liste di accesso, ecc.

Tabelle di instradamento[modifica]

L'instradamento in IPv6 è effettuato nello stesso modo di IPv4 ma richiede due tabelle di instradamento distinte, una per le rotte IPv4 e l'altra per le rotte IPv6. Le tabelle di instradamento IPv6 possono memorizzare diversi tipi di entry, tra cui:

  • entry indirette (codici O/S): specificano gli indirizzi, tipicamente link local, delle interfacce dei router next hop ai quali inviare i pacchetti indirizzati verso link remoti;
  • entry dirette: specificano le interfacce del router stesso attraverso le quali inviare i pacchetti indirizzati verso i link locali:
    • reti connesse (codice C): specificano i prefissi dei link locali;
    • indirizzi di interfaccia (codice L): specificano gli interface identifier nei link locali.
Protocolli di instradamento[modifica]

I protocolli di instradamento che supportano IPv6 possono adottare due approcci:

  • instradamento integrato (ad es. BGP): il protocollo consente di scambiare informazioni di instradamento sia IPv4 sia IPv6 allo stesso tempo → gli indirizzi IPv4 e IPv6 appartenenti alla stessa destinazione possono essere trasportati tramite un singolo messaggio → efficienza maggiore;
  • navi nella notte (ad es. RIP, OSPF): il protocollo consente di scambiare informazioni di instradamento solo IPv6 → data una destinazione, deve essere scambiato un messaggio per il suo indirizzo IPv4 e un altro messaggio per il suo indirizzo IPv6, e i messaggi sono completamente indipendenti tra loro → flessibilità maggiore: si possono usare due protocolli diversi, uno per le informazioni di instradamento IPv4 e un altro per le informazioni di instradamento IPv6.

Migrazione dei DNS[modifica]

I DNS che supportano IPv6 possono mappare due indirizzi IP allo stesso alias: un indirizzo IPv4 e uno IPv6 → una destinazione pubblica può essere raggiungibile tramite IPv4 oppure tramite IPv6.

I DNS che supportano IPv6 possono restituire gli indirizzi IPv6 non solo tramite IPv6, ma anche tramite IPv4: i messaggi DNS appartengono infatti al livello applicazione, così non importa il livello trasporto utilizzato per inoltrare le query e le risposte DNS. Le query DNSv6 vengono effettuate con il comando seguente: set q=aaaa.

Una società può decidere di offrire l'accesso al proprio sito Web pubblico anche tramite IPv6. Tuttavia, attualmente la maggior parte del traffico è tramite IPv4, così generalmente il servizio per il traffico IPv4 è più affidabile in termini di prestazioni e tolleranza ai guasti rispetto a quello per il traffico IPv6. Perciò la società, soprattutto se basa il business sul suo sito Web, non vuole che l'utente che si connette tramite IPv6 decida di passare a un altro sito Web concorrente a causa di problemi prestazionali. Una soluzione possibile è effettuare alcuni accertamenti preliminari per testare le prestazioni della connettività tra l'utente e il server della società, e implementare un meccanismo aggiuntivo nei DNS: essi dovrebbero essere capaci di guardare l'indirizzo sorgente della query DNS, e restituire solamente l'indirizzo IPv4 se non è stato effettuato alcun accertamento per la connettività, oppure entrambi gli indirizzi IPv4 e IPv6 se le prestazioni sono sufficientemente buone.

Tunneling[modifica]

Soluzioni di tunneling orientate alla rete[modifica]

La rete non sarà compatibile con IPv6 dal giorno zero → il traffico IPv6 potrebbe dover attraversare delle porzioni di rete solo IPv4. Le soluzioni di tunneling orientate alla rete permettono la connettività tra le reti IPv6 anche se esse sono connesse attraverso un'infrastruttura solo IPv4, e consistono nell'incapsulamento del pacchetto IPv6 all'interno di un'intestazione IPv4 solo per il trasporto lungo il tunnel:

IPv6 tunneling example.svg

La dimensione del pacchetto nel tunnel, compresa l'intestazione IPv4 lunga 20 byte, non deve superare la dimensione massima dei pacchetti IPv4 → sono possibili due soluzioni:

  • frammentazione: i router dovrebbero frammentare il pacchetto IPv4 prima di mandarlo nel tunnel → la frammentazione è deprecata per motivi prestazionali;
  • pacchetti IPv6 più piccoli: gli host dovrebbero generare dei pacchetti IPv6 con una dimensione della MTU più piccola per tenere conto della dimensione supplementare dovuta all'inserimento dell'intestazione IPv4 → i router possono specificare la dimensione della MTU consentita attraverso i messaggi ICMPv6 "Router Advertisement".

Tipicamente le soluzioni di tunneling orientate alla rete richiedono la configurazione manuale, e l'incapsulamento può essere basato su IPv6 in IPv4 (protocol type = 41), GRE, IPsec, ecc.

Soluzioni di tunneling orientate agli host[modifica]

Le soluzioni di tunneling orientate agli host sono più plug-and-play per gli host, ma non sono soluzioni professionali e non risolvono il problema della scarsità di indirizzi IPv4 perché ogni host ha ancora bisogno di avere un indirizzo IPv4.

Portare il supporto a IPv6 ai margini della rete[modifica]

Soluzioni basate su NAT[modifica]

Principali soluzioni basate su NAT.

L'obiettivo è migrare grandi reti di provider, in modo che le nuvole IPv4 e/o IPv6 al margine della rete possano usare il backbone IPv6 per interoperare. Lo scenario comune è un utente che vuole connettersi a una destinazione IPv4 attraverso la rete IPv6 del provider.

Tutte le opzioni disponibili fanno uso del NAT. L'utilizzo del NAT è un po' controcorrente dato che IPv6 aveva tra gli obiettivi quello di evitare l'utilizzo dei NAT nelle reti a causa dei numerosi problemi portati dai NAT (modifica dei pacchetti in transito, problemi su reti peer-to-peer, ecc.). Tuttavia il fatto che queste soluzioni sono basate su NAT presenta una serie di vantaggi: i NAT sono largamente diffusi nelle reti, se ne conoscono problemi e limitazioni, si conoscono le applicazioni che possono avere dei problemi nel passare attraverso i NAT; così in generale il vantaggio è la grande esperienza accumulata finora.

Principali componenti[modifica]

Nelle soluzioni basate su NAT ci sono tre principali componenti:

  • Customer-Premises Equipment (CPE): è il router all'edge del cliente subito prima della rete del provider;
  • Address Family Transition Router (AFTR): è un IPv6 Tunnel Concentrator, cioè l'apparato alla fine di un tunnel IPv6;
  • NAT44/NAT64: è un NAT per la traduzione degli indirizzi IPv4/IPv6 in indirizzi IPv4.

Principali soluzioni basate su NAT[modifica]

  • NAT64;
  • Dual-Stack Lite (DS-Lite): NAT44 + 4-over-6 tunnel;
  • Dual-Stack Lite Address+Port (DS-Lite A+P): DS-Lite con intervalli di porte preconfigurati;
  • NAT444: CGN + CPE NAT44, ovvero quando un utente domestico, che riceve il servizio dalla compagnia telefonica, inserisce un NAT nella propria rete domestica; ogni pacchetto in uscita dalla rete domestica è sottoposto a due address translation;
  • Carrier Grade NAT (CGN): NAT44 su larga scala, ovvero NAT utilizzato dalle compagnie telefoniche per mappare le centinaia di migliaia di indirizzi privati (degli utenti) nei limitati indirizzi pubblici a disposizione.

Per la migrazione di grosse reti orientate a dispositivi mobili si sta scegliendo la soluzione con NAT64.

Per migrare verso IPv6 mantenendo la compatibilità IPv4 ai margini della rete alcuni operatori telefonici stanno pianificando migrazioni massive a DS-Lite poiché è una soluzione abbondantemente sperimentata, ed esistono numerosi dispositivi compatibili già in commercio.

La soluzione A+P non è ancora presa seriamente in considerazione a causa della poca esperienza.

NAT64[modifica]

Esempio rete NAT64.svg
  1. L'utente solo IPv6 digita www.example.com nel browser, ed essendo IPv6 invia una richiesta AAAA al DNS64 del provider. Si supponga che www.example.com abbia l'indirizzo IPv4 "20.2.2.2".
  2. Il DNS64, in caso non abbia la risoluzione del nome, deve inviare la query ad un DNS superiore, presumibilmente nella rete IPv4.
    1. Nel caso migliore DNS64 invia la query AAAA al DNS superiore e ottiene una risposta di tipo AAAA (quindi IPv6), che ritrasmette così com'è all'host (è assolutamente lecito inviare in un pacchetto IPv4 una query DNS che richiede la risoluzione di un nome in un indirizzo IPv6).
    2. Nel caso peggiore il DNS superiore non ha supporto IPv4, quindi risponde con un "Name error"; il DNS64 invia nuovamente la query ma questa volta di tipo A, a seguito della quale riceverà una risposta corretta. Questa risposta verrà convertita in AAAA e ritrasmessa all'host. Nella risposta trasmessa all'host, gli ultimi 32 bit sono uguali a quelli inviati dal DNS superiore nel record di tipo A, mentre gli altri 96 bit completano l'indirizzo IPv6; quindi l'indirizzo finale sarà "64:FF9B::20.2.2.2".
  3. L'host è ora pronto a instaurare una connessione TCP con www.example.com.
  4. Entra in gioco il NAT64: converte il pacchetto IPv6 proveniente dall'host in IPv4, e fa l'operazione inversa per i pacchetti provenienti da 20.2.2.2.

Considerazioni[modifica]

  • In un scenario del genere non c'è tunneling: l'intestazione IPv6 viene solo sostituita con una IPv4 e viceversa.
  • L'host solo IPv6 non è consapevole del fatto che l'indirizzo di destinazione è relativo a un indirizzo IPv4.
  • Il NAT64 non solo è in grado di tradurre indirizzi IPv6 in indirizzi IPv4, ma in una certa maniera fa credere alla rete che ci sono a disposizione 232 indirizzi IPv6 dato che ogni pacchetto dall'host al NAT64 avrà come indirizzo di destinazione "64:FF9B::20.2.2.2", con il prefisso "64:FF9B/96".
  • La rete del provider, quella in cui si trovano il NAT64 e il DNS64, è IPv6 nativa, quindi un host nella rete del provider può contattare direttamente un altro host dotato di supporto IPv6 senza coinvolgere in alcun modo il NAT64.
  • "64:FF9B/96" è lo spazio di indirizzamento standardizzato appositamente per questa tecnica di traduzione, assegnato al NAT64, ma l'amministratore di rete potrebbe decidere di cambiarlo a seconda delle necessità. Si noti che l'amministratore di rete deve configurare l'instradamento affinché ogni pacchetto avente tale prefisso vada al NAT64, e deve configurare il NAT64 affinché traduca ogni pacchetto IPv6 avente tale prefisso in IPv4 e lo inoltri nella nuvola IPv4.

Svantaggi[modifica]

  • La presenza del NAT introduce un problema tipico: l'host dietro il NAT non può essere facilmente raggiunto dall'esterno.
  • Succede spesso che quando un DNS non ha la risoluzione di un indirizzo non risponde affatto, invece di inviare un "Name error"; il risultato è un allungamento dei tempi a causa dell'attesa del timeout del DNS64, che alla scadenza del timeout invia una query di tipo A.
  • Questa soluzione non funziona se l'utente vuole digitare direttamente l'indirizzo IPv4: l'utente deve sempre specificare il nome della destinazione.

DS-Lite[modifica]

Esempio rete DS-Lite.svg

La soluzione Dual-Stack Lite (DS-Lite) consiste nella semplificazione dei CPE spostando le funzionalità di NAT e DHCP ai margini della rete del provider, quindi in un apparato che funge da AFTR e da CGN-NAT44.

  1. Il server DHCP del provider assegna un indirizzo IPv6, univoco all'interno della rete del provider, ad ogni host di ogni CPE.
  2. Quando l'utente deve spedire pacchetti IPv4 è necessaria un'operazione di tunneling, in modo da incapsulare pacchetti IPv4 in pacchetti IPv6 dato che la rete del provider è solo IPv6. Allora, quando un CPE riceve un pacchetto IPv4 lo deve far passare in un tunnel in un pacchetto IPv6 per poterlo spedire all'AFTR oltre il quale c'è la nuvola IPv4; quindi lo scenario è costituito da tante operazioni di tunneling sulla rete IPv6 del provider tra l'AFTR e uno dei numerosi CPE degli utenti. In particolare, il pacchetto tra CPE e AFTR avrà come indirizzo di destinazione quello dell'AFTR, e come indirizzo di destinazione quello della destinazione nella rete IPv4.
  3. L'AFTR, dopo aver eliminato l'intestazione IPv6, lo invia al NAT44 che sostituisce l'indirizzo sorgente IPv4 (privato) con l'indirizzo IPv4 a cui il NAT riceverà i pacchetti associati a questo flusso.

Il vantaggio maggiore di DS-Lite è quello di ridurre notevolmente il numero di indirizzi pubblici del provider.

Possono esserci indirizzi IPv4 duplicati nella rete del provider? No, perché il NAT44 traduce direttamente gli indirizzi IPv4 degli host negli indirizzi IPv4 pubblici disponibili. Se ci fossero indirizzi IPv4 privati duplicati il NAT avrebbe problemi di ambiguità.

Svantaggi[modifica]

  • Un host IPv4 non può contattare una destinazione IPv6 → le destinazioni IPv6 sono raggiungibili solo da host IPv6. Invece, un host IPv6 può spedire e ricevere pacchetti da nodi IPv6 senza passare attraverso l'AFTR del provider.
  • Alcuni tipi di applicazioni non sono in grado di funzionare in una situazione del genere: il fatto che il NAT non sia gestibile dall'utente, dato che non si trova più sul CPE, rende impossibile effettuare operazioni comuni come l'apertura/chiusura delle porte necessarie a specifiche applicazioni.

DS-Lite A+P[modifica]

Esempio rete DS-Lite A+P.svg

La soluzione Dual-Stack Lite Address+Port (DS-Lite A+P) consiste nell'avere ancora una rete del provider solo IPv6, ma il NAT viene spostato sul CPE in modo che l'utente possa configurarlo in base alle proprie esigenze.

Come in DS-Lite, un pacchetto IPv4 in uscita dal CPE viene ancora fatto passare in un tunnel poiché la rete del provider è solo IPv6.

Il fatto che il NAT su ogni CPE richieda un indirizzo IPv4 pubblico viene risolto permettendo la duplicazione di indirizzi IPv4 pubblici, e i CPE vengono distinti in base alla porta. Infatti ogni CPE utilizza un determinato intervallo di porte, e l'AFTR, che conosce l'intervallo di porte utilizzato da ogni CPE, riesce a distinguere i flussi da e verso uno specifico CPE nonostante ci siano diversi CPE aventi lo stesso indirizzo IPv4 pubblico.

Questa soluzione è simile a quella con DS-Lite, ma lo spazio di indirizzi IPv4 privati è più sotto il controllo dell'utente finale, perché dato che il NAT è sul CPE dell'utente l'utente può configurarlo, anche se con alcune limitazioni: non può aprire e usare porte che non sono nel proprio intervallo. Questo metodo permette di risparmiare indirizzi IPv4 (ma comunque meno rispetto a DS-Lite).

Questa soluzione in Italia è sostanzialmente illegale perché, siccome il numero di porta non viene memorizzato, in caso di attacco non si riuscirebbe a risalire all'attaccante.

Trasportare il traffico IPv6 nella rete centrale[modifica]

L'obiettivo principale è avere nella rete globale traffico IPv6 senza stravolgere la rete esistente da più di 20 anni che attualmente funziona bene. Non sarebbe possibile sostenere costi di migrazione umani e tecnologici a livello mondiale per cambiare radicalmente la rete IPv4 esistente per renderla IPv6.

6PE[modifica]

L'obiettivo della soluzione 6 Provider Edge (6PE) è connettere delle nuvole IPv6 tra loro attraverso un backbone MPLS. 6PE richiede che la rete dell'operatore funzioni con MPLS. In questo scenario il margine del provider è rappresentato dai primi router che incontrano i CPE degli utenti.

Idea[modifica]

  • Mantenere invariato il core della rete (senza escludere la possibilità di future modifiche).
  • Aggiungere il supporto a IPv6 al margine della rete del provider.
  • Distribuire informazioni di routing IPv6 in MPLS/BGP, come nelle VPN: Human-edit-redo.svg Tecnologie e servizi di rete/VPN#Livello 3: BGP.

Requisiti[modifica]

6PE network example.svg

Il requisito fondamentale è avere una rete centrale MPLS.

Nella figura:

  • la rete centrale MPLS è quella costituita da PE-1, P-1, P-2, PE-2;
  • i due apparati laterali, PE-1 e PE-2, sono parzialmente immersi nella rete MPLS;
  • si può pensare ai canali tra CE e PE come dei canali che forniscono collegamento ADSL all'utente domestico.

6PE è pensato per prendere una rete centrale pienamente funzionante, in grado di trasportare pacchetti IPv4 con MPLS, e aggiungere il supporto IPv6 solo agli edge router del provider (PE). Infatti, una volta che un pacchetto viene incapsulato in un pacchetto MPLS, gli apparati intermedi non si interesseranno più al tipo di pacchetto contenuto, ma saranno solo interessati alla etichetta che permette loro di distinguere l'LSP nel quale instradarlo.

Infatti, sui PE è richiesto un ulteriore aggiornamento al fine di aggiungere il supporto MG-BGP, protocollo che permette di trasportare e comunicare sia rotte IPv4 sia rotte IPv6.

Quindi il grosso vantaggio di questa soluzione consiste nel richiedere l'aggiornamento solo dei PE e non di tutti i router intermedi: in fin dei conti, un'operazione che il provider può gestire senza elevati costi.

Come vengono annunciate le reti IPv6[modifica]

  1. CE-3 annuncia che può raggiungere la rete IPv6 "2001:3::/64".
  2. Questa informazione viene ricevuta anche da PE-2.
  3. PE-2 invia questa informazione a tutti i PE nella rete, dicendo che può raggiungere "2001:3::/64" attraverso il next hop "FFFF:20.2.2.2", nonostante la sua interfaccia sia IPv4 (questo perché se è data una rotta IPv6 deve essere dato un next hop IPv6).
  4. PE-1 riceve questa informazione.
  5. PE-1 invia l'informazione ricevuta a tutti i router ad esso collegati, quindi anche ai CE domestici, dicendo che può raggiungere la rete "2001:3::/64".
  6. Se non esiste ancora un percorso MPLS tra PE-1 e l'indirizzo "20.2.2.2", vengono usati i classici meccanismi MPLS (quindi il protocollo di segnalazione LDPv4) per instaurare questo percorso.

Come viene instradato il traffico IPv6[modifica]

6PE traffic routing.svg

Per instradare un pacchetto IPv6 vengono utilizzate due etichette:

etichetta esterna LDP/IGPv4 verso PE-2 etichetta interna MP-BGP verso CE-3 pacchetto IPv6 verso la destinazione IPv6
  • etichetta MP-BGP (interna): identifica il CE di destinazione a cui il PE di destinazione deve inviare il pacchetto;
  • etichetta LDP/IGPv4 (esterna): identifica l'LSP tra i due PE nella rete MPLS.

Si supponga che un host nella rete "2001:1::/64" voglia inviare un pacchetto a un host nella rete "2001:3::/64":

  1. il pacchetto arriva a CE-1;
  2. CE-1 sa che la rete "2001:3::1/64" esiste e invia il pacchetto verso PE-1;
  3. PE-1 mette due etichette davanti al pacchetto: l'etichetta interna e l'etichetta esterna;
  4. PE-1 invia il pacchetto a P-1, che lo invia a P-2;
  5. P-2, che è il penultimo hop, rimuove l'etichetta esterna dal pacchetto (penultimate label popping) e lo invia a PE-2;
  6. PE-2 rimuove l'etichetta interna e invia il pacchetto a CE-3;
  7. CE-3 inoltra il pacchetto alla destinazione nella rete "2001:3::/64".

Considerazioni[modifica]

  • I router PE devono essere dual stack e devono supportare MP-BGP, mentre i router intermedi non hanno bisogno di alcuna modifica.
  • Questa soluzione fornisce un servizio IPv6 nativo ai clienti senza cambiare la rete centrale MPLS IPv4 (richiede costi e rischi operativi minimi).
  • Questa soluzione scala fino a quando ci sono poche nuvole IPv6 da distribuire.

Problematiche di sicurezza[modifica]

Si ha poca esperienza con i problemi di sicurezza perché IPv6 non è ancora molto usato → IPv6 potrebbe ancora avere delle falle di sicurezza non scoperte che potrebbero essere sfruttate da malintenzionati. Inoltre, durante la fase di migrazione gli host hanno bisogno di aprire due porte in parallelo, una per IPv4 e un'altra per IPv6 → devono essere protette due porte da attacchi dall'esterno.

Attacchi DDoS con SYN flooding

L'interfaccia di un host può avere più indirizzi IPv6 → può generare più richieste SYN TCP, ognuna con un diverso indirizzo sorgente, a un server al fine di saturarne la memoria facendo aprire ad esso diverse connessioni TCP non chiuse.

Messaggi Router Advertisement falsi

Un host potrebbe iniziare a mandare dei messaggi "Router Advertisement" annunciando dei prefissi falsi → gli altri host nel link inizieranno a inviare pacchetti con dei prefissi sbagliati negli indirizzi sorgente.