La transizione ad IPv6

Mauro Tortonesi

Deep Space 6

Sommario

Questo articolo vuole essere una non troppo breve introduzione al nuovo protocollo di rete IPv6 e alla transizione della rete Internet al nuovo protocollo.


Indice

1. Introduzione a TCP/IP
2. I limiti di IPv4
2.1. Esaurimento dell'address space
2.2. Esplosione delle routing tables
2.3. Una soluzione a breve termine - CIDR
2.4. Lo scenario futuro
3. La soluzione IPv6
3.1. Address space enorme
3.2. Nuove tipologie di indirizzi
3.3. Indirizzi globali di tipo aggregabile
3.4. Autoconfigurazione di tipo stateless
3.5. Performance e scalabilità
3.6. La fase di transizione
4. Conclusioni
5. Ringraziamenti
Riferimenti

1. Introduzione a TCP/IP

TCP/IP è il protocollo di comunicazione di Internet. Più precisamente, TCP/IP è uno stack di protocolli che corrispondono ai livelli di rete e di trasporto del modello di riferimento OSI, espressamente progettati per costituire l'infrastruttura di Internet.

Il protocollo IP si occupa di trasmettere pacchetti di dati da una sorgente a una destinazione, dove per "sorgente" e "destinazione" intendiamo degli host identificati da indirizzi di lunghezza fissa.

Il protocollo TCP è in grado di stabilire un flusso di comunicazione bidirezionale ed affidabile fra due host, basandosi sui servizi offerti da IP.

In questa sede ci occuperemo di analizzare esclusivamente il protocollo IP: evidenzieremo i limiti della attuale versione IPv4 del protocollo e vedremo come essi vengano superati nella nuova versione IPv6.

2. I limiti di IPv4

La tecnologia IPv4 attualmente in uso, nonostante abbia funzionato per anni in modo eccellente, non è più in grado di sostenere gli attuali ritmi di crescita di Internet. Vediamo ora in dettaglio quali sono le problematiche principali.

2.1. Esaurimento dell'address space

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

  • 2^24 - 2 = 16,776,214

  • 2^16 - 2 = 65,534

  • 2^8 - 2 = 254

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

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

2.2. Esplosione delle routing tables

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

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

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

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

2.3. Una soluzione a breve termine - CIDR

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

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

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

Tabella 1. Indirizzi IP assegnati da CIDR

Indirizzi da: A: Assegnati in:
194.0.0.0 195.255.255.255 Europa
198.0.0.0 199.255.255.255 Nord America
200.0.0.0 201.255.255.255 Sud e Centro America
202.0.0.0 203.255.255.255 Asia e Pacifico

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

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

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

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

2.4. Lo scenario futuro

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

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

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

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

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

Per ulteriori informazioni si veda [HINDEN95].

3. La soluzione IPv6

Dall'analisi appena effettuata, si realizza che è una assoluta necessità, ai fini dello sviluppo di Internet, sostituire il protocollo IPv4 con un altro protocollo di rete che svolga le stesse funzioni, ma che risulti privo dei limiti che hanno finora contraddistinto la tecnologia IP e che riesca a soddisfare i requisiti imposti dai nuovi mercati che si stanno sviluppando nel settore delle telecomunicazioni.

La soluzione proposta da IETF è l'adozione del nuovo portocollo IPv6, una evoluzione del protocollo IPv4 destinata a sostituire quest'ultimo nel giro di pochi anni. Vediamo ora quali sono le caratteristiche principali di IPv6:

3.1. Address space enorme

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

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

3.2. Nuove tipologie di indirizzi

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

UNICAST

Indirizzi assegnati ad una singola interfaccia. Un pacchetto inviato ad un indirizzo unicast viene consegnato solo alla interfaccia di rete identificata da quel particolare indirizzo.

ANYCAST

Indirizzi assegnati ad un insieme di interfacce (tipicamente su nodi differenti). Un pacchetto inviato ad un indirizzo anycast viene consegnato ad una sola delle interfacce identificata da quel particolare indirizzo, solitamente la più vicina in termini di distanze di routing.

MULTICAST

Indirizzi assegnati ad un insieme di interfacce (tipicamente su nodi differenti). Un pacchetto inviato ad un indirizzo multicast viene consegnato a tutte le interfacce identificate da quell'indirizzo.

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

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

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

Per ulteriori informazioni si veda [RFC2373].

3.3. Indirizzi globali di tipo aggregabile

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

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

Figura 1. Formato dell'indirizzo IPv6 globale unicast

Formato dell'indirizzo IPv6 globale unicast

Format Prefix (FP)

Contiene i bit 001 ed identifica l'indirizzo IPv6 come indirizzo unicast di tipo globale.

Top-Level Aggregation (TLA) ID

Gli identificatori di tipo Top-Level Aggregation sono il livello più alto della gerarchia di routing, e vengono assegnati esclusivamente alle organizzazioni che prevedono una topologia di transito. Allo scopo di minimizzare la dimensione delle tabelle di routing per i router di tipo default-free, il campo TLA ID è lungo solo 13 bit. Infatti i router di tipo default-free devono avere, all'interno delle proprie tabelle, almeno una entry per ogni TLA ID attivo e altre contenenti le informazioni di routing per il TLA ID in cui si trovano. La dimensione del campo TLA ID permette di avere un massimo di 8,192 identificatori TLA diversi, e questo dovrebbe portare ad una migliore performance nel routing, dato che i router di tipo default-free hanno attualmente tabelle contenenti tipicamente 50,000 entry.

RESERVED

Campo riservato per una eventuale espansione futura dei campi TLA ID e/o NLA ID.

Next-Level Aggregation (NLA) ID

Gli identificatori di tipo Next-Level Aggregation sono usati da organizzazioni a cui è stato assegnato un TLA ID per creare una gerarchia di indirizzi e per identificare i siti. I 24 bit del campo NLA ID consentono ad ogni organizzazione in possesso di un TLA ID di supportare un numero di organizzazioni di livello inferiore pari all'incirca al massimo numero di reti (di classe A, B e C) che la tecnologia IPv4 poteva supportare prima della introduzione di CIDR.

Sub-Level Aggregation (SLA) ID

Il campo SLA ID è utilizzato dalle organizzazioni individuali per creare la propria gerarchia locale di indirizzamento e per identificare le sottoreti. La dimensione a 16 bit del campo SLA ID permette di supportare fino a 65,535 diverse sottoreti.

Interface ID

Il campo INTERFACE ID è utilizzato per identificare una interfaccia all'interno di una rete locale.

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

3.4. Autoconfigurazione di tipo stateless

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

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

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

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

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

3.5. Performance e scalabilità

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

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

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

3.6. La fase di transizione

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

  • Alta interoperabilità tra host IPv4 e host IPv6.

  • Massima flessibilità nel posizionamento di router e host IPv6 all'interno di una rete IPv4.

  • La transizione dovrà essere il più facile possibile per gli utenti, gli amministratori di sistema e gli operatori di rete.

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

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

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

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

4. Conclusioni

IPv6 si presenta come una tecnologia molto interessante e di sicuro successo, in quanto destinata a soppiantare IPv4. L'interesse che si è sviluppato attorno a questa tecnologia è notevole. Nonostante gli standard che definiscono il protocollo IPv6 non siano ancora tutti completi e testati, alcune aziende leader nel settore hanno già messo sul mercato i primi router IPv6, e molti sistemi operativi di tipo Unix (specialmente quelli appartenenti alla famiglia BSD) offrono una implementazione dello stack TCP/IPv6 completa e di ottima qualità.

5. Ringraziamenti

Desidero ringraziare, per le segnalazioni ed i suggerimenti che mi hanno inviato, Ermanno Sartori e l'amico Enrico Ardizzoni.

Riferimenti

[RFC791] Internet Protocol . IETF. Postel.

[RFC1517] Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) . IETF. Internet Engineering Steering Group e Hinden.

[RFC2373] IP Version 6 Addressing Architecture . IETF. Hinden e Deering.

[RFC2374] An IPv6 Aggregatable Global Unicast Address Format . IETF. Hinden, O'Dell, e Deering.

[RFC2450] Proposed TLA and NLA Assignment Rule . IETF. Hinden.

[RFC2460] IP Version 6 Addressing Architecture . IETF. Hinden e Deering.

[RFC2461] Neighbor Discovery for IP Version 6 (IPv6) . IETF. Narten, Nordmark, e Simpson.

[RFC2462] IPv6 Stateless Address Autoconfiguration . IETF. Thomson e Narten.

[HINDEN95] IP Next Generation Overview . Hinden.

[TRANSINTRO] An overview of the introduction of IPv6 in the Internet . IETF. Biemolt, Durand, Finkerson, Hazeltine, Kaat, Larder, van der Pol, Sekiya, Steenman, e Tsirtsis.


Aggiornato 18.02.2017 Documenti | DeepSpace6


Your connection is via: IPv4
Your address: 100.26.140.179
mirrors.bieringer.de
is maintained by
webmaster at bieringer dot de
(Impressum)
powered by Apache HTTP server powered by Linux