M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1. STRATEGIE EVOLUZIONARIEE RIVOLUZIONARIE: GLI ERRORIDEL PASSATO

S ono ormai passati oltre trent’anni dallanascita del protocollo IPv4 e può essere

sorprendente constatare che il denominato-re comune più basilare di questo protocollo,il trasporto del traffico in modalità besteffort, è ancora oggi uno dei suoi punti di for-za più importanti ed è ancora il servizio di tra-sporto fondamentale di internet. Questo no-nostante i ripetuti tentativi di miglioramentoche si sono susseguiti negli anni ed hannoportato alla standardizzazione di IPv6, cioè,quella che dovrebbe essere la successivaversione del protocollo IP. Dopo dodici annidal rilascio del primo documento di stan-dard, da parte della Internet Engineering Ta-sk Force (IETF), il protocollo IPv6 ha una dif-fusione molto limitata, ciò fa intuire che nonsia affatto semplice modificare il protocolloIP per farlo evolvere. Un’indicazione intuitivadella mole di lavoro svolta nella standardiz-zazione di IPv6 è riportata nella figura 1, chemostra il numero di standard per anno ed il

numero complessivo di standard IPv6 ema-nati dalla IETF. Il numero totale di standard èragguardevole, più di 160 a tutt’oggi; un talenumero di standard già approvati è indice diuna tecnologia ormai in via di maturazione. Èinoltre interessante notare che l’attività di

Nonostante lo straordinario successo dell’IP (Internet Protocol) versione 4, è

necessario far evolvere questo protocollo per rendere scalabili le comuni-

cazioni con utenti mobili. Strategie rivoluzionarie che concepiscono in vitro i

futuri protocolli presentano serie criticità. La rete ha infatti dimostrato che i

suoi cambiamenti avvengono naturalmente, secondo le esigenze del mer-

cato reale. Strategie evoluzionarie più aderenti ai trend del mercato posso-

no avere un maggior successo e dovrebbero tenere conto della grande dif-

fusione delle reti overlay come la telefonia Skype e lo streaming video su IP.

Maurizio DècinaPaolo Giacomazzi

IL FUTURODEL PROTOCOLLOINTERNET

17

3.4

FIGURA 1Numero di standard di IPv6 emanati dalla IETF dal 1995 al 2006

Numero totale di standard IPv6 emessi dal 1995Numero di standard IPv6 emessi per anno

180

160

140

120

100

80

60

40

20

01995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

0

standardizzazione è tutt’ora in accelerazio-ne, anzi, lo scorso anno, il 2006, è in assolutol’anno in cui sono stati emanati più standarddi IPv6. L’indicazione che ricaviamo è cheIPv6 è una tecnologia di interesse crescente.Il fatto che la diffusione di IPv6 sia molto infe-riore, rispetto a quanto ci si potrebbe aspet-tare dallo stato avanzato della sua standar-dizzazione, porta a domandarci quali siano imotivi che possono aver generato, e che at-tualmente mantengono, questo differenzialetra aspettative e realtà. Questi motivi posso-no concretizzarsi in mere difficoltà di rollout,in difficoltà tecnologiche più ampie e profon-de, in soluzioni di fatto che si sono ormai cri-stallizzate e che sono difficilmente gestibilitramite IPv6 o, addirittura, in una mancatacorrispondenza tra le aspettative di chi frui-sce dei servizi offerti dalla rete internet e lenuove potenzialità rese disponibili da IPv6.L’analisi che verrà sviluppata in questo arti-colo ci porterà a concludere che tutte questedifficoltà esistono e che non si può realistica-mente pensare di affrontare tutte le proble-matiche tecnologiche, architetturali e di ser-vizio con un unico protocollo, per quantocomplesso esso possa essere. Per iniziarel’analisi, è utile descrivere in breve un prece-dente tentativo di realizzare qualcosa di simi-le alla “Internet del futuro”: l’ATM (Asyncro-nous Transfer Mode), una tecnologia emersanella metà degli anni ‘80 e che per qualcheanno, fino all’inizio degli anni ‘90, è stataconsiderata come la vera tecnologia di comu-nicazione del futuro. Ci si sbagliava.ATM: Asynchronous Transfer Mode o“Another Terribile Mistake?” Questo è ciò chemoltissimi professionisti addetti ai lavori, ri-cercatori universitari e aziendali e consulentisi sono chiesti nei primi anni ‘90, quando do-po quasi un decennio di sforzi di ricerca e svi-luppo su ATM si produsse una tecnologia dicomunicazione di qualità eccezionale ma didiffusione molto limitata. Dopo vent’anni,ATM esiste ancora come tecnologia di nicchia,essenzialmente utilizzata dai carrier per vir-tualizzare il trasporto sulla rete fisica SDH.Una fine misera per uno sforzo mondiale cheha visto per molti anni coese le industrie e leuniversità di tutto il mondo per progettare latecnologia di comunicazione “definitiva”.Senza entrare nei dettagli, il sostanziale falli-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

18

GLOSSARIO

Best-effort: la modalità di trasporto dell’informazione classica di Internet edi IPv4. Nella modalità best-effort, la trasmissione di un pacchetto dati av-viene senza garanzie. In particolare, il pacchetto può essere perduto, i pac-chetti successivi di una comunicazione possono giungere alla destinazionein modo disordinato, cioè, con una sequenza diversa da quella di immissio-ne in rete alla sorgente. Nella modalità best-effort i ritardi di trasferimentodei pacchetti non sono controllati e, infine, un pacchetto può giungere du-plicato alla destinazione. Può sembrare che una modalità di comunicazionecon queste caratteristiche sia di bassa qualità. D’altra parte, la rete internetdeve il suo successo alla comunicazione best-effort che a tutt’oggi è ancorala modalità di trasferimento più utilizzata.

IPv4: protocollo IP, versione 4, utilizzato in internet per il trasporto unifor-me di tutte le tipologie di traffico come dati, voce e video. Il protocollo IPv4è ormai molto vecchio, dato che la sua prima standardizzazione risale al1980. D’altra parte, IPv4 è tutt’ora il protocollo di rete utilizzato in internet ela sua radicale semplicità ne ha finora spinto l’evoluzione rapida.

IPv6: il protocollo IP di generazione successiva a IPv4. Nato dall’esigenzainiziale di espandere lo spazio degli indirizzi di IPv4, IPv6 implementa unaserie di miglioramenti ulteriori. Le difficoltà incontrate da IPv6 nella pene-trazione nel mercato reale dipendono in parte dalla difficile coesistenza diIPv6 con IPv4, che richiede funzioni di traslazione piuttosto complesse.

Multicast: la comunicazione multicast o punto-multipunto vede coinvolteuna sorgente d’informazione e molteplici destinazioni, mentre la più nota ediffusa comunicazione punto-punto coinvolge una singola sorgente e unasingola destinazione. La comunicazione multicast è particolarmente adattaalla distribuzione di contenuti multimediali audio/video (per esempio film,eventi sportivi) dove un singolo fornitore di contenuti intende raggiungereun’ampia utenza, con il medesimo contenuto. In questi casi, la comunica-zione multicast può ridurre significativamente i costi di distribuzione delcontenuto rispetto all’utilizzo di una comunicazione punto-punto dalla ser-gente del contenuto ad ogni destinazione.

Overlay: un sistema overlay è costituito da componenti applicative ese-guite dai computer degli utenti del sistema stesso. I computer degli uten-ti diventano i nodi del sistema overlay e costituiscono una rete virtualecostruita su internet. Il concetto architetturale di sistema overlay è utiliz-zato dai sistemi peer-to-peer per la condivisione di file (per esempio Ka-zaa, Gnutella), per la telefonia su internet (per esempio Skype) e per la di-stribuzione di contenuti multimediali su internet in modalità streaming(per esempio CoolStreaming).

Streaming: modalità di trasporto di contenuti multimediali in tempo reale, confruizione del contenuto contestuale alla distribuzione. Nella fase iniziale del tra-sferimento streaming, una prima parte del contenuto viene accumulata in unbuffer nel client dell’utente (il playout buffer). Quando il livello di riempimentodel buffer raggiunge una predeterminata soglia minima, inizia la riproduzionedel contenuto tramite il client dell’utente. Il buffer viene letto (svuotato) dal clientalla velocità di riproduzione specifica del contenuto e contemporaneamenteviene riempito con le successive parti di contenuto che sono nel frattempotrasferite via internet. Il playout buffer disaccoppia la rete dal sistema di ripro-duzione del client, infatti, anche se la rete rallenta temporaneamente e la ve-locità di svuotamento del buffer è più elevata di quella di riempimento, il buffercontinua a fornire contenuto al sistema di riproduzione del client. Ovviamente,se il periodo di rallentamento della rete ha una durata eccessiva, il buffer primao poi si svuota e si ha un “buco” nella riproduzione del contenuto. Uno dei com-promessi più critici del trasporto in modalità streaming è la soglia di riempi-mento del playout buffer. Se nel buffer è grande la frequenza dei “buchi” nel-la riproduzione del contenuto è piccola, ma ciò è pagato con un ritardo siste-matico più elevato. Il compromesso dipende dalla tipologia di contenuto: perla visione di un film si può essere disposti a sopportare un ritardo iniziale con-sistente, ma per eventi sportivi in tempo reale, per esempio una partita di cal-cio, il ritardo ammissibile dall’utenza è molto più basso.

mento di ATM è stato l’approccio puramentetecnologico che si è adottato nella sua conce-zione e nel successivo progetto e sviluppo.Grazie a molto impegno e lavoro, sono statiindividuati i requisiti della “migliore” tecnolo-gia di comunicazione. ATM è stato realmentecreato e prodotto e gli scopi tecnologici sonostati raggiunti, ma nel frattempo il mondo èandato avanti e IPv4, nella sua semplicità, haconquistato il mercato, di conseguenza ATM èstato relegato in mercati di nicchia. È interes-sante ed istruttivo constatare che il mercatodella comunicazione è stato conquistato dauna tecnologia radicalmente semplice, IP. L’analisi delle cause del sostanziale insucces-so di ATM è propedeutica alla comprensionedi come le correnti esigenze dell’utenza dellarete internet possano essere efficacementesoddisfatte da un nuovo insieme di tecnolo-gie e di quali siano gli errori più pericolosi daevitare. ATM è stato concepito con poca con-siderazione rispetto a ciò che stava accaden-do nel mondo IP. In particolare, le applicazio-ni distribuite, già ai tempi di ATM, comunica-vano tramite TCP/IP e la rapida ascesa delmercato di tali applicazioni ha portato ad ac-crescere l’importanza strategica di TCP/IP. Ilcircolo virtuoso che si è creato tra l’ampia edeterogenea potenzialità di servizio delle ap-plicazioni distribuite e la semplicità di comu-nicazione ad esse offerta dal TCP/IP ha per-messo la rapida penetrazione di tale proto-collo nel mercato dell’ICT. Nel frattempo, ATMfu teorizzato e sviluppato nei laboratori.Pronto per l’entrata nel mercato, ATM si è tro-vato di fronte ad applicazioni progettate esviluppate per essere trasportate tramiteTCP/IP e un protocollo di rete (IP) già sceltodal mercato reale come il vero “collante” del-le reti. Le prospettive di ATM, a quel punto,erano già chiuse prima di aprirsi. Certo, ATMoffriva una qualità del trasporto in rete in-commensurabilmente superiore ad IP, ma illegacy che ormai si era creato aveva (ed oggiha ancor di più) un’inerzia tale che la “mera”elevatissima qualità tecnologica offerta daATM non è stata sufficiente a superare.È molto importante fare tesoro delle lezionidel recente passato: la definizione dogmatica,tramite teorizzazione aprioristica e standar-dizzazione di un nuovo protocollo si scontracon l’imponente forza di inerzia del legacy e

delle nuove fasi tecnologiche e di servizio chesi susseguono a ritmo crescente. Una dellepiù importanti lezioni che possiamo impararedal passato è che la migrazione verso l’“Inter-net del Futuro” dovrebbe in primo luogo indi-viduare le vere esigenze di cambiamento e mi-glioramento, sia dal punto di vista puramentetecnologico sia per quanto riguarda i servizi ele necessità del mercato. Queste esigenzevanno soddisfatte con miglioramenti tecnolo-gici o, se necessario, con vere e proprie “rivo-luzioni”, ma in armonia con gli sviluppi che ilmercato, indipendentemente dagli enti distandardizzazione e dai costruttori di apparatidi rete, propone e immette nella realtà di in-ternet. Uno dei più importanti di questi feno-meni è il networking overlay.

2. I SISTEMI OVERLAYE IL PEER-TO-PEER

I sistemi overlay sono noti universalmentecome “sistemi peer-to-peer”, anche se nonsono esattamente sinonimi: i sistemi peer-to-peer sono un caso particolare di sistemaoverlay. Attualmente, la grande maggioran-za dei sistemi overlay utilizzati in internet èdi tipo peer-to-peer, per cui si utilizzerannooverlay e peer-to-peer come sinonimi. I siste-mi peer-to-peer sono nati come comunitàper la condivisione di file (Gnutella, Bit Tor-rent, Kazaa ecc.): l’utente di un sistema peer-to-peer, attraverso la condivisione di file,può scaricare da altri utenti, in quel momen-to in linea, i file che gli interessano (musica,video ecc.). L’evoluzione successiva dei si-stemi peer-to-peer ha rivoluzionato il merca-to della telefonia su internet. Per esempio,Skype è una vera e propria rete telefonicaoverlay che permette a due persone chestanno utilizzando computer in rete di telefo-narsi tramite internet, senza utilizzare la retetelefonica fissa o radiomobile. La terza onda-ta dei sistemi peer-to-peer, tuttora in fase dirapida ascesa, riguarda lo streaming audio evideo. Attraverso questi sistemi (Coolstrea-ming, PPlive, QQlive, Octoshape ecc.) è pos-sibile fruire, tramite la propria connessionead internet, di contenuti audio/video, addi-rittura in tempo reale (per esempio eventisportivi) o quasi in tempo reale.I sistemi overlay costituiscono un fenomeno di

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

19

0

0

0

1

0

importanza strategica primaria. Basta consi-derare, infatti, che per un tipico carrier euro-peo, il traffico trasportato relativo ad applica-zioni peer-to-peer, supera ormai il 50% del to-tale. Il peer-to-peer, quindi, costituisce la mag-giore aliquota, tuttora in crescita, del trafficotrasportato nella rete internet. È altrettanto in-teressante notare che il traffico relativo alla te-lefonia trasportata su IP e ai dati business, checostituisce un’aliquota sensibilmente inferioreal 50% del totale traffico di un carrier, producefino al 60-70% del fatturato complessivo. I ser-vizi peer-to-peer sono frequentemente fruitidall’utenza residenziale tramite connessioniADSL pagate spesso a canone fisso. In tal mo-do, si è creato un modello di business nel qua-le la telefonia da computer a computer è tassa-ta a canone e non a tempo, in contrasto con ilclassico modello di business telefonico. I car-rier che forniscono sia servizi telefonici siaconnessione ADSL a internet vedono erodersiprogressivamente il fatturato relativo alla te-lefonia, dovuto alla parziale migrazione di unaparte delle telefonate su Skype.I sistemi peer-to-peer, che costituiscono un’in-novazione tecnologica totalmente indipen-dente dal corrente sforzo di standardizzazionedi IPv6, hanno già prodotto uno spostamentopari circa al 10% del business dei carrier. Lostreaming multimediale, già fruibile in moda-lità peer-to-peer, promette ulteriori sensibilimutamenti nel business dei distributori di con-tenuti. Le prime avvisaglie di questo fenome-no, che si prospetta dirompente almeno tantoquanto quello della telefonia peer-to-peer, so-no già state riscontrate, per esempio, nellecause legali intentate da alcuni distributori dicontenuti nei confronti di chi abilita o facilita lafruizione in modalità peer-to-peer di contenutiprotetti dai diritti d’autore o di distribuzione.Nell’identificare le migliori linee di sviluppodella internet del futuro, il peer-to-peer e, piùin generale, il networking overlay, è un feno-meno da tenere in grande considerazione.Qualsiasi nuova concezione tecnologica equalsiasi relativo sviluppo avulsi da questarealtà sono probabilmente destinati a rima-nere esercizi teorici, di scarso o nullo interes-se per le applicazioni pratiche e quindi supe-rati dalla realtà ancor prima di essere inseritinel mercato. Seguendo questa filosofia, sicercherà ora di individuare le problematiche

tecnologiche e di servizio più importanti e si-gnificative dei sistemi peer-to-peer, in modotale da identificare i requisiti ai quali dovreb-be aderire uno sviluppo di internet che asse-condi il fenomeno del peer-to-peer.

2.1. La telefonia peer-to-peer: SkypeIl concetto di base di sistema overlay è illu-strato nella figura 2, con particolare riferi-mento al sistema Skype per la realizzazionedella telefonia su internet in modalità peer-to-peer. La rete internet “fisica”, costituitadai link di comunicazione, dai router, dagliswitch, cioè, da tutti gli apparati che concor-rono alla creazione della comunicazioneend-to-end, è la rete underlay. Alla rete un-derlay partecipano anche i computer degliutenti della rete internet. Il sistema overlay ècostituito da componenti applicative che ri-siedono principalmente sui computer degliutenti della rete internet (chiameremo que-ste componenti applicative gli overlayclient). Nel sistema overlay, gli overlay clientassumono il ruolo di nodo della rete overlay.In pratica, si può pensare all’overlay clientcome ad un router del sistema overlay. Glioverlay client costituiscono una rete logica, alivello applicativo, sulla rete underlay. La fi-gura 2, quindi, mostra due reti sovrapposte,ma solo la rete underlay è costituita da veriapparati, la rete overlay è virtuale. Questarete virtuale, nel caso di Skype, ha a sua vol-ta due livelli gerarchici e ha strette analogiecon la tradizionale rete telefonica. I nodi dellivello gerarchico superiore, detti supernodi,hanno forti analogie con le classiche centralitelefoniche di transito e, in effetti, la rete lo-gica di Skype ha qualche analogia con laclassica rete telefonica a due livelli deglioperatori. Ogni elemento della rete overlayha un corrispondente elemento nella reteunderlay, nella maggior parte dei casi que-sto elemento è il computer che implementain software le funzionalità del nodo al livellooverlay. Nella figura 2, è mostrata con una li-nea tratteggiata la corrispondenza tra alcuninodi e supernodi di Skype con i computerche, al livello underlay, li istanziano.In Skype, e in tutti i sistemi overlay, la reteoverlay è creata sfruttando le risorse di com-putazione, memoria e disco dei client, nonchéla banda trasmissiva della connessione di rete

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

20

degli stessi client nei due sensi di trasmissio-ne verso la rete internet. Si osservi che la ban-da di upload, da computer a rete, è ugualmen-te importante rispetto a quella di download eche i supernodi offrono alla rete peer-to-peergrandi risorse di calcolo e di banda. Il softwa-re applicativo organizza queste risorse per co-stituire il sistema complessivo per l’erogazio-ne del servizio. Client con una CPU potente,ampia memoria, alta affidabilità e una buonaconnessione a internet sono riconosciuti dalsistema e, prima o poi, diventano supernodi(in alcuni sistemi, anche a insaputa del pro-prietario del computer) assumendo un ruolopreminente nella rete overlay, per esempio,instradando chiamate telefoniche di terzi.

2.2. La peer-to-peer streaming TV e ilmulticasting overlayGli utenti dei sistemi peer-to-peer streamingTV fruiscono di contenuti televisivi, anche intempo reale, tramite il loro computer connes-so a internet e, come fattore distintivo, questi

sistemi hanno un numero elevatissimo diutenti che possono raggiungere, su scala pla-netaria, sfruttando pienamente le potenzialitàdel multicasting, cosa che, con il protocollo IPutilizzato in modo naturale (underlay), non èpraticamente possibile. Come già evidenzia-to, i computer degli utenti del sistema overlaycostituiscono i nodi della rete di distribuzioneoverlay. Questa rete logica, nel più semplicedei casi, è un vero e proprio albero di distribu-zione. Il contenuto televisivo è immesso in re-te dal nodo “radice” dell’albero, che lo distri-buisce ad un numero limitato di utenti. Ogniutente ripropaga il contenuto verso altri uten-ti realizzando a tutti gli effetti una progressio-ne geometrica del numero di utenti che frui-scono dello stesso contenuto. In pochi pas-saggi, il numero di utenti che fruisce del con-tenuto può diventare enorme.Le risorse per realizzare questa distribuzionesono la capacità di calcolo e la memoria deicomputer connessi al sistema e la banda delcollegamento (per esempio, banda asimme-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

21

0

0

0

1

Nodo

La rete overlay di Skype

La rete underlay

NodoNodo

Nodo

Nodo

Nodo

NodoNodo

SupernodoSupernodo

Supernodo

Internet

PSTN/GSM/UMTS

Supernodo

gateway

gateway

Nodo

Nodo

Nodo

Nodo

FIGURA 2I sistemi overlay:la rete overlaydi Skype

0

trica nei sistemi ADSL) ad internet dei compu-ter. Con computer e con collegamenti ad in-ternet di fascia media, è possibile creare unsistema di distribuzione su scala planetaria.Le risorse del sistema, infatti, aumentano al-l’aumentare della dimensione dell’utenza,creando una notevole scalabilità naturale delsistema stesso che vede aumentare le risorsecomplessive di computazione e di trasmissio-ne di pari passo all’aumentare della doman-da di fruizione. Dato che ogni utente che si in-serisce nel sistema mette a disposizione ulte-riori risorse di computazione e trasmissione,la dimensione complessiva dell’utenza del si-stema di peer-to-peer streaming TV può cre-scere senza alcun evidente limite teorico.L’albero di distribuzione multicast è al livellooverlay ed è quasi ironico ricordare che al li-vello underlay ogni ramo dell’albero di distri-buzione è realizzato tramite una comunica-zione punto-punto (unicast) e che il livellounderlay è completamente agnostico rispet-to al fatto che al livello overlay la distribuzio-ne è multicast: i sistemi di peer-to-peer strea-ming TV sfruttano la capacità della rete un-derlay di creare comunicazioni punto-puntoper realizzare ciò che la rete underlay non èsostanzialmente capace di fare su scala glo-bale: la comunicazione multicast.

2.3. Le problematiche tecniche dei sistemioverlayA valle delle precedenti discussioni, è ragio-nevole concludere che la rete internet del fu-turo non può svilupparsi in modo indipen-dente dai sistemi overlay, anzi, si dovrebbecercare di facilitare ancor di più l’espansionedi servizi così di successo e di ridurne i costiin termini, per esempio, di risorse necessarieper farli funzionare. È soddisfacente consta-tare che IPv6 implementa in modo naturaleuno dei principali fattori di facilitazione tec-nologica dei sistemi peer-to-peer: indirizzi IPlunghi, di 128 bit, anziché di soli 32 bit degliindirizzi IPv4. Può sembrare strano che lalunghezza degli indirizzi possa costituire unproblema per i sistemi peer-to-peer, ma mo-streremo ora che il problema è serio, tanto daassumere una valenza strategica.Con riferimento alla figura 2, in un qualunquesistema peer-to-peer si arriva al momento nelquale tra due client deve avvenire uno scam-

bio di informazioni, anche intenso, per tra-sportare un file, per effettuare una chiamatatelefonica o per trasferire uno stream au-dio/video. La cosa può sembrare semplice: idue client si conoscono reciprocamente esanno come raggiungersi tramite i rispettiviindirizzi IP, quindi, sembra che lo scambiopossa avvenire senza problemi. Purtroppo,spesso questo non è vero, a causa della NAT(Network Address Translation), che in molticasi costringe i client che devono scambiarsiinformazioni a transitare attraverso un su-pernodo, come mostrato nella figura 2, inve-ce di comunicare direttamente. Questo com-porta un notevole consumo di risorse ma,prima di affrontare questo aspetto del pro-blema, analizziamo i motivi per i quali laNetwork Address Translation è necessaria eperché comporta a sua volta la necessità deltransito attraverso i supernodi.

2.3.1. IL CONFLITTO TRA NETWORK ADDRESS TRANSLATION

E I SISTEMI OVERLAY

La NAT è necessaria perché gli indirizzi IPv4 so-no pochi. Quando fu definito il protocollo IPv4,32 bit per codificare gli indirizzi di rete sembra-vano sovrabbondanti (232 = 4.294.967.296),ma ora i quattro miliardi di indirizzi IPv4 dispo-nibili sono ormai esauriti. Il protocollo IPrichiedeche ogni interfaccia di rete sia contraddistintada un indirizzo, cioè, ogni dispositivo, compu-ter, stampante, server, ogni interfaccia di ognirouter ecc. richiede un indirizzo, diverso da tut-ti gli altri. Anche con un’approssimativa valuta-zione di buon senso si conclude che gli indi-rizzi disponibili sono meno di quelli già in cam-po. Ciò è reso possibile dalla tecnica dellaNetwork Address Translation (NAT).La NAT espande artificialmente, senza veri epropri limiti superiori, lo spazio degli indirizziIPv4. Esistono alcuni intervalli di indirizzi IPv4detti “indirizzi privati” o, con un curioso emolto utilizzato neologismo, gli indirizzi “nat-tati”, che sono riusabili a piacere all’internodi reti chiuse. Per esempio, un’azienda puònumerare le interfacce della sua rete con indi-rizzi “nattati”. Le comunicazioni all’internodell’azienda sono garantite in modo stan-dard. Le comunicazioni verso l’esterno sonoinvece da gestire opportunamente, perchéaltre aziende o persone fisiche possono uti-lizzare gli stessi indirizzi “nattati”ed è assolu-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

22

tamente necessario evitare ambiguità. L’evi-dente collisione degli indirizzi “nattati”è evi-tata vietando di utilizzare indirizzi nattati al difuori delle reti private. Quando un pacchettogenerato da un computer con indirizzo “nat-tato”deve transitare sulla rete internet pub-blica, un dispositivo apposito, la NAT box, po-sto all’interfaccia tra la rete pubblica e la reteprivata, provvederà a traslare l’indirizzo “nat-tato”in modo che il pacchetto si presenti sul-la rete pubblica con un indirizzo valido glo-balmente. In molte tipologie di NAT box, tutti ipacchetti che transitano attraverso la NATbox verso la rete pubblica presentano comeindirizzo IP di sorgente l’indirizzo della NATbox, indipendentemente dall’indirizzo delcomputer che li ha generati. Questo risultato,apparentemente paradossale, è possibile inquanto la NAT box, mediante complicati mec-canismi che non trattiamo qui, riesce comun-que a garantire la coerenza end-to-end delleconnessioni che la attraversano. Il risultato ènotevole: con un solo indirizzo valido global-mente, quello della NAT box, è possibile ge-stire le comunicazioni di un’intera rete priva-ta di computer. Questo garantisce un effettodi leva talmente elevato sul numero di indiriz-zi disponibili che, tramite le NAT box, è possi-bile espandere in modo virtualmente illimita-to lo spazio degli indirizzi IP.Purtroppo, questa espansione virtuale degliindirizzi IPv4 è pagata con diversi tipi di svan-taggi e, in questa sezione, ci occupiamo diquelli direttamente connessi alle attività deisistemi overlay, che necessitano di comuni-cazione tra i client. Se i due client che devonocomunicare sono “nattati”, una comunica-zione diretta tra i client è, in molti casi impos-sibile, dipendentemente dal tipo e dalla con-figurazione delle NAT box. Infatti, l’indirizzo“nattato”dei due client non è noto al di fuoridella rispettiva rete privata e, in mancanza diquesto, non si riesce a stabilire una connes-sione. In questo caso, entrambi client devo-no prima connettersi a un supernodo. Que-sto è sempre possibile perché, per definizio-ne, i supernodi sono dotati di indirizzi IP pub-blici. A questo punto, la connessione tra iclient è spezzata in due segmenti (da client asupernodo e da supernodo all’altro client).Questo è il caso mostrato nell’esempio di fi-gura 2: due nodi, che assumiamo “nattati”,

devono comunicare e per farlo utilizzano co-me relay il supernodo.Il costo di questa modalità di comunicazioneè elevato. Quando la comunicazione tra client“nattati”avviene in due tratte nella rete over-lay, nella rete underlay questo corrisponde adue connessioni end-to-end distinte che ov-viamente aumentano la quantità di risorsenecessaria per effettuare il trasferimento diinformazione tra i due client. La percentualedi client “nattati”è già molto elevata ed è incontinua crescita, per cui un’aliquota signifi-cativa (anche se difficile da quantificare pre-cisamente) del traffico peer-to-peer è costi-tuito dai rilanci delle connessioni tra client“nattati”attraverso i supernodi. Questo feno-meno assume un’importanza ancora maggio-re se si ricorda che il traffico peer-to-peer co-stituisce ormai più del 50% del totale trafficodi internet. Si può concludere che in prospet-tiva una parte del traffico di internet, che po-trebbe forse raggiungere l’ordine del 20%(una previsione precisa è difficile), sarà ri-dondante e servirà solamente per aggirare ilproblema della scarsità degli indirizzi. Già og-gi questa aliquota di traffico “address-rela-ted” è notevole, tuttavia mancano studi pre-cisi che ne valutino esattamente il volume. Inprospettiva, pagare con una frazione impor-tante della capacità di internet il fatto di ave-re indirizzi corti sembra essere un prezzo ab-norme. In tal senso, è consolante constatareche IPv6 ha indirizzi di ben 128 bit e che, unavolta terminata la messa in campo di IPv6, ilproblema sarà rimosso alla radice. L’impattoquantitativo del problema NAT-overlay è tal-mente intenso che da solo sembra esseresufficiente a giustificare una migrazione daIPv4 a IPv6, questo nonostante sia ancoraabbastanza diffuso un giudizio negativo sullareale necessità di ampliare lo spazio degli in-dirizzi: “perché farlo? tanto c’e’ NAT”.L’inefficiente cooperazione tra i sistemi over-lay e NAT ha anche altri effetti negativi. Se siconsidera, per esempio, la telefonia peer-to-peer, dalla precedente discussione si capisceche le telefonate tra client “nattati”devonotransitare attraverso un supernodo, consu-mandone le risorse di CPU, memoria e la ca-pacità della connessione a internet. Per quan-to riguarda Skype, studi empirici hanno mo-strato che mediamente un supernodo è in gra-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

23

0

0

0

1

0

do di fare da transito per un massimo di pochediecine di telefonate contemporanee. Questopone un limite alla scalabilità di Skype e, piùin generale, dei sistemi peer-to-peer: il siste-ma può scalare fino a che ci sono supernodidisponibili. Visto che i supernodi sono compu-ter di profilo più elevato della media, con indi-rizzi pubblici (non nattati) e con connessionead internet con capacità elevata, è ovvio cheessi rappresentano la vera risorsa scarsa delsistema ed il più stretto collo di bottiglia per lascalabilità dei sistemi overlay. Si può conclu-dere che una delle esigenze primarie dello svi-luppo futuro di internet è di avere a disposi-zione uno spazio di indirizzi più ampio: ciò di-minuirebbe la necessità del NAT con molti ef-fetti positivi, non solo sui sistemi overlay.

3. SEPARAZIONE DI IDENTITÀE INDIRIZZI E L’HOST IDENTITYPROTOCOL (HIP)

Un grave problema attuale di internet è lamolteplicità dei significati e dei conseguentiutilizzi dell’indirizzo IP degli host. In primoluogo, l’indirizzo IP è un’informazione di loca-lizzazione, che permette ai pacchetti IP di rag-giungere la loro destinazione. D’altra parte,l’indirizzo IP è anche l’effettiva identità del-l’host, cioè, per un host che comunica con unpeer remoto, l’identità del peer è ancora unavolta l’indirizzo IP del peer stesso. Le conse-guenze di questo sovraccarico semantico del-l’indirizzo IP sono di portata addirittura impo-nente. Infatti, il punto di terminazione logicadelle connessioni a livello applicativo, per leapplicazioni distribuite, è il socket, cioè, l’indi-rizzo IP dell’host e la porta logica che corri-sponde al servizio indirizzato sull’host stes-so(Figura 3 A). Una comunicazione tra due ap-

plicazioni su internet è, dal punto di vista del-le applicazioni, un collegamento logico tradue socket, uno per ognuno dei componentiapplicativi coinvolti nella comunicazione. Da-to il doppio significato, identità e locazione,dell’indirizzo IP, il collegamento logico tra dueapplicazioni viene ad essere molto rigido: al-l’atto dell’instaurazione della connessione lo-gica, un’applicazione stabilisce che intendecomunicare con uno specifico host in una spe-cifica locazione, entrambe descritte dall’indi-rizzo IP di quell’host. È naturale chiedersi cosasuccede se uno dei due host si muove: cam-bia solo la locazione oppure cambia sia la lo-cazione che l’identità? Purtroppo, cambianoentrambe. Questo pone problemi nella ge-stione della mobilità che ancor oggi si posso-no considerare come essenzialmente irrisolti.Quando un host viene collocato in un'altrasede e quindi cambia indirizzo IP, cambia an-che identità. Addirittura, quando un disposi-tivo è in movimento, esso cambia ripetuta-mente identità col passare del tempo. Pur ri-cordando che la semplicità del trasferimentopunto-punto tra due dispositivi in posizionefissa è uno dei fattori che ha permesso il tra-volgente sviluppo di internet, si deve consta-tare che ora la comunicazione, fortementevincolata ad un concetto di posizione staticae poco mutabile dei dispositivi in rete, sta po-nendo seri vincoli tecnologici allo sviluppodelle applicazioni e, quindi, della internetstessa. Molte moderne applicazioni fruireb-bero di grandi vantaggi da un modello piùastratto della comunicazione, nel quale il di-spositivo che invia un’informazione non devenecessariamente conoscere l’indirizzo e/o lalocazione dei dispositivi che deve raggiunge-re, ma solo la loro identità. Il mittente del-l’informazione può in tal modo essere agno-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

24

Servizio ServizioSocket Socket

Locazione LocazioneIndirizzo IP Indirizzo IP

Endpoint Endpoint Identità HIP

A B

FIGURA 3A Il problema

della mobilità in IP,B Identità HIP

stico rispetto alla effettiva locazione del de-stinatario e preoccuparsi solo della sua iden-tità. Una tale potente astrazione permette-rebbe di gestire in modo naturale la mobilitàdei dispositivi, con una conseguente notevo-le flessibilità e scalabilità delle procedure perla gestione della mobilità. Anche il multicastsarebbe applicabile in modo semplice, bastipensare al fatto che la stessa identità può es-sere assegnata a tutti gli host che devono ri-cevere una data informazione: automatica-mente, questa sarebbe instradata verso tuttii destinatari realizzando il multicast in modonaturale. In conclusione, la mobilità ed il mul-ticast sollevano problemi di scalabilità prati-camente insormontabili con l’attuale suiteprotocollare di internet. Si pensi per esempioall’enorme differenza tra la rudimentale mo-bilità dei dispositivi IP wireless e la mobilitàavanzata di cui si dispone comunicando inve-ce tramite GSM/GPRS o UMTS, che, impie-gando una radicale separazione tra nomi e in-dirizzi, collegano in tempo reale tre miliardi diterminali in piena mobilità. Una penetrazionecompleta di IP nel segmento d’accesso wire-less sarebbe auspicabile da molti punti di vi-sta, ma il Mobile IP (la corrente soluzione del-la internet per la gestione della mobilità) nonlo permette su scala ampia e per il multica-sting la situazione è analoga [1, 2, 3].Le possibili soluzioni a questo problema di im-portanza strategica stanno sia al livello overlay[4, 5, 6] che al livello underlay [7]. Per quanto ri-guarda il livello overlay, le soluzioni finora pro-spettate e realizzate (si veda per esempio lacostruzione overlay degli alberi di distribuzio-ne multicast dei sistemi di peer-to-peer strea-ming video Coolstreaming o PPlive) sonoorientate in modo dedicato all’applicazionespecifica che le utilizza. Inoltre i livelli di astra-zione dell’identità rispetto all’indirizzamentofinora realizzate al livello overlay e valide per ladistribuzione multicast tendono a funzionaremale per la gestione della mobilità e viceversa.Sono state teorizzate soluzioni overlay gene-rali, in grado di fornire il disaccoppiamentoidentità-indirizzo in modo indipendente dallaspecifica applicazione e dalla funzionalità(multicast/mobilità) che si intende realizzare.Certamente, le soluzioni finora proposte sonoteoriche, ma indicano chiaramente una possi-bile via da perseguire. Fra tante proposte, il

concetto della i3 (Internet Indirection Infra-structure) merita di essere citata [4], se non al-tro per l’originalità e l’eleganza, d’altra parte,per ora questa soluzione rimane teorica.L’unico approccio che finora ha avuto la con-ferma di una standardizzazione in ambitoIETF è l’Host Identity Protocol [7] (HIP), ed èuna soluzione al livello underlay (Figura 3 B).I principi e gli obiettivi fondanti di HIP posso-no essere considerati come una scaletta dialcune delle più critiche ed urgenti problema-tiche da affrontare per lo sviluppo della reteInternet. In “Host Identity Protocol (HIP) Architecture,”di R. Moskowitz e P. Nikander, [7] si rileva che:❑ la disponibilità di uno spazio di nomi (ched’ora in avanti useremo come sinonimo diidentità) indipendente dagli indirizzi di rete èstrettamente necessaria per il futuro svilup-po delle applicazioni end-to-end;❑ lo spazio dei nomi deve essere indipen-dente dagli indirizzi IP;❑ I nomi devono rimpiazzare tutte le occor-renze di indirizzi IP nei payload applicativi deipacchetti;

• si nota, infatti, che le necessità pratichedelle applicazioni distribuite hanno por-tato gli sviluppatori a codificare e tra-sportare l’indirizzo IP del mittente e/odel destinatario del pacchetto all’internodel payload applicativo del pacchettostesso. Questo fatto, ovviamente, rendeancora più intricato il problema della tra-slazione degli indirizzi, in quanto non sideve intervenire solo a livello dell’headerdel pacchetto, ma anche nel suo payloadapplicativo. Questo è un intervento mol-to pesante, che richiederà nel lungo ter-mine un adeguamento delle ApplicationProgramming Interface delle applicazio-ni distribuite;

❑ la lunghezza dei nomi deve essere compa-tibile con un efficiente trasporto degli stessinei pacchetti, cioè, non devono essere trop-po lunghi per evitare di dover sopportare unoverhead eccessivo;❑ la probabilità di collisione tra i nomi deveessere bassa, in altre parole, non deve qua-si mai accadere che due entità siano deno-minate nello stesso modo. Purtroppo, que-sto obiettivo è in netto contrasto con il pre-cedente, in quanto la probabilità di collisio-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

25

0

0

0

1

0

ne aumenta al diminuire della lunghezza deinomi. Il famoso paradosso del compleanno(la probabilità che in un gruppo di sole 23persone scelte a caso, almeno due personecompiano gli anni nello stesso giorno supe-ra il 50%) fa intuire che il problema possaessere serio, cioè, prese due entità con no-mi estratti a caso, la probabilità di averedue entità con lo stesso nome può esseresorprendentemente elevata. Per quanto ri-guarda il nostro problema specifico, se i no-mi sono codificati con 64 bit, la probabilitàdi avere una collisione in una popolazionedi 640 milioni di individui è circa pari all’1%(cioè, molto elevata), è quindi necessarioorientarsi su nomi di almeno 160 bit e prefe-ribilmente più lunghi, gli Host Identity Tag(HIT). Per contrastare attacchi crittograficiprevedibilmente sempre più potenti (vedigli standard hash correnti) bisogna proba-bilmente ricorrere a nomi lunghi 512 bit.Un nome nello spazio dei nomi Host Identity(HI) identifica un sistema in rete in modostatisticamente univoco, cioè, univoco ameno di una piccola probabilità di collisio-ne. Un sistema (per esempio un computer oun più generico terminale d’utente) puòavere molteplici nomi e nel paradigma diHIP il nome di un sistema (o meglio, uno deinomi di un sistema) è la chiave pubblica diuna coppia di chiavi crittografiche asimme-triche. Il grande vantaggio di questa solu-zione è che il nome, contenuto nei pacchet-ti, può essere utilizzato agevolmente comeautenticatore dei pacchetti stessi e costitui-sce una difesa preventiva e strutturale damolti attacchi che correntemente sono at-tuati nei confronti delle comunicazioni sia inchiaro sia crittografate.Il nome di un sistema è, per sua natura, pub-blico (la chiave pubblica) e il sistema detienein segreto la parte privata della chiave. Il pos-sesso della chiave privata che corrispondeesattamente alla chiave pubblica è di per séun certificato di identità. La stessa chiave pri-vata può essere intenzionalmente distribuitatra molteplici sistemi che in tal caso diventa-no un gruppo omogeneo. Attualmente sipensa che gli HIT saranno conservati nei ser-ver del Domain Name System oppure in unaapposita infrastruttura dedicata, con caratte-ristiche simili al DNS.

3.1. Socket, identità e indirizzo IPCome mostrato nella figura 3 A, attualmentel’indirizzo IP di un sistema, individua la loca-zione dell’interfaccia fisica di rete del sistemastesso, identifica anche il sistema e, inoltre, vaa costituire una parte dell’identificativo delpunto di terminazione della comunicazione alivello applicativo (il socket). Per disaccoppiarequesti molteplici e variegati significati e fun-zioni, HIP interpone il concetto di identità fra lalocalizzazione (indirizzo IP), individualità delsistema in rete (endpoint) e punto di termina-zione a livello applicativo della comunicazione(socket). Il risultato, mostrato nella figura 3 B,è evidentemente più razionale e ordinato. L’i-dentificativo dell’host (HIT) concretizza l’iden-tità del sistema in rete, prima affidata all’indi-rizzo IP. L’indirizzo IP diventa un puro mezzo dilocalizzazione fisica del sistema e, se il sistemasi sposta, varia l’indirizzo IP, ma, giustamente,non la sua identità (cioè, il suo HIT). Dalla figu-ra 3 A è facilmente intuibile come nella internetattuale uno spostamento geografico di un ho-st possa comportare, paradossalmente, un ve-ro e proprio cambiamento di identità dell’hoststesso e una variazione del punto di termina-zione applicativo della comunicazione, contutti i conseguenti problemi.Il disaccoppiamento di identità e locazione di HIP(Figura 3 B) permette una gestione della mobilitàincommensurabilmente più semplice e scalabiledi quella, modesta, offerta attualmente da in-ternet. Infatti, l’host in movimento può cambiarelocazione (indirizzo) senza influire sulla sua iden-tità e quindi sulla sua rintracciabilità. D’altra par-te, l’host in movimento deve notificare al suo peerremoto l’avvenuto cambiamento di indirizzo IP(ilpeer deve essere conscio del cambio di locazio-ne) e il peer remoto, a sua volta, deve accertarsiche l’host in movimento è ancora raggiungibile alnuovo indirizzo.

3.1.1. LA COMUNICAZIONE RENDEZ-VOUS

Iniziare una comunicazione con un host in mo-vimento è più complicato. Il sistema che inten-de iniziare la comunicazione deve conoscere inanticipo come raggiungere l’host che si staspostando. Nel paradigma di HIP si è identifi-cata una nuova modalità di individuazione delpeer con il quale si intende stabilire una comu-nicazione: la comunicazione rendez-vous che,come suggerisce il nome, ha lo scopo di facili-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

26

tare gli “incontri” tra i nodi che intendono co-municare. Il meccanismo rendez-vous richiedela presenza di un Rendez-Vous Server (RVS),che fornisce un primo punto di contatto notoagli host che intendono comunicare. Ovvia-mente, il server rendez-vous può conoscerel’esistenza e l’identità di un host solo se l’hoststesso si è preventivamente registrato.Il meccanismo di rendez-vous in HIP è attual-mente in studio e non è ancora stato standar-dizzato, per cui è descritto solo in documentitemporanei della IETF, gli Internet Drafts. Ilmeccanismo di rendez-vous di HIP è descrit-to in “Host Identity Protocol (HIP) Rendez-vous Extension” [8]1.Un host che vuole rendersi rintracciabile si re-gistra presso un server rendez-vous, comuni-cando la propria identità, HIT, e l’indirizzo IPcorrente. Il server rendez-vous agisce comerelay dei pacchetti di segnalazione HIP direttiverso gli host registrati. Per rendersi effettiva-mente rintracciabile, l’host deve anche speci-ficare l’indirizzo IP del suo server rendez-vousnel suo record DNS [9] (Domain NameSystem), utilizzando un nuovo campo apposi-tamente definito, il record DNS denominatoHIPRVS. In aggiunta, l’host registra nel pro-prio record DNS anche l’identità, il suo HIT.Per esempio, l’host con nome DNS pippo.do-minio.it si registra presso il proprio server ren-dez-vous, RVS, e inserisce nel proprio recordDNS l’indirizzo IP di RVS, e la sua identità HIT.A questo punto, un qualunque host che inten-de raggiungere pippo.dominio.it esegue unarichiesta DNS, riceve sia l’identità HIT sia l’indi-rizzo del server rendez-vous di pippo.domi-nio.it e può in tal modo stabilire una comunica-zione, sia mutuata dal server rendez-vous (ini-zialmente) ma anche diretta una volta che ilserver rendez-vous ha comunicato all’host l’in-dirizzo IP corrente di pippo.dominio.it.

3.1.2. LA MOBILITÀ IN HIPAllo stato attuale degli studi e della standar-dizzazione, la mobilità in HIP è gestita in modoelementare. Essenzialmente, quando un hostin movimento cambia indirizzo IP lo comunicadirettamente al suo peer remoto che non ap-pena a conoscenza del nuovo indirizzo IP ini-zierà ad utilizzarlo [10]. Questa gestione dellamobilità appare tuttavia di gran lunga meno so-fisticata di quella di tipo carrier-grade, cioè, conun livello di qualità del servizio per la piena mo-bilità come quello offerto dagli operatori di te-lecomunicazioni ai loro clienti su scala mon-diale. Gli operatori radiomobili GSM/UMTS of-frono attualmente un servizio di piena mobilitàevoluto, affidabile, e scalabile su scala plane-taria, che coinvolge molte centinaia di opera-tori e alcuni miliardi di terminali d’utente. Lamobilità GSM/UMTS utilizza due tipi di nomi(permanente IMSI, International Mobile Sub-scriber Identity, e temporaneo TIMSI, Tempo-rary IMSI) tre tipi di indirizzi (permanente, MSI-SDN, Mobile Station ISDN Number, nel roamingtra operatori, MSRN, Mobile Station RoamingNumber, e nell’hand-over tra celle radio, HON,Hand Over Number) e si basa su un sistema digestione della mobilità che comprende varie ti-pologie di entità, tra le quali gli HLR (Home Lo-cation Register) e i VLR (Visitor Location Regi-ster) che, inseriti nell’architettura di un sistemaper la localizzazione e sostenuti da un’affida-bile protocollistica di segnalazione, possonotracciare e rendere raggiungibili in tempo rea-le tutti gli utenti della rete GSM/UMTS.La semplice mobilità end-to-end di HIP, gesti-ta da uno scambio di messaggi tra i due termi-nali e senza il supporto di un sistema dedicatoalla localizzazione è da considerarsi come unprimo tentativo di realizzare un servizio di pie-na mobilità. Per arrivare a gestire una mobilitàdi tipo carrier-grade nella internet, sembra es-sere inevitabile la realizzazione di un sistemaper la localizzazione simile, almeno per le ca-ratteristiche funzionali e di qualità, a quellogià maturo e consolidato del GSM/UMTS.

3.2. L’evoluzione di HIP rispettoal protocollo IP classicoIl protocollo IP classico fu fondato ipotizzandoquattro importanti principi fondanti (Figura 4 A): ❑ non-mutabilità: l’indirizzo IP non deve va-riare nel percorso del pacchetto dalla sorgen-

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

27

0

0

0

1

1 Il documento citato è un Internet Draft e non unostandard consolidato. Dato che gli Internet Draft so-no documenti temporanei, in genere è ritenutoscorretto citarli negli articoli, in quanto prima o poi ildocumento non sarà più reperibile (per esempio,potrà essere sostituito da uno documento di stan-dard consolidato (RFC)). Si è deciso comunque di ci-tare gli Internet Draft, perché sono gli unici riferi-menti ufficialmente disponibili relativi a tematichemolto avanzate e in via di sviluppo, come HIP.

0

te alla destinazione (come già visto, laNetwork Address Translation limita pesante-mente la validità generale di questo classico“invariante”);❑ non-mobililtà: dal punto di vista del peerremoto, l’indirizzo IP di un host in movimentonon deve variare durante la comunicazione;questo è ciò che il Mobile IP classico tenta diattuare, con grandissimi e praticamente in-sormontabili problemi di scalabilità;❑ reversibilità: un host che ha ricevuto unpacchetto può sempre raggiungere la sor-gente del pacchetto invertendo gli indirizzi disorgente e di destinazione;❑ onniscenza: ogni host sa quale indirizzodeve usare un partner remoto per inviargliun pacchetto.Come mostrato nella figura 4 B, nella rete in-ternet attuale il primo e il quarto principio so-no già stati pienamente violati (principalmentea causa della Network Address Translation) e ilsecondo, la non-mobilità, è già messo in peri-colo da alcuni aspetti del Mobile IP e del multi-homing. Nelle precedenti sezioni di questo ar-ticolo è stata illustrata la dimensione notevoledei problemi generati da questo venir menodei paradigmi di base secondo i quali il proto-collo IP fu inizialmente concepito. È interes-

sante notare che IPv6 è in realtà un tentativo diripristinare il primo grande invariante della in-ternet, la non mutabilità, fornendo uno spaziodi indirizzi così ampio che non si possa più pre-sentare la necessità di mutare l’indirizzo IP diun pacchetto in transito nella rete.L’interessante aspetto rivoluzionario di HIP èche l’unica ipotesi fondamentale che sarà an-cora necessaria è la terza, la reversibilità (Figu-ra 4 C): se il verso della comunicazione è inver-tibile semplicemente scambiando gli indirizzidi sorgente e di destinazione, allora non è piùstrettamente necessario contare sulla non-mutabilità, sulla non-mobilità e sull’onniscen-za relativa agli indirizzi IP, in quanto sarebberoforniti in modo indiretto dal sistema HIP.

4. CONCLUSIONI

In questo articolo si è cercato di dimostrare chel’approccio strategico corretto per il percorso dicrescita della internet è evoluzionario e che unsemplice “nuovo protocollo IP”, per esempioIPv6, è solo uno dei fattori di crescita della in-ternet, forse necessario, ma da solo assoluta-mente insufficiente. La rapidissima avanzata del-le nuove applicazioni distribuite peer-to-peere, più in generale, overlay, pone la questione

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

0

0

1

28

Indirizzamento IP classicoI quattro principali fondanti

Indirizzamento IP con HIP

Indirizzamento IP classico

La situazione attuale

Non

mut

abili

tà

Non

mut

abili

tà

Non

mob

ilità

Rive

rsib

ilità

Rive

rsib

ilità

Rive

rsib

ilità

Onni

scen

za

A B

C

FIGURA 4A I principi fondantidell’indirizzamento

IP classico,B la situazione

attuale,C il paradigma HIP

di come possano essere superati alcuni graviproblemi tecnologici della internet che la limita-no fortemente, oltre a rendere praticamente im-possibili la mobilità e la comunicazione multi-punto su larga scala. Abbiamo evidenziato chei problemi principali si concentrano nella ormaivecchia concezione del ruolo degli indirizzi di re-te IP, che assumono simultaneamente i signifi-cati di locazione fisica dell’host, di identità del-l’host e di punto di terminazione a livello appli-cativo della comunicazione. Un sovraccarico se-mantico così imponente pone vincoli sempre piùstringenti su un utilizzo flessibile degli indirizziIP e una delle principali problematiche a livellostrategico della internet del futuro è il disaccop-piamento dei concetti di identità degli host e del-la loro locazione geografica. In tal senso, il pro-cesso di evoluzione della internet è ancora in unostato abbastanza prematuro: si stanno studian-do soluzioni come l’Host Identification Protocol,per stabilire un’identità degli host indipenden-te dall’indirizzo IP, ma si è ancora ai primi pas-si. Ciò è in netto contrasto con lo stato ormai mol-to avanzato della standardizzazione di IPv6 che,però, non è ancora riuscito a penetrare in modosignificativo nel mercato. Il fatto che IPv6 non sipropone di risolvere il problema del disaccop-piamento di identità e indirizzo, dimostra che ef-fettivamente il nuovo protocollo IP, da solo, nonpotrà superare tutti gli ostacoli che ci separanodalla internet del futuro.

Bibliografia

[1] Chu Y., Rao S.G., Zhang H.: A case for end sy-stem multicast. In: Proceedings of ACM SIGME-TRICS’00, Santa Clara, CA, June 2000, p. 1–12.

[2] Holbrook H., Cheriton D.: IP multicast chan-nels: EXPRESS support for large-scale single-source applications. In: Proceedings of ACMSIGCOMM’99, Cambridge, Massachusetts,Aug. 1999, p. 65–78.

[3] Stoica I., Ng T., Zhanh H.: REUNITE: A recursive uni-cast approach to multicast. In: Proceedings of INFO-COM’00, Tel-Aviv, Israel, Mar. 2000, p. 1644–1653.

[4] Stoica I., Adkins D., Zhuang S., et al: InternetIndirection Infrastructure. In: Proceedings ofACM SIGCOMM, Pittsburgh, PA, 2002,http://i3 .cs.berkeley.edu/publications/pa-pers/i3-sigcomm.pdf

[5] Snoeren A.C., Balakrishnan H.: An approach tohost mobility. In: Proceedings of ACM/IEEEMOBICOM’99, Cambridge, MA, Aug. 1999.

[6] Jannotti J., Gifford D.K., Johnson K.L., KaashoekM.F., O’Toole J.W.: Overcast: Reliable multica-sting with an overlay network. In: Proceedingsof the 4-th USENIX Symposium on OperatingSystems Design and Implementation, San Die-go, California, October 2000, p. 197–212.

[7] Moskowitz R., Nikander P.: Host Identity Protocol(HIP) Architecture. IETF RFC 4423, May 2006.

[8] Laganier J., Eggert L.: Host Identity Protocol (HIP)Rendezvous Extension. IETF Internet-Draft,Network Working Group, draft-ietf-hip-rvs-05draft-ietf-hip-rvs (Experimental), June 7, 2006.

[9] Nikander P., Laganier J.: Host Identity Proto-col (HIP) Domain Name System (DNS) Exten-sions. IETF Internet-Draft, Network WorkingGroup, draft-ietf-hip-dns (Experimental),April 13, 2007.

[10] Henderson T.: End-Host Mobility and Multiho-ming with the Host Identity Protocol. IETF Inter-net-Draft, Network Working Group, draft-ietf-hip-mm-05, March 2, 2007.

PAOLO GIACOMAZZI si è laureato in Ingegneria Elettroni-ca presso il Politecnico di Milano nel 1990 ed ha con-seguito il Master in tecnologia dell’informazione alCEFRIEL. Dal 1992 al 1998 è stato ricercatore con ilPolitecnico di Milano dove ora è professore associa-to di telecomunicazioni. L’attività didattica e la ricer-ca riguardano la qualità del servizio nelle reti IP, lereti radiomobili B3G e la sicurezza nelle reti di teleco-municazioni. È editor del IEEE Network Magazine edè editor della Book Reviewing Feature del IEEENetwork Magazine.E-mail: giacomaz@elet.polimi.it

MAURIZIO DÈCINA è professore ordinario di telecomuni-cazioni al Politecnico di Milano presso il Dipartimen-to di Elettronica ed Informazione. Ha fondato e diret-to il centro CEFRIEL del Politecnico di Milano dal1987 al 2003.Dal 1994 al 1995 è stato presidente della Communi-cations Society dell’IEEE.Ha ricevuto tre premi dell’IEEE: nel 1986 il FellowAward per la telefonia a pacchetto, nel 1997l’Award in International Communications per glistandard internazionali, e nel 2000 il premio allacarriera Third Millennium Medal Award per gliesperti di telecomunicazioni più influenti nella se-conda metà del 900.Il prof. Dècina ha lavorato nell’industria, Telecom Ita-lia, Italtel e AT&T-Bell Laboratories, ed stato membrodel consiglio di amministrazione di numerose azien-de, tra cui Telecom Italia, Italtel, Tiscali e I.Net. Haanche fondato alcune aziende start-up, tra cui ICTConsulting e Securmatics.E-mail: maurizio.decina@polimi.it

M O N D O D I G I T A L E • n . 2 - g i u g n o 2 0 0 7

1

29

0

0

0

1