<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 
  "/usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd" [
  <!ENTITY bibliography SYSTEM "la_transizione_ad_ipv6-bib.xml">
]>
<!--<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">-->
<article lang="it">

  <articleinfo>
    <title>La transizione ad IPv6</title>
    <date>9 Gennaio 2002</date>
    <author>
      <firstname>Mauro</firstname>
      <surname>Tortonesi</surname>
      <affiliation>
        <orgname>Deep Space 6</orgname>
        <address><email>mauro@deepspace6.net</email></address>
      </affiliation>
    </author>
    <abstract>
      <para>
        Questo articolo vuole essere una non troppo breve introduzione
        al nuovo protocollo di rete IPv6 e alla transizione della rete
        Internet al nuovo protocollo. 
      </para>
    </abstract>
  </articleinfo>

  <sect1>
    <title>Introduzione a TCP/IP</title>
    <para>
      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.
    </para>

    <para>
      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.
    </para>

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

    <para>
      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.
    </para>

  </sect1>
    
  <sect1>
    <title>I limiti di IPv4</title>
    <para>
      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.
    </para>

    <sect2>
      <title>Esaurimento dell'address space</title>
      <para>
        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:
      </para>

      <itemizedlist>
        <listitem>
          <para>2^24 - 2 = 16,776,214</para>
        </listitem>
        <listitem>
          <para>2^16 - 2 = 65,534</para>
        </listitem>
        <listitem>
          <para>2^8 - 2 = 254</para>
        </listitem>
      </itemizedlist>
    
      <para>
        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) <xref linkend="RFC791"/>.
      </para>
 
      <para>
        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.
      </para>
    </sect2>
    
    <sect2>
      <title>Esplosione delle routing tables</title>
      <para>
        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.
      </para>

      <para>
        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. 
      </para>

      <para>
        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.
      </para>
      
      <para>
        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.
      </para>
    </sect2>
    
    <sect2>
      <title>Una soluzione a breve termine - CIDR</title>
      <para>
        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).
      </para>

      <para>
        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).
      </para>

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

      <table>
        <title>Indirizzi IP assegnati da CIDR</title>
        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
          <colspec colname='c1'/>
          <colspec colname='c2'/>
          <colspec colname='c3'/>
          <thead>
            <row>
              <entry>Indirizzi da:</entry>
              <entry>A:</entry>
              <entry>Assegnati in:</entry>
            </row>
          </thead>
          <tbody>
            <row>
              <entry>194.0.0.0</entry>
              <entry>195.255.255.255</entry>
              <entry>Europa</entry>
            </row>
            <row>
              <entry>198.0.0.0</entry>
              <entry>199.255.255.255</entry>
              <entry>Nord America</entry>
            </row>
            <row>
              <entry>200.0.0.0</entry>
              <entry>201.255.255.255</entry>
              <entry>Sud e Centro America</entry>
            </row>
            <row>
              <entry>202.0.0.0</entry>
              <entry>203.255.255.255</entry>
              <entry>Asia e Pacifico</entry>
            </row>
          </tbody>
        </tgroup>
      </table>
      
      <para>
        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.
      </para>

      <para>
        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.
      </para>

      <para>
        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.
      </para>

      <para>
        Per ulteriori informazioni si vedano <xref linkend="RFC1517"/>, 
        <xref linkend="RFC1518"/> e <xref linkend="RFC1519"/>.
      </para>

    </sect2>
    
    <sect2>
      <title>Lo scenario futuro</title>
      <para>
        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.
      </para>
 
      <para>
        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à.
      </para>
 
      <para>
        Anche il mercato del networked entertainment sembra essere in fase
        di crescita. Offerte di tipo <emphasis>Video on demand</emphasis> e 
        <emphasis>500 channel TV</emphasis> 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.
      </para>
      
      <para>
        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à. 
      </para>
 
      <para>
        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.
      </para>
 
      <para>
        Per ulteriori informazioni si veda <xref linkend="HINDEN95"/>.
      </para>
    </sect2>
  </sect1>
    
  <sect1>
    <title>La soluzione IPv6</title>
    <para>
      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.
    </para>

    <para>
      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:
    </para>
 
    <sect2>
      <title>Address space enorme</title>
      <para>
        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 <xref linkend="HINDEN95"/>). 
        Certamente, con l'introduzione di IPv6, scomparirà ogni rischio di esaurimento 
        dell'address space a breve termine.
      </para>
 
      <para>
        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 <xref linkend="RFC1715"/>.
      </para>
 
    </sect2>
    
    <sect2>
      <title>Nuove tipologie di indirizzi</title>
      <para>
        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:
      </para>
 
      <variablelist>
        <varlistentry>
          <term>UNICAST</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>ANYCAST</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>MULTICAST</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
      </variablelist>
 
      <para>
        È importante notare che non esistono indirizzi di tipo broadcast in
        IPv6, in quanto essi sono stati sostituiti dagli indirizzi di tipo
        multicast.
      </para>
 
      <para>
        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.
      </para> 
 
      <para>
        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.
      </para>
 
      <para>
        Per ulteriori informazioni si veda <xref linkend="RFC2373"/>.
      </para>
 
    </sect2>
 
    <sect2>
      <title>Indirizzi globali di tipo aggregabile</title>
      
      <para>
        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.
      </para>
 
      <para>
        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:
      </para>

      <figure>
        <title>Formato dell'indirizzo IPv6 globale unicast</title>
        <graphic align="center" fileref="../images/img6.png"/>
      </figure>
 
      <variablelist>
        <varlistentry>
          <term>Format Prefix (FP)</term>
          <listitem>
            <para>
              Contiene i bit 001 ed identifica l'indirizzo IPv6 come indirizzo
              unicast di tipo globale.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>Top-Level Aggregation (TLA) ID</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>RESERVED</term>
          <listitem>
            <para>
              Campo riservato per una eventuale espansione futura dei campi 
              TLA ID e/o NLA ID.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>Next-Level Aggregation (NLA) ID</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>Sub-Level Aggregation (SLA) ID</term>
          <listitem>
            <para>
              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.
            </para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>Interface ID</term>
          <listitem>
            <para>
              Il campo INTERFACE ID è utilizzato per identificare una 
              interfaccia all'interno di una rete locale.
            </para>
          </listitem>
        </varlistentry>
      </variablelist>
 
      <para>
        Per ulteriori informazioni si vedano <xref linkend="RFC2374"/> e 
        <xref linkend="RFC2450"/>.
      </para>
      
    </sect2>
 
    <sect2>
      <title>Autoconfigurazione di tipo stateless</title>
 
      <para>
        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).
      </para>
 
      <para>
        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.
      </para>
 
      <para>
        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. 
      </para>
 
      <para>
        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.
      </para>
 
      <para>
        Per ulteriori informazioni si vedano <xref linkend="RFC2461"/> e 
        <xref linkend="RFC2462"/>.
      </para>
 
    </sect2>
    
    <sect2>
      <title>Performance e scalabilità</title>
 
      <para>
        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.
      </para>
 
      <para>
        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).
      </para>
 
      <para>
        Per ulteriori informazioni si vedano <xref linkend="RFC2460"/> e 
        <xref linkend="HINDEN95"/>.
      </para>
 
    </sect2>
 
    <sect2>
      <title>La fase di transizione</title>
 
      <para>
        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: 
      </para>
 
      <itemizedlist>
        <listitem>
          <para>
            Alta interoperabilità tra host IPv4 e host IPv6.
          </para>
        </listitem>
        <listitem>
          <para>
            Massima flessibilità nel posizionamento di router e host IPv6 
            all'interno di una rete IPv4.
          </para>
        </listitem>
        <listitem>
          <para>
            La transizione dovrà essere il più facile possibile per gli utenti,
            gli amministratori di sistema e gli operatori di rete.
          </para>
        </listitem>
      </itemizedlist>
 
      <para>
        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). 
      </para>
 
      <para>
        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.
      </para>
 
      <para>
        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.
      </para>
 
      <para>
        Per ulteriori informazioni si vedano <xref linkend="HINDEN95"/> e 
        <xref linkend="TRANSINTRO"/>.
      </para>
    </sect2>
  </sect1>
 
  <sect1>
    <title>Conclusioni</title> 
    <para>
      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à.
    </para>
  </sect1>

  <sect1>
    <title>Ringraziamenti</title>
    <para>
      Desidero ringraziare, per le segnalazioni ed i suggerimenti che mi
      hanno inviato, Ermanno Sartori e l'amico Enrico Ardizzoni.
    </para>
  </sect1>
  
  <bibliography>
    <title>Riferimenti</title>
    &bibliography;
  </bibliography>
                              
</article>
<!--
vim: et ts=2 sw=2
-->
