IPv6 alias IPng: un futuro per Internet e le Intranet
Silvano Gai
5 Luglio 1996
Introduzione
In questi giorni si fa un gran parlare di reti ad alta velocità (ATM, Gigabit Ethernet), delle Intranet, delle reti locali virtuali, ma nessuno parla di una delle cose che cambierà più profondamente l’organizzazione delle nostre reti in futuro e cioè di IPv6.
Qualcuno di voi si chiederà cosa sia IPv6. IPv6 è la nuova versione di quel IP che è alla base di Internet, delle Intranet e di molte reti aziendali. Il lavoro di standardizzazione di IPv6 è partito nel 1991 e la parte principale si è completata in questi giorni con la pubblicazione degli RFC (Request For Comment), gli standard che specificano appunto IPv6 (si veda la sezione 1.9). Durante la fase di standardizzazione, questo nuovo protocollo è stato indicato anche con i termini IPng (IP nuova generazione) o IPv7. Che fine ha fatto IPv5? Se ne sono perse le tracce e quindi si è deciso di non riutilizzare quel numero di versione.
Ma procediamo con ordine. Non si può pensare di spiegare un nuovo protocollo in un singolo articolo per una rivista. Perciò, insieme all’amico Alessandro Degli Occhi, abbiamo pensato di analizzare in questo primo articolo solo le motivazioni alla base di IPv6, ed in particolare perchè è richiesto un nuovo protocollo IP, quali sono le caratteristiche che questo protocollo deve avere e qual è stato il cammino di standardizzazione che ha portato ad IPv6.
Il protocollo stesso, le sue nuove caratteristiche e le modalità di migrazione verrano discusse in altri contributi che appariranno su prossimi numeri di questa rivista e che, riorganizzati e ampliati, costituiranno un libro in italiano che pubblicherò nella primavera prossima con una primaria casa editrice.
Perchè IPv6
La risposta è semplice: "Internet sta divendando vittima del suo successo". Probabilmente molti di voi hanno sentito ripetere questa frase più volte negli ultimi tempi, ma cosa significa in realtà?
L’utente medio ha una visione di Internet tramite le applicazioni che usa quotidianamente per il suo lavoro. Dalla posta elettronica, resa facilmente utilizzabile da pacchetti applicativi quali Eudora e Pegasus, alla navigazione sui server WWW tramite potenti browser quali Netscape o Microsoft Explorer, oggi spesso arrichiti con funzionalità Java. Più in generale tutti gli applicativi di Internet, anche i più semplici quali FTP o Telnet, riscuotono un grande successo tra gli utenti e molte aziende hanno pensato di rimodellare le loro reti aziendali sul modello di Internet creando le Intranet.
Il grande successo di Internet e delle Intranet va di pari passo con quello dell’architettura di rete "Internet Protocol Suite" più comunemente nota come TCP/IP, che ne è alla base.
In particolare l’attuale protocollo IP (Internet Protocol) è un protocollo standardizzato nel 1981 dallo RFC 791 ed è quindi un protocollo ormai un po’ datato anche se mattone basilare dell’archittettura. Per non fare confusione indicheremo nel seguito l’attuale protocollo IP che ha numero di versione 4 con la sigla IPv4, il nuovo protocollo con la sigla IPv6 e useremo semplicemente IP per indicare ciò che è comune ad entrambe le versioni.
IP si occupa di disaccoppiare le applicazioni dalle reti trasmissive, cioè di fornire all’utente la possibilità di usare sempre tutte le sue applicazioni preferite indipendentemente dalla tecnologia di rete sottostante (si veda la figura 1).
Figura 1: IP (Internet Protocol)
Inoltre IP consente di utilizzare tecnologie diverse in parti diverse della rete: ad esempio, reti locali (Ethernet, Token Ring, FDDI) all’interno degli edifici e servizi pubblici a commutazione di trama (frame relay) o di cella (ATM) e canali diretti numerici (CDN) per la parte geografica della rete stessa.
IPv4 raggiunge questo risultato fornendo un servizio che ha due caratteristiche principali:
- indirizzamento universale: ogni interfaccia di rete IPv4 ha un indirizzo univoco a livello mondiale su 32 bit;
- best effort: IPv4 fa il massimo sforzo per consegnare il pacchetto, ma non garantisce nulla al livello superiore nè in termini di percentuale di pacchetti consegnati, nè in termini di tempo impiegato ad effettuare la consegna. IPv4 in sostanza non ha in sè il concetto di qualità del servizio (QoS: Quality of Service).
Queste due caratteristiche, che sono sinora state dei punti di forza per IPv4, rischiano di diventare i suoi principali limiti e spingono all’introduzione di IPv6. Vediamone i motivi.
Perchè un nuovo schema di indirizzamento
Abbiamo già detto che gli indirizzi IPv4 sono su 32 bit, cioè sono disponibili in totale circa 4 miliardi di indirizzi e, non esistendo 4 miliardi di calcolatori al mondo, non è immediato capire il perchè gli indirizzi stiano per esaurirsi. La causa va ricercata nella struttura degli indirizzi IPv4 e nella modalità di assegnazione che causano fortissimi sfridi.
Infatti gli indirizzi IPv4 non vengono assegnati singolarmente (cosa questa ovviamente impossibile per ragioni organizzative), ma a "reti". Le reti possono appartenere a 3 classi diverse:
- Classe A: 128 reti disponibili, ciascuna grande circa 16 milioni di indirizzi;
- Classe B: circa 16.000 reti disponibili, ciascuna grande circa 65.000 indirizzi;
- Classe C: circa 2 milioni di reti disponibili, ciascuna grande 254 indirizzi.
A Gennaio 1996 risultavano assegnate 92 reti di classe A, 5655 reti di classe B e 87.924 reti di classe C. Questi dati evidenziano che la criticità principale è sulle reti di classe B, che per la loro dimensione intermedia sono le più idonee ad essere assegnate ad una organizzazione. Infatti le reti di classe A sono troppo grandi e comunque ne rimangono da assegnare solo 36, mentre quelle di classe C sono troppo piccole. La tabella 1 mostra l’andamento della crescita di reti e indirizzi.
Tabella 1: crescita nel tempo di reti e indirizzi IPv4
Il problema dell’esaurimento degli indirizzi IPv4 viene compreso già nel 1991. In tale anno inizia a verificarsi una crescita nelle domande di assegnazione degli indirizzi più veloce di ogni previsione. Ci si trova nel momento storico in cui Internet sta divenendo l’unica rete per tutti. E quando si dice tutti vuole veramente dire tutti: aziende private e pubbliche, amministrazioni governative e non, università e centri di ricerca e anche e soprattutto privati cittadini. Questo è reso possibile dalla nascita degli ISP (Internet Service Provider) che forniscono a modici costi servizi di interconnessione ad Internet tramite la normale rete telefonica utilizzando prima i modem e ultimamente anche gli accessi ISDN. Una ulteriore svolta è recentissima: l’introduzione dei "cable modem" per fornire Internet a velocità elevata (maggiore di 1 Mb/s) a tutti gli utenti domestici che ricevono la televisione via cavo. In Italia la televisione è ricevuta quasi totalmente via etere e quella via cavo è agli albori ma, nel progetto Socrates di Telecom Italia, già si parla anche di Internet e di cable modem.
Le previsioni del 1991 erano che gli indirizzi di classe B si sarebbero esauriti entro il 1994. A fronte di questa previsione drammatica e per fornire un tempo ragionevole per lo sviluppo e la migrazione ad IPv6 l`IETF (Internet Engineering Task Force), il comitato che prende le decisioni tecniche su IP e su Internet, decise di assegnare non solo reti di classe B, ma anche blocchi di reti contigue di classe C. Ad esempio, una organizzazione che abbia 100 calcolatori con una previsione di crescita a 500 calcolatori può vedersi assegnare, invece di una rete di classe B, un blocco di 4 reti di classe C per un totale di circa 1000 indirizzi.
Questa nuova e più parca filosofia di assegnazione degli indirizzi sposta in avanti la data in cui gli indirizzi saranno esauriti: ci sono previsioni, molto incerte, che identificano una data tra il 2005 e il 2015.
Non c’è rosa senza spine, recita un vecchio proverbio, e anche questo nuovo schema di indirizzamento ha generato immediatamente problemi sui router costretti a mantenere l’informazione di instradamento per ogni rete. Infatti se si assegna una rete di classe B ad una organizzazione i router dovranno avere una sola regola di instradamento, ma se si assegnano 16 reti di classe C i router dovranno avere 16 regole di instradamento diverse, usando 16 volte tanta memoria a livello delle tabelle di instradamento. Per ovviare a questo inconveniente, nel 1992 viene introdotto il CIDR (Classless InterDomain Routing), cioè viene in sostanza eliminato il concetto di classe delle reti a livello di tabelle di instradamento.
Infine viene consigliato che tutte le Intranet usino al loro interno gli stessi indirizzi e a tal fine viene pubblicato lo RFC 1597, poi rivisto dallo RFC 1918, che assegna una rete di classe A (la 10.0.0.0) e alcune reti di classe B e C per le Intranet.
Dovrebbe essere a questo punto chiaro che IPv6 ha necessità di un nuovo schema di indirizzamento che abbia le seguenti caratteristiche:
- un maggior numero di bit in modo che lo spazio di indirizzamento non sia ulteriormente soggetto ad esaurimento;
- uno spazio di indirizzamento non organizzato in classi, ma che utilizzi a livello dei router tecniche di tipo CIDR;
- uno schema di assegnazione degli indirizzi mirato a minimizzare le dimensioni delle tabelle di instradamento sui router e ad aumentare l’efficienza del CIDR;
- indirizzi globali per Internet, e locali per le Intranet.
IPv4 è un protocollo non connesso. Questo significa che trasmette ogni pacchetto indipendentemente da tutti gli altri, specificando nell’header (intestazione) del pacchetto gli indirizzi IPv4 completi del mittente e del destinatario. Il pacchetto non viene marcato come appartenente ad un flusso o ad una connessione, nè viene numerato in alcun modo. Questo implica che non è possibile correggere errori a questo livello e neanche capire se un pacchetto è stato consegnato oppure no e tantomeno qual è stato il tempo di consegna. Un servizio di questo tipo viene detto "Best Effort" (migliore sforzo) in quanto ogni nodo IPv4 esegue il suo "migliore sforzo" per consegnare il pacchetto integro e nel minor tempo, ma non è in grado di garantire neanche che la consegna avverrà.
I protocolli non connessi di tipo best effort sono molto facili da realizzare e hanno un overhead (sovraccarico) limitato e costante. Questo ha permesso ad IPv4 di imporsi e divenire rapidamente quasi l’unico protocollo sopravvissuto a livello 3 del modello di riferimento ISO/OSI.
Tuttavia la disponibilità da un lato di nuove reti ad alta velocità quali ATM in grado di garantire la QoS e la necessità dall’altro di sviluppare nuove applicazioni multimediali che hanno necessità di avere una QoS garantita hanno fatto discutere se la scelta "Best Effort" sia ancora da considerarsi la migliore per IPv6.
Lo IETF ha già identificato da tempo essere un limite di IP la carenza del concetto di QoS e ha sviluppato un protocollo addizionale detto RSVP (Resource reSerVation Protocol) per allocare risorse di rete sui router e renderli quindi idonei a garantire la QoS ad applicazioni che si basano su IPv4, ma che richiedono esplicitamente di avere una data QoS tramite RSVP.
IPv6, pur mantenendosi fedele all’origine non connessa di IPv4, ha cercato di introdurre al suo interno migliori meccanismi di integrazione verso i concetti di QoS e con RSVP.
Le caratteristiche che IPv6 deve soddisfare
Fin qui abbiamo parlato delle ragioni per cui bisogna passare da IPv4 ad IPv6 e abbiamo intravisto alcuni punti in cui IPv6 sarà certamente diverso da IPv4. La domanda che dobbiamo ora porci è: "quali caratteristiche vogliamo mantenere, quali vogliamo eliminare e quali nuove introdurre?".
Uno spettro che lo IETF ha sempre avuto presente è la cosiddetta "sindrome da seconda generazione" in cui si aggiunge tutto ciò che i vari utenti chiedono sino ad ottenere un protocollo lento, ingestibile e quindi inutile.
Passiamo in rassegna le principali apettative emerse nei confronti di IPv6.
Dipende essenzialmente cosa indichiamo con il termine "a sufficienza". Una proposta potrebbe essere quella di avere un indirizzo IPv6 per ogni futuro potenziale utente di Internet. Si può stimare che la crescita della popolazione mondiale raggiunga i 10 miliardi di persone e assumere che ogni persona avrà più di un calcolatore in quanto calcolatori saranno anche, ad esempio, gli elettrodomestici, gli apparati elettromedicali e i dispositivi elettrici in genere. Già oggi sono realtà sistemi di illuminazione domestica in cui tutte le lampade hanno un indirizzo e vengono accesse e spente con messaggi inviati dagli interruttori su un bus di servizio. Nella futura Internet l’utente vorrà ordinare da fuori casa al proprio forno di iniziare a cuocere il tacchino, oppure ricevere un messaggio dall’antifurto casalingo che indichi una possibile intrusione e dare un`occhiata tramite il proprio browser Internet utilizzando una telecamera remota brandeggiabile. Gli esempi si sprecano mentre già sul mercato appaiono telefoni cellulari con incorporato il terminale Java. Una stima di 256 indirizzi IPv6 per ogni abitante del pianeta non è irrealistica.
Una proposta ancora più drastica è quella di prevedere tanti indirizzi IPv6 quanti sono gli atomi dell’universo, consci che occorre almeno un atomo per realizzare un calcolatore. Ma attenti a non esagerare: infatti più indirizzi significa una maggior lunghezza dell’indirizzo IPv6 e poiché sia l`indirizzo del mittente sia quello del destinatario devono essere trasportati all’interno dell’header di ogni pacchetto IPv6 questo vuol dire maggior overhead.
D’altro canto tutti sono concordi nel definire uno spazio di indirizzamento che non sia più soggetto ad esaurimento in futuro.
Oltre a quanti indirizzi assegnare occorre anche considerare l’efficienza dello schema di assegnazione. Uno studio accurato di Christian Huitema propone di definire l’efficienza di assegnazione degli indirizzi H come il rapporto tra il logaritmo in base 10 del numero di indirizzi e il numero di bit dell’indirizzo.
In uno schema ad efficienza massima tutti gli indirizzi sono utilizzati e quindi H è uguale al logaritmo in base 10 di 2, cioè H=0.301. Una analisi degli schemi di indirizzamento reali mostra che H varia tra 0.22 e 0.26.
La decisione finale è di prevedere un milione di miliardi di calcolatori in rete (1015) che con H pari a 0.22 (caso peggiore) richiede 68 bit di indirizzo. Dovendo, per ragioni realizzative, l’indirizzo essere un multiplo di 32 bit si è optato per avere l’indirizzo IPv6 su 128 bit, cioè 16 byte, cioè 4 word da 32 bit.
Indirizzi multicast e anycast
Oltre agli indirizzi unicast a livello 3 (quelli sino ad ora descritti), IPv4 utilizza anche indirizzi multicast o di classe D per applicazioni multimediali quali videoconferenza su Internet. Questi indirizzi multicast sono previsti anche in IPv6.
IPv6 introduce anche un nuovo tipo di indirizzo detto "anycast". Si tratta sempre di indirizzi di gruppo in cui però a rispondere è solo il membro del gruppo più "vicino" al mittente. L’utilizzo degli indirizzi anycast è potenzialmente molto interessante in quanto con un indirizzo anycast si può accedere ad esempio al più vicino router, al più vicino name server o time server.
Unificare Intranet e Internet
IPv6 deve fornire un meccanismo di indirizzamento unificato per Internet e le Intranet, superando le soluzioni transitorie di IPv4 (RFC 1597 e RFC 1918). A tal scopo oltre agli indirizzi globali sono previsti anche indirizzi locali e indirizzi per i link. Gli indirizzi locali sono da utilizzarsi per quei nodi di reti interni alle Intranet, mentre gli indirizzi di link servono per numerare gli estremi di link tra router che hanno quindi rilievo solo per scopi di routing e di gestione.
Sono infine previsti indirizzi compatibili con gli indirizzi IPv4, OSI NSAP e Novell IPX.
Utilizzare meglio le LAN
IPv4, quando opera su una rete locale, ha spesso la necessità di determinare la corrispondenza tra un indirizzo IPv4 e un indirizzo MAC e vicevera. IPv4 effettua queste operazioni tramite un protocollo ausiliario detto ARP (Address Resolution Protocol) che utilizza trasmissioni in broadcast a livello MAC. Un pacchetto broadcast è un pacchetto che viene ricevuto e causa un interrupt su tutte le stazioni, comprese quelle che non usano il protocollo IP. Si tratta di una disottimizzazione che deve essere corretta in IPv6 utilizzando un metodo di "neighbor discovery" su rete locale più efficiente di ARP e che utilizzi trasmissioni in multicast e non in broadcast. Infatti una stazione può determinare a livello di scheda di rete quali multicast ricevere, mentre è obbligata a ricevere tutti i broadcast.
Sicurezza
La sicurezza in IPv4 è oggi gestita tramite particolari router o elaboratori che svolgono il ruolo di "firewall" (muro tagliafuoco). Essi non servono a risolvere problemi di sicurezza intrinseci in IPv4, ma a compensare le debolezze dei sistemi operativi di molti elaboratori e la gestione spesso superficiale che della sicurezza viene fatta a livello di singolo elaboratore.
Ad IPv6 non si chiede necessariamente di migliorare le cose in termini di sicurezza, ma di non peggiorarle. In realtà lo IETF ha definito una serie di procedure di criptografia e autenticazione che saranno disponibili sin dall’inizio in IPv6. Queste procedure saranno però realizzate in modo compatibile anche su IPv4.
Inoltre IPv6 dovrà avere una oculata gestione del "Source Routing" cioè della possibilità di determinare a livello di stazione mittente il cammino che il pacchetto IP deve fare. Questa prestazione, già presente in IPv4, anche se non sempre realizzata od attiva, viene sfruttata spesso dagli hacker per tentare di superare i firewall.
La disponibilità di procedure di sicurezza standard sarà indubbiamente uno degli incentivi principali per molti gestori di rete a migrare ad IPv6.
Routing
È chiaro che questo tema è centrale nel progetto di un protocollo che dovrà instradare i pacchetti sulla Internet del futuro. Se prendiamo come base di partenza il routing di IPv4 vediamo che le tabelle di routing dei router di Internet tendono ad esplodere. Infatti, se non si utilizza il CIDR, ogni singola rete deve essere annunciata con una entry nelle tabelle di instradamento. L’introduzione del CIDR permette di annunciare un blocco di reti con indirizzi contigui (ad esempio, la 195.1.4.0, la 195.1.5.0, la 195.1.6.0 e la 195.1.7.0) con una unica entry specificando quanti bit sono da considerarsi significativi (nel nostro esempio 195.1.4.0/22, cioè qualsiasi rete che ha i primi 22 bit pari a 195.1.4.0).
Il CIDR comunque può fare poco se non è legato all’assegnazione degli indirizzi. Infatti se gli indirizzi vengono assegnati agli ISP (Internet Service Provider) e da questi agli utenti, il CIDR funziona bene in quanto da un punto di vista teorico tutti gli indirizzi di un singolo ISP possono essere annunciati con una sola entry. Possiamo pensare ad una forma di routing gerarchico accompagnata da una forma di assegnazione degli indirizzi anch’essa gerarchica legata alla topologia della rete. Alla radice dell’albero gerarchico possiamo pensare ad una ripartizione degli indirizzi per continenti, quindi all’interno di un continente una ripartizione per ISP, quindi per organizzazione e poi per reti all’interno dell’organizzazione. Questo modello minimizza le tabelle sui router permettendo al CIDR di aggregare gli indirizzi prima per utente, poi per ISP e quindi per continente, ma ha un grosso limite: l’utente non ha più indirizzi a lui stabilmente assegnati.
Se si considera come funziona l’assegnazione degli indirizzi IPv4 oggi, una organizzazione può rivolgersi alle autorità preposte INTERNIC (America del Nord), APNIC (Asia e Pacifico) e RIPE-NCC (Europa) e ottenere indirizzi che l’organizzazione userà indipendentemente dall’ISP cui si collegherà. In futuro l’organizzazione potrà cambiare ISP senza per questo cambiare indirizzi. Con IPv6 quando l’organizzazione cambierà ISP dovrà necessariamente cambiare indirizzi. È addirittura possibile che una organizzazione debba cambiare indirizzi perchè due ISP si sono fusi o separati e quindi per cause indipendenti dalla sua volontà.
Per rendere accettabile in IPv6 un modello di assegnazione degli indirizzi, come quello appena descritto, basato sulla topologia della rete è indispensabile disporre di meccanismi di autoconfigurazione (plug and play) in cui è la rete che dinamicamente assegna gli indirizzi alle stazioni.
Sinora abbiamo parlato del calcolo delle tabelle di instradamento che vengono utilizzate per l’instradamento di default verso una data destinazione. IPv6 dovrà inoltre prevedere la possibilità di avere instradamenti particolari basati su particolari politiche di routing (policy) o sulla richiesta di particolari QoS (dette in questo contesto anche ToS: Type of Service). Un esempio di instradamento con una policy particolare è quello che determina il trasferimento di pacchetti verso una data destinazione lungo un cammino che è determinato anche dall’indirizzo del mittente (cosa questa impossibile in IPv4).
Infine occorrerà che il routing di IPv6 sia in grado di fornire un ottimo supporto alla mobilità cioè a quegli utenti che, dotati ad esempio di un PC portabile e di un telefono cellulare, si connettono ad Internet in luoghi continuamente diversi.
Buon supporto di ATM
La grande convergenza industriale che si sta verificando intorno ad ATM (Asynchronous Transfer Mode) farà di questa tecnologia un attore principale nelle future reti sia a livello geografico sia a livello locale. I progettisti di IPv6 sono consci di questo e hanno cercato di migliorare in IPv6 il supporto per ATM. Ma cosa ha ATM di tanto particolare? Principalmente due caratteristiche: quella di essere una rete NBMA (Non-Broadcast Multiple Access) e quella di supportare la QoS.
Essere una rete NBMA significa essere una rete con molti punti di accesso che però non fornisce un semplice meccanismo per trasmettere un pacchetto a tutte le altre stazioni. IPv4 è stato progettato per funzionare su canali punto-punto quali i CDN che non sono ad accesso multiplo (hanno solo due estremi) o sulle reti locali che sono ad accesso multiplo, ma in cui la trasmissione di un pacchetto ad una singola stazione o a tutte le stazioni ha esattamente lo stesso costo. Altre reti NBMA sono, ad esempio, le reti X.25 e le reti Frame Relay (se dotate di segnalazione), ma la necessità di fornire un efficiente supporto di IP sulle reti NBMA si è posto solo con ATM, proprio in considerazione del grande ruolo che si pensa questa tecnologia avrà nel futuro.
Garantire la QoS significa poter associare ad ogni flusso di dati certe caratteristiche di qualità. Ad esempio, se il flusso di dati è generato da un trasferimento di file è molto importante che il tasso di perdita sia uguale a zero, ma è assolutamente irrilevante il ritardo cui sono soggetti i pacchetti lungo il cammino. Se invece il flusso di dati è generato da una sorgente audio o video, può essere tollerato un certo tasso di perdita dei dati (noi siamo in grado di comprendere segnali audio e video anche se incompleti), ma è fondamentale garantire ritardi limitati e poco varianti da un pacchetto all’altro.
Non va infine dimenticato che la QoS può essere utilizzata solo se gli applicativi la richiedono, cosa che gli applicativi odierni non fanno. Occorre prevedere che gli applicativi richiedano la QoS tramite un protocollo quale RSVP (si veda la sezione 1.2.2) e che questo, operando congiuntamente ad IPv6, trasformi la richiesta in una richiesta di QoS alla rete ATM (si veda la figura 2).
Figura 2: Gestione delle richieste di QoS
Il concetto di flusso
Per semplificare la realizzazione di IPv6 su ATM e semplificare la gestione del QoS è necessario introdurre il concetto di flusso. Un flusso è una sequenza di pacchetti in qualche modo correlati (ad esempio, perchè generati dalla stessa applicazione) e che quindi devono essere trattati coerentemente dal livello IP. I pacchetti appartengono allo stesso flusso in funzione di parametri quali indirizzo di mittente e destinatario, QoS, accounting, autorizzazioni, autenticazione e sicurezza.
Non esistono relazioni tra il concetto di flusso e altri concetti quali la connessione TCP: ad esempio, un flusso può contenere più connessioni TCP. Inoltre occorre evidenziare che l’introduzione del concetto di flusso avviene su un protocollo che è e resta non connesso (spesso detto anche "datagram") e che quindi il flusso non ha come scopi quelli dei protocolli connessi, ad esempio la correzione degli errori. Più in generale, un flusso può avere come destinazione sia una singola stazione sia un gruppo di stazioni e quindi avremo flussi unicast o multicast.
Una volta introdotto il concetto di flusso possiamo introdurre quello di identificatore di flusso (flow label) con cui marcheremo i pacchetti o datagram riservando un campo apposito nell’header IPv6. In questo modo IPv6 ha la possibilità, all’atto della ricezione di un pacchetto, di sapere a quale flusso appartiene esaminado la flow label e quindi conoscere le esigenze del pacchetto in termini di QoS.
Priorità differenziate
Anche se un applicativo non effettua richieste di QoS deve comunque essere possibile differenziare il traffico generato dai principali applicativi in funzione delle esigenze di tempo reale degli applicativi stessi. A tal fine nell’header IPv6 è stato introdotto un campo "priority" su 4 bit per differenziare 16 potenziali priorità di traffico. A oggi sono definite priorità crescenti per news, email, ftp, nfs, telnet, X, protocolli di routing e SNMP.
Il plug and play
Abbiamo già visto nella sezione 1.3.1 come IPv6 necessiti di meccanismi di autoconfigurazione (o plug and play) per gestire gli indirizzi che devono poter cambiare nel tempo. Inoltre una gestione manuale risulterebbe oltremodo scomoda poiché un indirizzo IPv6 richiede 32 cifre esadecimali per essere scritto (ad esempio, FEDC:BA98:1234:5678:0BCA:9987:0102:1230).
Il protocollo DHCP (Dynamic Host Configuration Protocol), disponibile su alcune realizzazioni di IPv4, è stato considerato essere un buon punto di partenza. L’idea è quella di sviluppare un protocollo DHCPv6 che permetta la configurazione automatica degli indirizzi degli host e delle sottoreti, l’apprendimento dei router di default e, tramite una interazione con il DNS (Domain Name Server), anche una configurazione automatica dei nomi degli host.
La realizzazione del DHCPv6 su tutti gli host IPv6 permetterà ai gestori delle reti di rinconfigurare gli indirizzi agendo semplicemente sul server primario DHCPv6.
Il supporto per la mobilità
Come già accennato in precedenza, un sempre crescente numero di utenti di Internet non lavora più seduto alla scrivania del suo ufficio, ma mentre è in viaggio. L’utente mobile è normalmente dotato di un PC portabile con una scheda di rete PCMCIA che lo connette ad un telefono cellulare o a qualche rete pubblica via radio.
IPv4 non fornisce supporto per la mobilità. Infatti ogni calcolatore ha un indirizzo fisso che appartiene ad una rete. Se il calcolatore si connette ad una rete diversa i pacchetti ad esso destinati continuano a raggiungere la rete originale e lì vengono persi.
È chiaro che il requisito di fornire un supporto in IPv6 per la mobilità è di primaria importanza: si stima che, nella sola America del Nord, nel 2007 ci saranno da 20 a 40 milioni di utenti mobili. È altrettanto chiaro che questo è uno dei requisiti più complessi da soddisfare in quanto deve trattare una moltitudine di problemi che vanno da quelli tipici delle trasmissioni via radio (affidabilità, roaming, hand-off) a quelli legati al protocollo IP (identificazione, indirizzamento, configurazione, routing) a quelli molto importanti della sicurezza.
La soluzione che si sta delineando prevede che l’utente mobile abbia due indirizzi, uno "permanente" sulla rete della sua organizzazione e uno "dinamico" dipendente dal punto in cui è connesso ad un dato istante di tempo. Il firewall dell’organizzazione, quando l’utente è in viaggio, agisce come "proxy" per l’indirizzo permanente e stabilisce un tunnel sicuro verso l’indirizzo dinamico.
Transizione semplice da IPv4 a IPv6
Un grande numero di utenti vedrà la transizione ad IPv6 come un qualcosa che occorre rassegnarsi a subire piuttosto che come un potenziale vantaggio. Chi, come il sottoscritto ha vissuto altre transizioni sa come queste, anche se ben pianificate, possano trasformarsi facilmente in un "bagno di sangue". Cambiare il software di rete è molto simile a cambiare la versione del sistema operativo: è un passo che potenzialmente porta qualche incompatibilità e causa la necessità di aggiornamenti hardware e software.
Lo IETF ha deciso di attuare la migrazione con un approccio "dual-stack", ma questo campo è senza dubbio uno di quelli in cui i venditori di apparati si daranno più battaglia per semplificare la vita all’utente e quindi guadagnare quote di mercato. Infatti saranno ben pochi gli utenti che potranno migrare tutta la loro rete ad un’ora X: la maggior parte delle organizzazioni avrà un transitorio che durerà mesi o addirittura anni in cui IPv6 dovrà convivere con IPv4.
Per questa ragione lo IETF ha deciso che IPv4 e IPv6 siano due protocolli diversi cui corrispondono due stack di protocollo separati. Quando una stazione riceve dalla sua rete locale una trama distingue immediatamente dal protocol type se la trama contiene un pacchetto IPv4 o IPv6, esattamente con lo stesso meccanismo con cui oggi distingue un pacchetto IPv4 da un pacchetto Decnet. Infatti sappiamo che i pacchetti IPv4 hanno protocol type 0800h, mentre quelli IPv6 hanno protocol type 86DDh.
Quindi il primo campo dei pacchetti IPv4 e IPv6, che è la versione del protocollo (e può assumere i valori 4 oppure 6), rimarrà inutilizzato in quanto allo stack IPv4 arriveranno solo i pacchetti IPv4 e allo stack IPv6 solo quelli IPv6.
Uno dei passi critici della transizione sarà quella di gestire in parallelo indirizzi IPv4 e IPv6. Sarà necessario un tempestivo aggiornamento dei server DNS seguito da quello dei server DHCP. Una stazione con il dual-stack utilizzerà IPv4 con il relativo indirizzo su 32 bit per comunicare con altre stazioni IPv4, mentre utilizzerà IPv6 con il relativo indirizzo su 128 bit per comunicare con altre stazioni IPv6.
È chiaro che perchè questo approccio funzioni le isole IPv6 devono essere tra loro interconnesse. Tale connettività sarà realizzata tramite una serie di tunnel su Internet e quindi su IPv4, che formeranno una rete sovrapposta detta 6-Bone. Su questo approccio esiste una esperienza positiva che è la costruzione di MBone (la rete per la videoconferenza su Internet) che è stata realizzata con successo seguendo la stessa filosofia.
6-Bone crescerà e alcune isole si connetteranno tra loro direttamente in IPv6 senza bisogno di usare tunnel. Un sempre maggior numero di macchine comunicheranno in IPv6 e arriverà un giorno, detto il "doomsday" (giorno del Giudizio) di IPv4, in cui gli elaboratori che avranno solo IPv4 perderanno la connettività globale diretta in Internet.
Il criterio di scelta
Tutti questi requisiti da soddisfare fanno intravvedere quanto sia stato difficile scegliere il nuovo protocollo IPv6 cui affidare le sorti di Internet e delle Intranet. Ad essi se ne somma un altro: "mantenere semplice il critical router loop". Cosa sia il critical router loop è presto detto: è quell’insieme di linee di codice che instrada la maggior parte dei pacchetti, tutti quei pacchetti che non hanno richieste particolari se non quella di giungere a destinazione. Il critical router loop più di ogni altra cosa determina le prestazioni dei router e una aggiunta non oculata di tutte le nuove prestazioni richieste e precedentemente elencate rischiava di complicarlo inverosimilmente.
Alla fine i progettisti di IPv6, S. Deering e R. Hinden (RFC 1883, "Internet Protocol, Version 6 (IPv6) Specification," December 1995), decisero di far loro una famosa massima di Antoine de Saint-Exupery, l’autore del "Piccolo Principe", bel libro di cui consiglio a tutti la lettura, sulla semplicità architetturale.
La semplicità architetturale
In ogni cosa, si raggiunge la perfezione non quando non c’è più nulla da aggiungere, ma quando non c’è più nulla da togliere.
Antoine de Saint-Exupery
Il risultato è un protocollo con un progetto estremamente pulito e un header di piccole dimensioni con pochi campi. Si consideri che l’header IPv4 (figura 3) è grande 24 byte di cui 8 sono usati per gli indirizzi IPv4 e i rimanenti 16 byte da 12 campi addizionali.
Figura 3: l’header IPv4
L’header IPv6 (figura 4) è grande 40 byte di cui 32 sono usati per gli indirizzi IPv6 e i rimanenti 8 byte da 6 campi addizionali.
Figura 4: l’header IPv6
E tutti i campi per realizzare le molte nuove funzionalità aggiuntive? Sono stati inseriti in degli "Extension Header" che sono presenti solo se la funzionalità è effettivamente richiesta. In questo modo la maggior parte dei pacchetti transita molto velocemente tramite i critical router loop dei router che incontra lungo il suo cammino e solo i pacchetti che hanno richieste particolari hanno un trattamento più sofisticato che prevede l’analisi degli extension header. In ogni caso, molti extension header riguardano funzionalità "end to end" e quindi non devono essere processati dai router, ma solo dai nodi mittente e destinatario (un tipico caso è l’extension header per la criptografia).
Siamo a questo punto balzati alle conclusioni, ma vediamo ora qual è stato il processo decisionale che ha portato alla stesura dello RFC 1883, cioè dello standard IPv6.
Il cammino di standardizzazione
Il cammino di standardizzazione inizia formalmente nel 1992, quando lo IETF nel meeting di Boston emette una "call for proposal" per IPv6 e vengono creati numerosi gruppi di lavoro.
Le principali proposte candidate a divenire IPv6 sono state le seguenti.
TUBA
La proposta nota come TUBA (TCP and UDP over Bigger Addresses) era quella di adottare il protocollo ISO 8473 CLNP come sostituto dell’IPv4, tentando in questo modo una fusione "in extremis" tra il mondo OSI e il mondo Internet. Questo avrebbe permesso di disporre degli indirizzi OSI NSAP su 20 byte e di una piattaforma comune su cui utilizzare protocolli di trasporto OSI quali il TP4 oltre al TCP e all’UDP.
La critica maggiore mossa al CLNP dal mondo Internet era quella di essere stato copiato 10 anni prima da IPv4, introducendo alcune modifiche considerate peggiorative.
I sostenitori della proposta TUBA, durante i due anni di competizioni, sono rimasti molto fedeli al progetto originale del CLNP, rifiutandosi di introdurre aspetti innovativi quali il multicast, la mobilità o la QoS, per ragioni di compatibilità con la base installata OSI (peraltro molto marginale). Questa rigidezza è stata alla base del fallimento della proposta TUBA, cui sta facendo seguito un fallimento generale del CLNP OSI.
IPv7, TP/IX, CATNIP
Robert Ullman propose nel 1992 un nuovo protocollo IP detto IPv7. La proposta fu rielaborata nel 1993 e assunse il nome di TP/IX per indicare la volontà di cambiare contemporaneamente sia il protocollo IP che il TCP. La proposta conteneva idee interessanti per velocizzare il processamento dei pacchetti e un nuovo protocollo di routing denominato RAP. Nel 1994 la proposta ebbe una ulteriore evoluzione tentando di definire un formato unico per pacchetti IP, CLNP e IPX e assumendo la nuova denominazione di CATNIP. CATNIP avrebbe dovuto essere una piattaforma comune su cui appoggiare vari protocolli di trasporto quali OSI/TP4, TCP, UDP e SPX. Gli indirizzi di livello 3 adottati da CATNIP erano quelli OSI/NSAP.
IP in IP, IPAE
IP in IP è una proposta datata 1992 che prevede di utilizzare due livelli di IPv4 per contrastare la carenza di indirizzi a livello di Internet: un livello per realizzare una dorsale mondiale ed un secondo livello all’interno di aree delimitate. Nel 1993 la proposta ebbe una evoluzione e fu chiamata IPAE (IP Address Encapsulation) e fu accettata come soluzione transitoria verso SIP.
SIP
SIP (Simple IP) è una proposta di Steve Deering del Novembre 1992. Essa si basava sull’idea di portare gli indirizzi IP a 64 bit e di eliminare alcune dettagli di IPv4 ormai ritenuti obsoleti. Essa immediatamente trovò l’adesione di diversi costruttori che ne apprezzarono la semplicità.
PIP
PIP (P Internet Protocol) è una proposta di Paul Francis che introduce significative novità sul fronte del routing permettendo una efficiente implementazione del policy routing e della mobilità. Nel settembre 1993 PIP si fuse con SIP dando origine a SIPP.
SIPP
SIPP (Simple IP Plus) cerca di riunire la semplicità realizzativa di SIP e la flessibilità nel routing di PIP. SIPP è stato progettato per funzionare efficientemente su reti ad alte prestazioni, quali ATM, ma anche su reti a basse prestazioni, quali le reti wireless. SIPP ha un header di dimensioni molto contenute e indirizzi su 64 bit.
Particolare attenzione è posta al modo in cui l’header è codificato. Con SIPP l’header può essere processato molto efficientemente dai router e può essere esteso in futuro per inserire nuove opzioni.
La valutazione
Una valutazione comparata delle tre proposte residue (CATNIP, SIPP e TUBA) portò ai risultati contenuti nella tabella 2.
CATNIP
SIPP
TUBA
disponibilità di una specifica completa no
sì
quasi
semplicità no
no
no
scalabilità sì
sì
sì
flessibilità topologica sì
sì
sì
prestazioni medie
medie
medie
robustezza del servizio media
media
sì
meccanismi di transizione medi
no
medi
indipendenza dalle reti sottostanti sì
sì
sì
servizio non connesso (datagram) sì
sì
sì
semplicità di configurazione ignota
media
media
sicurezza ignota
sì
media
unicità dei nomi media
media
media
accesso agli standard sì
sì
medio
supporto del multicast ignoto
sì
medio
estendibilità ignota
media
media
disponibilità di classi di servizio ignota
sì
media
supporto della mobilità ignoto
medio
medio
protocollo di controllo ignoto
sì
medio
supporto del tunneling ignoto
sì
medio
Tabella 2: Analisi comparata delle tre proposte per IPv6
La decisione
La decisione fu presa nel Giugno del 1994 e fu quella di adottare SIPP come base per IPv6 modificando però la lunghezza degli indirizzi da 64 a 128 bit.
Conclusioni
Il punto di non ritorno è probabilmente stato superato, un nuovo protocollo IP è ormai standard (si veda la sezione 1.9) e sarà un attore principale nel nostro futuro. Alcuni contendenti sono usciti sconfitti, tra questi indubbiamente la sconfitta più dura è toccata al CLNP di OSI. Ma è tempo di dimenticare i "se" e i "ma" e di iniziare a lavorare su questo nuovo standard.
Come avrete capito, un articolo, seppur lungo come questo, serve solo a dare un’idea di cosa ci attende. Altri contributi appariranno su questa rivista e un libro in italiano che tratterà completamente IPv6 sarà in libreria nella primavera 1997. A quel punto i principali costruttori avranno una versione di IPv6 disponibile e si potrà iniziare a sperimentare.
Buon lavoro!
- S. Bradner, A. Mankin, "RFC 1752: The Recommendation for the IP Next Generation Protocol," January 1995
- IAB, IESG, "RFC 1881: IPv6 Address Allocation Management," December 1995
- S. Deering, R. Hinden, "RFC 1883: Internet Protocol, Version 6 (IPv6) Specification," December 1995
- R. Hinden, S. Deering, "RFC 1884: IP Version 6 Addressing Architecture," December 1995
- A. Conta, S. Deering, "RFC 1885: Internet Control Message Protocol (ICMPv6)," December 1995
- S. Thomson, C. Huitema, "RFC 1886: DNS Extensions to support IP version 6," December 1995
- Y. Rekhter, T. Li, "RFC 1887; An Architecture for IPv6 Unicast Address Allocation," December 1995
- R. Hinden, J. Postel, "RFC 1897: IPv6 Testing Address Allocation," January 1996
Copyright © 1997-2006 -
Silvano Gai
Ultima modifica:
February 16, 2008