Passa al contenuto principale

3. L'indirizzamento classless come soluzione

  1. L'indirizzamento classless come soluzione

La soluzione creata dalla comunità fu di deprecare il sistema di assegnazione di indirizzi di rete di classe A/B/C a favore dell'uso di blocchi gerarchici di indirizzi IP "classless" (denominati prefissi). L'assegnazione dei prefissi è pensata per seguire approssimativamente la topologia sottostante di Internet in modo che l'aggregazione possa essere utilizzata per facilitare la scalabilità del sistema di routing globale. Un'implicazione di questa strategia è che l'assegnazione e l'aggregazione dei prefissi sono generalmente eseguite secondo le relazioni fornitore-cliente, poiché è così che la topologia di Internet è determinata.

Quando fu proposto originariamente in [RFC1338] e [RFC1519], questo piano di indirizzamento era destinato a essere una risposta relativamente a breve termine, della durata di circa tre-cinque anni, durante la quale un'architettura di indirizzamento e routing più permanente sarebbe stata progettata e implementata. Come possono suggerire le date dei documenti originali, il CIDR ha ampiamente superato la sua durata prevista ed è diventato la soluzione a medio termine dei problemi descritti sopra.

Si noti che nel testo che segue descriviamo le politiche e le procedure attuali che sono state messe in atto per implementare l'architettura di allocazione qui discussa. Questa descrizione non deve essere interpretata come una direttiva per l'IANA.

Accoppiata alle strategie di gestione degli indirizzi implementate dai Regional Internet Registries (vedere [NRO] per i dettagli), la distribuzione di un indirizzamento di stile CIDR ha anche ridotto il tasso di consumo dello spazio di indirizzamento IPv4, fornendo così un sollievo a breve e medio termine al problema n. 3 descritto sopra.

Si noti che, così come definito, questo piano non richiede né presuppone la riassegnazione delle parti del vecchio spazio "classe C" che non si prestano all'aggregazione (a volte chiamato "the swamp" [la palude]). Questo ridurrebbe alquanto le dimensioni delle tabelle di routing (la stima attuale è che "the swamp" contenga circa 15.000 voci), ma al prezzo di un costoso impegno di rinumerazione. Analogamente, non vi è alcun rigido requisito che un qualsiasi sito terminale rinumeri quando cambia fornitore di servizi di transito, ma i siti terminali sono incoraggiati a farlo per eliminare la necessità di un annuncio esplicito dei loro prefissi nel sistema di routing globale.

3.1. Concetto di base e notazione dei prefissi

Nel senso più semplice, il passaggio dai numeri di rete di classe A/B/C ai prefissi classless consiste nel rendere esplicito quali bit in un indirizzo IPv4 a 32 bit sono interpretati come il numero di rete (o prefisso) associato a un sito e quali sono utilizzati per numerare i singoli sistemi terminali all'interno del sito. Nella notazione CIDR, un prefisso è rappresentato come una quantità a 4 ottetti, proprio come un indirizzo IPv4 tradizionale o un numero di rete, seguita dal carattere "/" (barra) e da un valore decimale compreso tra 0 e 32 che descrive il numero di bit significativi.

Ad esempio, la rete "classe B" originaria 172.16.0.0, con maschera di rete implicita 255.255.0.0, è definita come il prefisso 172.16.0.0/16, il "/16" indica che la maschera per estrarre la parte di rete del prefisso è un valore a 32 bit i cui 16 bit più significativi sono uno e i 16 bit meno significativi sono zero. Allo stesso modo, il numero di rete "classe C" originario 192.168.99.0 è definito come il prefisso 192.168.99.0/24; i 24 bit più significativi sono uno e gli 8 bit meno significativi sono zero.

L'uso di prefissi classless con lunghezze di prefisso esplicite consente una corrispondenza molto più flessibile dei blocchi di spazio di indirizzamento in base ai reali bisogni. Laddove in precedenza erano disponibili solo tre dimensioni di rete, i prefissi possono essere definiti per descrivere qualsiasi blocco di dimensioni potenza di due compreso tra uno e 2^32 indirizzi di sistemi terminali. Nella pratica, il serbatoio di indirizzi non allocati è amministrato dalla Internet Assigned Numbers Authority ([IANA]). L'IANA effettua allocazioni da questo serbatoio verso i Regional Internet Registries, secondo necessità. Queste allocazioni sono fatte sotto forma di blocchi contigui allineati sui bit di 2^24 indirizzi (anche detti prefissi /8). I Regional Internet Registries (RIR), a loro volta, allocano o assegnano blocchi di indirizzi più piccoli ai Local Internet Registries (LIR) o ai Internet Service Providers (ISP). Queste entità possono utilizzare direttamente l'assegnazione (come è generalmente il caso per un ISP) o possono effettuare nuove sotto-allocazioni di indirizzi ai propri clienti. Queste assegnazioni di indirizzi dei RIR variano in base alle necessità di ciascun ISP o LIR. Ad esempio, un grande ISP potrebbe vedersi allocato un blocco di 2^17 indirizzi (un prefisso /15), mentre un ISP più piccolo potrebbe vedersi allocato un blocco di 2^11 indirizzi (un prefisso /21).

Si noti che i termini "allocate" (allocare) e "assign" (assegnare) hanno un significato preciso nel sistema dei registri di indirizzi Internet; "allocate" si riferisce alla delega di un blocco di spazio di indirizzamento a un'organizzazione che è tenuta a effettuare nuove sotto-delegazioni, e "assign" è utilizzato per i siti che utilizzano direttamente (cioè numerano singoli host) il blocco di indirizzi ricevuto.

La tabella seguente fornisce un pratico riferimento per tutte le dimensioni di prefisso CIDR, indicando il numero di indirizzi possibili in ciascun prefisso e il numero di prefissi di tale dimensione che possono essere numerati nello spazio-tempo di indirizzamento IPv4 a 32 bit:

   notation       addrs/block      # blocks

-------- ----------- ----------

n.n.n.n/32 1 4294967296 "host route"

n.n.n.x/31 2 2147483648 "p2p link"

n.n.n.x/30 4 1073741824

n.n.n.x/29 8 536870912

n.n.n.x/28 16 268435456

n.n.n.x/27 32 134217728

n.n.n.x/26 64 67108864

n.n.n.x/25 128 33554432

n.n.n.0/24 256 16777216 legacy "Class C"

n.n.x.0/23 512 8388608

n.n.x.0/22 1024 4194304

n.n.x.0/21 2048 2097152

n.n.x.0/20 4096 1048576

n.n.x.0/19 8192 524288

n.n.x.0/18 16384 262144

n.n.x.0/17 32768 131072

n.n.0.0/16 65536 65536 legacy "Class B"

n.x.0.0/15 131072 32768

n.x.0.0/14 262144 16384

n.x.0.0/13 524288 8192

n.x.0.0/12 1048576 4096

n.x.0.0/11 2097152 2048

n.x.0.0/10 4194304 1024

n.x.0.0/9 8388608 512

n.0.0.0/8 16777216 256 legacy "Class A"

x.0.0.0/7 33554432 128

x.0.0.0/6 67108864 64

x.0.0.0/5 134217728 32

x.0.0.0/4 268435456 16

x.0.0.0/3 536870912 8

x.0.0.0/2 1073741824 4

x.0.0.0/1 2147483648 2

0.0.0.0/0 4294967296 1 "default route"

n è un valore decimale a 8 bit. I collegamenti point-to-point sono discussi più in dettaglio in [RFC3021].

x è un valore di 1-7 bit, basato sulla lunghezza del prefisso, spostato nei bit più significativi dell'ottetto e convertito in forma decimale; i bit meno significativi dell'ottetto sono zero.

Nella pratica, prefissi di lunghezza inferiore a 8 non sono stati finora né allocati né assegnati, sebbene rotte verso tali prefissi brevi possano esistere nelle tabelle di routing se o quando viene effettuata un'aggregazione aggressiva. Al momento della stesura di questo documento, nessuna di tali rotte è osservata nel sistema di routing globale, ma errori degli operatori e altri eventi hanno portato alcune di esse (cioè 128.0.0.0/1 e 192.0.0.0/2) a essere osservate in alcune reti in alcuni momenti nel passato.