|
IPv4 e IPv6 sono protocolli incompatibili. Per questo motivo la transizione verso il nuovo
protocollo non può risultare indolore ed è associata a costi significativi
sia per i Service Provider sia per i clienti. Tuttavia i costi della transizione vanno
confrontati con i costi della non-transizione correlati con l'esigenza di far evolvere
IPv4 per supportare i nuovi servizi. Dal confronto può emergere quale sia,
caso per caso, il momento conveniente in cui avviare la transizione.
Qualunque sia il momento di inizio della transizione, non è ipotizzabile
individuare una data spartiacque, prima della quale tutta la rete è IPv4 e dopo
la quale diventa magicamente IPv6: a livello Internet la transizione sarà un processo
lungo che vedrà per molti anni la coesistenza dei due protocolli.
Per agevolare la transizione, l'IETF ha istituito un gruppo di lavoro denominato
ngtrans (Next Generation TRANSition) che si occupa di specificare i meccanismi
di supporto all'interlavoro tra IPv4 e IPv6. In particolare sono stati affrontati
due problemi principali:
- come far comunicare terminali IPv6 con terminali IPv4;
- come trasportare IPv6 su una rete IPv4, per far comunicare "isole" IPv6 interconnesse
attraverso la rete Internet IPv4.
Questo secondo problema, molto rilevante nella prima fase di introduzione di IPv6,
sarà affiancato in futuro dal problema reciproco: come fare a trasportare IPv4
su IPv6. Tuttavia, la discussione di questo aspetto è stata rimandata al momento
in cui vi sarà una significativa presenza di IPv6 nelle reti che compongono Internet.
L'analisi di questi problemi ha portato alla definizione di un insieme di meccanismi
di transizione, i quali trovano ciascuno il proprio campo di applicazione ed utilizzo.
La comunicazione tra terminali IPv4 e IPv6
Lo schema base per permettere tutte le comunicazioni è il cosiddetto IP dual stack,
che prevede che ogni nuovo terminale, server, router e altro apparato che tratta il
livello IP supporti entrambe i protocolli. In questo modo le comunicazioni tra terminali
IPv6 avvengono in modo diretto, mentre quando un terminale IPv4/IPv6 deve comunicare con
un terminale solo IPv4 lo può fare in IPv4.
Questo schema non è molto gravoso per i terminali ed i server: si tratta di un
aggiornamento software che non ha impatti significativi sul sistema. Tuttavia il principale
svantaggio di questo schema è la necessità di dover mantenere una rete
multiprotocollo con una doppia infrastruttura di routing e quindi con un aumento del carico
di lavoro per gli amministratori. Inoltre, l'uso generalizzato del modello IP dual stack
non sarà possibile quando nuovi indirizzi IPv4 non potranno più essere assegnati
perché lo spazio di indirizzamento è esaurito.
Per superare questi problemi sono state definite alcune soluzioni di interlavoro
tra reti soltanto IPv6 e reti soltanto IPv4, che consentano la comunicazione
end-to-end tra terminali eterogenei:
- dispositivi ALG di tipo IP dual stack, che permettono di operare la conversione
di protocollo ai confini tra reti disomogenee attraverso l'uso di Proxy applicativi
realizzati su server dual stack;
- dispositivi NAT-PT (Network Address Translator - Protocol Translator)
(RFC2766),
che permettono di operare la conversione di indirizzo e protocollo ai confini
tra reti disomogenee al livello IP;
- il meccanismo DSTM (Dual Stack Transition Mechanism), che propone l'uso
dello schema IP dual stack sulla base di indirizzi IPv4 assegnati dinamicamente
solo all'occorrenza e sull'uso di tunneling IPv4 in IPv6 per attraversare la rete
locale IPv6 prima di accedere alla rete esterna IPv4.
Questi meccanismi di transizione presentano gli stessi svantaggi degli analoghi
meccanismi proposti per interconnettere reti IPv4 disgiunte, ma hanno un significativo
vantaggio di prospettiva. Infatti, mentre nel caso delle reti IPv4 essi
sono meccanismi definitivi, dei quali non si potrà più fare a meno,
nella transizione verso IPv6 essi sono funzionali alla coesistenza di IPv4 ed IPv6,
che dovrebbe terminare quando la rete Internet sarà tutta IPv6.
Il trasporto di IPv6 su IPv4
La tecnica di base per trasportare IPv6 su IPv4 è quella del tunneling,
che prevede l'incapsulamento di pacchetti IPv6 all'interno di pacchetti IPv4,
per consentire loro di attraversare porzioni IPv4 della rete. Un tunnel è
un collegamento tra due end-point IPv4 che deve essere configurato: si tratta di specificare
per quali destinazioni IPv6 (un indirizzo o un prefisso) i pacchetti debbano essere
incapsulati e verso quale end-point IPv4 remoto debbano essere inviati.
Nel caso più semplice la configurazione dei tunnel avviene manualmente da parte
dell'ammistratore di rete in accordo con l'amministratore della rete in cui risiede
l'end-point IPv4 remoto: questo tipo di tunneling è denominato abitualmente
tunneling statico. La gran parte delle interconnessioni tra reti IPv6 utilizzate
nella sperimentazione mondiale di 6Bone è
realizzata attraverso tunneling statico.
Tuttavia la gestione di grandi quantità di tunnel, come ad esempio nel caso
delle connessioni degli utenti, è causa di un gravoso carico amministrativo
per i gestori delle reti e rende necessaria la definizione di meccanismi automatici
per la configurazione dei tunnel. Questo tipo di tunneling, detto tunneling dinamico,
è stato proposto in numerose varianti. La prima proposta (RFC2893),
basata sulla possibilità di utilizzare indirizzi IPv6 generati automaticamente
a partire dagli indirizzi IPv4 sorgente e destinazione (indirizzi IPv4 compatibili),
non ha riscosso molto consenso, perché rende impossibile in IPv6 realizzare
un routing gerarchico ottimale richiedendo di fatto l'importazione delle tabelle
di routing IPv4 all'interno dell'infrastruttura di routing IPv6.
Le soluzioni di maggiore interesse, ognuna delle quali trova il proprio ambito di
applicazione, sono le seguenti:
- 6over4 (RFC2529),
che prevede la possibilità di realizzare un incapsulamento
automatico di pacchetti IPv6 su una rete IPv4 in cui sia abilitato il servizio
IP multicast [20], utilizzato per fare in modo che IPv6 veda l'intera rete
come un'unica LAN (Local Area Network). Ciò rende possibile la
determinazione automatica dell'end-point IPv4 remoto attraverso meccanismi
nativi del nuovo protocollo. Questa soluzione presenta problemi di scalabilità
e si scontra con il fatto che il servizio IP multicast non è ancora disponibile
in modo generalizzato sulla rete Internet: per questi motivi si tratta di una soluzione
efficace all'interno di reti aziendali o campus che supportano IP multicast.
- 6to4 (RFC3056),
che definisce una modalità di costruzione automatica di
indirizzi IPv6 a partire da indirizzi IPv4 migliorativa rispetto agli indirizzi
IPv4 compatibili. Questa tecnica rende estremamente agevoli le comunicazioni tra
"isole" IPv6 immerse in una rete IPv4. Presenta tuttavia problemi non completamente
risolti per il caso delle comunicazioni tra una rete IPv6 isolata e la rete
Internet IPv6, che cresce sulla base di uno schema di indirizzamento unicast
diverso da quello previsto dal 6to4.
- Tunnel Broker IPv6 (RFC3053),
che prevede l'uso di server dedicati che si fanno carico
della configurazione automatica dei tunnel per conto degli utenti. Questa tecnica
risulta particolarmente adatta nel caso dei collegamenti tra piccoli utenti
(la tradizionale utenza dial-up di Internet) ed un Service Provider IPv6.
Tunnel Broker IPv6
Il Tunnel Broker IPv6 (RFC3053) è uno strumento
di transizione da IPv4 ad IPv6 sviluppato con il contributo di CSELT nell'ambito
del gruppo di lavoro ngtrans dell'IETF.
Il Tunnel Broker IPv6 offre un servizio di
configurazione automatica di tunnel IPv6 in IPv4 ad utenti collegati alla rete
Internet IPv4 (il requisito è quello che tra l'utente e la sede del Provider del servizio
vi sia connettività IPv4: Internet è il caso più comune, ma può
trattarsi anche di una rete IPv4 privata).
Il modo di funzionamento del servizio è il seguente:
- L'utente contatta il Tunnel Broker ed effettua una procedura di registrazione,
ad esempio riempiendo un modulo Web che costituisce la pagina di accesso al servizio.
L'uso di https (secure http) è consigliato per preservare la privacy dell'utente.
In risposta ottiene una coppia <username, password> che utilizzerà per accedere
al servizio.
- L'utente contatta nuovamente il Tunnel Broker e si autentica, dopo di che fornisce
informazioni minime sulla configurazione del suo terminale (indirizzo IP, sistema operativo,
software di supporto ad IPv6).
- Il Tunnel Broker configura l'end-point del tunnel lato rete,
il DNS Server ed il terminale dell'utente.
- A questo punto il tunnel è attivo e l'utente è collegato alla rete IPv6.
L'utente può modificare o rimuovere in sicurezza il proprio tunnel accedendo
nuovamente al TB con il proprio <username, password>. Inoltre l'amministratore
del Tunnel Broker può controllare l'attività degli utenti per far rispettare
le proprie politiche di accesso al servizio.
Riferimenti
- [RFC2766]
G. Tsirtsis e P. Srisuresh, Network Address Translation - Protocol Translation (NAT-PT),
RFC2766, Feb. 2000
- J. Bound, L. Toutain, F. Dupont, H. Afifi e A. Durand, Dual Stack Transition Mechanism (DSTM),
draft-ietf-ngtrans-dstm-04.txt, Gen. 2001
- [RFC2893]
R. Gilligan e E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC2893, Ago. 2000
- [RFC2529]
B. Carpenter e C. Jung, Transmission of IPv6 over IPv4 Domains without Explicit Tunnels,
RFC2529, Mar 1999
- [RFC3056]
B. Carpenter e K. Moore, Connection of IPv6 Domains via IPv4 Clouds, RFC3056, Feb. 2001
- [RFC3053]
A. Durand, P. Fasano, I. Guardini e D. Lento, IPv6 Tunnel Broker, RFC3053, Feb. 2001
|
