Classless Inter-Domain Routing

(Reindirizzamento da CIDR)

Il Classless Inter-Domain Routing (CIDR) è un metodo per suddividere gli indirizzi IP allo scopo di allocarli con il minimo spreco, che ricopre un ruolo importante anche nel routing IP. La internet engineering task force ha introdotto CIDR nel 1993 per sostituire il precedente metodo di suddivisione classful usato fino a quel periodo. Il suo obiettivo era quello di rallentare l'esaurimento rapido degli indirizzi IPv4, e delineare, allo stesso tempo, un metodo per contenere le dimensioni delle tabelle di instradamento dei router a servizio di Internet, dimensioni crescenti come effetto collaterale di detta suddivisione.[1][2]

Gli indirizzi IP sono costituiti da due gruppi di bit nell'indirizzo: i bit più significativi costituiscono il prefisso di rete, che identifica un'intera rete classful (spesso indicata con il termine network in questo contesto) o una subnet, mentre l'insieme dei bit meno significativi costituisce l'identificativo dell'host, che può essere assegnato a una particolare interfaccia di un host su quella rete. Questa divisione viene usata come base per il routing del traffico tra reti IP e per le policy di allocazione degli indirizzi.

Laddove il metodo classful mantiene il prefisso di rete a una dimensione fissa di uno o più gruppi consecutivi da 8 bit (più significativi) per ottenere un numero finito di blocchi di indirizzi appartenenti alle tre classi A, B o C, con CIDR i bit del prefissi di rete che vengono allocati agli internet service provider e ai clienti finali possono essere di lunghezza variabile, al fine di ottimizzare lo spazio di indirizzamento.

Il CIDR è basato sul subnet masking a lunghezza variabile (VLSM), con il quale i prefissi di rete hanno lunghezze variabili, in contrasto alle lunghezze fisse del precedente metodo classful. Il vantaggio principale di questo sistema è che viene garantito un controllo più fine sulle dimensioni delle subnet allocate alle organizzazioni, rallentando pertanto l'esaurimento precoce degli indirizzi IPv4 causato dall'allocazione di blocchi di indirizzi più grandi del necessario. CIDR ha dato origine a un nuovo sistema di scrivere gli indirizzi IP conosciuto come notazione CIDR, nella quale un indirizzo IP è seguito da un suffisso che indica il numero di bit del prefisso. Alcuni esempi di notazione CIDR sono gli indirizzi 192.0.2.0/24 e 2001:db8::/32 per IPv6. I blocchi di indirizzi che hanno prefissi contigui possono essere aggregati dai router come supernetwork, riducendo il numero globale di voci nella tabella di routing.

Retroscena

modifica

Ciascun indirizzo IP consiste in un prefisso di rete seguito da un identificatore di host. Il dilemma è stabilire quanti dei 32 bit dell'indirizzo costituiscono il prefisso di rete e quanti l'identificatore dell'host. Nella precedente suddivisione classful di IPv4 i primi 3 bit dell'indirizzo IP definivano il totale dei bit che appartenevano al prefisso di rete:[3]

Primi 3 bit Bit del prefisso di rete Bit identificatore host Classe Indirizzi ip di esempio
000 through 011 8 24 Classe A 44.0.0.1
100 through 101 16 16 Classe B 128.32.0.1
110 24 8 Classe C 192.12.33.3

Il vantaggio di questo sistema era che i prefissi di rete potevano essere determinati automaticamente per ciascun indirizzo di rete senza bisogno di ulteriori informazioni. Lo svantaggio era che essendo disponibili solo tre taglie di grandezza prestabilite, le reti erano solitamente troppo grandi o troppo piccole per la maggior parte delle organizzazioni. Il blocco più piccolo allocabile conteneva 28 = 256 indirizzi, molti di più del necessario per una rete personale o di un dipartimento, ma troppo piccola per un'intera grande azienda. Il blocco intermedio conteneva 216 = 65536 indirizzi, troppo grande per essere usato in maniera efficiente anche da una grande organizzazione. Ma per quelle che avevano bisogno di più di 65536 indirizzi, il blocco più grande disponibile ne forniva 224 = 16777216, che erano davvero troppi. Questo portava a inefficienze sia nell'uso degli indirizzi che nell'instradamento, perché i router dovevano scambiarsi gli annunci delle informazioni di routing relative a un gran numero di reti di classe C disperse geograficamente che per questo motivo non si potevano aggregare in una supernetwork.

Nell'arco del decennio successivo allo sviluppo del Domain Name System, divenne evidente che il vecchio schema delle reti basate su classi non era scalabile.[4] Questo portò allo sviluppo del subnetting e del CIDR. Le precedenti distinzioni di classe basate sui 3 bit furono rimosse, e il nuovo sistema venne descritto come classless, in opposizione al vecchio sistema che divenne noto come classful. I protocolli di routing vennero modificati per trasportare non solo gli indirizzi IP, ma anche le corrispondenti subnet mask. Implementare CIDR comportò l'aggiornamento di ogni host e router in tanti piccoli modi, e ciò non fu una piccola impresa in un periodo in cui Internet stava entrando in una fase di crescita rapida. Nel 1993 la Internet Engineering Task Force pubblicò un nuovo set di standard, RFC 1518 ed RFC 1519 per definire questo nuovo metodo per allocare blocchi di indirizzi IP ed instradare pacchetti IPv4. Nel 2006 ne venne pubblicata una versione aggiornata, RFC 4632.[5] Dopo un periodo di sperimentazione con varie alternative, il Classless Inter-Domain Routing venne basato sul variable-length subnet masking (VLSM), che permette a ciascuna rete di essere suddivisa in varie subnet di grandezza multipla delle potenze di 2, in modo da poter dimensionare ogni rete in base alle esigenze locali. Le subnet mask a lunghezza variabile vennero menzionate come alternativa per la prima volta nella RFC 950.[6] Le tecniche per raggruppare gli indirizzi per operazioni comuni erano basate sul concetto di cluster addressing, proposto per prima da Herbert Rokitansky.[7][8]

Notazione CIDR

modifica

La notazione CIDR è la rappresentazione compatta di un indirizzo IP e della sua subnet mask associata. La notazione è stata inventata da Phil Karn negli anni '80.[9][10] Essa specifica un indirizzo IP, uno slash, ('/') e un numero decimale. Questo numero è il conteggio dei bit consecutivi impostati ad 1 da sinistra a destra nel prefisso di rete, e può essere anche considerato come unità di misura della lunghezza del prefisso di rete. L'indirizzo ip in notazione CIDR è sempre rappresentato secondo gli standard per IPv4 o IPv6.

La notazione può delineare lo specifico indirizzo di un'interfaccia, come 10.0.0.1/8, o l'indirizzo iniziale di un'intera rete, usando un identificatore di host corrispondente al numero 0 in binario (ad esempio 10.0.0.0/8). La notazione CIDR può anche essere usata senza indirizzo IP, per esempio quando ci si riferisce a una /24 come descrizione generica di una rete che ha un prefisso lungo 24 bit e gli identificatori degli host lunghi 8 bit.

Per esempio:

  • 198.51.100.14/24 rappresenta l'indirizzo IPv4 198.51.100.14 e il suo prefisso di rete associato 198.51.100.0, o allo stesso modo, la subnet mask 255.255.255.0, che ha 24 bit impostati a 1.
  • il blocco IPv4 198.51.100.0/22 rappresenta i 1024 indirizzi IPv4 da 198.51.100.0 a 198.51.103.255.
  • il blocco IPv6 2001:db8::/48 rappresenta l'insieme di indirizzi IPv6 da 2001:db8:0:0:0:0:0:0 a 2001:db8:0:ffff:ffff:ffff:ffff:ffff.
  • ::1/128 rappresenta l'indirizzo di loopback IPv6. la lunghezza del suo prefisso è 128 che è anche il numero di bit dell'indirizzo

In IPv4, quella che adesso è conosciuta come "notazione CIDR" divenne di largo impiego solo dopo l'implementazione di CIDR. Non appare negli standard di CIDR originali, che utilizzano invece una subnet mask in notazione decimale separata da punti dopo lo slash (per esempio, 192.24.12.0/255.255.252.0).[2] Descrivere la lunghezza del prefisso di rete con un singolo numero rendeva più semplice per gli amministratori di rete concettualizzare e calcolare mentalmente, così iniziò ad essere incorporata nei documenti degli standard successivi[11][12] e nelle interfacce per la configurazione degli apparati.

Il numero di indirizzi dentro una network o una subnet può essere calcolato con la formula 2lunghezza indirizzo−lunghezza del prefisso, dove lunghezza indirizzo è 128 per IPv6 e 32 per IPv4. Ad esempio, in IPv4, la lunghezza del prefisso /29 fornisce: 232−29 = 23 = 8 indirizzi.

Maschera di sottorete

modifica
  Lo stesso argomento in dettaglio: Maschera di sottorete.

Una subnet mask è una maschera di bit che codifica la lunghezza del prefisso associatata a un indirizzo IPv4 lunga 32 bit, dei quali un certo numero sono impostati a 1 e rappresentano la lunghezza del prefisso, e i restanti bit impostati a 0, che viene tipicamente espressa in formato decimale quadruplo separata da punti (es. 255.255.255.0). Essa rappresenta lo stesso tipo di informazione di una lunghezza di prefisso ma precede l'avvento di CIDR. Nella notazione CIDR, i bit del prefisso sono sempre contigui. La RFC 950[6] permetteva un tempo alle subnet mask di rappresentare anche bit non contigui, fino alla RFC 4632,[5] dove venne stabilito che i bit dovevano essere lasciati contigui. Come conseguenza di questa restrizione sia la subnet mask che la notazione CIDR svolgono la medesima funzione.

Blocchi CIDR

modifica

CIDR è fondamentalmente uno standard per la rappresentazione degli indirizzi IP e sulle loro proprietà di routing che agisce sui singoli bit ed basato sulla lunghezza dei prefissi. È in grado di facilitare il routing permettendo di raggruppare un certo numero blocchi di indirizzi contigui in una singola voce nella tabella di routing. Questi gruppi, comunemente chiamati Blocchi CIDR condividono una sequenza iniziale di bit nella rappresentazione binaria dei loro indirizzi IP. Ciascun blocco CIDR viene rappresentato usando una sintassi simile a quella usata per gli indirizzi IPv4: una notazione decimale separata da punti, seguita da uno slash, e poi un numero decimale da 0 a 32, come nell'esempio a.b.c.d/n. La prima parte identifica il blocco, il numero decimale dopo lo slash è la lunghezza del prefisso, e corrisponde al numero di bit iniziali che tutti gli indirizzi IP di quel blocco condividono, contando dal bit più significativo. Per descrivere un generico blocco CIDR in una conversazione, ponendo l'enfasi e l'attenzione sulla sua dimensione, ci si può riferire ad esso omettendo la porzione dell'indirizzo. Ad esempio, quando si sente dire una "barra venti (/20)" ci si riferisce a un blocco CIDR con un prefisso non specificato lungo 20 bit.

Un indirizzo IP costituisce parte di un blocco CIDR e si dice che corrisponde al prefisso CIDR se gli n bit iniziali dell'indirizzo e il prefisso CIDR sono gli stessi. Un indirizzo IPv4 è lungo 32 bit per cui da un prefisso CIDR di n bit rimangono 32 - n bit non corrispondenti, il che significa che 232 - n indirizzi IPv4 hanno n bit corrispondenti al prefisso del loro blocco CIDR. Prefissi CIDR più corti hanno corrispondenze con un maggior numero di indirizzi IP, mentre è vero il contrario per i prefissi CIDR più corti, che hanno corrispondenze con un numero inferiore di indirizzi IP. Nel caso di blocchi CIDR sovrapposti, un indirizzo può avere corrispondenze con più di un prefisso CIDR.

CIDR viene utilizzato anche per gli indirizzi IPv6 e la semantica della sua sintassi è identica. La lunghezza del prefisso può variare da 0 a 128 per via del numero maggiore dei bit che costituiscono l'indirizzo. Tuttavia, per convenzione, le subnet utilizzate sulle reti broadcast del livello MAC hanno sempre prefissi di lunghezza /64.[13] Prefissi più lunghi (/127) sono usati solo su alcuni link punto-punto tra router, per la sicurezza e altre ragioni amministrative.[14]

Assegnazione dei blocchi CIDR

modifica

La Internet Assigned Numbers Authority delega ai Regional Internet Registry la gestione di blocchi CIDR grandi, dal prefisso corto. IANA non alloca mai blocchi di dimensione più grande della /8, che contengono oltre 16 milioni di indirizzi. Ciascun RIR è responsabile dell'allocazione di tali blocchi in una singola, grande area geografica (un intero continente, ma ci sono delle eccezioni). Per esempio, i blocchi 2.0.0.0/8 e 62.0.0.0/8 sono solo due dei tanti amministrati da RIPE NCC, il RIR europeo. Blocchi di questa dimensione vengono suddivisi in blocchi di dimensione più piccola, quindi dal prefisso lungo, e assegnati ai Local Internet Registry (LIR). Lo stesso tipo di suddivisione può essere ripetuta dai livelli più bassi di delegazione, fino ad arrivare ai clienti finali che ricevono subnet dimensionate in base alle loro necessità a breve termine. Le reti di committenza servite da un singolo ISP sono incoraggiate da IETF ad utilizzare esclusivamente lo spazio di indirizzamento fornito dal loro ISP. Dall'altra parte, reti servite da ISP multipli possono ottenere spazio di indirizzamento indipendente dal provider direttamente dal RIR appropriato.

Per esempio, nel 1990 l'indirizzo 208.130.29.33, oggi riassegnato, era utilizzato da www.freesoft.org. Un'analisi di questo indirizzo identifica tre prefissi CIDR. 208.128.0.0/11 era assegnato da ARIN (il RIR del Nord America) a MCI. Automated Research Systems, un VAR del Virginia, aveva preso in affitto una connessione a Internet da MCI e gli era stato assegnato il blocco 208.130.28.0/22, in grado di indirizzare poco più di 1000 dispositivi. ARS utilizzava un blocco /24 per i suoi server accessibili dall'esterno, a cui 208.130.29.33 apparteneva. Tutti questi prefissi CIDR venivano usati in parti diverse della rete. Fuori dalla rete di MCI, il blocco 208.128.0.0/11 veniva usato per dirigere il traffico legato non solo a 208.130.29.33, ma anche a quasi altri due milioni di indirizzi IP con gli stessi 11 bit iniziali. Nei router della rete di MCI era elencato il blocco 208.130.28.0/22, al quale veniva diretto tutto il traffico destinato alla linea affittata da ARS. 128.130.29.0/24 veniva utilizzato dalla rete aziendale di ARS ed elencato esclusivamente dai suoi router.

Blocchi CIDR IPv4

modifica
Formato degli indirizzi Differenza

dall'ultimo indirizzo

Maschera Indirizzi Relativo

alla classe A, B, C

Restrizioni

su a, b, c e d (0..255 dove non specificato)

Uso tipico
Decimale 2n
a.b.c.d/32 +0.0.0.0 255.255.255.255 1 20 1⁄256 C Host route
a.b.c.d/31 +0.0.0.1 255.255.255.254 2 21 1⁄128 C d = 0 ... (2n) ... 254 Collegamenti punto-punto (RFC 3021)
a.b.c.d/30 +0.0.0.3 255.255.255.252 4 22 1⁄64 C d = 0 ... (4n) ... 252 Collegamenti punto-punto (glue network)
a.b.c.d/29 +0.0.0.7 255.255.255.248 8 23 1⁄32 C d = 0 ... (8n) ... 248 La più piccola rete multi-host
a.b.c.d/28 +0.0.0.15 255.255.255.240 16 24 1⁄16 C d = 0 ... (16n) ... 240 Piccola LAN
a.b.c.d/27 +0.0.0.31 255.255.255.224 32 25 1⁄8 C d = 0 ... (32n) ... 224
a.b.c.d/26 +0.0.0.63 255.255.255.192 64 26 1⁄4 C d = 0, 64, 128, 192
a.b.c.d/25 +0.0.0.127 255.255.255.128 128 27 1⁄2 C d = 0, 128 Grande LAN
a.b.c.0/24 +0.0.0.255 255.255.255.0 256 28 1 C
a.b.c.0/23 +0.0.1.255 255.255.254.0 512 29 2 C c = 0 ... (2n) ... 254
a.b.c.0/22 +0.0.3.255 255.255.252.0 1,024 210 4 C c = 0 ... (4n) ... 252 Piccola azienda
a.b.c.0/21 +0.0.7.255 255.255.248.0 2,048 211 8 C c = 0 ... (8n) ... 248 Piccolo ISP/ grande azienda
a.b.c.0/20 +0.0.15.255 255.255.240.0 4,096 212 16 C c = 0 ... (16n) ... 240
a.b.c.0/19 +0.0.31.255 255.255.224.0 8,192 213 32 C c = 0 ... (32n) ... 224 ISP/ grande azienda
a.b.c.0/18 +0.0.63.255 255.255.192.0 16,384 214 64 C c = 0, 64, 128, 192
a.b.c.0/17 +0.0.127.255 255.255.128.0 32,768 215 128 C c = 0, 128
a.b.0.0/16 +0.0.255.255 255.255.0.0 65,536 216 256 C = B
a.b.0.0/15 +0.1.255.255 255.254.0.0 131,072 217 2 B b = 0 ... (2n) ... 254
a.b.0.0/14 +0.3.255.255 255.252.0.0 262,144 218 4 B b = 0 ... (4n) ... 252
a.b.0.0/13 +0.7.255.255 255.248.0.0 524,288 219 8 B b = 0 ... (8n) ... 248
a.b.0.0/12 +0.15.255.255 255.240.0.0 1,048,576 220 16 B b = 0 ... (16n) ... 240
a.b.0.0/11 +0.31.255.255 255.224.0.0 2,097,152 221 32 B b = 0 ... (32n) ... 224
a.b.0.0/10 +0.63.255.255 255.192.0.0 4,194,304 222 64 B b = 0, 64, 128, 192
a.b.0.0/9 +0.127.255.255 255.128.0.0 8,388,608 223 128 B b = 0, 128
a.0.0.0/8 +0.255.255.255 255.0.0.0 16,777,216 224 256 B = A Il più grande blocco allocabile dalla IANA
a.0.0.0/7 +1.255.255.255 254.0.0.0 33,554,432 225 2 A a = 0 ... (2n) ... 254
a.0.0.0/6 +3.255.255.255 252.0.0.0 67,108,864 226 4 A a = 0 ... (4n) ... 252
a.0.0.0/5 +7.255.255.255 248.0.0.0 134,217,728 227 8 A a = 0 ... (8n) ... 248
a.0.0.0/4 +15.255.255.255 240.0.0.0 268,435,456 228 16 A a = 0 ... (16n) ... 240
a.0.0.0/3 +31.255.255.255 224.0.0.0 536,870,912 229 32 A a = 0 ... (32n) ... 224
a.0.0.0/2 +63.255.255.255 192.0.0.0 1,073,741,824 230 64 A a = 0, 64, 128, 192
a.0.0.0/1 +127.255.255.255 128.0.0.0 2,147,483,648 231 128 A a = 0, 128
0.0.0.0/0 +255.255.255.255 0.0.0.0 4,294,967,296 232 256 A L'intera Internet IPv4, rotta di default.

Nell'uso comune, il primo indirizzo di una subnet, con tutti i bit dell'host identifier impostati a 0, è riservato per riferirsi alla rete stessa, e viene chiamato talvolta network identifier. L'ultimo indirizzo, quello con tutti i bit dell'host identifier impostati a 1, viene usato come indirizzo di broadcast per quella rete. Questo diminuisce di 2 il numero di indirizzi effettivamente utilizzabili per gli host. Come risultato, un indirizzo /31, con un solo bit di host identifier, sarebbe inutilizzabile, perché questa subnet non avrebbe indirizzi disponibili dopo questa diminuzione. La RFC 3021 crea una eccezione alle regole bit host tutti a uno e bit host tutti a zero per rendere le reti /31 utilizzabili per i collegamenti punto-punto. Agli indirizzi /32 si può accedere solamente attraverso regole di routing esplicite, perché non c'è spazio per un identificatore di rete in tali indirizzi.

Nelle subnet più grandi di /32 e /31, il numero degli indirizzi disponibili viene solitamente ridotto di due, vale a dire l'indirizzo più grande, che è riservato come indirizzo di broadcast, e l'indirizzo più piccolo, che identifica la rete stessa.[15][16]

Blocchi CIDR IPv6

modifica

La dimensione più grande degli indirizzi IPv6 ha permesso l'implementazione dell'aggregazione delle rotte a livello mondiale e garantito spazi di indirizzamento sufficientemente grandi a ciascun sito. La dimensione standard delle subnet per le reti IPv6 è un blocco /64, che è obbligatoria per il funzionamento della stateless address autoconfiguration.[17] Inizialmente, IETF raccomandava come best practice nella RFC 3177 che a tutti i siti finali venisse allocato un blocco di indirizzi /48.[18] Tuttavia, le critiche e la rivalutazione delle necessità e pratiche attuali ha portato a delle raccomandazioni per un'allocazione più flessibile nella RFC 6177, suggerendo un'allocazione significativamente più piccola per alcuni siti, come un blocco /56 per le reti domestiche.

La seguente lista di riferimento per il subnetting IPv6 elenca le dimensioni per le sottoreti IPv6. A seconda del tipo di collegamenti potrebbero essere necessarie subnet di dimensioni differenti.[19] Le subnet mask separano i bit del network identifier dai bit dell'interface identifier. Selezionare una grandezza di prefisso inferiore comporta la copertura un numero minore di reti, ma con più indirizzi disponibili per ciascuna rete.[20]

2001:0db8:0123:4567:89ab:cdef:1234:5678
|||| |||| |||| |||| |||| |||| |||| ||||
|||| |||| |||| |||| |||| |||| |||| |||128     End-point singoli e loopback
|||| |||| |||| |||| |||| |||| |||| |||127   Collegamenti punto-punto (inter-router)
|||| |||| |||| |||| |||| |||| |||| ||124
|||| |||| |||| |||| |||| |||| |||| |120
|||| |||| |||| |||| |||| |||| |||| 116
|||| |||| |||| |||| |||| |||| |||112
|||| |||| |||| |||| |||| |||| ||108
|||| |||| |||| |||| |||| |||| |104
|||| |||| |||| |||| |||| |||| 100
|||| |||| |||| |||| |||| |||96
|||| |||| |||| |||| |||| ||92
|||| |||| |||| |||| |||| |88
|||| |||| |||| |||| |||| 84
|||| |||| |||| |||| |||80
|||| |||| |||| |||| ||76
|||| |||| |||| |||| |72
|||| |||| |||| |||| 68
|||| |||| |||| |||64   LAN Singola; lunghezza prefix minima per SLAAC
|||| |||| |||| ||60   Alcuni deployment 6rd molto limitati (/60 = 16 blocchi /64)
|||| |||| |||| |56   Dimensione minima per l'assegnazione ai siti finali;[19] e.g. home network (/56 = 256 blocchi /64)
|||| |||| |||| 52   blocco /52 = 4096 blocchi /64
|||| |||| |||48   Dimensione tipica assegnata ai siti più grandi (/48 = 65536 /64 blocks)
|||| |||| ||44
|||| |||| |40
|||| |||| 36  Possibili allocazioni ai Local Internet Registry (LIR) extra-small
|||| |||32   Allocazioni ai LIR minimum allocations
|||| ||28   Allocazioni ai LIR medium allocations
|||| |24   Allocazioni ai LIR large allocations
|||| 20   Allocazioni ai LIR extra large
|||16
||12   Allocazioni ai Regional Internet registry (RIR) da parte di IANA [22]
|8
4

Aggregazione dei prefissi

modifica

Il CIDR permette un'aggregazione a grana fine dei prefissi di rete. Per esempio, se i primi 20 bit dell'indirizzo corrispondono, sedici reti /24 contigue possono essere aggregate e annunciate come una rete più grande dal prefisso /20, con una singola voce nella tabella di routing. Questo riduce il numero di rotte che necessitano di essere annunciate.

  1. ^ (EN) Yakov Rekhter, Tony Li, RFC ft-rekhter-ipaddress-guide: An Architecture for IP Address Allocation with CIDR, su IETF Datatracker, 1º settembre 1993. URL consultato il 23 dicembre 2022.
  2. ^ a b (EN) Vince Fuller, Tony Li, Kannan Varadhan, Jessica Yu, RFC ft-fuller-cidr-strategy: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, su IETF Datatracker, 1º settembre 1993. URL consultato il 23 dicembre 2022.
  3. ^ (EN) RFC 943: Assigned numbers, su IETF Datatracker, 1º aprile 1985. URL consultato il 23 dicembre 2022.
  4. ^ (EN) Bob Hinden, RFC ft-ietf-iesg-cidr: Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR), su IETF Datatracker, 1º settembre 1993. URL consultato il 23 dicembre 2022.
  5. ^ a b (EN) Vince Fuller, Tony Li, RFC ft-ietf-grow-rfc1519bis: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, su IETF Datatracker, 31 agosto 2006. URL consultato il 23 dicembre 2022.
  6. ^ a b J. Mogul; J. Postel, eds. (August 1985). Internet Standard Subnetting Procedure. sec. 2.1. doi:10.17487/RFC0950. RFC 950., su datatracker.ietf.org.
  7. ^ Carl-Herbert Rokitansky, "Internet Cluster Addressing Scheme and its Application to Public Data Networks", Proc. 9th International Conference on Computer Communication (ICCC' 88), pp. 482-491, Tel Aviv, Israel, October/November 1988.
  8. ^ Re: Cluster Addressing and CIDR, su mailarchive.ietf.org. URL consultato il 23 dicembre 2022.
  9. ^ (EN) nanog: Re: Stupid Question maybe?, su seclists.org. URL consultato il 23 dicembre 2022.
  10. ^ (EN) nanog: Re: Stupid Question maybe?, su seclists.org. URL consultato il 23 dicembre 2022.
  11. ^ (EN) Bill Manning, Troy Pummill, RFC ft-rfced-info-pummill: Variable Length Subnet Table For IPv4, su IETF Datatracker, 1º dicembre 1995. URL consultato il 23 dicembre 2022.
  12. ^ (EN) Mark Kosters, Jasdip Singh, Scott Williamson, Koert Zeilstra, RFC ft-rfced-info-williamson: Referral Whois (RWhois) Protocol V1.5, su IETF Datatracker, 1º giugno 1997. URL consultato il 23 dicembre 2022.
  13. ^ (EN) B. Carpenter e S. Jiang, Significance of IPv6 Interface Identifiers, 2014-02, DOI:10.17487/RFC7136. URL consultato il 24 dicembre 2022.
  14. ^ (EN) M. Kohno, B. Nitzan e R. Bush, Using 127-Bit IPv6 Prefixes on Inter-Router Links, 2011-04, DOI:10.17487/RFC6164. URL consultato il 24 dicembre 2022.
  15. ^ J. Mogul, ed. (October 1984). Broadcasting Internet Datagrams in the Presence of Subnets. sec. 7. doi:10.17487/RFC0922. RFC 922., su datatracker.ietf.org.
  16. ^ F. Baker, ed. (June 1995). Requirements for IP Version 4 Routers. sec. 4.2.3.1. doi:10.17487/RFC1812. RFC 1812., su datatracker.ietf.org.
  17. ^ (EN) Dr Thomas Narten, Tatsuya Jinmei, Dr Susan Thomson, RFC ft-ietf-ipv6-rfc2462bis: IPv6 Stateless Address Autoconfiguration, su IETF Datatracker, 24 settembre 2007. URL consultato il 24 dicembre 2022.
  18. ^ (EN) IAB, RFC ft-iesg-ipv6-addressing-recommendations: IAB/IESG Recommendations on IPv6 Address Allocations to Sites, su IETF Datatracker, 1º settembre 2001. URL consultato il 24 dicembre 2022.
  19. ^ ARIN IPv6 Wiki, su www.arin.net. URL consultato il 24 dicembre 2022.
  20. ^ IP Allocation Rates, su web.archive.org, 3 febbraio 2011. URL consultato il 24 dicembre 2022 (archiviato dall'url originale il 3 febbraio 2011).

Voci correlate

modifica

Altri progetti

modifica

Collegamenti esterni

modifica