Skip to content

Quanto è grave l'esaurimento degli indirizzi IPv4?

Questa è la soluzione più valida che troverai da fornire, tuttavia, guardala attentamente e vedi se può essere adattata al tuo progetto.

Soluzione:

Soluzione 1:

È molto grave. Ecco un elenco di esempi di ciò che, per esperienza diretta, gli ISP consumer stanno facendo per combattere la carenza di indirizzi IPv4:

  • Ripetuti spostamenti di blocchi IPv4 tra le città che causano brevi interruzioni e ripristini della connessione per i clienti.
  • Ridurre i tempi di locazione DHCP da giorni a minuti.
  • Consentire agli utenti di scegliere se desiderano o meno la traduzione degli indirizzi di rete (NAT) sull'apparecchiatura di base del cliente (CPE), per poi attivarla retroattivamente per tutti.
  • Abilitazione del NAT sul CPE per i clienti che hanno già utilizzato l'opportunità di scegliere il NAT.
  • Riduzione del limite del numero di indirizzi MAC (Media Access Control) attivi simultaneamente applicato dal CPE.
  • Distribuzione di NAT di livello carrier (CGN) per i clienti che avevano un indirizzo IP reale al momento della sottoscrizione del servizio.

Tutte queste misure riducono la qualità del prodotto che l'ISP vende ai propri clienti. L'unica spiegazione sensata del motivo per cui si starebbero comportando in questo modo con i loro clienti è la carenza di indirizzi IPv4.

La carenza di indirizzi IPv4 ha portato alla frammentazione dello spazio degli indirizzi, che presenta molteplici difetti:

  • Spese amministrative che non solo costano tempo e denaro, ma sono anche soggette a errori e hanno portato a interruzioni.
  • Grande utilizzo della capacità della memoria indirizzabile al contenuto (CAM) sui router backbone, che qualche anno fa ha portato a un'interruzione significativa in diversi ISP quando ha superato il limite di un particolare modello popolare di router.

Senza NAT, oggi non potremmo farcela con i 3700 milioni di indirizzi IPv4 instradabili. Ma il NAT è una soluzione fragile che offre una connettività meno affidabile e problemi difficili da debuggare. Più strati di NAT ci sono, peggio sarà. Due decenni di duro lavoro hanno fatto sì che un singolo strato di NAT funzionasse per lo più, ma abbiamo già superato il punto in cui un singolo strato di NAT era sufficiente per aggirare la carenza di indirizzi IPv4.

Soluzione 2:

Prima di iniziare a esaurire gli indirizzi IPv4, non si usava (ampiamente) il NAT. Ogni computer connesso a Internet aveva il proprio indirizzo univoco globale. Quando il NAT è stato introdotto per la prima volta, è stato per passare dal dare ai clienti dell'ISP 1 indirizzo reale per ogni dispositivo che il cliente utilizzava/ possedeva a dare a un cliente 1 indirizzo reale. Questo ha risolto il problema per un po' di tempo (anni), mentre si pensava di passare all'IPv6. Invece di passare all'IPv6, (per lo più) tutti hanno aspettato che gli altri passassero e quindi (per lo più) nessuno ha lanciato l'IPv6. Ora ci troviamo di nuovo di fronte allo stesso problema, ma questa volta viene implementato un secondo livello di NAT (CGN) in modo che gli ISP possano condividere un indirizzo reale tra più clienti.

L'esaurimento degli indirizzi IP non è un grosso problema se il NAT non è terribile, anche nel caso in cui l'utente finale non abbia alcun controllo su di esso (Carrier Grade NAT o CGN).

Ma io sostengo che il NAT è terribile, soprattutto nel caso in cui l'utente finale non ne abbia il controllo. E (come persona il cui lavoro è l'ingegneria e l'amministrazione di rete, ma che ha una laurea in ingegneria del software), sostengo che distribuendo il NAT invece dell'IPv6, gli amministratori di rete hanno spostato il peso della soluzione dell'esaurimento degli indirizzi dal loro campo agli utenti finali e agli sviluppatori di applicazioni.

Quindi (secondo me), perché il NAT è una cosa terribile e malvagia che dovrebbe essere evitata?

Vediamo se riesco a rendergli giustizia spiegando cosa rompe (e quali problemi causa, a cui ci siamo talmente abituati da non renderci conto che potrebbe essere migliore):

  • Indipendenza dal livello di rete
  • Connessioni peer to peer
  • Denominazione e localizzazione coerente delle risorse
  • Instradamento ottimale del traffico, gli host conoscono il loro indirizzo reale
  • Tracciamento dell'origine del traffico dannoso
  • Protocolli di rete che separano dati e controllo in connessioni separate

Vediamo se riesco a spiegare ciascuno di questi elementi.

Indipendenza del livello di rete

Si suppone che gli ISP si limitino a far passare i pacchetti di livello 3 e non si preoccupino di cosa c'è nei livelli superiori. Che si tratti di TCP, UDP o di qualcosa di meglio/più esotico (SCTP forse? o anche qualche altro protocollo migliore di TCP/UDP, ma oscuro a causa della mancanza di supporto NAT), il vostro ISP non dovrebbe preoccuparsi die; tutto ciò dovrebbe apparire come dati per loro.

Ma non è così, non quando implementano la "seconda ondata" di NAT, il NAT "Carrier Grade". A quel punto dovranno necessariamente considerare e supportare i protocolli di livello 4 che si desidera utilizzare. Al momento, ciò significa praticamente che si possono usare solo TCP e UDP. Gli altri protocolli verrebbero bloccati o eliminati (nella maggior parte dei casi, secondo la mia esperienza) o inoltrati all'ultimo host "all'interno" del NAT che utilizza quel protocollo (ho visto un'implementazione che lo fa). Anche l'inoltro all'ultimo host che ha usato quel protocollo non è una vera soluzione: non appena due host lo usano, si rompe.

Immagino che ci siano alcuni protocolli sostitutivi di TCP e UDP attualmente non testati e non utilizzati proprio a causa di questo problema. Non fraintendetemi, TCP e UDP sono stati progettati in modo impressionante ed è sorprendente come entrambi siano stati in grado di adattarsi al modo in cui utilizziamo Internet oggi. Ma chissà cosa ci siamo persi? Ho letto di SCTP e mi sembra una buona idea, ma non l'ho mai usato perché era poco pratico a causa del NAT.

Connessioni peer to peer

Questa è una cosa importante. In realtà, il più grande secondo me. Se avete due utenti finali, entrambi dietro il proprio NAT, non importa quale dei due cerchi di connettersi per primo, il NAT dell'altro utente lascerà cadere il suo pacchetto e la connessione non avrà successo.

Questo riguarda i giochi, le chat vocali/video (come Skype), l'hosting dei propri server, ecc.

Esistono delle soluzioni. Il problema è che queste soluzioni costano tempo agli sviluppatori, tempo e disagi agli utenti finali o costi di infrastruttura del servizio. Inoltre non sono infallibili e a volte si rompono. (Si vedano i commenti di altri utenti sull'interruzione di servizio subita da Skype).

Una soluzione è il port forwarding, in cui si programma il dispositivo NAT per inoltrare una specifica porta in entrata a un computer specifico dietro il dispositivo NAT. Esistono interi siti web dedicati a questa operazione per tutti i diversi dispositivi NAT esistenti. Vedere https://portforward.com/. Questo in genere costa all'utente finale tempo e frustrazione.

Un altro workaround consiste nell'aggiungere alle applicazioni il supporto per cose come l'hole punching e nel mantenere un'infrastruttura server che non sia dietro un NAT per introdurre due client NATed. Questo di solito costa tempo di sviluppo e mette gli sviluppatori nella posizione di dover potenzialmente mantenere l'infrastruttura del server dove non sarebbe stato necessario in precedenza.

(Ricordate cosa ho detto a proposito della distribuzione di NAT invece che di IPv6, spostando il peso del problema dagli amministratori di rete agli utenti finali e agli sviluppatori di applicazioni)?

Denominazione/localizzazione coerente delle risorse di rete

Poiché all'interno di un NAT viene utilizzato uno spazio di indirizzi diverso da quello esterno, qualsiasi servizio offerto da un dispositivo all'interno di un NAT ha più indirizzi da raggiungere e quello corretto da utilizzare dipende da dove il client vi accede. (Questo rimane un problema anche dopo aver fatto funzionare il port forwarding).

Se si dispone di un server Web all'interno di un NAT, ad esempio sulla porta 192.168.0.23 porta 80, e il dispositivo NAT (router/gateway) ha un indirizzo esterno di 35.72.216.228, e si è impostato il port forwarding per la porta TCP 80, ora si può accedere al server Web utilizzando sia la porta 192.168.0.23 porta 80 O la porta 35.72.216.228 80. La scelta dipende dal fatto che ci si trovi all'interno o all'esterno del NAT. Se ci si trova all'esterno della NAT e si utilizza l'indirizzo 192.168.0.23, non si riuscirà a raggiungere la destinazione desiderata. Se ci si trova all'interno della NAT e si utilizza l'indirizzo esterno 35.72.216.228, non si potrà raggiungere la posizione prevista. potrebbe arrivare dove si vuole, se l'implementazione del NAT è avanzata e supporta le forcelle ma il server web che serve la richiesta vedrà la richiesta come proveniente dal dispositivo NAT. Ciò significa che tutto il traffico deve passare attraverso il dispositivo NAT, anche se c'è un percorso più breve nella rete dietro il NAT, e significa che i log del server web diventano molto meno utili perché elencano tutti il dispositivo NAT come origine della connessione. Se l'implementazione del NAT non supporta l'hairpin, non è possibile arrivare dove ci si aspettava di arrivare.

Il problema si aggrava non appena si utilizza il DNS. Improvvisamente, se si vuole che tutto funzioni correttamente per qualcosa ospitato dietro un NAT, si dovranno dare risposte diverse all'indirizzo del servizio ospitato all'interno di un NAT, in base a chi lo chiede (AKA split horizon DNS, IIRC). Che schifo.

E tutto questo presuppone che ci sia qualcuno che conosca bene il port forwarding, l'hairpin NAT e lo split horizon DNS. E gli utenti finali? Che possibilità hanno di configurare correttamente tutto questo quando acquistano un router consumer e una telecamera di sicurezza IP e vogliono che "funzioni"?

E questo mi porta a:

Instradamento ottimale del traffico, host che conoscono il loro vero indirizzo

Come abbiamo visto, anche con un hairpin NAT avanzato il traffico non scorre sempre attraverso il percorso ottimale. Questo anche nel caso in cui un amministratore esperto configuri un server e disponga di hairpin NAT. (Certo, lo split horizon DNS può portare a un instradamento ottimale del traffico interno nelle mani di un amministratore di rete).

Cosa succede quando uno sviluppatore di applicazioni crea un programma come Dropbox e lo distribuisce agli utenti finali che non sono specializzati nella configurazione di apparecchiature di rete? In particolare, cosa succede quando inserisco un file da 4 GB nel mio file di condivisione e poi cerco di accedervi sul computer successivo? Il file viene trasferito direttamente tra le macchine o devo aspettare che venga caricato su un server cloud attraverso una connessione WAN lenta e poi aspettare una seconda volta che venga scaricato attraverso la stessa connessione WAN lenta?

Per un'implementazione ingenua, verrebbe caricato e poi scaricato, utilizzando come mediatore l'infrastruttura server di Dropbox che non si trova dietro un NAT. Ma se le due macchine si rendessero conto di essere sulla stessa rete, potrebbero trasferire direttamente il file molto più velocemente. Quindi, per il nostro primo tentativo di implementazione meno ingenua, potremmo chiedere al sistema operativo quali indirizzi IP(v4) ha la macchina e poi verificarlo con altre macchine registrate sullo stesso account Dropbox. Se è nello stesso intervallo, trasferiamo direttamente il file. Questo potrebbe funzionare in molti casi. Ma anche in questo caso c'è un problema: il NAT funziona solo perché possiamo riutilizzare gli indirizzi. Cosa succede se l'indirizzo 192.168.0.23 e l'indirizzo 192.168.0.42 registrati sullo stesso account Dropbox si trovano in realtà su reti diverse (come la rete di casa e quella di lavoro)? A questo punto si deve tornare a utilizzare l'infrastruttura del server Dropbox per fare da mediatore. (Alla fine, Dropbox ha cercato di risolvere il problema facendo sì che ogni client Dropbox trasmettesse sulla rete locale nella speranza di trovare altri client. Ma queste trasmissioni non attraversano i router che si trovano dietro il NAT, il che significa che non è una soluzione completa, soprattutto nel caso di CGN.)

IP statici

Inoltre, poiché la prima carenza (e l'ondata di NAT) si verificò quando molte connessioni dei consumatori non erano sempre attive (come le connessioni dial-up), gli ISP potevano fare un uso migliore dei loro indirizzi assegnando indirizzi IP pubblici/esterni solo quando si era effettivamente connessi. In questo modo, quando ci si connetteva, si otteneva qualsiasi indirizzo disponibile, invece di ottenere sempre lo stesso. Questo rende molto più difficile la gestione del proprio server e lo sviluppo di applicazioni peer to peer, perché devono fare i conti con i peer che si spostano invece di avere indirizzi fissi.

Offuscamento dell'origine del traffico dannoso

Poiché il NAT riscrive le connessioni in uscita come se provenissero dal dispositivo NAT stesso, tutti i comportamenti, buoni o cattivi, sono racchiusi in un indirizzo IP esterno. Non ho visto nessun dispositivo NAT che registri ogni connessione in uscita per impostazione predefinita. Ciò significa che, per impostazione predefinita, l'origine del traffico dannoso passato può essere rintracciata solo dal dispositivo NAT attraverso il quale è passata. Mentre le apparecchiature di classe enterprise o carrier possono essere configurate per registrare ogni connessione in uscita, non ho visto nessun router consumer che lo faccia. È interessante vedere se (e per quanto tempo) gli ISP terranno un registro di tutte le connessioni TCP e UDP effettuate attraverso i CGN man mano che li introdurranno. Tali registri sarebbero necessari per gestire le denunce di abuso e le denunce DMCA.

Alcuni pensano che il NAT aumenti la sicurezza. Se lo fa, lo fa attraverso l'oscurità. L'abbandono predefinito del traffico in entrata che il NAT rende obbligatorio è lo stesso che avere un firewall stateful. Mi risulta che qualsiasi hardware in grado di eseguire il tracciamento delle connessioni necessario per il NAT dovrebbe essere in grado di eseguire un firewall stateful, quindi il NAT non merita alcun punto.

Protocolli che utilizzano una seconda connessione

Protocolli come FTP e SIP (VoIP) tendono a utilizzare connessioni separate per il controllo e il contenuto effettivo dei dati. Ogni protocollo che fa questo deve avere un software di aiuto chiamato ALG (application layer gateway) su ogni dispositivo NAT che attraversa, o aggirare il problema con qualche tipo di mediatore o hole punching. Nella mia esperienza, gli ALG sono raramente o mai aggiornati e sono stati la causa di almeno un paio di problemi che ho avuto a che fare con SIP. Ogni volta che sento qualcuno riferire che il VoIP non ha funzionato perché l'audio funzionava solo in un modo, sospetto immediatamente che da qualche parte ci sia un gateway NAT che rilascia pacchetti UDP di cui non riesce a capire cosa fare.

In sintesi, il NAT tende a rompersi:

  • protocolli alternativi a TCP o UDP
  • sistemi peer-to-peer
  • accesso a qualcosa ospitato dietro il NAT
  • come SIP e FTP. Gli ALG per aggirare questo problema causano ancora oggi problemi strani e casuali, soprattutto con SIP.

In fondo, l'approccio a strati che lo stack di rete adotta è relativamente semplice ed elegante. Se si cerca di spiegarlo a qualcuno che non conosce le reti, è inevitabile pensare che la propria rete domestica sia probabilmente una rete semplice da capire. In un paio di casi ho visto che questo ha portato a idee piuttosto interessanti (eccessivamente complicate) sul funzionamento del routing a causa della confusione tra indirizzi esterni e interni.

Sospetto che senza NAT, il VoIP sarebbe onnipresente e integrato con la rete PSTN, e che effettuare chiamate da un telefono cellulare o da un computer sarebbe gratuito (a parte l'internet che si è già pagato). Dopotutto, perché dovrei pagare per il telefono quando io e voi possiamo semplicemente aprire un flusso VoIP a 64K e funziona bene come la rete PSTN? Sembra che oggi il problema numero 1 nell'implementazione del VoIP sia il passaggio attraverso i dispositivi NAT.

Sospetto che di solito non ci rendiamo conto di quanto molte cose potrebbero essere più semplici se avessimo la connettività end-to-end che il NAT interrompe. Le persone si inviano ancora i file via e-mail (o con Dropbox) a causa del problema fondamentale della necessità di un mediatore per quando due client sono dietro NAT.


Soluzione 3:

Un grande sintomo dell'esaurimento dell'IPv4 che non ho visto menzionato in altre risposte è che alcuni fornitori di servizi mobili hanno iniziato a utilizzare solo l'IPv6 diversi anni fa. È possibile che stiate usando l'IPv6 da anni e non lo sappiate nemmeno. I fornitori di servizi di telefonia mobile sono nuovi nel mondo di Internet e non dispongono necessariamente di enormi allocazioni IPv4 preesistenti da cui attingere. Inoltre, richiedono un numero maggiore di indirizzi rispetto al cavo/DSL/fibra, perché il telefono non può condividere un indirizzo IP pubblico con altri membri della famiglia.

Credo che i fornitori di IaaS e PaaS saranno i prossimi, a causa della loro crescita che non è legata agli indirizzi fisici dei clienti. Non mi sorprenderebbe vedere presto i fornitori di IaaS offrire solo IPv6 a prezzi scontati.


Soluzione 4:

I principali RIR hanno esaurito lo spazio per le normali allocazioni qualche tempo fa. Per la maggior parte dei provider, quindi, le uniche fonti di indirizzi IPv4 sono le proprie scorte e i mercati.

Ci sono scenari in cui è preferibile avere un IPv4 pubblico dedicato, ma non è assolutamente indispensabile. Esiste anche un gruppo di indirizzi IPv4 pubblici che sono stati assegnati ma che non sono attualmente in uso sulla rete Internet pubblica (potrebbero essere in uso su reti private o potrebbero non essere affatto in uso). Infine, ci sono reti più vecchie con indirizzi allocati in modo molto più lasco del necessario.

I tre maggiori RIR consentono ora la vendita di indirizzi sia tra i loro membri che ai rispettivi membri. Quindi abbiamo un mercato tra organizzazioni che hanno indirizzi che non utilizzano o che hanno indirizzi che potrebbero essere liberati ad un costo, da un lato, e organizzazioni che hanno davvero bisogno di più indirizzi IP, dall'altro.

Ciò che è difficile da prevedere è la quantità di domanda e offerta che ci sarà ad ogni punto di prezzo e quindi l'andamento del prezzo di mercato in futuro. Finora il prezzo per IP sembra essere rimasto sorprendentemente basso.


Soluzione 5:

Idealmente, ogni host su Internet dovrebbe essere in grado di ottenere un indirizzo IP di portata globale, ma l'esaurimento degli indirizzi IPv4 è reale, infatti l'ARIN ha già esaurito gli indirizzi nel suo pool libero.

Il motivo per cui tutti possono ancora accedere ai servizi Internet è grazie alle tecniche di Network Address Translation (NAT) che consentono a più host di condividere indirizzi IP pubblici. Tuttavia, ciò non avviene senza problemi.

Sezione recensioni e valutazioni



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.