Accessibilità di contenuti IPv4 da parte di Host IPv6 : il NAT64

Uno dei tanti miti che circondano IPv6 è che "IPv6 elimina completamente il bisogno del NAT". In teoria è vero, poiché IPv6 ha una disponibilità virtualmente infinita di indirizzi IP, e quindi non vi è alcuna ragione di economizzare sul loro utilizzo.

Ricordo che il NAT in ambiente IPv4 (anche noto come NAT44) è nato proprio per ridurre sensibilmente l'utilizzo di indirizzi IPv4 pubblici. Senza l'introduzione del NAT44, l'Internet così come la conosciamo oggi non sarebbe stata possibile, a causa della scarsità degli indirizzi IPv4 pubblici.

Solo che dalla teoria alla pratica come sempre, ne passa. Purtroppo, a dispetto delle affermazioni dei "puristi" di IPv6, il NAT in ambiente IPv6, uscito dalla porta è rientrato a pieno titolo dalla finestra. Vi sono scenari dove una qualche forma di NAT è indispensabile anche in ambito IPv6. Voglio illustrarvene quattro (che non sono gli unici !).

Scenario 1

Supponiamo che un Cliente Enterprise utilizzi i servizi di un ISP per la connettività all'Internet IPv6, e che il Cliente non abbia un suo blocco PI (Provider-Independent) di indirizzi IPv6, ma che utilizzi un blocco PA (Provider-Assigned) assegnatogli dall'ISP. Il Cliente utilizzerà il blocco PA, che potrebbe essere ad esempio un /48, per numerare tutti i suoi Host, server e tutta la sua infrastruttura di rete IPv6. Supponiamo ad un certo punto che il Cliente voglia, per ragioni economiche, utilizzare i servizi di un altro ISP. 

Poiché il Cliente non ha un suo blocco PI, potrebbe esere costretto a cambiare l'intero piano di numerazione IPv6 utilizzando un blocco PA fornito dal nuovo ISP (a meno che il nuovo ISP non consenta l'annuncio del blocco PA del vecchio ISP). Per evitare questo problema è stata sviluppata una forma di NAT66 "leggera", detta NPTv6, descritta nella RFC 6296 - IPv6-to-IPv6 Network Prefix Translation, Giugno 2011. Ancora oggi questa forma di NAT è poco supportata dai costruttori. Mi riprometto in futuro di scrivere un post per illustrarne il (semplice) funzionamento.

Scenario 2

Supponiamo che un ISP non abbia più a disposizione indirizzi IPv4 pubblici da assegnare ai suoi Clienti. Per consentire l'accesso ai contenuti sull'Internet IPv4 a questi Clienti, una possibile soluzione è quella di assegnare ai Clienti un indirizzo IPv4 privato (RFC 1918), quindi eseguire un trasporto del traffico IPv4 fino a un particolare router della rete dell'ISP e qui eseguire un semplice classico NAT44. L'idea potrebbe essere di utilizzare un Tunnel IPv4-in-IPv6 e la classica funzione NAT44 nel seguente modo:

• Il Tunnel IPv4-in-IPv6 ha come estremi il router in casa Cliente e un router nella rete dell'ISP. 
• Il router della rete dell'ISP, una volta decapsulato il pacchetto IPv4 dal pacchetto IPv6, esegue in modo centralizzato la classica funzione NAT44.

Questo meccanismo è uno standard IETF denominato DS-lite (Dual Stack leggero), specificato nella RFC 6333 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion, Agosto 2011. Anche per il DS-lite, mi riprometto in futuro di scrivere un post per illustrarne il funzionamento.

Scenario 3 

Premessa: la stragrande maggioranza dei server web è raggiungibile solo dall'Internet IPv4. Solo pochi grandi OTT (Over The Top) come Google, Facebook, Twitter, Yahoo, Netflix, ecc. sono raggiungibili attraverso l'Internet IPv6. E questo durerà ancora per molti anni a venire. 

Ciò premesso, supponiamo che vogliate mettere su degli accordi di business con una compagnia cinese, e che questa, a causa della scarsità endemica degli indirizzi IPv4 nel continente asiatico, utilizzi per i suoi sistemi solo indirizzi IPv6 (NOTA: APNIC ha esaurito gli indirizzi IPv4 pubblici a disposizione il 15 Aprile 2011 !). Come mettere in comunicazione gli Host della compagnia cinese con i vostri server, raggiungibili solo dall'Internet IPv4 ? (Ahi, Ahi, Ahi, networker fai da te ?) 

Ancora, supponiamo che facciate un viaggio in Cina e appena arrivate sul suolo cinese il vostro Smartphone si aggancia a un operatore locale, il quale, anche qui a causa della indisponibilità di indirizzi IPv4, vi assegna un indirizzo IPv6. Come fate a collegarvi ai vostri siti preferiti, raggiungibili solo dall'Internet IPv4 (e sono molti) ? 

Bene, da qualche parte c'è bisogno di un qualche meccanismo che consenta, a partire da indirizzi IPv6 sorgente e destinazione, di trasformare pacchetti IPv6 in pacchetti IPv4, con gli indirizzi "giusti". Questo meccanismo è noto come NAT64 ed è per l'appunto una forma di NAT. 

Scenario 4 

Alcune applicazioni e servizi non funzionano correttamente su IPv6, a causa di pratiche di programmazione, diciamo poco corrette, che fanno riferimento ad API specificamente scritte per IPv4, piuttosto che ad API scritte in modo "agnostico" e indipendente dalla particolare famiglia di indirizzi.

Una recente inchiesta nel mercato Android ha mostrato che l'85% delle applicazioni è dichiarata IPv6-compliant, mentre il 15% non funziona su reti IPv6 (vedi i dati qui). La maggior parte delle applicazioni che non funzionano su IPv6 sono applicazioni peer-to-peer (Skype, Tango, ecc.).

Come è possibile allora far funzionare una applicazione del genere, quando di mezzo c'è una rete IPv6 ? Anche qui, il problema può essere risolto con sistema di doppio NAT, NAT46 e NAT64. Il meccanismo è stato standardizzato in ambito IETF (RFC 6877 -  464XLAT: Combination of Stateful and Stateless Translation, Aprile 2013) e prende il nome di 464XLAT. In realtà 464XLAT altro non è che una combinazione di due modalità di funzionamento del NAT64 citato nello Scenario 3: stateless e stateful. Magari in seguito scriverò un post anche su questo.

In questo post illustrerò il funzionamento e gli aspetti di configurazione del NAT64. In realtà vi allego per il download un piccolo estratto della presentazione che io e il mio collega Giorgio Valent abbiamo scritto su IPv6 (tutto e ancor di più, la presentazione è di quasi 700 slides commentate !), e che utilizziamo nei nostri corsi base ed avanzati. Questo estratto tratta in modo abbastanza dettagliato del NAT64, sia nella modalità stateful (la più importante) che stateless (utilizzata solo in casi molto particolari). Potete scaricare il documento qui.

Buona lettura.

CONCLUSIONI 

Capisco che vi sia una certa riluttanza a studiare IPv6, vuoi perché uno dentro di se pensa che IPv4 sia immortale, o perché "ma questi cavolo di indirizzi IPv6 hanno una struttura illeggibile", o ecc. ecc. Ma come ho scritto in un post precedente, "Resistance is futile", se volete lavorare in questo campo prima o poi con IPv6 dovrete farci i conti. Per cui vi consiglio di iniziare a studiarlo un po'. E poi, rimanete sintonizzati su questo blog, dove di tanto in tanto proporrò qualcosa (spero) di interessante.

Qualora siate interessati ad approfondimenti, noi della Reiss Romoli abbiamo profuso su IPv6 molte energie e abbiamo nel nostro catalogo molti corsi sull'argomento, base ed avanzati, che abbiamo già realizzato con successo per molti ISP e per molti Clienti Large Business. Ad ausilio della parte didattica, abbiamo anche realizzato un Lab molto complesso che emula tutta la catena, dagli Host, ai server DNS, RADIUS, DHCPv6, al backbone IPv6, fino all'Internet IPv6.

Abbiamo inoltre un "IPv6 Express Consulting Service" attraverso il quale forniamo supporto tecnico su attività di progettazione (definizione di piani di numerazione e di migrazione), assessment degli attuali apparati di rete, allestimento e collaudo di test plant, implementazione e testing di nuove release software, trasferimento delle competenze agli specialisti interni all’azienda e formazione ai formatori aziendali. Tramite questo servizio forniamo inoltre assistenza nella definizione di eventuali bandi di gara, nella selezione dei migliori fornitori, nell’acquisizione degli apparati e delle infrastrutture tecnologiche.