Tecnologie e servizi di rete/Migrazione a IPv6: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
→‎DS-Lite: http://appunti.shoutwiki.com/w/index.php?title=Tecnologie_e_servizi_di_rete%2FMigrazione_a_IPv6&diff=17887
Nessun oggetto della modifica
Riga 54:
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.
 
====Soluzioni di tunneling orientate alla rete====
===Tunneling===
====Soluzioni di tunneling orientate alla rete====
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:
[[File:IPv6 tunneling example.svg|center|thumb|upright=2]]
Line 63 ⟶ 62:
* <span style="text-decoration:underline;">pacchetti IPv6 più piccoli</span>: 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".
 
====Soluzioni di tunneling orientate agli host====
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. Le soluzioni di questo tipo sono:
* uso degli indirizzi IPv6 IPv4-compatible, con terminazione del tunnel sull'host o sul router;
* 6over4;
* ISATAP.
 
====Uso degli indirizzi IPv6 IPv4-compatible====
Si basano sul fatto che gli host dual-stack, quando è necessario contattare una destinazione IPv4, inviino pacchetti IPv6 ad un indirizzo IPv6 IPv4-compatible, cioè costruito con i primi 96 bit alti a zero e con i restanti 32 coincidenti con quelli dell'indirizzo IPv4 di destinazione. Tale pacchetto IPv6 viene poi incapsulato in un pacchetto IPv4, la cui destinazione è diversa a seconda che si voglia terminare il tunnel sull'host di destinazione o su un router dual-stack, in particolare:
* <span style="text-decoration:underline;">terminazione end-to-end</span>: la pseudo-interfaccia sull'host dual-stack effettua l'incapsulamento in un pacchetto IPv4 destinato all'host che si vuole contattare;
* <span style="text-decoration:underline;">terminazione sul router dual-stack</span>: la pseudo-interfaccia sull'host manda i pacchetti destinati ad un host all'indirizzo IPv4 del router dual-stack, quindi:
*# si genera un indirizzo IPv6 IPv4-compatible per la destinazione, come prima;
*# si incapsula il pacchetto IPv6 in uno IPv4 destinato al router dual-stack;
*# il router dual-stack decapsula il pacchetto e invia all'host di destinazione.
 
====6over4====
L'idea è quella di emulare, attraverso IPv4, una rete locale che ha supporto al multicast. In pratica, come per connettere due host IPv6 attraverso la rete Ethernet sottostante si usa la neighbor discovery, appoggiandosi al fatto che Ethernet ha dei meccanismi per il broadcast, in questa soluzione si ragiona come se fosse IPv4 il protocollo di livello inferiore e si modifica la neighbor discovery per trovare indirizzi IPv4 al posto di indirizzi MAC.
Questo discorso può essere generalizzato al caso in cui si vogliono connettere non dei singoli host, ma nuvole di reti IPv6 attraverso router dual-stack che comunicano in una rete IPv4. In questo caso, oltre alla neighbor discovery, si può utilizzare una versione modificata della router discovery, in modo da inviare una router solicitation per scoprire gli indirizzi IPv4 dei router connessi alla rete IPv4 dell'host che consentono di raggiungere varie reti IPv6; infatti dalla router advertisement l'host può avere informazioni sulle reti IPv6 che si possono raggiungere da quel router.
 
Il problema di questa soluzione è l'uso dell'IPv4 multicast, che di solito è disabilitato nelle reti che coinvolgono provider diversi. Questa soluzione è utilizzabile quando si ha una rete tutta sotto il proprio controllo: per questo motivo essa non è utilizzabile per migrare la rete globale da IPv4 a IPv6.
 
=====Neighbor discovery di 6over4=====
Su proposta dell'RFC, gli indirizzi IPv6 sono mappati sugli indirizzi IPv4: in pratica l'indirizzo IPv4 viene usato come interface identifier dell'indirizzo IPv6 della destinazione. Ciò renderebbe inutile il meccanismo illustrato finora, perché l'host potrebbe effettuare il tunneling direttamente, senza bisogno della neighbor discorvery per conoscere l'indirizzo IPv4. Ciò ovviamente non è valido quando l'indirizzo IPv6 non è costruito a partire da quello IPv4, quindi per contattare un router è comunque necessario un meccanismo più generale.
Supponendo, quindi, di conoscere soltanto un indirizzo IPv6, si invia la neighbor discovery al solicited node multicast address (ad esempio se l'indirizzo IPv6 è <tt>fe80::101:101</tt> allora si manda a <tt>ff02::1:ff01:101</tt>) su una rete IPv4 6over4 multicast all'inidirizzo <tt>239.192.x.y</tt>, costruito con gli ultimi 16 bit dell'indirizzo IPv6 (quindi nell'esempio precedente sarà <tt>239.192.1.1</tt>).
 
====ISATAP====
L'idea è simile a quella del 6over4, cioè usare la rete IPv4 come link fisico per raggiungere le destinazioni IPv6, ma si vuole superare la limitazione di richiedere il supporto al multicast. In assenza dei meccanismi di neighbor discovery, l'indirizzo IPv4 delle destinazioni che usano ISATAP viene incorporato nell'indirizzo IPv6, più precisamente nell'interface identifier, che ha la forma <tt>0000:5efe:x:y</tt>, in cui <tt>x</tt> e <tt>y</tt> sono i 32 bit dell'indirizzo IPv4.
Come si intuisce, questa soluzione non affronta il problema per cui si è introdotto IPv6, cioè la scarsità di indirizzi IPv4. Questa soluzione è però più utile nello scenario di un link IPv4 che connette non host, ma router cha hanno al confine delle nuvole IPv6. In questo caso un host all'interno della rete IPv4 che voglia comunicare in IPv6 con un host appartenente ad una nuvola dovrà essere dotato di una Potential Router List (PRL). I problemi che a questo punto si pongono sono:
* <span style="text-decoration:underline;">Come viene acquisita la PRL?</span>
:Ci sono due diverse soluzioni: la prima, che è proprietaria, si basa sull'uso del DHCP; la seconda, che è standard, si basa sull'uso del DNS. Nella seconda si usa una query DNS per un nome particolare dal formato <tt>isatap.dominio.it</tt>, che fornirà la PRL dei router IPv6 collegati alla rete IPv4 del dominio specificato nella query.
* <span style="text-decoration:underline;">A quale router devono essere inviati i pacchetti per la destinazione IPv6?</span>
:Si usa una router discovery unicast ad ognuno dei router della PRL, in modo da farsi rispondere con una router advertisement. Si ricordi, infatti, che nella router advertisement i router possono anche annunciare la lista delle reti IPv6 che si possono raggiungere tramite essi (vedi il flag <tt>L=0</tt> nella ''Prefix Information Option'' della ''ICMP Router Advertisement'').
 
===Soluzioni di tunneling orientate alla rete===
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), [[#Tecnologie e servizi di rete/VPN#GRE|GRE]], IPsec, ecc.
 
====6to4====
====Soluzioni di tunneling orientate agli host====
Il più grande passo in avanti rispetto alle soluzioni precedenti viene dalla considerazione che nel nuovo scenario c'è una intera rete IPv6 che ha bisogno di un indirizzo IPv4 per uscire dalla nuvola IPv6, non più un singolo host. Il mapping tra i due indirizzi viene quindi effettuato nel prefisso IPv6, non nell'interface identifier: si assegna a tutte le reti IPv6 un prefisso speciale che includa l'indirizzo IPv4 assegnato all'interfaccia del router dual-stack che si affaccia sulla nuvola. Il prefisso <tt>2002::/16</tt> identifica delle stazioni IPv6 che stanno usando 6to4: nei successivi 32 bit si pone l'indirizzo IPv4 e altri 16 rimangono disponibili per rappresentare più subnet diverse, mentre l'interface identifier si ottiene come negli altri casi di uso di IPv6.
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.
In questa soluzione esiste anche un router che ha un ruolo particolare, il '''6to4 Relay''', che deve essere il default gateway dei router 6to4, in modo da inoltrare alla IPv6 globale i pacchetti che non hanno il formato dei 6to4 appena visto. Questo router ha indirizzo <tt>192.88.99.1</tt>, che è un indirizzo anycast: è stato usato da chi ha pensato il 6to4 perchè si è pensato allo scenario in cui nella stessa rete ci siano più 6to4 Relay, da cui nascerebbe il problema di dover usare indirizzi diversi. In questo modo invece, poichè l'indirizzo anycast è processato in maniera diversa dai protocolli di routing, si può usare lo stesso indirizzo e fornire anche del ''load balancing''.
 
=====Esempio pratico=====
Ipotizziamo che ci siano due nuvole IPv6 collegate ad una nuvola IPv4, e che le interfacce dei router dual-stack abbiano, per le interfacce collegate alle nuvole IPv6, gli indirizzi <tt>192.1.2.3</tt> per la rete A e <tt>9.254.2.252</tt> per la rete B. Supponiamo inoltre che un host a appartenente alla rete A voglia inviare un pacchetto all'host b appartenente alla rete B. Dalla configurazione delineata e da quanto detto si ricava che gli host presenti nella rete A avranno un indirizzo del tipo <tt>2002:c001:02:03/48</tt> e quelli presenti nella rete B <tt>2002:09fe:02fc::/48</tt>. Il pacchetto IPv6 da a a b sarà incapsulato in un pacchetto IPv4 che ha come indirizzo di destinazione <tt>9.254.2.252</tt>, ricavato dal prefisso dell'indirizzo IPv6 di destinazione: quando il pacchetto arriverà a quel router, esso sarà decapsulato e inoltrato secondo il piano di indirizzamento IPv6 della nuvola contenente la rete B.
 
====Teredo====
È molto simile al 6to4, tranne per il fatto che l'incapsulamento è effettuato dentro un segmento UDP contenuto in una pacchetto IPv4, al posto di essere semplicemente incapsulato in IPv4. Questo si fa per superare un limite del 6to4, cioè il passaggio attraverso i NAT: poichè nel 6to4 non è presente un segmento di livello 2 dentro il pacchetto IPv4 incapsulante, il NAT non può funzionare.
 
====Tunnel broker====
Il problema della soluzione 6to4 è che non è sufficientemente generica: si è vincolati all'uso degli indirizzi <tt>2002::/16</tt> e non si possono usare i comuni global unicast. Nella soluzione con tunnel broker, visto che non è più possibile dedurre dal prefisso IPv6 quale sia l'endpoint a cui mandare il pacchetto, si utilizza un server che, dato un generico indirizzo IPv6, fornisce l'indirizzo del tunnel endpoint da contattare. I router che implementano il tunnel broker sono chiamati '''tunnel server''', mentre i server che forniscono il mapping si chiamano '''tunnel broker server'''. I tunnel sono realizzati come in 6to4, quindi IPv6 dentro IPv4: se ci fosse il problema di attraversare un NAT si potrebbe anche pensare di usare l'approccio di Teredo, incapsulando dentro UDP, quindi dentro IPv4.
 
Il tunnel broker server deve essere configurato: viene usato il '''Tunnel Information Control''' (TIC) per inoltrare le informazioni sulle reti raggiungibili da un determinato tunnel server, dal tunnel server che si sta configurando al tunnel broker server. Il '''Tunnel Setup Protocol''' (TSP) viene invece usato per chiedere le informazioni al tunnel broker server. Anche in questo caso si può avere un default gateway per la rete IPv6 globale. Ricapitolando, un router con questa configurazione, quando arriva un pacchetto, può:
* inoltrarlo direttamente se fa match con una entry nella tabella di instradamento (situazione classica);
* chiedere al tunnel broker server per vedere se si tratta di un indirizzo per cui serve il tunneling;
* mandarlo su un default gateway per la IPv6 globale se la risposta del tunnel broker server è negativa.
 
=====Problemi=====
* È una soluzione centralizzata e per questo il tunnel broker server è un ''single point of failure''.
* Complica il piano di controllo.
* Se questo server serve ad interconnettere reti diverse, anche appartenenti a provider diversi, nasce il problema della responsabilità della sua gestione.
 
=====Vantaggi=====
* È più flessibile del 6to4, perchè consente l'uso di tutti gli indirizzi global unicast.
 
==Portare il supporto a IPv6 ai margini della rete==