Anche se può sembrare paradossale, il problema principale della tecnologia IPv4 non è di natura tecnica, ma è dovuto ad una poco saggia politica di assegnamento degli indirizzi da parte delle autorità competenti. Infatti, fino a pochi anni fa il NIC (Network Information Center) assegnava, a chiunque ne facesse richiesta, blocchi di indirizzi di dimensione fissata:

a seconda delle esigenze. Utilizzando questa tecnica, la limitata dimensione dell'address space di IPv4 consentiva di assegnare non più di 128 blocchi di indirizzi di classe A (da 0.0.0.0 a 127.255.255.255), 16,256 di classe B (da 128.0.0.0 a 191.255.255.255) e 2,064,512 di classe C (da 192.0.0.0 a 223.255.255.255) [RFC791].

Tuttavia, per molte organizzazioni una rete di classe A era troppo grande e una di classe C troppo piccola, pertanto esse sono state costrette a richiedere un blocco di indirizzi di classe B. In questo senso, l'assenza di una misura intermedia tra le reti di classe B e C ha portato ad un enorme spreco di indirizzi, visto che una rete di classe B è ancora troppo grande per molte organizzazioni (tanto è vero che più del 50% delle organizzazioni a cui è stato assegnato un indirizzo di classe B non hanno più di 50 host). Lo spreco è stato finora di dimensioni tali da causare in un futuro non troppo lontano il totale esaurimento degli indirizzi IPv4. Da quel momento in poi, una ulteriore crescita di Internet sarà impossibile.

Dal punto di vista del routing, un indirizzo IP è diviso in un identificatore di rete e in un identificatore di host. Poichè l'indirizzo globale IPv4 è di tipo non aggregabile, per poter instradare un pacchetto verso la corretta destinazione i router sono obbligati a mantenere una tabella con tante registrazioni quante sono le reti collegate ad Internet, ognuna contenente almeno le informazioni sulla linea da utilizzare per raggiungere la rispettiva rete.

Considerando il fatto che il numero massimo di reti che si possono avere con la tecnica di assegnamento di indirizzi presentata al paragrafo precedente è 2,080,896, la richiesta di memoria per i dispositivi di routing è decisamente elevata. Tuttavia, si tratta di una condizione ancora affrontabile dal punto di vista economico.

Il problema risiede invece nel fatto che la complessità di molti algoritmi collegati alla gestione delle tabelle di routing cresce più che linearmente all'aumentare delle dimensioni delle tabelle, con un conseguente degrado di prestazioni.

La situazione è ancora più grave di quanto sembri, poiché gran parte del software/firmware dei router attualmente utilizzati è stato progettato quando Internet non aveva ancora le dimensioni attuali, e molte scelte di progetto fatte allora sono oggi ben lontane dall'essere ottimali. Per di più, molti algoritmi di routing richiedono la periodica trasmissione delle tabelle, e più grandi sono quest'ultime, maggiore è la possibilità che una di esse non venga trasmessa correttamente, portando così a problemi di instabilità di routing.

Per cercare di porre un freno allo spreco di indirizzi e all'esplosione delle tabelle di routing, IETF (Internet Engineering Task Force) ha sviluppato una nuova procedura per il routing e l'assegnamento degli indirizzi: CIDR (Classless InterDomain Routing).

L'idea è quella di assegnare gli indirizzi di classe C rimasti in blocchi contigui di dimensione variabile, a seconda delle esigenze. Si tratta di una politica di assegnazione molto efficiente che consente di minimizzare gli sprechi, visto che in questo modo una organizzazione che abbia bisogno, ad esempio, di 1,000 indirizzi ne riceverà esattamente 1,024 (4 reti di classe C contigue) anziché 64,534 (un indirizzo di classe B).

Inoltre CIDR specifica anche le seguenti regole di allocazione degli indirizzi, che vengono assegnati in base alla posizione geografica delle organizzazioni richiedenti:

In questo modo, ogni regione viene fornita di 33,554,428 (2*[2^{24}-2]) indirizzi allocabili, con altri 335,544,280 indirizzi (da 204.0.0.0 a 223.255.255.255) riservati per il futuro. Questa soluzione porta ad una riduzione delle dimensioni delle tabelle di routing per quanto riguarda le destinazioni che si trovano all'esterno della propria zona geografica, in quanto permette l'accorpamento delle informazioni di routing relative ad un numero notevole di reti in un'unica entry. Si pensi ad esempio ad un router che si trova in Francia. Con una sola entry nella routing table, si può ottenere che esso spedisca tutti i pacchetti con indirizzo compreso tra 198.0.0.0 e 199.255.255.255 verso il proprio gateway nordamericano standard.

Per minimizzare la dimensione delle tabelle di routing anche per quanto riguarda le destinazioni all'interno della stessa zona geografica, sono necessari ultriori accorgimenti. Infatti si potrebbe memorizzare una entry per ogni indirizzo di classe C (in modo che ad ogni organizzazione possa corrisponderne più di una), ma così facendo otterremmo 131,068 (2*[2^{16}-2]) entry, ovvero proprio quella esplosione nelle tabelle di routing che stiamo cercando di evitare. Si è invece pensato di utilizzare una singola entry per ogni organizzazione, memorizzando sia l'identificatore di rete corrispondente che la lunghezza di quest'ultimo. In questo modo ogni pacchetto viene instradato verso la rete con l'identificatore che soddisfa la condizione di longest matching prefix rispetto all'indirizzo di destinazione.

In buona sostanza, CIDR crea un sottospazio di tipo aggregabile all'interno dell'address space di IPv4, sopperendo almeno in parte ai problemi accennati in precedenza. Tuttavia è importante sottolineare che, nonostante CIDR rappresenti una ottima soluzione a breve termine, essa non è in grado di risolvere i problemi di IPv4 e tantomeno di salvare la tecnologia esistente dall'inevitabile collasso.

Per ulteriori informazioni si vedano [RFC1517], [RFC1518] e [RFC1519].

Stiamo assistendo ad una nuova fase dello sviluppo di Internet. Finora la crescita di Internet è stata guidata dal mercato dei computer (dai PC ai mainframe), ma è verosimile che a breve la situazione cambi. Nuovi mercati, di dimensioni potenzialmente enormi, si stanno sviluppando nel settore delle telecomunicazioni, ed imporranno dei nuovi requisiti alle tecnologie di Internetworking.

Il mercato dei dispositivi portatili (laptop, handheld, ecc...) sembra essere destinato ad una rapida espansione, vista la continua diminuzione dei prezzi e le notevoli capacità offerte da questo tipo di dispositivi. Tuttavia, offrire agli utenti la possibilità di essere collegati alla rete 24 ore su 24, in ogni angolo della Terra, con un dispositivo alimentato a batteria, richiede l'utilizzo di un protocollo di comunicazione semplice, snello, autoconfigurabile, e con un buon supporto alla mobilità.

Anche il mercato del networked entertainment sembra essere in fase di crescita. Offerte di tipo Video on demand e 500 channel TV saranno a breve una realtà anche in alcune zone d'Italia. E questa è solo della punta dell'iceberg. Le dimensioni di questo mercato sono potenzialmente enormi, dato che in teoria si potrebbe arrivare a collegare ad Internet tutti gli apparecchi televisivi del mondo. I requisiti imposti da questa tipologia di applicazioni, sono soprattutto in termini di elevate prestazioni per il protocollo di networking utilizzato, e di basso costo per i dispositivi che lo implementano.

Infine, il terzo e potenzialmente più vasto mercato è quello del device control. Si tratta di collegare alla rete i dispositivi di controllo degli elettrodomestici di tutti i giorni, come frigoriferi, lavatrici, impianti di riscaldamento, condizionamento, illuminazione, ecc... La nuova generazione di dispositivi intelligenti permetterebbe di ottenere un enorme risparmio energetico. In questo settore è estremamente importante avere soluzioni semplici, robuste, di basso costo ed elevata affidabilità.

Purtroppo IPv4 risulta essere assolutamente inadeguato per far fronte alle nuove esigenze, a partire dalle dimensioni del suo address space, che sono assolutamente insufficienti. La sfida che ci troviamo di fronte è quella di definire un nuovo protocollo che soddisfi tutti i requisiti imposti dai nuovi mercati, sulla base del quale si possa costruire una unica, immensa infrastruttura informatica che garantisca la massima interoperabilità e che raggiunga dimensioni di livello mondiale.

Per ulteriori informazioni si veda [HINDEN95].

La caratteristica di IPv6 che salta subito all'occhio è sicuramente l'enorme dimensione dell'address space. Infatti, passando dagli indirizzi a 32 bit di IPv4 a quelli a 128 bit di IPv6 otteniamo un numero di indirizzi disponibili pari a 340,282,366,920,938,463,463,374,607,431,768,211,456. Si tratta di una dimensione 79,228,162,514,264,337,593,543,950,336 volte più grande di quella dell'address space di IPv4. Con un rapido calcolo si ricava che un address space di tale dimensione permettebbe in teoria di avere 665,570,793,348,866,943,898,599 indirizzi per ogni metro quadro di superficie sul nostro pianeta (assumendo che la superficie della Terra sia pari a 511,263,971,197,990 metri quadrati; per ulteriori informazioni si veda [HINDEN95]). Certamente, con l'introduzione di IPv6, scomparirà ogni rischio di esaurimento dell'address space a breve termine.

Ad alcuni potrà sembrare che la dimensione degli indirizzi IPv6 sia addirittura eccessiva, ed infatti durante le fasi iniziali del progetto di IPv6 erano previsti indirizzi di 64 bit. Tuttavia in seguito ci si accorse che solo un address space a 128 bit sarebbe stato in grado di sostenere la crescita di Internet per i prossimi 30 anni, anche in caso di pessima allocazione degli indirizzi. Per ulteriori informazioni si veda [RFC1715].

Gli indirizzi IPv6 sono identificatori a 128 bit, assegnati non a dei nodi, ma alle loro interfacce di rete. Esistono tre tipi di indirizzi globali IPv6:

È importante notare che non esistono indirizzi di tipo broadcast in IPv6, in quanto essi sono stati sostituiti dagli indirizzi di tipo multicast.

La rappresentazione testuale degli indirizzi IPv6 è del tipo x:x:x:x:x:x:x:x, dove le "x" sono i valori, espressi in base esadecimale, delle otto parti a 16 bit dell'indirizzo. È possibile abbreviare una sequenza di zeri con il simbolo ::. Ad esempio, indirizzi IPv6 validi sono 3ffe:8171:51:ffff::5049 e fe80::248:54ff:fe4b:1c6f.

IPv6 definisce inoltre due tipi di indirizzi UNICAST per uso locale. Indirizzi di tipo link-local possono essere utilizzati solo su di un singolo link e sono identificati dal prefisso di 10 bit 1111111010 (fe80::/10); essi vengono utilizzati per l'autoconfigurazione degli indirizzi IPv6 globali associati alle interfacce, e per il neighbour discovery. Gli indirizzi di tipo site-local, al contrario, possono essere utilizzati solo all'interno di un sito e sono identificati dal prefisso di 10 bit 1111111011 (fec0::/10); vengono utilizzati per la costruzione di un address space privato all'interno di una organizzazione.

Per ulteriori informazioni si veda [RFC2373].

La esperienza acquisita in un tre decenni di studi sulle problematiche del routing in una rete enorme ed eterogenea come Internet, ha permesso all'IETF di definire per IPv6 una tipologia di indirizzi globali di tipo aggregabile, che permette di minimizzare le dimensioni delle tabelle di routing.

Le decisioni sull'instradamento dei pacchetti IPv6 vengono effettuate secondo la regola del "longest matching prefix" introdotta da CIDR, ed il formato degli indirizzi globali di tipo UNICAST è il seguente:

Figura 1. Formato dell'indirizzo IPv6 globale unicast

Per ulteriori informazioni si vedano [RFC2374] e [RFC2450].

Alla base dei criteri di progetto di IPv6 vi è anche quello della ottimizzazione delle risorse umane. IPv6 infatti minimizza la necessità di interventi amministrativi nel renumbering dei siti e nell'assegnamento degli indirizzi alle interfacce, introducendo la funzionalità di stateless address autoconfiguration, in alternativa all'autoconfigurazione di tipo stateful (DHCPv6).

Questa nuova ed importante funzionalità consente di configurare gli indirizzi IPv6 assegnati a tutte le interfacce di rete all'interno di una organizzazione (escluse quelle dei router), con il minimo sforzo. Non è richiesto, infatti, alcun tipo di intervento sugli host, ma solo un minimo intervento sui router.

Il meccanismo di autoconfigurazione di tipo stateless permette ad un host di generare i propri indirizzi utilizzando una combinazione di informazioni disponibili localmente e di informazioni provvedute dai router. I router forniscono i prefissi che identificano la sottorete (o le sottoreti) associata ad un link (o ad un sito), mentre gli host generano un identificatore che contraddistingue in modo univoco una interfaccia di rete all'interno del link (o del sito). Gli indirizzi vengono formati combinando il prefisso e l'identificatore. In assenza di router, un host può generare solo indirizzi di tipo link-local.

L'approccio di tipo stateless all'autoconfigurazione è utilizzato quando un sito non è particolarmante interessato ad avere uno stretto controllo sugli indirizzi che vengono assegnati agli host, purché essi siano unici e il routing da e verso di essi funzioni.

Per ulteriori informazioni si vedano [RFC2461] e [RFC2462].

IPv6 è stato appositamente studiato per essere più performante e scalabile di IPv4. Infatti, rispetto ad un pacchetto IPv4, un pacchetto IPv6 ha un header di lunghezza fissa con numero inferiore di campi (8 anziché 12); le operazioni di trasmissione, di forwarding e di ricezione di un pacchetto risultano in questo modo notevolmente semplificate. Anche la gestione delle IP options è stata snellita: ora esse vengono processate solo dal nodo di destinazione (a parte la Hop-by-Hop option, che viene processata da tutti i nodi nel cammino tra sorgente e destinazione). Inoltre, i pacchetti IPv6 non hanno nessun tipo di checksum, dato che il calcolo e la verifica di quest'ultima è una operazione piuttosto dispendiosa e pressochè inutile; infatti essa viene eseguita sia dal protocollo di livello inferiore che da quello di livello superiore. Infine, la frammentazione dei pacchetti IPv6 viene eseguita solo sul nodo sorgente, e non sui router attraverso il cammino di destinazione; questo significa che ora il nodo sorgente deve verificare che la dimensione dei pacchetti inviati non superi il MTU del cammino di destinazione, ma tutto sommato si tratta di un prezzo piuttosto basso da pagare in considerazione del notevole aumento di performance che si ottiene sui router.

Le semplificazioni nel protocollo IPv6 non solo contribuiscono a determinare un notevole incremento di prestazioni rispetto ad IPv4, ma rendono anche più semplice ed economica l'implementazione del protocollo IP sui dispositivi di piccole dimensioni, specialmente se alimentati a batteria. Tuttavia IPv6 si presenta come una tecnologia interessante anche per applicazioni high-performance. Infatti il basso overhead imposto e la possibilità di avere pacchetti di dimensione maggiore di 64KB consentono di utilizzare appieno le potenzialità di reti ad alte prestazioni come ATM, e le capacità di calcolo dei supercomputer (specialmente in ambienti di computazione distribuita).

Per ulteriori informazioni si vedano [RFC2460] e [HINDEN95].

La sfida più grande che dovrà fronteggiare Internet nel prossimo futuro, è quella di completare la transizione ad IPv6 prima che le capacità di routing e di indirizzamento di IPv4 collassino (la transizione sarà molto più semplice se gli indirizzi IPv4 saranno ancora globali ed unici). I tre requisiti che devono essere soddisfatti affinché la transizione ad IPv6 abbia successo sono:

La transizione da IPv4 ad IPv6 sarà verosimilmente molto lunga e delicata, data la enorme base di software IPv4 installato. Infatti, tutto il software di networking dovrà essere modificato. Non solo dovrà essere aggiornato quello che opera a livello rete, ma anche quello che opera a livello di applicazione. Per quanto riguarda Linux, si tratta praticamente dell'intero parco di software disponibile per questo sistema operativo (compresi kernel e glibc, ovviamente).

Ci vorrà un decennio o forse più, prima che una parte significativa di Internet funzioni sulla base del protocollo IPv6. Per questo motivo, IETF ha sviluppato una strategia di transizione molto flessibile, che si basa su un notevole numero di tecniche diverse (DSTM, Tunnel Broker, 6to4, 6on4, ecc...). Ognuna di queste tecniche ha caratteristiche che la distinguono dalle altre, ed ognuna è pensata per una particolare situazione logistica.

Da notare il fatto che molti protocolli hano tentato di rimpiazzare TCP/IP (ad esempio XTP e OSI), tuttavia uno degli elementi che hanno portato al loro fallimento è stato il fatto che per nessuno di essi è mai stata elaborata una strategia di transizione che andasse oltre al semplice dual stack.

Per ulteriori informazioni si vedano [HINDEN95] e [TRANSINTRO].